Proposed Changes for Sandesha
Current Implementation
After the first implementation Sandesha was restructured with a new architecture to support the new WS-RM specification published in 2004. With the new architecture Sandesha was mainly implemented as a new Provider so that it can handle the requests more manageably.
With these new improvements Sandesha participated for the WS-RM inter-op workshop at BEA's San Francisco office. The workshop was mainly focusing on the set of scenarios specified by the inter-op group to test the interoperation between the different implementations of WS-RM. Other participants for the above inter-op workshop were IBM, Microsoft and BEA. Sandesha was able to interoperate considerably with these implementations. The inter-op session has helped us to identify the defects in Sandesha and also the possible improvements.
With these results in our hand we had a set of face-to-face sessions with Aleksander Slominski who has visited Sri Lanka this month as a guest of Lanka Software Foundation where we discussed the required changes to Sandesha to cater for all the inter-op scenarios. Based on the ideas discussed we have finalized a complete mechanism to support asynchronous message transfer for Sandesha.
Proposed Architecture
The proposed architecture can be best described by the following diagram.(Message path for a complete loop is shown the by numbers)
Components shown in the above diagram can be described as follows.
RMSender
This is the sender for Sandesha (similar to HTTPSender) but the functionality of the RMSender will be limited to pushing the request message to the ClientQueue and returning. So the client can send the next message without waiting for the response (Asynchronous messaging)
This will be singleton queue to store the request messages and their acknowledgements. In order to achieve the persistency we need to replace the queues with a database where some sort of serialization is required.
Sender
This is a running thread started by the RMSender to send the request messages. By default Sender will use the HTTPSender to send the requests, but the user will be provided with the option of selecting a different sender for this purpose. (This can be done using the client-config.wsdd). In the server side also we use the same sender that will keep on sending the responses (if any) to the client asynchronously.
When the Sender sends an HTTP request there is a possibility (when the wsa:From address is set to the anonymous URI) that the receiver sends the acknowledgment using the same HTTP request, but it should be noted that we are not expecting any responses over the same HTTP request. These scenarios are shown using 4.1 and 10.1 arrows.
RMSender will initiate and start the SimpleAxisServer where it will keep on listening to a particular port for asynchronous acknowledgements and responses. It will keep on updating the ClientQueue (or a database) depending on the requests (responses or acknowledgements) it will receive.
RMProvider
The main functionality of this provider is to push the incoming requests to the InQueue and to update the OutQueue if it receives any asynchronous acknowledgements for the responses sent to the client (Shown as X in the diagram)
After inserting the message to the InQueue the provider will return sending an either an acknowledgement to the client using the same HTTP connection or by simply terminating the connection.
These are singleton message queues that are used to keep the messages until a proper message order is completed so that the service can be invoked.
RMInvoker
A separate thread running that will invoke the service using the provider specified by the user. By default it will use the RPCProvider to pass the SOAP requests to the corresponding web service. User should also be able to customize the actual provider that should be used to dispatch the requests to the service.
If there is any application response for the request it will be pushed to the OutQueue by the RMInvoker.
Note:
With this implementation we have use few threads to support the asynchronous messaging model although it is not advisable to use threads inside a j2ee containers. We have to follow this approach since still we dont have the asynchronous support from axis. Once axis supports asynchronous message transfer then we can remove those threads and let axis to handle that part as well.
With these changes we expect that the Sandesha will be able to support all the inter-op scenarios and complying with the WS-ReliableMessaging Specification.
Please feel free to send your comments and suggestions on this so that we can come up with a very good architecture.
Reference:
WS-ReliableMessaging Specification: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-reliablemessaging.asp
WS-RM Inter-op Scenarios:
ftp://www6.software.ibm.com/software/developer/library/ws-rmscenario.doc