JSR 153: Enterprise Java Beans 2.1 posted to JCP

Discussions

News: JSR 153: Enterprise Java Beans 2.1 posted to JCP

  1. The Enterprise JavaBeans 2.1 specification extends the existing Enterprise JavaBeans 2.0 specification with new features, including support for JAXM message-driven beans, enhancements to EJB QL to support aggregate and other operations, support for linking of messaging destinations, support for web services usages within EJB, and a container-managed timer service.

    Read JSR 153: EJB 2.1

    Improvements include:

    * Support for the use of Message-Driven Beans with JAXM messaging.
    * Enhancements to EJB QL
    * Support for Linking of Message Destinations
    * Timers
    * Support for Web Services Usages

       What does everyone think? Is this enough?

    Floyd

    Threaded Messages (17)

  2. Glad to see some of these changes. Would it be nice to have a Message Driven Bean dynamically bind to a destination, instead of having to hard code one. Does the Linking of Destinations help there... will it allow you to consume from multiple destinations instead of just one?


  3. There is actually nothing in the EJB2.0 spec that *limits* MDB's to just one destination.

    The only thing in the spec related to destination is the optional message selector in the deployment descriptor.

    The actual implementation of message destination connection and message selector is up to the appserver vendor - and it just so happens that most of them have chosen a static, single-destination, single-selector implementation.

    I think that there might be limitations in the JMS spec when in comes to ServerSessionPools (which is perhaps what most appservers use underneath) - but I havent read it in enough depth to be sure - maybe someone else can shed some light on this vague part of the JMS spec.

    Having said all that - I agree with you, in that I think that the future EJB spec *SHOULD* definitely specify how dynamic subscriptions/connections are handled as well as subscriptions/connections to multiple topics/queues.

    Until then, we need to put pressure on the vendors until they support more dynamic MDB's. I certainly lobby anyone who will listen ;)
    We have a large requirement for this when connecting to a Reuters market data flow. There are vast numbers of topics and the topics (stocks) you are interested in changes dynamically. Dynamic MDB's would be very attractive to banking and finance application builders.

  4. <quote>
    There is actually nothing in the EJB2.0 spec that *limits* MDB's to just one destination.
    </quote>

    The DTD clearly states that an MDB can only have one destination. If you want to use the same class but make it a listener to two different destinations, you will have to deploy two different MDB's.

    Note that a tool such as EJBGen can make it easier to develop these "multi-faced" EJB's: define the common tags in base classes and specialize your MDB's in subclasses. But I'm digressing.

    <quote>
    The actual implementation of message destination connection and message selector is up to the appserver vendor
    </quote>

    Not really. The MDB is expected to behave like a normal JMS listener. If you specify a message selector in its deployment descriptor, then the listener will be declared to JMS with that same message selector. The container merely acts as a proxy, it doesn't interpret any of the JMS-related settings, it simply forwards them to underlying the JMSConnection.

    <quote>
    Having said all that - I agree with you, in that I think that the future EJB spec *SHOULD* definitely specify how dynamic subscriptions/connections are handled as well as subscriptions/connections to multiple topics/queues.
    </quote>

    I can see the interest in doing that but keep in mind that EJB is a static component model specification. One of the main assumptions is that all the information the EJB's need to run are known at deployment time. It is unlikely that the EJB specification will evolve in the sense that you demand.

    That being said, all hope is not lost: what this means is simply that you need to use another API to achieve your goal, and this other API is JMX. JMX is as dynamic as EJB is static.

    I don't want to dive too much into details, but basically, I would solve your problem by having a separate JMX application that takes care of undeploying/deploying MDB's as they are needed, possibly modifying their deployment descriptors on the fly. You get the idea.


    --
    Cedric




  5. >> The DTD clearly states that an MDB can only have one
    >> destination. If you want to use the same class but make
    >> it a listener to two different destinations, you will
    >> have to deploy two different MDB's

    Where in the spec is this stated? I have been looking for it...

    I had this same discussion about 2 months ago (with Tyler Jewel) but at THAT time I was under the same impression as you are.
    I thought that MDB's were limited to purely static JMS connections but I was convinced otherwise. I have looked quite a bit in the spec but I havent found anything that specifically limits MDB's to 1 connection/subscription - though a few books that have recently been written, talk about this limitation (in fact, one you were involved in ;).

    As far as I can see, in the DTD, the message-selector is optional... and the message-driven-destination is only used to specify whether it is a queue or a topic...
    The language used to describe the element doesnt refer to destinations in the plural sense but that is about as strong as it gets.
    (BTW, I unofficially understand that a certain appserver will support somewhat dynamic/multiple connections some time in the near future)

    Anyway, I would be happy to know where in the spec it is defined/limited.

    >> Not really. The MDB is expected to behave like a normal
    >> JMS listener. If you specify a message selector in its
    >> deployment descriptor, then the listener will be
    >> declared to JMS with that same message selector. The
    >> container merely acts as a proxy, it doesn't interpret
    >> any of the JMS-related settings, it simply forwards them
    >> to underlying the JMSConnection

    Again, if my understanding is correct (and in this case I might not be) you cannot have a simple JMS listener driving an MDB... Well you CAN, but you would not have any parallel message processing because a TopicSession or a QueueConnection is single threaded. Therefore you dont receive a new message until you acknowledge the previous one (or the onMessage method returns) - meaning you would lose concurrent message processing which is one of the main scalability benefits of MDB's.
    Please let me know if I have got the wrong end of the stick ...


    >> I can see the interest in doing that but keep in mind
    >> that EJB is a static component model specification. One
    >> of the main assumptions is that all the information the
    >> EJB's need to run are known at deployment time. It is
    >> unlikely that the EJB specification will evolve in the
    >> sense that you demand.

    I dont know if I agree (about the static component model part) but in any case, losing the basic abilities that vanilla JMS gives you (like multiple/dynamic subscriptions message selectors) is quite a loss if that is the way MDB's are destined to stay.
    In the end, I am not too sure if it isnt the JMS spec that needs to change...


    -Nick
  6. Not really. The MDB is expected to behave like a normal

    >> JMS listener. If you specify a message selector in its
    >> deployment descriptor, then the listener will be
    >> declared to JMS with that same message selector. The
    >> container merely acts as a proxy, it doesn't interpret
    >> any of the JMS-related settings, it simply forwards them
    >> to underlying the JMSConnection

    ... Actually, regarding JMS, Cedric, I think I mis-understood your point the first time around - so you can probably ignore my reply above.

    What you are saying is that the container just uses the settings provided (via a DD presumably) to connect to the JMS provider.

    I guess my point is that the DD where the destination(s) are defined is the appserver specific DD - hence it is the appserver's "implementation".

    Also, if ServerSessionPools are used for concurrent processing of messages - again this an appserver implementation.

    -Nick
  7. Sun/JCP also posted an accompanying JSR 154: Servlet API 2.4 which is also to address Web service related issues: deployment modularity and security and others (see Java Skyline, Server News).


    Regards,

    Rich



  8. Heck no. How many folks want the thread manager exposed to your beans? How many of you are tired that the startup classes are not documented in the standard?

    (Who else thinks putting query languages on top of real-time messaging middleware is unneeded bloatware? Just asking.)
  9. They are so boring with their stupid/complex persistent layer: Entity Beans.
    Why don't they go for JDO.. it's so much easier !

    OR
  10. I am glad to see timers get mention. This has been proprietary to the application server or some third party vendor. It will be nice to write platform independent code that makes use of timing functionality...
  11. With respect to the web services integration ... this is something we are trying to do on a client site at present for an enhancement to their product.

    Now there is little point in going ahead with the project if the spec. (and hence I trust the major vendors) will be there in the near future.

    Does anyone have any sort of idea of when we can see J2EE1.4 and EJB2.1 finalised?
  12. Logging, JSR 149, JSR 150
  13. Some issues I'd like to see resolved:

    - Entity bean enhancements such as optimistic locking support for CMP beans (version column etc.).

    - Timer or scheduling services via timer activated beans.

    - Am I correct in thinking the current finders only accept a string literal for an 'IN' expression ? I'd like to bulk load a list of entity beans by primary key. So at runtime I'd provide a list of primary keys to the finder (or ejbSelect) method. Is this missing or have I misinterpreted the spec ?

    - Auditing. Has anyone seen any products to help in this area ? I'd like to turn auditing on for a set of beans and keep track of inserts, updates, deletes etc, along with the principal that made the change. Ideally be able to choose the audit data source (may be even message based). I'd prefer to accomplish this in a database independent fashion and without polluting the data model.


    Darren
  14. Auditing: I generally push this to the data server. Actually a good use for DB triggers. But it's not the best pattern in the world: you should be able to recognize class method invocations (and undo the effect of those).

    So, a method dispatcher that registers object state before/after; keeps persistant until a commit? Where does it persist; how does it undo actions done on services that do not subscribe to this pattern? E.g., JMS messages to batch systems. Tremendous fun :-(
  15. HOw about refining the integration of JAAS for authentication? Like what the Group name is the Container uses, support for n-value login forms, portable means for binding the authenticated user into the container.
  16. I would also support the need for Optimistic Control.

    In addition to that implementing almost all of
    sql functions in EJBQL would be definitely useful.

    Instead of specifying query, I hope it can also take the
    name of stored procedure and link it to the Entity beans.
    There is a certain amount of risk attached to it, but
    existing applications would benefit from it.

    In existing applications, there are multiple sources
    which changes the database on a regular basis including
    batch jobs, other applications apart from EJBs.
    It would be immensely helpful if the changes in database
    can also be propogated to EJBs using triggers, JMS ..
    This would keep cache updated.

  17. CMP Entity should be able to manage their persistence
    by invoking stored procedures.
    It would be much more performant !
  18. My immediate concerns are with 2.0 CMP:

    1) Give me support for polymorphic relationships, i. e., allow A is related to B when B is an abstract base class.

    2) Allow CMR for the remote interface, i. e., allow remote clients to navigate entity relationships, too.

    3) Need a way to interpose validation logic in container-generated setters, i. e., if an attribute can't be null, the setter should throw an exception if passed null.

    More to follow, I'm sure.

    -Peris