Question on Interservlet communication

[El Durango]

Hi I am working on a project that requires Java Servlets and need some
professional advice.
The application requires a servlet to act as an "operator" which sends and
recieves messages between other Servlets or Applications. I need to have
this servlet be able to interface with another servlet as well as an
application. I setup a Java app to communicate with it, however I need the
app to recieve the specific message that the servlet produces rather than
its html output.
There are many different approaches to accomplishing something like this:
I am sure I can define sockets on both the servlet side and the application
side and communicate at a "lower level", but I don't want to take that route
because it may cause issues later on (Firewall). Another thing is that I
should not need to make any server configurations or system configurations
(example: change webserver ports or configure tomcat,setup RMI).
One option that I already have thought of is to pass variables between the
"operator" servlet and other servlets/apps via HTTP. This method should
work, however I would rather access and call methods between each other
rather than pass the variables around.
Now I am open to all suggestions even if they do break any of the previous
constraints, however I would like to take the "easiest and least painful"
route if there is such a thing I hope that you may know about
something I may have overlooked, at the moment I am still researching for
the best possible method to accomplish this. I have read about interservlet
communication but did not find anything that would satisfy communication
with another java application.
Note: all communication has to be bi-directional.
Any suggestions would be welcome.

thank you.

 

[Wendy S]

Hi I am working on a project that requires Java Servlets and need some
professional advice.
The application requires a servlet to act as an "operator" which sends and
recieves messages between other Servlets or Applications. I need to have
this servlet be able to interface with another servlet as well as an
application.

You seem to be describing SOAP messaging here. Apache Axis can run as a
separate webapp under Tomcat, or you can incorporate it in your own webapp.
Then the web service can call the same supporting classes that a Servlet
might, only while the Servlet responds in HTML, the web service would
respond in XML.

 

[John C. Bollinger]

Hi I am working on a project that requires Java Servlets and need some
professional advice.
The application requires a servlet to act as an "operator" which sends and
recieves messages between other Servlets or Applications. I need to have

Why does the operator need to be a servlet? What you are describing
doesn't sound like a servlet at all.

Is this supposed to be some kind of message dispatch agent, or is it
more like a mail host? (That is, should it proactively deliver messages
to their destinations, or does it wait for clients to poll for
messages?) And what is the nature of the messages?

this servlet be able to interface with another servlet as well as an
application. I setup a Java app to communicate with it, however I need the
app to recieve the specific message that the servlet produces rather than
its html output.

Servlets don't have to respond in HTML. Your servlet container may
constrain you to accepting requests and delivering responses via HTTP,
however. The message body may contain HTML, XML, serialized Objects,
random bytes, etc..

There are many different approaches to accomplishing something like this:
I am sure I can define sockets on both the servlet side and the application
side and communicate at a "lower level", but I don't want to take that route
because it may cause issues later on (Firewall). Another thing is that I

It also doesn't conform very well to the servlet model. If that
approach is even remotely attractive to you then you are probably
looking for something other than (or perhaps in addition to) a servlet
to fill the role. If a core reqirement here is that the "operator" run
inside a servlet container, then perhaps you should look into a
ServletContextListener implementation. In that case, however, you do
still have the problem of how your applications talk to the operator.

Servlet clients are also a strange architectural choice if you expect
them to be on the receiving end of messages.

should not need to make any server configurations or system configurations
(example: change webserver ports or configure tomcat,setup RMI).
One option that I already have thought of is to pass variables between the
"operator" servlet and other servlets/apps via HTTP. This method should
work, however I would rather access and call methods between each other
rather than pass the variables around.

Well, for an object to invoke the methods of another object in a
different VM you need RMI or some other RPC framework, which you have
ruled out. Are these restrictions for your convenience or are they
required by the server operator?

A servlet can pass information to other servlets in the same container
-- IN A PARTICULAR REQUEST CONTEXT -- by using a RequestDispatcher to
forward a Request to that servlet or to include a response from that
servlet. Arbitrary objects may be bound as request attributes and thus
passed among the servlets. If you need communication that is outside of
any request context then servlets are not the right tool.

Now I am open to all suggestions even if they do break any of the previous
constraints, however I would like to take the "easiest and least painful"
route if there is such a thing I hope that you may know about
something I may have overlooked, at the moment I am still researching for
the best possible method to accomplish this. I have read about interservlet
communication but did not find anything that would satisfy communication
with another java application.
Note: all communication has to be bi-directional.
Any suggestions would be welcome.

Have you looked into Java Message Service (JMS)? It is probably
worthwhile to read up on it, because even if you don't end up using JMS
you may gain a better insight into just what might be involved in
implementing what you describe.

I in any case have considerable misgivings about your scheme. The only
reason I can think of right now for wanting to have messaging among
servlets outside the context of request processing is to maintain
application state. Exchanging messages is a terribly poor way to do
that: duplicate copies of the state must then be kept in various places
and the different components might easilly get out of sync. State can
readily be stored in the application or session context, or even in a
Request object and then retrieved as necessary; if that isn't sufficient
then you should probably be looking at a backend database.
Alternatively, perhaps you need to separate the servlets from the work
you currently have them performing -- maybe they can just provide an
interface to the distributed application in such a way that they don't
need to communicate directly with each other or with external
applications (except via the normal request processing channels).

John Bollinger
(e-mail address removed)

 

[dan]

the easy way to achive that is to communicate with ur application
using http. In this approach u just deal with communication between
servlet which is pretty simple.
other approach (socket,RMI,corba ,..) are more complicate to implement
but may achieve better performance.
so if u dont need high communication performance, use XML as a message
format and http as a communication layer.

-Dan
(e-mail address removed)