Article: Message Driven Beans and J2EE Connectors

Discussions

News: Article: Message Driven Beans and J2EE Connectors

  1. J2EE 1.4 has improved our lives with respect to Message Driven Beans, JMS, and J2EE Connector Architecture. Debu Panda has written about the new features available to us, and how you can implement applications using them.

    Using a JMS Provider with MDBs via the J2EE Connector Architecture

    James Strachan has pointed out "if you're gonna demonstrate the nice new features of J2EE 1.4, it'd be a good idea to use the nice & clean polymorphic API in JMS 1.1 (Connection, Session, MessageProducer, MessageConsumer) rather than having to use all those Queue* and Topic* classes."
  2. True, EJB 2.1 is better than 2.0 but for JMS usage it has still taken a superbly flexible and powerful API (JMS) and restricted it with typical EJB constraints. Even with 2.1 it is not possible for example to dynamically define message selectors, an immensely powerful way of implementing and Observer/Observable pattern.

    Using an asynchronous messaging API like JMS is a great way to make your distributed applications scalable. Just look at the way any modern windows framework (Swing, Motif, MS Windows etc.) is implemented, for complex distributed tasks you need asynchronous messaging, the same extends to complex server-side applications. MDBs and J2EE CA are too heavyweight, as complexity scales up we will find it harder and harder to implement the solutions with these tools. Moore's law is working a lot quicker than Sun's J2EE specs, worse still they want to make EJB 3.0 backwards compatible. I'm still a strong J2EE fan but I don't hold out much hope for the long term future of MDB in their current state.

    JavaSpaces on the other hand...

    -John-
  3. True, EJB 2.1 is better than 2.0 but for JMS usage it has still taken a superbly flexible and powerful API (JMS) and restricted it with typical EJB constraints. Even with 2.1 it is not possible for example to dynamically define message selectors, an immensely powerful way of implementing and Observer/Observable pattern.Using an asynchronous messaging API like JMS is a great way to make your distributed applications scalable.
    Agreed. Though you don't have to use JMS 1.1 inside an EJB container if you don't want to. Using JMS inside EJB only really helps if you're doing XA transactions with JMS and other resources. The core parts of the JMS 1.1 API: Session, MessageProducer, MessageConsumer are all pretty simple & easy to use - its just unfortunate that using JMS inside EJB is hard & complex.

    FWIW the next version of Spring (1.1 in July) should include a nice & simple JmsTemplate class which mirrors the JdbcTemplate & JdoTemplate classes to make working with JMS both inside lightweight containers and inside EJBs much easier to use - then your code will work irrespective of your deployment container.

    I'd like to go further than this and have a really simple to use, lightweight POJO based container for JMS applications - where the lightweight container injects the Session, MessageConsumer, MessageProducer into your POJO and you don't need to worry about all the EJB restrictions etc. Kinda like Message Driven Objects rather than Message Driven EJBs (MBDs). Some lightweight container along these lines might one day end up in Spring (if I ever get the time to hack something like this together :)

    I wonder if the EJB3 crowd will try make a simpler model for working with JMS - as there's really no reason to why it has to be this hard?

    James
    ActiveMQ
  4. I'd like to go further than this and have a really simple to use, lightweight POJO based container for JMS applications - where the lightweight container injects the Session, MessageConsumer, MessageProducer into your POJO and you don't need to worry about all the EJB restrictions etc. Kinda like Message Driven Objects rather than Message Driven EJBs (MBDs). Some lightweight container along these lines might one day end up in Spring (if I ever get the time to hack something like this together :)I wonder if the EJB3 crowd will try make a simpler model for working with JMS - as there's really no reason to why it has to be this hard?
    Hi James,
       I think Rod's Spring framework is a much better approach than MDBs however the idea of a POJO like MDO sounds very attractive and if it needs someone to "hacking together" you're the man to do it! There's also no reason why it can't retain the XA compliance, perhaps we should speak off line and come up with a new lightweight asynchronous messaging framework, ActiveMQ and Geronimo of course would be the reference implementation. Fancy a pint this evening?

    -John-
  5. I'd like to go further than this and have a really simple to use, lightweight POJO based container for JMS applications - where the lightweight container injects the Session, MessageConsumer, MessageProducer into your POJO and you don't need to worry about all the EJB restrictions etc. Kinda like Message Driven Objects rather than Message Driven EJBs (MBDs). Some lightweight container along these lines might one day end up in Spring (if I ever get the time to hack something like this together :)I wonder if the EJB3 crowd will try make a simpler model for working with JMS - as there's really no reason to why it has to be this hard?
    Hi James,   I think Rod's Spring framework is a much better approach than MDBs however the idea of a POJO like MDO sounds very attractive and if it needs someone to "hacking together" you're the man to do it! There's also no reason why it can't retain the XA compliance, perhaps we should speak off line and come up with a new lightweight asynchronous messaging framework, ActiveMQ and Geronimo of course would be the reference implementation. Fancy a pint this evening?-John-
    What with England losing in the football I sure do :)

    Lets take the drinking details offline - but yes absolutely a POJO based MDO framework could certainly be fully XA compliant and work with other XA resources and use automatic transaction demarcation like Spring. Or if no other non-JMS resources are used we could just use the lightweight JMS transactions.

    We can reuse all the Spring transaction stuff - but just provide the POJO / MDO functionailty and hide the user from the gory details of pooling JMS connections / sessions and transaction enlistment etc.

    James
    ActiveMQ