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>>