Hi All,
I'm working on integrating a messaging product (MQ) with our application server. More specifically, I'd like to have servlets running in an appserver to call programs on a mainframe thru a messaging mechanism like MQ. I'm considering using JMS to accomplish vendor independence.

Now, I've seen JMS implementations in Java being offered by quite a few vendors with sample pgms etc. I've not seen any using EJBs. Now, my question is "Is it possible to have an EJB living on my appserver taking requests from servlets and in turn routing this thru a JMS interface to the MQ provider?" I don't see any issue here since the route would be something like:
servlet->stateless session bean (EJB)->{JMS}->JMS impl/wrapper on MQ->--->channel->--->mainframe MQ->message handler.

However, I'm just wondering (given the restrictions on EJB programming like "no threads" etc), if there are any problems with this design. Also, my premise of using an EJB is no sacred cow - shoot it down if you think it is a bad idea.

I'd also like to confirm if the EJB->{JMS}->JMS Impl is a feasible solution or there are some hidden issues here.

I'm planning to use Bea WebLogic 5.1 & IBM MQSeries as my appserver & MQ - however, I'd like to keep this open since I want to keep it vendor neutral.

Please share your ideas & if you have any leads/pointers to this configuration, please post it too!
Thanks!
--Das

did u look through the EJB2.0 specs.I think the whole process will become a lot simpler.

now to what u said "Is it possible to have an EJB living on my appserver taking requests from servlets and in turn routing this thru a JMS interface"
yes u can do so.just use weblogic startup classes along with JMS(preferably asynchronous mode)
hope this helps.
kt

Yeah, I see that EJB2.0 makes it easier with the message driven bean. But how tough does this make implementing it on EJB1.1? Since 2.0 is still a way out ... I'd like to explore the possibility in 1.1.
Thanks for your suggestion. I'll take a closer look at WebLogic docs.
--Das

Hi all,
It looks like it is possible to make a call from EJB to a third party MQ thru the JMS interface (EJB 1.1). However, the story is different for a reverse call. In EJB 2.0, we have the message bean to handle the return call from a JMS queue. Any ideas on how one could handle this in 1.1 since we don't have the luxury of the message bean?

Also, I understand that WebLogic keeps updating it's container with EJB2.0 public draft specs. Any idea when a final spec will be approved (both by Sun & also the corresponding container).

Has any one else tried using an existing JMS implementation to make calls from Weblogic to MQSeries & back?
Thanks!
--Das

Hi Pratap,

We use JMS and MQ a lot but not EJB. I am surprised to read that you can not have your own thread inside your session bean that will take the incomming request and create the message and send it to another system. Now if you have only one message request to send then you may send then message with the info where you will wait for the reply(using correlation type id). You don't need multiple Thread for that. Anyway bottom line is try. Note that in this case it is a sync. message.


Rabi

Hi Rabi,
Thanks for your reply. I cannot start a thread in a session bean because one is not supposed to do *any* thread synchronization in an EJB (since it may conflict with the container which handles thread management.) Another issue is that there is no guarantee that by the time the MQ returns with the resultQueue, the initiating EJB is not already passivated. If so, the messages will remain in the queue forever(?). Only the container can activate the bean back to life.

Well, one architecture that I've found people using is to post/send the request using EJB to the Queue Manager. Now a separate standalone Java application (which can spawn threads) keeps looking the resultQueue. Once the queue detects messages, it receives them & then makes a call to the EJB (thru the container just like any client pgm) & pass these messages as parameters.

I'd really appreciate it if someone could corroborate this architecture. If there are better alternatives, please do suggest them.
Thanks,
--Das

I designed and implemented a messaging framework (both synch and asynch calls) using ATG Dynamo and Oracle AQ. Unfortunatelly the Oracle implementation of JMS over their proprietary AQ API was unacceptably slow, so I decided to use the Java AQ API. ATG Dynamo allows you to define services within its component architecture and I had to fully design and implement the framework for message dispatching, queue connection pooling, response handling (using correlation IDs as someone correctly pointed out). I am using normal Java threading and some Oracle AQ features regarding message expiration and exception handling.

It was a good experience designing this, but as I said, I could fully use the Java threading. It seems a bit ridiculous to have to completely separate the messaging outside of the application server just because of the threading issues. Unfortunatelly I have no experience with the Bea server. There must be another way to do this.

Thank you all for this discussion about using EJBs w/ JMS. I wanted to confirm what someone said earlier, that is, that it is possible to implement stateless session bean JMS message providers for asynch and synch communication. we did not encounter any special issues when we did so. The issue of using EJB 1.1 compliant stateless session beans as JMS message consumers is interesting though. Someone pointed out that this is could be difficult since the bean implementation can not be handled directly. This is what we are finding too. Fiorano have a suggested framework at there sight. We were considering using a bean/servlet proxy for the message consumer that would receive messages on behalf of the consumer EJB. What do you think about this?

Hi,
I'm interested in knowing what architecture you used to implement the 'asynch' version of your SSBean+JMS integration. Specifically, does your SSBean ever get an acknowledgement about the success or failure of your messaging? Also, how do you handle the exceptions?

I infer that your 'synch' implementation would be something like : SSBean posts a message on the queue managed by JMS. It then goes into a QueueReceive mode & waits for the return queue to be filled. Is this right? If not could you also explain your synch implementation too?
Thanks very much.
--Das

HI Das
   We have designed a JMS System with EJB 1.1 . In Asynchrounous Communication mode we need to maintain seperate Queues for Request and Response. A Job Processor which is a stand alone java application keeps polling the queue and Updates with the response. The Job Processor will get the Response from the Session bean and updates the Response Queue. Clients can query the Response Queue for the Status of Job/Process.

Hi Karunakar,
Thanks for your comment. Your solution for the Aysnchronous communication is interesting. You have a standalone class polling the return queue & then notifying the bean when a request arrives ... hmm ... Now, in your design do all your messages use the same request & reply-to queue? If not, how is the reply-to queue name communicated to this standalone class by the bean(s)? Also, do you spawn a new thread from this standalone class for each client which sends a request message?
Thanks in advance,
--Das

hello,
I agree with your architecture. In EJB 1.1 it is perfectly possible to send JMS messages within a session (or entity) bean. It is also possible to SYNCHRONOUSLY receive a JMS
message within a bean (receive method on the MessageConsumer called in the bean method). However, if you need to asynchronously receive a message within a bean, then you need to use a Message-Driven Bean, which is only available in EJB2.0. If you do not have message-driven beans, then your solution is correct, having a non EJB component, which is a JMS client waiting for messages, and which will invoke your EJB component on message reception; however, in this case, be careful that your message reception will not occur within a transaction handled by the EJB server, which may be the case with message-driven beans.
In the JOnAS opensource EJB platform, we have implemented the EJB1.1 JMS capabilities, and it is now possible to send or synchronously receive JMS messages in a bean method within the scope of a global transaction (e.g. sending a message and writing a database may be two operations belonging to a same transaction).

Best Regards,

François

Thanks François, for validating the design. I had not thought of the transaction of the asynchronous receive part - I'll keep that in mind.

--Das

Hello François,

   Currently, I am doing an application server replacement project. The current one in use is home-grown and based on Orbix. The application server, wrapping host transactions, provides services for different channels like wap banking, mobile banking and internet banking. We have made a design decision to prioritise requests from different channels and time-out those requests in case the host cannot cope with voluminous traffic. In order to do this, we are evaluating the possibility of inserting a message queue between clients and the application server so that we can put control on client requests. Although the asynchronous communication capability of messaging solution has been touted very much, it seems to me we have to do some synchronous messaging between application server clients and the server itself. So I want to know if there is any serious performance impact of this kind of design (synchronous messaging). Could you please share some experience with me about constructing this kind of system if you have any? Thank you very much.

Best regards,
CK

Hmmm.

this is a mjor problem I have. I want to be able to have a session bean send a request to JMS, have a reciever then delegate a method call to t athird party across a socket and the return e the reponse via a temporary queue back to the session bean.

Problem is that a message is only sent to a queue on a commit.

Hi,

We have done something very similar to what you are trying to do. We have a IBM MQ wrapper which is called by EJBs to send messages to our back-end (a COBOL program), but we are using WebShpere appserver. A few points to make:

1. Initially we are using MQ JMS wrapper which is provided by IBM. We couldn't get it work by calling the wrapper directly from EJBs. The problem seems that MQ JMS implementation is not thread safe. Once we made the wrapper as a RMI object, it works fine.
2. We eventually ended up using MQ Java API instead of MQ JMS API as advised by IBM consultants. They don't have confidence with their JMS implementation, also seems that they don't like JMS standard at all. We have been supplied a custom-made wrapper by IBM and they reckon we can call the wrapper directly from EJBs. They demo a sample and it seems work. But we have doubt if they would work properly in a real world, as they definitly ignor the EJBs spec that no threads would be created inside EJBs. So we need more testing.

Hope this would give you some useful information.

Cheers,
Faith Huang

Thanks, Faith, for your very useful mail. This is exactly the kind of info I've been looking for!
In our case, we're trying to do the same thing - i.e call a COBOL program via the MQJMS. The appserver is Weblogic, though.

I did not realize that the MQJMS is not threadsafe! Since JMS is part of the J2EE specs, it is unbelievable that they did not check out the EJB requirements while implementing MQJMS. So, how did you go about RMI wrappering the product? Did you register it on your Appserver's JNDI or was it in a separate JVM itself? Any information on this would be most appreciated.

Is the MQJava threadsafe? Is that why they fell back on it instead of JMS?

Thanks once again for your comments. Hope to hear more details on your solutions to these issues.
Regards,
--Das

Faith,

Thank you for the interesting posting. We are currently working on a system similar to the ones you and Das are building, except that we are using iPlanet App Server instead of WebSphere or WebLogic.

Regarding the issue of thread-safety and MQ-Series JMS: could you please make clearer what you mean?

The documentation that we have says that Connection is thread-safe, but Session, MessageProducer and MessageConsumer are not thread-safe. If that documentation is correct then the thread-safety problem is inconvenient, but not a disaster for us.

But if your experience has been that Connection is not thread-safe either then that is very serious and we would very much like to hear about that.

Thank you,

Sean Broadley
SolNet, New Zealand

A late addition to this thread I know. But given the obvious need to understand how to bind both JMS and EJB together I thought I'd add my "biased" view.

One of the problems is staying vendor neutral. You might choose MQSeries or TIBCO or someother vendor's messaging. But you still need industrial strength supported JMS wrappers to ensure that you can reuse the existing MoM infrastructure with, in particular, new EJB apps.

I would suggest that you take a peek at SpiritSoft's offering in this domain. There is a wealth of info on the website (www.spirit-soft.com) including on-line help with examples.

Although clearly a vendor, the core engineering folks have delivered many systems in the past and so are perhaps more aware of what it takes to build and deliver a real system that solves real problems.

Just my tuppence worth ....

Steve Ross-Talbot

Hi,
supposing a SLSB method is being used to receive messages from a Topic synchronously (using subscriber.receive(timeout)), will this create any problems as far as the requirement that session should not be accessed by multiple threads is concerned ? If there are many simultaneous users wanting to receive messages from the same Topic, each will have its own instance of the SLSB, so I guess that this scenario would work, but I am not sure if somehow in a scenario like this any thing could go wrong specially with respect to simultaneous access from many clients.....
any pointers are appreciated....

regards,
farhat
 

Steve Ross-Talbot,

Can you give me the architecture using SpiritWave product of Spirit Soft within the App Server and Messaging product?

Is it that JMS drivers of spiritWave will replace the actual JMS adapters/drivers provided by the App Servers, and EJB should call the spiritWave JMS drivers?


Senthilnathan

Faith,

I agree with you. I think there is a problem with the WebSphere JMS implementation. We did a small prototype exercise using Sun Solaris 7 with 512MB RAM, WebSphere 3.5, IBM JMS adapter for WebSphere, Visual Age 3.5, IBM XML Parser,MQSeries 5.1 Server.

We tried to put a XML document into the Local queue using JMS. When we did so, we encountered some exceptions. IBM was called who then said that it could be problem with the installation or memory.

In the meantime we called WebLogic who converted all the EJBs developed for WebSphere using Visual Cafe and ported them on the Sun Solaris 7 with 512 MB and WebLogic Server 5.1. A demo was also given.

Now IBM is breaking their head with new Solaris 7, 1GB RAM.

Any way we are waiting for further Info.

If any of those reading my info can give me more info about JMS behaviour between WebSphere & WebLogic Servers.

Regards

Senthilnathan

Can you please elaborate on MQ JMS implementation- not thread safe.


Dshah

All,

I was tasked recently with replacing a session bean call to a class that spawned threads, since the EJB spec states that only the container can thread.

We had a stateless session bean calling a standard Java class provided by a third party. This class started its own threads and so as it was running in the same VM was deemed to break the spec.

We decided to use JMS to send the method call to the client class.

Now the session bean accepts a method call as normal but instead of calling the third party client directly it now sends a message to a JMS queue and then synchronously awaits a resposne before returning a response to the client.

It achieves this by marshalling the method call and sending this as the message body of an ObjectMessage. ObjectMessage can only accept one object so we set the first element as the method name and the parameters as subsequent elements.

We also set the JMSReplyTo message header to a temporary queue so that the receiver can respond to this queue directly, avoiding the use of apparently expensive selectors and the non-specified JMSMessageIDs.

A separate receiver process running in a separate VM monitors the queue. When a message is receieved the method name, parameters and temporay queue are extracted. A huge if statement extracts the parameters based on the method name and the calls the third party class and then sends the response back to the temporary queue.

The waiting stateless session bean returns the results to the client.

The first issue we hit was that messages are not sent to a queue until a transaction is committed so this caused a deadlock with the session bean and reciever.

we were lucky in that all of our methods were read only so we simply set the tansaction attribute to NOT_SUPPORTED and everything worked.

I do not not know how this would be resolved when you required the request/response to occue in an EJB tx.

A

Hi ,
it is possible to integrate JMS with EJBs. The only problem using the bean as a message Listener (beacuse of threads , activation , passivation, etc). Otherwise it is perfectly fine to post/publish a message to a topic in weblogic server . You only need take of one thing is that You obtain a connection to a topic post a message and close the connection innediately.
All these problems have been solved in the version EJB.2.0.
sudershan vellore

Hi,

1) Which JMS implementation are you talking about? IBM have informed us that MQ-JMS "isn't supported for use in EJB's. It violates the constraints set for EJB's whether in point-to-point or publish-subscribe." We're still not clear on whether they mean "don't use MessageListeners" or "just don't do anything".

2) Why close the connection immediately? Would a static reference to a started connection (or a singleton) cause some thread violation? Opening and closing JMS Connections is heavy-weight.

3) Event-driven MessageListeners are clearly out (since "event-driven" implies "uses threads"). But what about QueueRequesters or QueueReceivers - ie using the synchronous JMS MessageConsumers instead of the asynchronous MessageListener? (Here it gets odd, because calling suspend() or wait() on a thread is illegal in an EJB container, but blocking on network I/O is legal.)

Sean Broadley

Hi,
There are no limitations in a EJB publishing JMS Messages.

BUT , An EJB CANNOT be made to receive a JMS Message asynchronously since this results in the invocation of the Bean methods directly. By definition, an EJB can only be accessed through its remote interface. The EJB's container is responsible for managing and invoking all calls on the Bean. Since the EJB container manages transactions as well as thread safety operations of the Bean, direct access to the bean's method is restricted, since this can result in a potentially catastrophic operation. EJB's cannot be used to create a JMS message listener to asynchronously receive messages, as this would result in the invocation of the Bean methods directly.


Sudershan Vellore

MQ-Series is not supported by IBM for use in an EJB container.

The IBM support people have informed us that the MQ-Series implementation of JMS does "just about all" of the things you are not allowed to do in an EJB container, including calling native code, managing threads, accessing files, etc.

This, according to IBM, applies to any use of MQ-JMS. Sending, receiving, anything. We are surprised and disappointed that the extensive documentation which comes with MQ-Series makes no mention of this problem. They spend over 500 pages talking about Java interfaces for MQ series but never mention this.

They also said that it "might work", depending on how rigorously the application server enforces the restrictions on what you can do in an EJB container. We're not keen on a solution which is unsupported, violates the specifications, but "might work".

Since we had relied on (at least!) the ability to SEND messages via JMS from inside our EJB container, we're rather upset.

Sean

Sean,
But aren't the same kind of operations (eg. calling a native library, etc) performed by, say, a JDBC driver? Does that mean that we cannot do bean managed persistence unless the driver is 100% Java with *absolutely* no native calls?

What about logging from a bean? We have to have a File I/O at some point of time in order to do this. So, where do we draw the line on "following the specs"?

I was reading a similar discussion somewhere & some opinions suggested that for "real-time" solutions, we may have to work-around some of these restrictions - for instance having helper classes/libraries do the file i/o rather than the bean itself (though essentially the file i/o is done from the same JVM.)

What's your opinion on this?
--Das

Das,

You're asking two perceptive questions that both deserve careful replies, so I'll reply in two posts.

First: Why do I complain about JMS-MQ breaking the rules about native code, etc, when my JDBC driver also breaks those rules?

The answer is "because those rules don't apply to the JDBC code". My commonsense view as that dealing with databases is an EJB1.1 AppServer's job, but dealing with JMS isn't. The EJB1.1 spec backs up that commonsense view.

According to the EJB 1.1 spec the code which implements the JDBC API is part of the job of the "Container Provider" (ie, the App Server's job). There are no programming
restrictions on what the Container Provider can do - they can use threads, native code, etc, as much as they want.

In the real world (as opposed to the spec) the provider of the AppServer need not provide the implementation of the JDBC code - they can instead tell me what third party database drivers they support, or set standards for what those drivers have to be like and let me pick one which meets the AppServer's standards. That's fine with me, I think that meets their responsiblities as a "Container Provider".

But providing something which implements the JMS API is not the job of the "Container Provider". So the JMS code is the responsibility of the "Bean Provider" (the "Bean Provider" is you and me - the people developing the applications). The familiar code restrictions for EJBs (no thread management, no file I/O, etc) are actually the restrictions set down in the EJB1.1 spec on what the Bean Provider's code is allowed to do.

So the EJB spec backs up my commonsense view that dealing with databases is part of and EJB1.1 container's job, but dealing with JMS isn't. So I expect the people who provided my App Server (who happen to be iPlanet) to deal with issues regarding compatibility with database drivers and to be able to tell me what is compatible and what is not (within reason). But because dealing with JMS isn't part of the EJB1.1 container's job, I don't expect iPlanet to deal with issues regarding compatibility with JMS providers.

I have logged a question with iPlanet and I'll be very pleased if they can tell me things about compatibility of iPlanet App Server's EJB container with JMS-MQ. But since it's not the EJB container's responsibility to deal with JMS I won't blame them if they can't help.

This changes, of course, with EJB2.0. It's not just that MessageBeans appear - also JMS becomes part of the Container Provider's responsibilities.

Sean

Das,

You asked for my opinion about file I/O for logging, etc.
Be warned that asking for my opinion on a quiet Sunday afternoon when I have spare time will get you a lot of reply.

First, You don't need to do file I/O for logging. You can log to a database (or there are other options - eg to a remote object). You also don't need to use file I/O for configuration information (which seems to be the other main use of file I/O from app servers). It's quite possible to write real-world real-time applications that follow the EJB spec.

But I'm a pragmatist. My opinion is that the solution you should use always depends on what your problem is like. You might not have the resources to be able to achieve all of: on time, on budget, fast, reliable, and matching J2EE specs. If you aren't meeting the specs that give two problems (1) it may not be reliable, (2) it may not be portable.

Encapsulating your violations of the rules in helper classes won't make your code any more reliable. But it will make it easier to fix if it doesn't work, and it will make it easier to fix to make it portable.

I've ported a J2EE application from one AppServer to another. Some violations of standards had occurred in the application, and we had to change them to get it to work on the other AppServer. When those violations had been well encapsulated in one helper class they were easy to change. But when a violation of standards occurred in many places fixing it was much less pleasant.

Sean

i gained a lot from the messages u people posted. it seams that u people can help me out. in the architecture that we are trying to build, SSBean sends a JMS message and this message is to be sent in the same transaction context as of the ssbean.

trax attribute for the ssbean is required. what is happening is, when the client to the bean does not passes a transaction context then offcourse ssbean initiates one for itself but the JMS message is not linked to this transaction at all. what i mean is, even if the JMS fails to send the message, then also the database updates are committed.

in the other case when the client initiates the transaction before invoking the method on ssbean(javax.transaction.UserTransaction) then the JMS follows the ideal path ; i.e. database updates are committed only when the message goes across.

thanks in advance.

manish

Hello Sudershan,
I would appreciate if you could explain in a bit more detail why an asynchronous JMS message invokes directly a Bean method and not the remote interface?

-Enric

Hi Das,

did ou figure this out? I am also looking for something similar. If you have a solution, could you pass thin to me also

anil_k_d at yahoo dot com

Anil,
What is your environment? Depending on the vendor & version, you may have better options available today that 6 months ago :-)

--Das