Java Message Service Transport

Exchange of SOAP messages via the HTTP(S) transport is useful for traditional request/response type applications. The Remote Procedure Call (RPC) programming paradigm is simple to use and understand: the client sends a message and is blocked until the server decides to return a response. If any errors occur during the invocation, the client will know about immediately and can take appropriate action.

The RPC style is less useful for a different class of applications. As an example, an application that submits a purchase order for processing may not care if the server is going to process the request straight away. As a matter of fact, the application may be written in such a way that the purchase orders are processed at night to avoid loading the system unnecessarily during peak hours.

In applications such as the purchase order system sketched above, the client just wants to ensure that the request is put in a safe place such that it will not be lost in case of non-catastrophic errors. The typicaly solution to this problem is to use a messaging system, where requests are entered into a queue from where they are processed at a later time by a queue receiver application.

The Java Message Service (JMS) has emerged as the preferred messaging API for Java and J2EE applications. JMS is an API for accessing any enterprise messaging system, which means that client applications are portable and can use a common vocabulary when referring to message concepts such as queues and topics, as well as producer and consumer applications.

Novell exteNd Web Services SDK supports sending SOAP messages to a JMS destination (queue or topic). Instead of using the usual HTTP transport, the Novell exteNd WSSDK runtime will use a JMS transport to transfer the message. While such messages are usually "one way" meaning that the client application doesn't expect a reply, the Novell exteNd WSSDK client can optionally wait for a reply message on a different destination.

On the server side, Novell exteNd WSSDK supports a Message Driven Bean (MDB) based skeleton. MDB is a new bean type introduced in J2EE 1.3, which listens to messages from a JMS destination and processes them inside the J2EE container environment. This for instance means that a MDB can processes messages in the context of a (distributed) transaction. The MDB skeleton in Novell exteNd WSSDK works exactly like the Servlet based skeleton.

In a Servlet based skeleton, the generated base class implements the doPost method. When doPost is invoked, Novell exteNd WSSDK extracts the SOAP message and dispatches to a business method in the user supplied implementation class. The result of the invocation is written to the Servlet response and returned to the caller. In a nutshell, users only worry about implementing the business methods.

The MDB skeleton is a generated base class, which implements to onMessage method. As in the Servlet, each invocation of onMessage causes Novell exteNd WSSDK to extract parameters from the SOAP message and invoke the requested business method. If a return value is present, the MDB skeleton will return it to a reply destination. The user's implementation class is the same whether Servlet or MDB base class is used.

Deployment of Web Services that use the Java Message Service for transporting SOAP messages is typically done in one of the following two ways:

The first scenario is illustrated in Figure 1 below. In this scenario, the client application is typically within the firewall and on the same local area network as the JMS server and EJB container. Alternatively, the client is using the capabilities of the JMS provider to transmit messages across firewalls.


Figure 1: Novell exteNd Web Services SDK client using JMS transport to enchange SOAP messages via a JMS destination (queue or topic).

The four steps illustrated in Figure 1 are described in more detail below:

  1. First, a Novell exteNd Web Services SDK client configured for JMS transport sends a message to a JMS destination (queue in this example). Note that the client application is exactly the same regardless of whether JMS or HTTP transport is used. The usual JAX-RPC API is used to send the SOAP message.
  2. Second, JMS listener receives a message from the destination. In this case, we use a MDB based Novell exteNd Web Services SDK skeleton. The MDB processes the request in the relavant business method and optionally returns the result to a reply destination. Note that the skeleton implementation class is exactly the same as if a Servlet based skeleton was used. The code to receive a message from a JMS destination and send a reply is done automatically in the servlet base class generated by Novell exteNd Web Services SDK.
  3. Third, if the method has a return value, it is send as a SOAP message to a reply destination.
  4. Fourth, in case of a return value, the Novell exteNd Web Services SDK client blocks while waiting for the server to process the message. The client application may set a timeout to avoid waiting indefinitely if an error occurs or the server doesn't reply in a timely manner.
    5. The second scenario is illustrated in Figure 2 below. In this case, the Novell exteNd Web Services SDK client uses regular SOAP/HTTP to transmit messages to a Servlet based endpoint. The Servlet is merely a router, which acts as a facade to a JMS destination. The JMS router will receive incoming SOAP messages and forward them onto a JMS destination.


    Figure 2: Novell exteNd Web Services SDK JMS "router" Servlet enchanging SOAP messages via a JMS destination (queue or topic).
    The six steps in Figure 2 are described in detail below:
    1. The client (Novell exteNd Web Services SDK or other) sends a SOAP message using HTTP transport to the Novell exteNd Web Services SDK JMS router Servlet.
    2. The router Servlet forwards the message to a destination, which was defined as part of the router Servlet configuration. The parameters for connecting to a particular JMS provider are also part of the router Servlet configuration.
    3. A message driven bean or other JMS message listener consumes the SOAP message from the destination. In this case, we show a Novell exteNd Web Services SDK MDB based skeleton. Please refer to the description above for detail.
    4. The MDB skeleton optionally sends a reply message to a reply destination.
    5. The Novell exteNd Web Services SDK JMS router Servlet consumes the reply message.
    6. The reply message is sent back to the client via normal HTTP transport.
      7. As can be seen from the above two examples of using the Java Message Service transport, several configurations and a great deal of flexibility is possible. This section includes the following examples to further illustrate the Java Message Service transport features of Novell exteNd Web Services SDK:
      The "JMS" example shows how to build a simple Servlet that routes messages onto a JMS destination. The Novell exteNd Web Services SDK Service has two methods to send and receive messages.

      The second "JMS" example shows how to develop a Novell exteNd Web Services SDK client that uses the JMS transport. The client needs to set some properties unless it is using the default, Novell exteNd MQ JMS provider.

      The "MDB" example shows how to build a MDB based Novell exteNd Web Services SDK service. While the implementation of the skeleton class is exactly the same as we've seen before, the packaging of the application is different.

      Back to top.
Copyright © 2001-2003, Novell, Inc. All rights reserved.