Synchronous communication from sessio bean to JMS consumer


EJB design: Synchronous communication from sessio bean to JMS consumer

  1. What is the best way to set up asynchronous communication from a stateless session bean to a consumer through JMS? I have read about using the JMSCorrelationID to place the producing message id in and then have the original producer then receieve based on a selector which uses the correlation id. If this is the standard approach, is it beter to have one queue or one for the requests and one for the responses? Are there are problems with having the producer then consume messages? Finally what is the best way to marshall the method calls? A method on my session bean is called and I need to delegate the method call through JMS. I have looked at the different message types and there is a MAPMessage which allows name value pairs and then another method that accepts a serializable object. Presumably this means the only way to send the parameters is to extract the individual values and use the Maop message - it seems a bit messy having to unpack the method call.

    Thanks in advance
  2. Aaron-

    I have an implementation of this with a stand alone Java client in the next release of the MDB chapter. I'm hoping to get that release out in the next couple of days. I'm implementing the JMS consumers as MDBs and a stand alone Java client as the request/response mechanism. You could take my Java client and implement it as a stateless session bean.

    There are some issues with doing this architecture and they mostly rely around security issues. There is no security around WHO can register a message selector so you could have a malicious client get your messages.

    Something to be careful about, however: if you send a message and want to do a blocking receive in the same method, make sure you COMMIT the JMS transacted session after you send the message but before you do the blocking receive. Otherwise, the message will never be flushed from the buffer and you will be waiting for a response that will never come. I've seen many, many people run into this problem when they use container-managed transactions.

  3. You don't have to pass parameters using the map message, you can put things in the message header, and the selector should work on those as well.



    PS. If you do use MapMessage, I think it is (sadly) lacking a Date get and set. :-/