You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by ja...@apache.org on 2005/03/15 07:50:33 UTC
cvs commit: ws-site/targets/ws-fx/sandesha/images Architecture.jpg Architecture2.jpg ClientInitialization.png ClientTermination.png EchoAsync.png EchoSync.png PingAsync.png PingSync.png RMModel.jpg ServerReqWithAsyncAck.png ServerReqWithSyncAck.png ServerWithResponse.png ServerWithResponseSyncAck.png
jaliya 2005/03/14 22:50:33
Modified: targets/ws-fx/sandesha index.html
Added: targets/ws-fx/sandesha architecture.html
targets/ws-fx/sandesha/images Architecture.jpg
Architecture2.jpg ClientInitialization.png
ClientTermination.png EchoAsync.png EchoSync.png
PingAsync.png PingSync.png RMModel.jpg
ServerReqWithAsyncAck.png ServerReqWithSyncAck.png
ServerWithResponse.png
ServerWithResponseSyncAck.png
Log:
Added the architecture guide to Sandesha
Revision Changes Path
1.3 +2 -2 ws-site/targets/ws-fx/sandesha/index.html
Index: index.html
===================================================================
RCS file: /home/cvs/ws-site/targets/ws-fx/sandesha/index.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- index.html 2 Mar 2005 14:42:19 -0000 1.2
+++ index.html 15 Mar 2005 06:50:32 -0000 1.3
@@ -2,8 +2,8 @@
@import url("./style/maven-base.css");
@import url("./style/maven-theme.css");</style><link rel="stylesheet" href="./style/print.css" type="text/css" media="print"></link><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"></meta></head><body class="composite"><div id="banner"><a href="http://ws.apache.org/" id="organizationLogo"><img alt="Apache Web Services" src="http://www.apache.org/images/asf-logo.gif"></img></a><a href="http://ws.apache.org/ws-fx/sandesha/" id="projectLogo"><img alt="Apache Sandesha" src="http://ws.apache.org/ws-fx/sandesha/images/Sandesha.jpg"></img></a><div class="clear"><hr></hr></div></div><div id="breadcrumbs"><div class="xleft">
- Last published: 02 March 2005
- | Doc for 1.0</div><div class="xright"></div><div class="clear"><hr></hr></div></div><div id="leftColumn"><div id="navcolumn"><div id="menuSandesha"><h5>Sandesha</h5><ul><li class="none"><a href="userguide.html">Simple User Guide</a></li></ul></div><div id="menuProject_Documentation"><h5>Project Documentation</h5><ul><li class="none"><strong><a href="index.html">About Apache Sandesha</a></strong></li><li class="collapsed"><a href="project-info.html">Project Info</a></li><li class="collapsed"><a href="maven-reports.html">Project Reports</a></li><li class="none"><a href="http://maven.apache.org/development-process.html" class="externalLink" title="External Link">Development Process</a></li></ul></div><a href="http://maven.apache.org/" title="Built by Maven" id="poweredBy"><img alt="Built by Maven" src="./images/logos/maven-button-1.png"></img></a></div></div><div id="bodyColumn"><div class="contentBox"><div class="section"><a name="Apache_Sandesha"></a><h2>Apache Sandesha</h2><p>
+ Last published: 15 March 2005
+ | Doc for 1.0</div><div class="xright"></div><div class="clear"><hr></hr></div></div><div id="leftColumn"><div id="navcolumn"><div id="menuSandesha"><h5>Sandesha</h5><ul><li class="none"><a href="userguide.html">Simple User Guide</a></li><li class="none"><a href="architecture.html">Architecture Guide</a></li></ul></div><div id="menuProject_Documentation"><h5>Project Documentation</h5><ul><li class="none"><strong><a href="index.html">About Apache Sandesha</a></strong></li><li class="collapsed"><a href="project-info.html">Project Info</a></li><li class="collapsed"><a href="maven-reports.html">Project Reports</a></li><li class="none"><a href="http://maven.apache.org/development-process.html" class="externalLink" title="External Link">Development Process</a></li></ul></div><a href="http://maven.apache.org/" title="Built by Maven" id="poweredBy"><img alt="Built by Maven" src="./images/logos/maven-button-1.png"></img></a></div></div><div id="bodyColumn"><div class="contentBox"><div class="section"><a name="Apache_Sandesha"></a><h2>Apache Sandesha</h2><p>
Apache Sandesha is an implementation of the Web Services ReliableMessaging (WS-ReliableMessaging), published by the IBM, Microsoft and BEA as a joint specification, on top of Apache Axis (The Next Generation SOAP). Apache Sandesha provides; An implementation for WS-ReliableMessaging with the support to WS-Policy and WS- Addressing. Interoperability with other WS-ReliableMessaging implementations. Sandesha provides a complete support for WS-ReliableMessaging specification allowing a reliable communication between web services as well as web services and clients. It also provides the INORDER message delivery assurance for the users.
</p></div></div></div><div class="clear"><hr></hr></div><div id="footer"><div class="xright">� 2003-2005, Apache Web Services</div><div class="clear"><hr></hr></div></div></body></html>
\ No newline at end of file
1.1 ws-site/targets/ws-fx/sandesha/architecture.html
Index: architecture.html
===================================================================
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html><head><title>Sandesha - Architecture Guide of Apache Sandesha</title><style type="text/css" media="all">
@import url("./style/maven-base.css");
@import url("./style/maven-theme.css");</style><link rel="stylesheet" href="./style/print.css" type="text/css" media="print"></link><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"></meta></head><body class="composite"><div id="banner"><a href="http://ws.apache.org/" id="organizationLogo"><img alt="Apache Web Services" src="http://www.apache.org/images/asf-logo.gif"></img></a><a href="http://ws.apache.org/ws-fx/sandesha/" id="projectLogo"><img alt="Apache Sandesha" src="http://ws.apache.org/ws-fx/sandesha/images/Sandesha.jpg"></img></a><div class="clear"><hr></hr></div></div><div id="breadcrumbs"><div class="xleft">
Last published: 15 March 2005
| Doc for 1.0</div><div class="xright"></div><div class="clear"><hr></hr></div></div><div id="leftColumn"><div id="navcolumn"><div id="menuSandesha"><h5>Sandesha</h5><ul><li class="none"><a href="userguide.html">Simple User Guide</a></li><li class="none"><a href="architecture.html">Architecture Guide</a></li></ul></div><div id="menuProject_Documentation"><h5>Project Documentation</h5><ul><li class="none"><a href="index.html">About Apache Sandesha</a></li><li class="collapsed"><a href="project-info.html">Project Info</a></li><li class="collapsed"><a href="maven-reports.html">Project Reports</a></li><li class="none"><a href="http://maven.apache.org/development-process.html" class="externalLink" title="External Link">Development Process</a></li></ul></div><a href="http://maven.apache.org/" title="Built by Maven" id="poweredBy"><img alt="Built by Maven" src="./images/logos/maven-button-1.png"></img></a></div></div><div id="bodyColumn"><div class="contentBox"><div class="section"><a name="Architecture_Guide_of_Apache_Sandesha"></a><h2>Architecture Guide of Apache Sandesha</h2><p>Apache Sandesha is implemented on top of the
current version of Apache Axis. In-order to support the reliable message
delivery in web services there are set of new messages that needs to be passed
between the parties to the communication. According to the WS-RelibleMessging
specification these messages are exchanged between the RM Source and the RM
Destination and enable the delivery assurance. Rest of the this architecture
guide will focus on how Apache Sandesha has achieved the above goal and its
architecture.</p><div class="subsection"><a name="The_Model"></a><h3>The Model</h3><p>
WS-ReliableMessaging protocol
provides the solution for the reliable delivery of messages based on the pattern
<i>end-point managers</i>. The model proposed by the specification is as
follows, see [1].</p><p align="center">
<img border="0" src="images/RMModel.jpg" width="320" height="183" alt=""></img></p><p align="center">
</p><p align="center">
<font size="2">Figure 1: The Reliable Messaging Model</font></p></div><div class="subsection"><a name="Architecture_of_Apache_Sandesha"></a><h3>Architecture of Apache Sandesha</h3><p>The architecture of Sandesha was mainly guided by the requirements of the WS-ReliableMessaging protocol and
the Axis Architecture [2]. According to the specification it is a core
requirement that the RM Source has an endpoint reference.</p><p> �<i>?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.?</i>[1]
</p><p>
�As a consequence to the above fact
the Sandesha architecture cannot utilize the default synchronous message pattern
provided by the Axis engine for asynchronous invocations. A separate end point
reference is required for the RM Source. Similarly the server end point manger
is required to have an independent sender to support asynchronous responses.
Overall both client and server endpoint managers needs a sender and a receiver.
In order to support the connectivity between the sender and the receiver with
respect to particular end point manager Sandesha architecture uses an in-memory
Queue by default. The architecture providers the capability to plug a database
instead of a Queue, which will ultimately, leads to the persistence. </p><p>
So at this point the top level
architecture would be explained using the following diagram.</p><p align="center">
<img border="0" src="images/Architecture.jpg" width="440" height="201" alt=""></img></p><p align="center">
<font size="2">Figure 2: High Level Architecture of Apache Sandesha</font></p><p>This
architecture provides a complete support for both synchronous and asynchronous
messaging scenarios. WS-Addressing [3] provides the information for the
correlation of messages when the asynchronous pattern is adopted. However with
the use of two way transports (like HTTP), there is a possibility that the
Acknowledgements for the requests to be sent using the same connection. As shown
using the dotted lines) So the sender in both the sides should be able to handle
that accordingly. </p></div><div class="subsection"><a name="Sandesha__architecture_on_top_of_Apache_Axis"></a><h3>Sandesha architecture on top of Apache Axis</h3><p align="center"></p><p>
A more detailed view of the
architecture will emerge when the Axis specific components are added to the
above diagram. A complete diagram would be as follows.
</p><p align="center">
<img border="0" src="images/Architecture2.jpg" width="637" height="219" alt=""></img></p><p align="center">
<font size="2">Figure 3: Sandesha Architecture on top of Apache Axis</font></p><p>The
individual components and the message paths in the above diagram can be
described in more detailed as follows. </p></div><div class="subsection"><a name="Client"></a><h3>Client</h3><p>This is
the program that invokes (utilize) the web service. According to the high-level
architecture this is the Application Source<b>.</b></p></div><div class="subsection"><a name="Axis__Engine"></a><h3>Axis Engine</h3><p>This is
the apache Axis. Axis is essentially a SOAP engine
a framework for constructing SOAP processors such as clients, servers, gateways,
etc.</p></div><div class="subsection"><a name="RMSender"></a><h3>RMSender</h3><p>This is the transport
sender that the user should use in order to enable reliability in the client
side Axis Engine. However RMSender will not directly write the request to the
transport layer, instead it will insert the request to a Queue. </p></div><div class="subsection"><a name="Queue"></a><h3>Queue</h3><p>This is the persistence layer for Sandesha.
Currently the solution for reliability is achieved using an in-memory Queue. But
Sandesha provides an extensible storage manager for the storage and hence
replacing the Queue with a database is fairly easy. Although the Queue acts as a
single component, it will maintain two Queues for incoming and out going
messages internally.</p></div><div class="subsection"><a name="_Sender"></a><h3> Sender</h3><p>This is a running thread to send the request
messages. Sandesha uses the same sender in the server side to send the responses
(if any) to the client asynchronously. <br></br>
When the Sender sends a request using by directional transport protocol (e.g.
HTTP) there is a possibility (when the <wsa:From> [3] address is set to the
anonymous URI [3]) that the receiver sends the acknowledgment using the same
connection. However, it should be noted that Sandesha is not expecting any
application responses over the same connection. <br></br>
�</p></div><div class="subsection"><a name="Receiver"></a><h3>Receiver</h3><p>This is the listener for the client side and it is
the SimpleAxisServer that is used as the receiver for Sandesha. The
functionality of the Receiver is to accept the asynchronous SOAP messages and to
insert them to the Queue according to the correlation information present in the
message itself.</p></div><div class="subsection"><a name="RMProvider"></a><h3>RMProvider</h3><p>This is the provider used by Sandesha inside the
Axis engine in the server side. RMProvider will identify the incoming message
and insert the required message or messages to the Queue. It will also generate
messages for Reliable Messaging specific messages such as <wsrm:AckRequested>,
see [3].</p></div><div class="subsection"><a name="RMInvoker"></a><h3>RMInvoker</h3><p align="left">This is a runnable component that actually handles the
dispatching of the web service request to the actual service. RMInvoker will
also put the service response (if any) to the Queue present in the server side.</p></div><div class="subsection"><a name="Service"></a><h3>Service</h3><p>
This is the actual web
service, which will be the Application Destination according to the high-level
architecture.</p></div><div class="subsection"><a name="Messaging_Scenarios"></a><h3>Messaging Scenarios</h3><p>
There are many messaging scenarios that can be used to consume web services.
These combinations are created mainly by the usage of the WS-Addressing headers
and the MEPs of the service. Following sequence diagrams will explain some of
the possible combinations.</p></div><div class="subsection"><a name="Client_Side_-_Request_Only_with_Synchronous_Acknowledgement"></a><h3>Client Side - Request Only with Synchronous Acknowledgement</h3><p>
In this scenario, client makes a service request to a service with one way
operation. Client has specified that the operations are synchronous in nature.
So the RMSource will include the anonymous URI for the <wsa:From> EPR of the out
going messages. So the sequence acknowledgement will come only on the same
connection.</p><p style="text-align:center">
<img border="0" src="images/PingSync.png" width="717" height="360" alt=""></img></p><p style="text-align:center">
<font size="2">Figure 4: Client Side - Request Only with Synchronous
Acknowledgement</font></p><p style="text-align:center">
�</p></div><div class="subsection"><a name="Client_Side_-_Initialization"></a><h3>Client Side - Initialization</h3><p style="text-align: justify;">This is happening only at the first message of a
particular sequence. Web service client should initialize the reliable messaging
environment before sending messages. This can be done by calling the method�
initClient(true) in the RMInitiator class. This will Initialize the Queue,
Sender and the Client side receiver.</p><p style="text-align:center">
<img border="0" src="images/ClientInitialization.png" width="556" height="250" alt=""></img></p><p style="text-align:center">
<font size="2">Figure 5: Client Side - Initialization</font></p><p style="text-align:center">
�</p></div><div class="subsection"><a name="Client_Side_-_Termination"></a><h3>Client Side - Termination</h3><p>
This is happening only after the last message of a
particular sequence. Web service client should terminate the RM Environment
after receiving all the messages.� This can be done by calling the method�
stopClient() in the RMInitiator class. This will first check whether all the
sequence are complete with acknowledgements and then terminate the Queue, Sender
and the Client side receiver passing control back to the client.</p><p style="text-align:center">
<img border="0" src="images/ClientTermination.png" width="556" height="259" alt=""></img></p><p style="text-align:center">
<font size="2">Figure 6: Client Side - Termination</font></p><p style="text-align:center">
�</p></div><div class="subsection"><a name="Client_Side_-_Request_Only_with_Asynchronous_Acknowledgement"></a><h3>Client Side - Request Only with Asynchronous Acknowledgement</h3><p>
In this scenario client invoke a web service with one-way operation. When
sending the service requests the RMSource will include the client side endpoint
reference in the <wsa:From> address. So the sequence acknowledgements will be
sent through a new connection other than the one use for the request.</p><p style="text-align:center">
<img border="0" src="images/PingAsync.png" width="799" height="402" alt=""></img></p><p style="text-align:center">
<font size="2">Figure 7: Client Side - Request Only with Asynchronous
Acknowledgement</font></p><p style="text-align:center">
�</p></div><div class="subsection"><a name="Client_Side_-_Request_Response_with_Synchronous_Acknowledgement"></a><h3>Client Side - Request Response with Synchronous Acknowledgement</h3><p>
In this scenario client invoke a web service with two-way operation. When
sending the service requests the RMSource will include the anonymous URI in the
<wsa:From> address. So the sequence acknowledgements will be sent through the
same one use for the request (note that; this can only be used with two way
transports).</p><p>
�</p><p style="text-align:center">
<img border="0" src="images/EchoSync.png" width="814" height="403" alt=""></img></p><p style="text-align:center">
<font size="2">Figure 8: Client Side - Request Response with Synchronous
Acknowledgement</font></p><p style="text-align:center">
�</p></div><div class="subsection"><a name="Client_Side_-_Request_Response_with_Asynchronous_Acknowledgement"></a><h3>Client Side - Request Response with Asynchronous Acknowledgement</h3><p style="text-align:left">
In this scenario client invoke a web service with two-way operation. When
sending the service requests the RMSource will include the client side endpoint
reference in the <wsa:From> End Point Reference (EPR) and also in the <wsa:ReplyTo>
EPR. So the sequence acknowledgements will be sent through a new connection
other than the one use for the request. Service response will be received by the
client in a new sequence. Sending service response is similar to sending a
request in the client side. A separate sequence is created by the server (if the
client has not offered a sequence).</p><p style="text-align:center">
<img border="0" src="images/EchoAsync.png" width="825" height="414" alt=""></img></p><p style="text-align:center">
<font size="2">Figure 9: Client Side - Request Response with Asynchronous
Acknowledgement</font></p><p style="text-align:center">
�</p></div><div class="subsection"><a name="Server_Side_-_Request_Only_with_Synchronous_Acknowledgement"></a><h3>Server Side - Request Only with Synchronous Acknowledgement</h3><p align="left">This sequence diagram will illustrate the sequence of operations
that will be executed� when the RMDestination receives a One-way service
request. Sequence Acknowledgement is sent using the same connection.</p><p style="text-align:center">
<img border="0" src="images/ServerReqWithSyncAck.png" width="741" height="245" alt=""></img></p><p style="text-align:center">
<font size="2">Figure 10: Server Side - Request Only with Synchronous
Acknowledgement</font></p><p style="text-align:center">
�</p></div><div class="subsection"><a name="Server_Side_-_Request_Only_with_Asynchronous_Acknowledgement"></a><h3>Server Side - Request Only with Asynchronous Acknowledgement</h3><p align="left">This sequence diagram will illustrate the sequence of operations
that will be executed� when the RMDestination receives a One-way service
request. Sequence Acknowledgement is sent using a separate connection. This will
happen only if the <wsa:From> End Point Reference (EPR) is not anonymous URI.</p><p align="center">
<img border="0" src="images/ServerReqWithAsyncAck.png" width="741" height="325" alt=""></img></p><p align="center"><font size="2">Figure 10: Server Side - Request Only with
Asynchronous Acknowledgement</font></p><p align="center">�</p></div><div class="subsection"><a name="Server_Side_-_Request_Response_with_Synchronous_Acknowledgement"></a><h3>Server Side - Request Response with Synchronous Acknowledgement</h3><p align="left">In this scenario, the RMDestination will receive a service
request for an operation of request/response in nature. The incoming message has
anonymous URI for the <wsa:From> EPR and a non-anonymous� EPR for <wsa:ReplyTo>,
hence the acknowledgement is sent using the same connection with which the
service request has sent while the service response is sent using a different
connection.</p><p style="text-align:center">
<img border="0" src="images/ServerWithResponseSyncAck.png" width="741" height="343" alt=""></img></p><p style="text-align:center">
<font size="2">Figure 11: Server� Side - Request Response with Synchronous
Acknowledgement</font></p><p style="text-align:center">
�</p></div><div class="subsection"><a name="Server_Side_-_Request_Response_with_Asynchronous_Acknowledgement"></a><h3>Server Side - Request Response with Asynchronous Acknowledgement</h3><p align="left">In this scenario, the RMDestination will receive a service
request for an operation of request/response in nature. The incoming message has
non-anonymous EPR for the <wsa:From> EPR and a non-anonymous EPR for <wsa:ReplyTo>,
hence the acknowledgement is sent using the same connection with which the
service request has sent while the service response is sent using a different
connection.</p><p style="text-align:left">
�</p><p style="text-align:center">
<img border="0" src="images/ServerWithResponse.png" width="741" height="414" alt=""></img></p><p style="text-align:center">
<font size="2">Figure 12: Server� Side - Request Response with Asynchronous
Acknowledgement</font></p><p style="text-align:center">
�</p></div><div class="subsection"><a name="Conclusions_and_Future_Work"></a><h3>Conclusions and Future Work</h3><p align="left">Sandesha implements the WS-ReliableMessaging protocol on top of
Apache Axis. This has enabled the Axis community to perform web service
invocations reliably not only with Axis itself but also with other web service
platforms like Microsoft .NET which implements the above protocol. Currently
Sandesha does not provide the persistence with respect to software component
failures. This can be achieved using a database as the storage for SOAP messages
instead of an in-memory Queue. The future developments will mainly focus on this
area and also to implement Sandesha on top of Apache Axis 2, which is the new
version of Axis still under development.</p></div><div class="subsection"><a name="References"></a><h3>References</h3><p align="left">1. WS-RelliableMessaging protocol, available at
ftp://www6.software.ibm.com/software/developer/library/ws-reliablemessaging200502.pdf<br></br>
2. Apache Axis Architecture, available at http://ws.apache.org/Axis/java/architecture-guide.html
<br></br>
3. WS-Addressing specification, available at
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/</p><p align="left"><br></br>
�</p></div></div></div></div><div class="clear"><hr></hr></div><div id="footer"><div class="xright">� 2003-2005, Apache Web Services</div><div class="clear"><hr></hr></div></div></body></html>
1.1 ws-site/targets/ws-fx/sandesha/images/Architecture.jpg
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/Architecture2.jpg
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/ClientInitialization.png
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/ClientTermination.png
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/EchoAsync.png
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/EchoSync.png
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/PingAsync.png
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/PingSync.png
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/RMModel.jpg
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/ServerReqWithAsyncAck.png
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/ServerReqWithSyncAck.png
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/ServerWithResponse.png
<<Binary file>>
1.1 ws-site/targets/ws-fx/sandesha/images/ServerWithResponseSyncAck.png
<<Binary file>>