I have a project that I am just getting started on. Unfortunately, I don't think that we'll be able to use WebSphere 5 on this release, as I don't think that the organization will support upgrading to it.
With the lack of a message driven bean, I was curious as to how others have accomplished asynchronous processing using JMS and EJBs? I was thinking that I will probably have to launch some message listeners from servlets inside of WebSphere which will then dispatch out to session EJBs. Any thoughts on this?
The product will conceivably run in a WebSphere cluster. Any advice that you can give me on this?
You are in for some fun =)
IBM supports what they call messaging beans in 4.0, and only in their Enterprise Edition. Although you can make it work with the Advanced Edition. Its basically a session bean that implements the Message Listener interface ... If you are planning to use WebSphere MQ / MQ Series, persistent message performance suck’s, big time. As far as clustering, its a little hokey too. SonicMQ DOES NOT WORK with WebSphere ( just a little tidbit of info ).
If you can't use a WebSphere startup class, then maybe having the listeners in a bean with application scope could work. ... depends on what you are doing, clustering etc...
A very simple alternative, not involving strange features of your app-server: Build a stand-alon Java application (with main method) and let that application register a listener to the queue.
When a message arrives, the application just calls a Stateless SessionBean. If you call the method on the SLSB onMessage() you are quite well prepaired for EJB 2.0 :-)
With this solution, you may run into transaction problems. So be a bit careful with error handling. On the other hand, this will be true for most non-EJB solutions to this problem!
Tomas Inger wrote:
>A very simple alternative, not involving strange features of your app-server
Yes, that's important from the portability point of view. But if you are willing to bend that a little, you can make the JMS subscriber a startup class. That way, all the components involved run within the same JVM.
Good idea :-)
But note that the start-up classes are outside the EJB specification. On the other hand, how often do you change application server? In real life!!