Messaging
| Aim | Investigating possible Messaging architectures for asynchronous messaging between ESP (VB6) and MAP's Java applications. |
| Background | This is primarily to facilitate information such as updated customer addresses on the ESP side to be passed to Java Applications which utilise this information. However this system, if succesful could possibly be extended to service other needs. |
| Objectives | To implement a pilot messaging system which reliably transfers address information from the VB side to a message queue. A Java client should be able to then query the message queue and pick up any pending messages on the queue. |
The MSSOAP Toolkit version 3 only supports RPC style calls. The manual suggests editing the WSDL file
of the service, to remove the line which defines the return type for the call. This forces the toolkit
to close the connection on the VB side. In addition, there is no reliability mechanism for these types
of calls.
At present, AXIS does not support pure asynchronous messaging or even 'one-way' calls similar to those
of the SOAP Toolkit described above, and it is presently unclear whether it will ever support messaging.
The developers at present seem to be concentrating on ironing out the bugs and adding new features to
RPC style communication.
I focused my investigations into enabling reliable asynchronous communications in this type of a
scenario using either of two Java APIs, which support asynchronous messaging.
The Java API for XML Messaging (JAXM) Optional Package enables applications to send and receive document oriented XML messages using a pure Java API. JAXM implements Simple Object Access Protocol (SOAP) 1.1 with Attachments messaging so that developers can focus on building, sending, receiving, and decomposing messages for their applications instead of programming low level XML communications routines.
JAXM is one among the many Java APIs for XML Processing. Unfortunately, JAXM seems to be loosing favour
with the developer community and even within the team which created the specifications. The reasons
include existence of a similar standard (JMS) for messaging which is reportedly easier to use and
provide better features.
JAXM which was part of the JWSDP version 1.1 (Java Web Services Development Pack) has been dropped in
version 1.2 and is offered as an additional download.
The Reference Implementation for the latest JAXM specification (1.1.2) requires all participating
clients to run on the same servlet or J2EE container (in our case, Tomcat). This does not help the
situation as we require a message queue, which accepts SOAP Messages from an external source (ESP) and
then forwards it onto a Java Client.
JMS is a strategic technology for J2EE. JMS will work in concert with other technologies to provide reliable, asynchronous communication between components in a distributed computing environment.
JMS was developed by Sun working in close cooperation with leading enterprise-messaging vendors
including IBM, Hewlett-Packard and Sonic Software.
JMS is a part of the J2EE platform since the release of version 1.3. The J2EE platform now has a
reference implementation of the JMS standard. In addition there are a number of commercial as well as
open-source implementations.
One such open-source implementation is JORAM (Java Open Reliable Asynchronous Messaging) by the
ObjectWeb consortium .
JORAM incorporates a 100% pure Java implementation of JMS (Java Message Service API released by Sun Microsystems, Inc.). It provides access to a MOM (Message Oriented Middleware), built on top of the ScalAgent agents based distributed platform. JORAM is a free, open source initiative.
JMS clients and the Message Queue communicate using a JMS specific protocol, which is unknown to VB. So we need a mechanism to get the message from VB and push it onto the JMS queue for a Java client to retrieve the message at a later time. This could be done using a web service running on AXIS.
There exists a reliable connection between the JORAM Message Queue and AXIS and between the Message
Queue and the Java Client. The JMS specification calls for this reliability and if the JORAM
implementation adheres strictly to this specification, which it claims, we should have no problems there.
So the system at present operates in the following manner:
- VB sends a message wrapped in a SOAP Package to AXIS
- AXIS unwraps the message and pushes it onto the message queue (The service utilises the JORAM API for this).
- AXIS informs VB of the success or failure of this operation.
- A Java client at a later time can connect to the queue to receive the message.
I have managed to successfully send and receive Text Messages. In theory, one should also be able to send and receive objects (or in this case, an AddressBean with updated address information). I am in the process of getting this to work.
The problem seems to be in the SOAP Toolkit's ability to successfully read a .wsdl file created by AXIS. I plan to use the Low Level API of the SOAP Toolkit which does not require a wsdl file to circumvent this problem.