SOAP RPC over JMS - I wish

["Forden, David Keith" <Da...@epiqus.com>]

Hi,

We are implementing an internal infrastructure for business object
communication using J2EE/JMS. Ultimately we will be seeking to migrate our
code to Message Driven Beans using EJB 2.0. This will not change how we need
to implement message transport. In the mean time we have put together a
threaded listener infrastructure (boot strapped server objects that are JMS
and EJB clients) that maps JMS messages to EJB.

I have come to the point where we need to start defining transactional
interfaces for business objects within the payloads of JMS messages. Each
transaction is an intrinsic RPC operation where a request/respose model is
required. We will need each business object to translate (marshall) the
message transaction into an EJB transaction and possibly to other
transactional objects since our framework is designed to be pluggable. 

My assessment of SOAP is that it will provide a very neat solution for RPC
over JMS. I would like to know whether or not anyone else is doing something
similar and/or whether you (the experts) think I am going the right or wrong
way about things. 

My current justifications for wanting to go this way are as follows:

1) SOAP provides a defined marshalling layer and RPC semantic using XML
messages.
2) We have already adopted XML as our chosen format for the message
payloads.
3) The draft ebXML standard has nominated SOAP support.
4) If we do not use SOAP then we will need to invent our own marshalling and
RPC library
5) Using SOAP allows us to provide a DTD catalog using HTTP and possibly
index it using URI's as an attribute in an LDAP "Message" object. This gives
us excellent decoupling for business components.

I would greatly appreciate any ideas and/or opinions. I would also
appreciate any hints as to how one would go about using the current
xml.apache.org libraries to implement this. We will happily release any code
that we write which is useable without our proprietary ideas and libraries.

Dave Forden