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?
Thanks,
Michael
-
JMS and WebSphere (4 messages)
- Posted by: Michael Collins
- Posted on: September 10 2002 13:28 EDT
Threaded Messages (4)
- JMS and WebSphere by Travis Kay on September 10 2002 16:54 EDT
- JMS and WebSphere by Tomas Inger on September 11 2002 02:37 EDT
-
JMS and WebSphere by Ravi Shankar on September 11 2002 02:37 EDT
- JMS and WebSphere by Tomas Inger on September 13 2002 08:24 EDT
-
JMS and WebSphere by Ravi Shankar on September 11 2002 02:37 EDT
- JMS and WebSphere by Tomas Inger on September 11 2002 02:37 EDT
-
JMS and WebSphere[ Go to top ]
- Posted by: Travis Kay
- Posted on: September 10 2002 16:54 EDT
- in response to Michael Collins
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...
Regards,
TLK.
-
JMS and WebSphere[ Go to top ]
- Posted by: Tomas Inger
- Posted on: September 11 2002 02:37 EDT
- in response to Travis Kay
Hi!
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 -
JMS and WebSphere[ Go to top ]
- Posted by: Ravi Shankar
- Posted on: September 11 2002 14:37 EDT
- in response to Tomas Inger
Hi,
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.
- Ravi -
JMS and WebSphere[ Go to top ]
- Posted by: Tomas Inger
- Posted on: September 13 2002 08:24 EDT
- in response to Ravi Shankar
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!!
/Tomas