Diagram 1: General architecture of the implementation
|
This software package contains a prototype implementation of WS-ReliableMessaging web service specification. WS-RM and its supporting specifications provide a way to tie several SOAP messages into a sequence of messages which can be tracked by the both the SOAP server (endpoint B) and the SOAP client (endpoint A). The state of the sequence can be queried by the endpoint A at any time, thus receiving information about possibly lost individual messages and acknowledgements about the received messages.
The WS-ReliableMessaging has been implemented on top of Apache Axis SOAP implementation, as a series of SOAP message handlers manipulating WS-RM related SOAP messages and SOAP header metadata. It will not work with any other SOAP implementation.
The implementation also utilizes the following supporting web service specifications:
|
|
The following diagram represents the two WS-RM endpoints that will be conveying SOAP messages and WS-RM metadata.
Both Endpoint A and Endpoint B are implemented as independent SOAP services, providing
WS-ReliableMessaging and WS-SecureConversation functionality. The following diagram
described a common usage scenario as a sequence diagram. The diagram contains only
two actual SOAP application level method calls (echoText), but also
features all the WS-ReliableMessaging and WS-SecureConversation related SOAP calls
with full examples.
ReliableMessagingSource, which can be used for:
SecurityFactory, which can be used for:
The implementation can be added on top of an existing SOAP web application, when the SOAP application is configured to pass all SOAP traffic through the WS-RM implementation's handler classes. This will add WS-RM functionality to the existing SOAP application.
This chapter will provide a short description about setting a SOAP web service to use the implementation. This includes setting the web service to to pass SOAP messages through the WS-RM handlers. The next diagram illustrates the different handlers in both reliable messaging endpoints A and B. See javadocs for more examples about using the implementation from Java application code.
The handlers are extensions of Apache Axis' handler architecture. They must be registered in both endpoints in order to work properly, by routing all SOAP messages through the appropriate handlers. This is done using configuration files in both endpoints.
Listing 1 shows the configuration of Endpoint A server and listing 2 shows the configuration of Endpoint A client.
<?xml version="1.0" encoding="UTF-8"?> <deployment xmlns:java="http://xml.apache.org/axis/wsdd/providers/java" xmlns="http://xml.apache.org/axis/wsdd/"> <transport name="http"> <requestFlow> <handler type="java:org.apache.axis.handlers.http.URLMapper"/> <handler type=" java:org.serapi.rm.ReliableMessagingSource$redirect"/> <handler type="java:org.serapi.rm.ReliableMessagingSource$sequenceAcknowledgement"/> </requestFlow> </transport> <service name="EndpointA" style="message"> <parameter name="className" value="org.serapi.rm.ReliableMessagingSource$pivot"/> <parameter name="allowedMethods" value="*"/> </service> </deployment>
<?xml version="1.0" encoding="UTF-8"?> <deployment xmlns:java="http://xml.apache.org/axis/wsdd/providers/java" xmlns="http://xml.apache.org/axis/wsdd/"> <transport name="http" pivot="java:org.apache.axis.transport.http.HTTPSender"> <requestFlow> <handler type=" java:org.serapi.rm.ReliableMessagingSource$sequence"/> </requestFlow> <responseFlow> <handler type="java:org.serapi.rm.ReliableMessagingSource$sequenceAcknowledgement"/> </responseFlow> </transport> </deployment>
Listing 3 shows the Endpoint B SOAP server configuration. The actual SOAP service using the WS-RM implementation should be also introduced here as a service.
<?xml version="1.0" encoding="UTF-8"?> <deployment xmlns:java="http://xml.apache.org/axis/wsdd/providers/java" xmlns="http://xml.apache.org/axis/wsdd/"> <transport name="http"> <requestFlow> <handler type="java:org.apache.axis.handlers.http.URLMapper"/> <handler type=" java:org.serapi.rm.ReliableMessagingDestination$redirect"/> <handler type="java:org.serapi.rm.ReliableMessagingDestination$sequence"/> </requestFlow> <responseFlow> <handler type="java:org.serapi.rm.ReliableMessagingDestination$ackRequested"/> </responseFlow> </transport> <service name="EndpointB" style="message"> <parameter name="className" value="org.serapi.rm.ReliableMessagingDestination$pivot"/> <parameter name="allowedMethods" value="*"/> </service> </deployment>
WS-RM is not a very clear specification and not a very strict one. This is specially true, when more WS specifications are applied to create secure and trustworthy messaging functionality. There are many things left to decide for the implementations, such as whether to use syncronous or asynchronous messaging for WS-RM messages or whether to return individual SOAP messages for sequence acknowledgements or to piggyback them in application level SOAP messages.
In particular, WS-SecureConversation assumes both endpoints engaged in exchange of SOAP messages should implements a PKI (Public Key Infrastructure) of sorts, in order to securely exchange secret information. This means PKI related security information must be deployed between these endpoints before the messaging can commence. For example, this prototype implementation uses hard coded public/private key pairs of 2048 bits used to recognize endpoints; Endpoint A holds its own private key and endpoint B's public key, endpoint B holds its own private key and endpoint A's public key.
All this leads to the fact that WS-ReliableMessaging or WS-SecureConversation are not a "pluggable" solutions, meaning it is extremely difficult to produce an implementation that could replace/be replaced with a "drop-in" solution by a third party vendor.