I was reading an article on Sun's website It says that A message-driven bean has no state for a specific client, but its instance variables can contain state across the handling of client message, including an open database connection and an object reference to an EJB object
From my understanding, the client application must also locate in the server where MDB is located. Then, inside the client application, I create a MDB object and call its onMessage() method to check messages and determine the owner of the message?
Please let me know if my understanding is not correct
Originally posted by Allen Springers: From my understanding, the client application must also locate in the server where MDB is located.
No, the client must know where the queue for the MDB is. It doesn't have to know anything about the MDB.
Originally posted by Allen Springers: Then, inside the client application, I create a MDB object and call its onMessage() method to check messages and determine the owner of the message?
It sounds like your mixing MDB code with EJB code, but I could be wrong. In general, the message should contain information about who sent it or in the case that it doesn't, you can encode that information in the header (not the content) of the message before sending to the MDB.
I still don't understand what any of this has to do with state. Every time an MDB gets a message off the queue, it can just decode the header (or if needs to the content) to determine where the message came from. Generally you only want an MDB decoding the content if its going to do something with it. A lot of times, though, MDBs are placed as routing mechanisms in which they read the header and then pass to a session bean. [ October 24, 2007: Message edited by: Scott Selikoff ]
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com