On Sep 25, 2008, at 1:03 AM, Simon Aquilina wrote:
I think either jms or remote ejbs will do what you want with no infrastructure/middleware coding on your part.
I'm not entirely sure you are using "asynchronous" in its usual meaning. With (asynchronous) jms you'd have a thread in client A that would send a message. As soon as it is sent the thread will get control again (before the message is delivered) and can continue with other work. The message could be received by an MDB B which would process it and possibly send one or more messages in response, to any destination. A could have another thread listening for responses on this destination, or the original thread could listen (and block) waiting for a resonse.
If (as your diagram indicates) you want A to receive a response before continuing with other work, I think EJBs alone will do what you want. A would look up in jndi an ejb business interface and would call appropriate methods on it. The ejb (B) would process the message (method call arguments) and return the response. If A is not a java client you can use CORBA to communicate with a (java) ejb, although this is not the easiest thing to get working ever invented.
Another option if you need looser coupling is jaxws web services which among other things can provide access to ejbs, where the request and response messages are xml documents. This is a rather large subject to try to describe in an email however.
In my experience j2ca outbound connectors are mostly useful when you need to communicate with a system you have little control over such as an existing database or messaging system. If you are writing both the client and server there is almost always a more convenient, flexible, and easier solution.
Hope this is helpful