![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
WS-ReliableMessaging protocol provides a solution for the reliable delivery of messages using the concept of endpoint managers (EPMs). The proposed model uses two EPMs, namely Reliable Messaging (RM) Source and RM Destination, to handle the reliable delivery of messages. Figure 1 shows how they interact at a very abstract level.
Figure 1: The reliable messaging model
According to the above model, the reliable delivery of messages is handled by the RM Source and RM Destination, while providing a transparent message path to the Application Source (web service client) and to the Application Destination (web service).
Sandesha is implemented on top of Apache Axis and the architecture of Sandesha is mainly guided by that of Axis and what is shown in Figure 1 above. According to the specification, it is a core requirement that the RM Source has an endpoint reference.
"The RM Source MUST have an endpoint reference that uniquely identifies the RM Destination endpoint; correlations across messages addressed to the unique endpoint MUST be meaningful." (Please refer to the WS-ReliableMessage specification for more information in Resources section.)
Axis architecture provides a synchronous messaging framework. As a result, Sandesha cannot support the asynchronous messaging requirement by mere utilization of Axis's capabilities. As a consequence, Sandesha architecture has to provide an asynchronous messaging framework in addition to the functionality provided for the reliable message delivery. To support both these requirements, Sandesha has introduced an architecture with a separate Sender and Receiver to both client and server sides. In order to support the connectivity between the Sender and the Receiver with respect to a particular EPM, Sandesha architecture uses an in-memory Queue by default. The architecture provides the capability to plug a database instead of a Queue, which ultimately leads to the persistence.
The top level architecture is shown in Figure 2 below.
Figure 2: High-level architecture of Sandesha
This architecture provides complete support for both synchronous and asynchronous messaging scenarios. WS-Addressing provides the information for the correlation of messages when the asynchronous pattern is adopted. However, with the use of bi-directional transports (like HTTP), there is a possibility that the acknowledgements to the requests will be sent using the same connection, as shown by the dotted lines in Figure 2. So the sender in both sides should be prepared to handle that type of situation accordingly.
Sandesha architecture on top of Apache Axis
A more detailed view of the architecture will emerge when the Axis-specific components are added to Figure 2. Figure 3 shows the complete architecture of Sandesha.
Figure 3: Sandesha architecture on top of Apache Axis
Figure 3 shows the components in RM Source and RM Destination. Although the diagram shows a single Axis engine per RM endpoint, the Sender and the Receiver utilize Axis in their send and receive functionality, providing an entirely Axis-based architecture. The individual components in Figure 3 are described in more detail below.
Client: This is the program that invokes (utilizes) the web service. Based on the high-level architecture, this is the Application Source. Sandesha provides the capability of invoking several web services (might be in different RM Destinations) using a single RM Source at the Client.
SandeshaContext: This provides the user with an API to set various RM-specific parameters. Axis's invocation mechanism is mainly based on Call; however, SandeshaContext is used to pass the additional parameters from client code to Sandesha and Axis-specific components. Using this Client can set values for WS-Addressing if the Client needs to override the default values. In addition, SandeshaContext can be used to set various runtime parameters to the RM Source.
Call component: This is the Axis's call mechanism. This provides a synchronous invocation (blocking Client with single transport connection) paradigm to the clients. And if the Web Service client needs to have non-blocking (still with single transport connection), then the Client should use AsyncCall instead of Call. Sandesha provides the capability of using both Call and AsyncCall on the Client.
Axis engine: This is the engine of Apache Axis, which is essentially a Simple Object Access Protocol (SOAP) engine -- a framework for constructing SOAP processors such as clients, servers, gateways, and so forth.
RMSender: This is the transport sender that the user should use in order to enable reliable messaging on the client side of the Axis engine. However, RMSender will not directly write the request to the transport layer. It inserts the request to the "Queue" instead.
Queue: This is the persistence layer for Sandesha. The solution for reliable messaging is achieved using an in-memory Queue. However, Sandesha provides an extensible storage manager API that implements storage based on a database in a fairly straightforward manner. (Sandesha currently supports only an in-memory Queue.) Although the Queue acts as a single component, it maintains two queues for incoming and outgoing messages. In addition, the interface to the Queue is given throw to two storage managers, namely ClientStorageManager and ServerStorageManager. These two storage managers, which are not shown in Figure 3, provide the required functionality for the RM Source and RM Destination utilizing the Queue.
Sender: This is a running thread from a thread pool to send the request messages. Sandesha uses the same Sender component on the client side as well as the server side. The Sender is used to send all the messages flowing out from a particular EPM (RM Source or RM Destination).
When the Sender sends a request using bi-directional transport protocol (for example, HTTP), there is a possibility (when the <wsrm:AcksTo> address is set to the anonymous Uniform Resource Identifiers (URI) (See the first and third references in the Resources section.)) that the receiver sends the acknowledgment using the same connection. Although Sandesha handles acknowledgements sent in the same transport connection, it does not support application responses sent in the same transport connection.
Receiver: This is the listener for the client side and it is Axis's SimpleAxisServer that is used as the receiver for Sandesha. The functionality of the Receiver is to accept the asynchronous SOAP messages and insert them into the Queue, according to the correlation information present in the message itself. Sandesha uses the same configuration as in the RM Destination inside the Receiver so that the same components are used to handle the asynchronous responses. (In Sandesha architecture, asynchronous responses are handled as incoming requests. However, responses are not used to invoke web services; rather, they are inserted to the "Queue" with respective correlation information.)
RMProvider: This is the provider used by Sandesha inside the Axis engine on the server side. RMProvider identifies the incoming messages and inserts the required messages into the Queue. It also generates reliable messaging-specific messages, such as Acknowledgement and Terminate Sequence messages.
RMInvoker: This is a runnable component that dispatches web service requests to the actual service. RMInvoker also puts the service response, if any, into the Queue on the server side. Sandesha provides the capability of using several RMInvoker threads to dispatch web service requests, allowing web services to invoke other web services deployed in the same server without running into deadlocks.
Service: This is the web service itself. In the high-level architecture, this is referred to as Application Destination.
Complete messaging scenario explanation
Web service clients can consume web services in many ways, depending on factors such as the Message Exchange Pattern (MEP) of the service operation (IN-OUT, IN-ONLY, and so forth), the transport connection, and the blocking and non-blocking API provided by the web service engine for the client application. Apache Sandesha provides the capability of utilizing all these invocation patterns that Axis provides for web service clients with reliable messaging. The following messaging scenario explains the sequence of invocations of different components in RM Source and RM Destination.
Initialization of SandeshaContext in RM Source
Before invoking a web service, it is required that the client application initialize the SandeshaContext. The model that Sandesha proposes requires the users to first set the required parameters to the SandeshaContext, and then initialize it. A single instance of the SandeshaContext represents a single sequence with respect to the WS-ReliableMessaging specification. However, if the Client creates many sequences by creating many instances of SandeshaContext, then SandeshaContext acts as a collection of sequences.
illustrates the sequence of invocations when SandeshaContext is initialized.
Figure 4: Initialization of SandeshaContext
Ending sequences in the RM Source
Once the Client receives responses or gets the control back if they are one-way messages, Sandesha requires the Client to explicitly inform the RM Source to "end" the sequences by using SandeshaContext, which will then check all the active sequences and try to terminate them one by one. The maximum wait time that SandeshaContext waits for a particular sequence is the "inactivity" time out of that sequence. Figure 5 shows the steps for the sequence termination.
Figure 5: Ending sequences
Service invocation -- two-way (Service has a response.)
In this scenario, the web service client invokes an IN-OUT operation of a web service. In Sandesha, this type of IN-OUT operation is supported in an asynchronous environment, such as using separate transport connections to send the request and to receive the response. In this scenario, you must assume that the <wsrm:AcksTo> value is set to an anonymous URI and <wsrm:Offer> is sent in the <wsrm:CreateSequence> header, offering a sequence for Web Service responses.
Figure 6 shows the sequence of invocations for this scenario on the client side.
Figure 6: Service invocation -- RM Source
- The Client initializes the SandeshaContext, as shown in Figure 4.
- The Client invokes the Call. (This is the invocation point for the Client to the Axis engine.)
- The RMSender creates the required reliable messaging-specific messages (Create Sequence, Terminate Sequence, and so forth), inserts them into the Queue with the request message, and keeps on monitoring the Queue until a response is received.
- The Sender (has already been started by the SandeshaContext in the initialization step) keeps on monitoring the Queue for messages (through the ClientStorageManager) to be sent, finds the new messages, and sends them to the destination. The Sender gets only the messages that are available for sending. This mechanism verifies that the Sender sends web service requests once the Create Sequence operation is completed and the messages are retransmitted with appropriate timing settings.
- In this scenario, the Sender first sends the Create Sequence request. Depending on the value of the
<wsa:ReplyTo>address, the Create Sequence response can be received by the RM Source using the same transport connection or a different transport connection. In either case, the Queue is updated with the response message. This allows the Sender to send the Web Service request messages. A particular message will be available for sending as long as it is not acknowledged or its inactivity time out, as per the RM Policy Assertions, has not been reached. - Once the acknowledgements for all the messages are received, the Queue allows the Sender to send the Terminate Sequence message.
- Whenever the Receiver receives a message, it identifies the message and updates the Queue using the correlation information present in the message as addressing headers. In this scenario, once the Receiver receives the web service response, it creates the required acknowledgement message that needs to be sent to the RM Destination acknowledging the reception of the web service response, and inserts it into the Queue. This will be picked up later by the Sender and sent to the RM Destination. The RM Destination will also send the Terminate Sequence message for this response sequence once it receives acknowledgements for all the responses.
- When the RMSender finds the web service response available in the Queue, it returns this response to the client application. In this case, whether the Client is using Call or AsyncCall of Axis does not make any difference to the operation of the RMSender.
- When the Client gets the responses for all its invocations, Sandesha requires the client application to end the sequence. During this phase, the RM Source cleans the storage, and if there are no active sequences, it stops the Sender and the Receiver from transferring the control back to the Client.
The steps that are executed in the RM Destination when a message is received are shown in Figure 7 below. Please note that when the Queue is initialized, the Sender and Invoker happen only at the first message to the particular RM Destination.
Figure 7: Service invocation -- RM Destination
- RMProvider receives a message and inserts this message to the Queue if it is a web service request. If this is a protocol-specific message, such as Create Sequence Request, Acknowledgement Request, or Terminate Sequence message, then it performs the necessary action. For example, if it is a request for an acknowledgement, then it inserts the acknowledgement message to the Queue for sending back.
- RMInvoker monitors the Queue (through the ServerStorageManager) for the web service requests and invokes the service. It is assumed that the Queue has the messages correctly ordered for it to dispatch. If the service request has a response, then RMInvoker inserts this into the Queue for sending back to Client. If this is the first response message, then the RMInvoker inserts a Create Sequence Request message as well. (This is only if the outgoing sequence is not specified when the initial request comes from the Client using
<wsrm:Offer>. (See the first reference in the Resources section.)) RMInvoker also inserts the Terminate Sequence message when the last response message for that sequence is inserted into the Queue. - The sender, similar to the RM Source, keeps monitoring the Queue for messages to be sent, identifies them, and immediately sends them to the RM Source.
If the client invokes a web service with the IN-ONLY operation, then the sequence of invocations in both RM Source and RM Destination will be subsets of the sequences, as shown in Figure 7 above. There will not be a waiting time in the RM Source until it gets the response from the sending part in the RM Destination.
Sandesha implements the WS-ReliableMessaging protocol on top of Apache Axis. This has enabled the Axis community to perform web service invocations reliably with not only Axis itself, but also with other web service platforms such as Microsoft .NET that implements the above protocol. Sandesha does not currently provide the persistence with respect to software component failures; however, you can achieve this by using a database as the storage for SOAP messages instead of an in-memory Queue. Future developments will mainly focus on this area and to also implement Sandesha on top of Apache Axis 2, which is the new version of Axis still under development.
Learn
- WS-ReliableMessaging : WS-ReliableMessaging specification
- Apache Axis : Apache web service engine
- WS-Addressing : WS-Addressing specification
- WS-Policy : WS-Policy specification
- The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
- Standards roadmap -- understand the impact and importance of standards and specifications for the development of SOA and web services.
- SOA and web services -- hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop web services applications.
Get products and technologies
-
Get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®. You can download evaluation versions of the products at no charge, or select the Linux™ or Windows® version of developerWorks' Software Evaluation Kit.
Discuss
- developerWorks blogs: Get involved in
the developerWorks community.
Jaliya is currently a graduate student studying computer science at the University of Indiana in Bloomington, Indiana. He has a Bachelors Degree from the University of Moratuwa in Sri Lanka. He is also a member of the Lanka Software Foundation, a committer for Apache Sandesha and Apache Axis2, and represents the PMC for Apache Sandesha. Jaliya has two years of working experience as a software engineer and has worked for Virtusa Corporation and Lanka Software Foundation. You can contact him at jaliya@opensource.lk.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
