Help using JMS in a network/general architecture

Question

Hi everybody :
We are working on the development of a distributed application. The architecture of the system is something like this:
- A dispatcherthat receives requests (in a string shape) via http post. This unit has to encapsulate this request in a object and fordward such a petition to the correct service according a parameter of the request string.
- A little number of services (4 or 5) that wait for requests delivered by the dispatcher. When a petition arrives, is attended to, and a response is sent to the client, using the http post that the client has used to send us the initial request. The computation complexity could be severe (access to DB, on-demand compilations, multimedia handling...).
The distribution arises when we wanted to place each service on different machines due a heavy amount of requests.
On a first approach, we are considering to use a servlet to manage the requests and JMS as middleware messaging service, as we want to provide an efficient communication layer between the modules of our application.
Here come my doubts:
- Would be the system more efficient if the service-providers are some kind of Enterprise Java Beans? And servlets?
- I have readed the JMS and de JNDI tutorial. I have performed many tests in local mode, and i want now to do the same in a network mode... could somebody orient me? How do could i bind a connection factory with a specific resource across the network? In coding time or in deploying time?
Help will be very very appreciated!!!!!
Thank you very much for reading this message
Greetings from Maria, Spain (europe)

Answer 1

Hello Maria,
You mention several things regarding architecture. I'll try to iterate them for you. As always this is just one persons idea/opionion.
Receive Request from HTTP Posts. (Dispatcher)
-- Sounds like an XML String morphed into an object via servlet. You could standardize on SOAP if it's not too much overhead.
Services - High computation...
Let jms receive and queue these requests. A service delegate can spawn threads to deal with the complex computations. I say Queue so you can cap the active thread count and pause the delegators thread creation due to any memory / cpu constraints...
As far as JMS is concerned I'm unaware of your transactional requirements. In enterprise systems I have written, everything must be transacted and audited. JMS has a nice model for this. You could move to a pub/sub architecture as well.
Scalability - (Distribution arises) - Each machine can maintain it's own queue and the servlets can distribute to them. Or you can pub/sub them via a dispatcher, it's own machine if desired - and let each machine act as a listener. A nice model as the amount of services grows.
- Now that I've only reiterated what you've tried..
Would be the system more efficient if the service-providers are some kind of Enterprise Java Beans? And servlets?
-In my opionion for the high volume HTTP requests, servlets can lift the load.
-You system has a high level of requests and load on your CPU. I'll also assume that transactions and auditing are required. As I'm sure you well know EJB is not the fastest animal in the forest. I would not use Message Driven Beans as you will have a hard time tunning performance within an EJB Container.
- Now after I've said all that any fallout and persistance requrements from each service can leverage EJB's. Just remember that EJB's lend themselves well to web/commerce apps. I have no idea of your applications context so I'm taking a stab. There are wonderful tools in the EJB architecture, however, just because you've chosen Java doesn't mean you have to use EJB's. If speed in an issue for these services ( persisted or session level ) perhaps a mix is what your desire. ( I find session beans to be much better accessors than there sluggish entity brothers. )
JNDI - Create a Service Locator that abstract the lookups for your services. Depending on how far you want to go. Our Service Locator can look up a multitude of contexts. Be it Weblogic/Websphere or a file system. There is no magic to it you just have to plug and play the contexts.
"I have readed the JMS and de JNDI tutorial. I have performed many tests in local mode, and i want now to do the same in a network mode... could somebody orient me? How do could i bind a connection factory with a specific resource across the network? In coding time or in deploying time?"
--I would take the performance hit on late binding and use caching to try and gain some back.  Below is a small example...
-- All in all, It would help you to become more familiar with the EJB spec if your planning on that path. You soon come to notice it's features ( and particular quirks ).
Good Luck,
Hope this helps
private String serverInstance;
private String serverPort;
/** Creates new ServiceLocator */
protected ServiceLocator(String host, String port) {
this.serverInstance = host;
this.serverPort = port;
public String getServerPort() {
return this.serverPort;
public String getServerInstance() {
return this.serverInstance;
private javax.naming.Context getInitialContext() throws javax.naming.NamingException {
javax.naming.Context ctx = null;
java.util.Properties prop = new java.util.Properties();
prop.put("java.naming.factory.initial", "com.sun.jndi.rmi.registry.RegistryContextFactory");
prop.put("java.naming.provider.url", "rmi://"+serverInstance+":"+serverPort+"");
prop.put("java.naming.factory.url.pkgs", "org.objectweb.jonas.naming");
ctx = new javax.naming.InitialContext(prop);
return ctx;
public Object getContainerService(String jndiName) throws javax.naming.NamingException {
javax.naming.Context ctx = getInitialContext();
java.lang.Object obj = ctx.lookup(jndiName);
return obj;
public static ServiceLocator getInstance(String host, String port) {       
return new ServiceLocator(host, port);