EJB design: Integrate C batch with Java using JMS - Design issue
- Posted by: andres bernasconi
- Posted on: October 15 2004 09:03 EDT
i'm trying to connect a C application to an EJB using JMS.
This is the scenario:
A have a service A exposed as an SLSB. This service is currently in use and provides functionality needed by a C Batch program.
I want the Batch program to execute some methods of the SLSB so i thought of this aproach: create a JMS queue. Create a Message-driven Bean (MDB) that listens to that queue. Let the C batch program send messages to that queue.
The MDB is just a proxy (another interface) to the Service A.
Decouple as much as possible the batch C program from Java.
What is the best way to map JMS messages to real Service Methods.
For instance: C Batch sends a MapMessage with pairs like MethodName/doTheJob, param1/aValue, param2/anotherValue, etc. That would mean i want to execute ServiceA.doTheJob(aValue, anotherValue).
Thanks in advance
- Integrate C batch with Java using JMS - Design issue by James Strachan on October 16 2004 03:39 EDT
- Integrate C batch with Java using JMS - Design issue by andres bernasconi on October 16 2004 15:29 EDT
- Integrate C batch with Java using JMS - Design issue by Bill de h?ra on October 17 2004 11:28 EDT
- Integrate C batch with Java using JMS - Design issue by Raymond Henry on October 17 2004 12:29 EDT
Depending on your JMS provider you may have a proprietary C interface you can use to talk to the JMS provider. Though that does tie your C into a specific JMS provider.
Another approach is to use a REST API to the JMS provider. This allows you to send messages from C via a simple HTTP POST which are then delivered to the JMS Queue allowing you to use MDBs, transactions, load balancing and dead letter queues in Java land, but a simple lightweight HTTP POST in C. (There are lots of open source C libraries for doing HTTP POST). e.g.
Then probably use XML for the payload.
Enteprise Open Source
Very good info there. But that solves only the messaging part of my problem, and ends where my design issue begins. Once i receive a message from my C Batch program y need to "map" it to a real BO method, wich could need parameters. What is the BEST way to do this mapping?
I thought of some solutions but i dont think they are the best...
a) Implement Command Pattern.
The problem with this is that the C code is coupled to the Java Code. I dont want to change code in C when i change code in Java. Beside i will need a command object for each possible method exposed.
b) Use plain nested if's
Receive a MapMessage where "method" receives the method name. According to the "method" parameter do a nested-if block, one for each method exposed. The problem with this is that it's hard to maintain.
c) Generic Execute Class
I was thinking maybe it could be an approach like the b) option...but instead of nested if's have a Factory that maps names to classes, configured externally in an XML File.That file could also have parameter name dictacting wich type of variable is wich... The problem here is making all the parameter-type acknowledging and coding every parsing possibility. To think: what about object parameters?
I am pretty sure there are better aproaches around and thats why im asking for assistance..
again any help is apreciated.
Once i receive a message from my C Batch program y need to "map" it to a real BO method, wich could need parameters. What is the BEST way to do this mapping?
James' answer still stands. Expose the C code to URLs only. Each URL maps to an invocation on the bean(s) or a JMS queue. Parameters can be passed in a GET query string as the body of a POST.
For example: I've solved something like your problem with a abstract servlet that takes in the dispatch mappings as a configuraton and passes the data onto either a JMS queue or a bean. Each "service" is then provided by subclassing that servlet - note that the subclass is itself empty and does no work, but doing it this way allowed specifying the backend mapping and the service URL via web.xml. Aside from getting the configuration mechanism nearly for free, it was all nicely self-documenting, and new services could be deployed by running a script. Finally, neither client or service had a clue about each other's implementation details, their contract was URL driven.
Beyond that you'd need to say more about the specifics of your project -ie is either the Java or the C legacy code that can't be changed, whether the C code is expected a repsonse, whether you can even use a servlet/http - there are a number of ways to cut a solution and deciding what to do often comes down to what's already in place.
Why don't you use a Web Service / SOAP? You should be able to get a C library for creating SOAP messages. Then you can use Axis to create your WS that inerfaces to the EJB.
It's the standard way of doing cross-platform integration.
It solves your transport and method-mapping issues.