Hi, We're in the process of migrating an app that is based on C++ and CORBA to J2EE.
We have this simple design right now, that goes like this. - Stateless Session bean is the facade that clients use to doWork() - doWork() + creates a stateful EJB to hold results (resultBean) + sends a msg to different JMS queues, each responsible for doing different work, passing along a handle to the resultBean - When JMS queue workers finish, they send the results in a resultMsg to a JMS result queue hosted by the EJB container - A MDB onMessage() fires within the EJB container an then sends the result to the resultBean via its handle This means that the resultBean must be multithreaded and, therefore, must use synchronization. I've read through the "Opinion: EJB Limitations. Can you break them? Can you not?" on TSS, and from what I can tell, using any form of synchronization in the EJB, or any object it might delegate to, is non-compliant. The remark that made this hit home for me was Message #104977 by Bill Burke where he states: "My beef with EJB's is that there is no concept of a service. Multi-threaded objects that can retain state. " Seems like our design would be very common and so how does one go about achieving this in a compliant way? Thanks for any suggestions, Mike =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
