JMS callbacks
What is the best way to get this going
EIS tier (legacy server written in C++, COM) wants to send callback notification to EJB.
EJB Client -> Stateless EJB Server -> JCA -> Legacy Server
Would the best way be to have MDB and have a resource adapter that Legacy Server can use to publish messages, and have a MDB receive messages from the RA. The MDB can then push these messages to EJB clients that are wishing to be notified.
Related to that: if have a bunch of stateless EJBs and let's say this MDB, how to manage clients that wish to get notified. Would the MDB have to maintain a list of interested clients that wish to get notified when a specific async operation on the legacy server completed?
[742 byte] By [
SRama] at [2007-10-2 10:36:41]
It might simplify things if you just used JMS as the messaging backbone to communicate from the C++ world and the Java world; using queues for requests and topics for notifications, then you can handle all communication using one technology, JMS, which is then easier to manage and monitor (rather than having EJB clients, EJB servers, JNDI servers, COM<->EJB bridges, MDBs and RAs).
If you went that route, you'd just need to use JMS or MDBs in the Java world and find a C/C++ API for your JMS provider. e.g.
http://activemq.org/C+Integration
or if you are on windows with C++/COM you could maybe use .Net on the legacy server
http://activemq.org/dot+Net
James
http://logicblaze.com/
I will lookinto activemq shortly.
If you can answer this question for me, it will help me evaluate activemq in the scenario given below.
Now here is the question.
We have a EJB client -> EJB Server (MiddleTier) -> C++/COM (Legacy Server EIS Tier)
Since I am designing the server side beans in the middletier, what might the best way to expose the callbacks to the client? Because let's say we make a asynchronous call to the C++/com server. IT executes and on completion it sends a notification to the JMS consumer sitting in the middle-tier. Since I am designing server-side ejb beans, these beans in turn might be consumed by other EJBs, or Servlet clients. They possibly require a event notification.
So would this make sense
Servlet (client) -> EJB (server-side beans) -> JCA -> C++/COM
1) servlet requests a async operation via EJB business method. EJB returns a request ID for future use and EJB invokes server side operation via JCA
2) servlet requests a call back notification using request id (provides some sort of JMS end point). Essentially uses the queue to express interest. At this point do we need to have some sort of JMS provider running in the middletier? I presume so. The servlet will essential make a request to the JMS provider in the middletier for notification (based on request id).
3) C++/COM uses .net to topic for notifying middletier upon task completion
4) middletier notifies servlet client.
The question is do I need to have two hops for this notification. From C++/com to JMS provider in middletier, and the JMS provider in turn notifies the client?
c++/com notifies jms provider in middletier
middletier jms provider then notifies ejb clients (like servlets etc that have expressed interest).
thanks
SRama at 2007-7-13 2:40:01 >
Why are you asynchronously notifying a servlet? If thats the same servlet thread (http request) as started the operation, you might as well just use a blocking operation on the EJB.
In terms of C++/com to JMS; if you host your JMS broker inside the JVM of the EJB container then there is no hop; it has the same network hops as if you were talking directly over sockets. But the JMS option gives you deployment options to use separate brokers if you need to (depending on how many EJB containers you have).
James
http://logicblaze.com/
I want to expose some functionality which has a async behaviour like running stored procedures. You really don't want the client to block on a request that can take 1 hr or even 6-7 hours depending upon the nature of the stored procedure. Imagine some stored procedure doing data replication etc..just an example.
If the servlet has other things to do call x(), then call y(), it can possibly do some parallel flows meanwhile and not wait for this operation. The servlet can possibly exit after the async operation has completed and move on to other processing (that we will know once the call back comes thru). Or it could be as simple as the servlet using the callback to notify the customer via email that requested operation has completed.
The whole idea is that the servlet uses the EJB as a means to get access to stored procedure logic, it requests this async operation, then it moves on to doing other things. The Legacy tier that executes the stored procedure needs to inform its clients that the stored procedure is complete. In this it was the EJB that initiated it on behalf of the servlet. Then the EJB perhaps needs to notify its clients...it is a chained notifcation. If you think this model is bad, and we should consider using a JMS broker let me know.
The point about servlet block is a choice the client of the EJB has to make: whether they want to poll or not wait.
Can you also elaborate on what you mean by hosting the JMS broker inside the JVM of EJB?
thanks very much James..
SRama at 2007-7-13 2:40:01 >
since it is an ejb exposing this asynch operation, it is hard to predict how a potential client might use the call (synchronous or asynchornous) and need to support both models. Also given the nature of the call (call to some stored procedure which might take any amt of time to complete), I need to support a programming model where I can expect the client (another eJB, a servlet, some java standalone program) to be alive for that long (some sort of daemon for e.g. continuosly alive and can receive the notification for e.g, in which case this daemon possibly publishes a JMS connection point that the EJB can call into).
I too thought of this blocking call, but it defeats the purpose of having async operation.
SRam
SRama at 2007-7-13 2:40:01 >
If you want the servlet to just kick off some work and not wait for it to be completed, just send a JMS message to a queue for some other process to complete the work.
If you want to wait for some work to be completed but not all of it, call an EJB synchronously then get the EJB to send a JMS message for the asynchronous work to be completed.
I don't follow why you'd want an async communication mechanism back to the servlet; just use a blocking synchronous call if you want; or make all the work asynchronous (via say JMS).
In terms of running a JMS broker inside the same JVM of the EJB container - most pure Java based JMS providers should be able to be hosted inside the same JVM as your EJB container. e.g.
http://activemq.org/How+do+I+embed+a+Broker+inside+a+Connection
James
http://logicblaze.com/
>> I don't follow why you'd want an async communication mechanism back to the servlet; just use a blocking synchronous call if you want; or make all the work asynchronous (via say JMS).
Well the only thing I want is a notifcation back from the server legacy tier to the actual client that initiated the async operation. Was the operation successful or not? if it failed why?
If the servlet initiated the asynch operation, wouldn't it want to be notified about the process completion status (instead of making the servlet poll for the status). Any thoughts?
SRama at 2007-7-13 2:40:01 >
