You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by ch...@apache.org on 2006/04/26 09:05:33 UTC
svn commit: r397118 [1/2] - in /webservices/sandesha/site/sandesha2:
architectureGuide.html images/architecture.jpg images/basicArchitecture.png
images/storage.jpg userGuide.html
Author: chamikara
Date: Wed Apr 26 00:05:31 2006
New Revision: 397118
URL: http://svn.apache.org/viewcvs?rev=397118&view=rev
Log:
Updated the userguide and archi guide in the site.
Added:
webservices/sandesha/site/sandesha2/images/architecture.jpg (with props)
webservices/sandesha/site/sandesha2/images/storage.jpg (with props)
Removed:
webservices/sandesha/site/sandesha2/images/basicArchitecture.png
Modified:
webservices/sandesha/site/sandesha2/architectureGuide.html
webservices/sandesha/site/sandesha2/userGuide.html
Modified: webservices/sandesha/site/sandesha2/architectureGuide.html
URL: http://svn.apache.org/viewcvs/webservices/sandesha/site/sandesha2/architectureGuide.html?rev=397118&r1=397117&r2=397118&view=diff
==============================================================================
--- webservices/sandesha/site/sandesha2/architectureGuide.html (original)
+++ webservices/sandesha/site/sandesha2/architectureGuide.html Wed Apr 26 00:05:31 2006
@@ -2,169 +2,206 @@
@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/sandesha2" id="projectLogo"><img alt="Apache Sandesha2" 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: 06 March 2006
- | Doc for 0.9</div><div class="xright"></div><div class="clear"><hr></hr></div></div><div id="leftColumn"><div id="navcolumn"><div id="menuApache_Sandesha2"><h5>Apache Sandesha2</h5><ul><li class="none"><a href="index.html">Home</a></li><li class="expanded"><a href="">Downloads</a><ul><li class="none"><a href="download.cgi">Releases</a></li><li class="none"><a href="http://svn.apache.org/repos/asf/webservices/sandesha/trunk" class="externalLink" title="External Link">Source Code</a></li></ul></li><li class="expanded"><a href="">Documentation</a><ul><li class="none"><a href="userGuide.html">User Guide</a></li><li class="none"><a href="architectureGuide.html">Architecture Guide</a></li><li class="none"><a href="samplesGuide.html">Samples Guide</a></li><li class="none"><a href="apidocs/index.html">Java Docs</a></li></ul></li><li class="expanded"><a href="">Project Information</a><ul><li class="none"><a href="mail-lists.html">Mailing Lists</a></li><li class="no
ne"><a href="team-list.html">Project Team</a></li></ul></li></ul></div><div id="menuProject_Documentation"><h5>Project Documentation</h5><ul><li class="none"><a href="index.html">About Apache Sandesha2</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="Sandesha2_Architecture_Guide"></a><h2>Sandesha2 Architecture Guide</h2><div class="subsection"><a name="Content"></a><h3>Content</h3><ul>
+ Last published: 26 April 2006
+ | Doc for SNAPSHOT</div><div class="xright"></div><div class="clear"><hr></hr></div></div><div id="leftColumn"><div id="navcolumn"><div id="menuApache_Sandesha2"><h5>Apache Sandesha2</h5><ul><li class="none"><a href="index.html">Home</a></li><li class="expanded"><a href="">Downloads</a><ul><li class="none"><a href="download.cgi">Releases</a></li><li class="none"><a href="http://svn.apache.org/repos/asf/webservices/sandesha/trunk" class="externalLink" title="External Link">Source Code</a></li></ul></li><li class="expanded"><a href="">Documentation</a><ul><li class="none"><a href="userGuide.html">User Guide</a></li><li class="none"><a href="architectureGuide.html">Architecture Guide</a></li><li class="none"><a href="apidocs/index.html">Java Docs</a></li></ul></li><li class="expanded"><a href="">Project Information</a><ul><li class="none"><a href="mail-lists.html">Mailing Lists</a></li><li class="none"><a href="team-list.html">Project Team</a></li></ul></li></
ul></div><div id="menuProject_Documentation"><h5>Project Documentation</h5><ul><li class="none"><a href="index.html">About Apache Sandesha2</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="Apache_Sandesha2_Architecture_Guide"></a><h2>Apache Sandesha2 Architecture Guide</h2><div class="subsection"><a name="Content"></a><h3>Content</h3><ul>
<li><a href="#intro">Introduction</a></li>
- <li><a href="#architecture">Basic Architecture of Sandesha2</a>
- <ul>
- <li><a href="#handlers">Handlers</a></li>
+ <li><a href="#architecture">Architecture</a></li>
+ <li><ul>
+ <li><a href="#hnd">Handlers</a></li>
<li><a href="#sender">Sender</a></li>
- <li><a href="#msgprocessors">Message Processors</a></li>
- <li><a href="#inorder_invoker">InOrderInvoker</a></li>
- <li><a href="#storage">Storage Framework</a></li>
- <li><a href="#delivery">Delivery Assurances</a></li>
+ <li><a href="#mp">Message Processors</a></li>
+ <li><a href="#ioi">InOrderInvoker</a></li>
+ <li><a href="#sf">Storage Framework</a></li>
</ul>
</li>
- <li><a href="#example">Example Scenario</a>
- <ul>
- <li><a href="#client_side">Client side</a></li>
- <li><a href="#server_side">Server side</a></li>
- </ul>
- </li>
-</ul><p><a name="intro"></a></p></div><div class="subsection"><a name="Introduction"></a><h3>Introduction</h3><p>Sandesha2 implements Web services (WS)-ReliableMessaging (RM) for Axis2.
-From the point of view of Axis2 engine, Sandesha2 is a module. When this
-module is engaged to a service, that service gets reliable messaging
-capability. According to the WS-ReliableMessaging specification reliable
-communication happens between two endpoints. These endpoints are called the
-RM Source and the RM Destination. Before communication, RM Source and RM
-Destination perform a message exchange to create something called a sequence.
-A sequence is always identified by a unique sequenceID. The messages of a
-sequence are numbered starting from one.</p><p>The reliability is obtained basically using acknowledgements. RM Source is
-required to send each message one or more times. RM Destination sends back
+ <li><a href="#da">Delivery Assurances</a></li>
+ <li><a href="#es">Example Scenarios</a></li>
+</ul><p><a name="intro"></a></p></div><div class="subsection"><a name="Introduction"></a><h3>Introduction</h3><p>Sandesha2 gives reliable messaging capabilities Axis2. From the point of
+view of the Axis2 engine, Sandesha2 is a module. When this module is engaged
+to a service, clients have the option of invoking it in a reliable manner. In
+the client side Sandesha2 module can be used to interact with existing
+reliable web services.</p><p>According to the WS-ReliableMessaging specification which is implemented
+by Sandesha2, reliable communication happens between two endpoints. These
+endpoints are called the RM Source (RMS) and the RM Destination (RMD). Before
+communication, RMS and RMD perform a message exchange to create a
+relationship called a Sequence between them. A sequence is always identified
+by a unique Sequence Identifier.</p><p>Each message of a sequence is numbered, starting from one. In Sandesha2
+the maximum number of messages a sequence can support is 2 to the power 64
+(size of long). But practically this may be limited by the memory available
+for your system . The message number is used by the destination to support
+additional delivery assurances. This will be explained later in this
+tutorial.</p><p>The reliability is obtained basically using acknowledgements. RMS is
+required to send each message one or more times to the RMD. RMD sends back
acknowledgements to notify the successful reception of messages. After
-receiving the acknowledgement for a certain message RM Source can stop the
+receiving an acknowledgement for a certain message RMS can stop the
retransmission of that message.</p><p>When all messages of a certain sequence have been successfully transmitted
-to RM Destination, RM Source sends a TerminateSequence message to the RM
-Destination. If and when RM Destination receives this message it can free any
-resources allocated for this sequence.</p><p>Following popular diagram explains the most basic operations of the RM
-Source and the RM Destination.</p><p><img alt="WS-RM Model" src="images/RMModel.jpg"></img></p><p>Application Source which is basically the client code gives the messages
-to the RM Source. RM Source first does the initial message exchange with the
-RM Destination and establish a sequence. After that RM Source send the
-messages one or more times. RM Destination send back Acknowledgements. After
-receiving acknowledgements for all the messages RM Source will send a
-TerminateSequence message to the RM Destination.</p><p>RM Destination will obtain the messages and invoke them by passing to the
-Application Destination. If RM Destination is configured to invoke the
-messages in order, it will have to pause the invocation of some messages
-until all previous once have been received and invoked.</p><p><a name="architecture"></a></p></div><div class="subsection"><a name="Basic_Architecture_of_Sandesha2"></a><h3>Basic Architecture of Sandesha2</h3><p><img alt="Basic Architecture" src="images/basicArchitecture.png"></img></p><p></p><p>Above diagram gives the basic architecture of Sandesha2. Let's try to
-understand each part of this in detail.</p><p><a name="handlers"></a></p></div><div class="subsection"><a name="Handlers"></a><h3>Handlers</h3><p>Sandesha module deploy three handlers into Axis2 phases.</p><ol>
- <li><a href="#outhandler">SandeshaOutHandler</a></li>
- <li><a href="#inhandler">SandeshaInHandler</a></li>
- <li><a href="#globalinhandler">SandeshaGlobalInHandler</a></li>
-</ol><p><a name="outhandler"></a></p><p><b>SandeshaOutHandler</b> is the only handler added to the outFlow by
-Sandesha2 module. This handler stops the out going application messages till
-a sequence is established. The handler is deployed to the RMPhase of the
-outFlow.</p><p><a name="inhandler"></a></p><p><b>SandeshaInHandler</b> is the second handler of the inFlow. Since this
-is situated in the RMPhase which comes after the dispatch phase, this handler
-gets called only for messages that come to RM enabled services.</p><p><a name="globalinhandler"></a></p><p><b>SandeshaGlobalInHandler</b> is deployed to the predispatch phase (of
-inFlow) when the RM module is engaged. So this gets called for all the
-messages that come to Axis2. This performs global functions such as duplicate
-detection.</p><p><a name="sender"></a></p></div><div class="subsection"><a name="Sender"></a><h3>Sender</h3><p>Sender is responsible for transmission and retransmission of messages. The
+to RMD, RMS sends a TerminateSequence message. If RMD receives this message
+it can free any resources allocated for this sequence. Otherwise resource
+deallocation will happen based on a timeout.</p><p>Following diagram explains operation of the RMS and the RMD.</p><p><img alt="WS-RM Model" src="images/RMModel.jpg"></img></p><p><a>Sandesha2 support two reliable messaging specifications. It fully support
+WS-ReliableMessaging February 2005 specification which was created by
+collaboration of several companies. Later this specification was submitted to
+OASIS and currently being standardized under the OASIS WS-RX technical
+committee. Sandesha2 support up to the revision CD 3 of the specification
+being developed under this technical committee.</a><a name="architecture"></a></p></div><div class="subsection"><a name="Architecture"></a><h3>Architecture</h3><p><img alt="Architecture" src="images/architecture.jpg"></img></p><p></p><p>Sandesha2 components are used in a completely symmetric manner, in the
+server side and the client side, as shown in the diagram above. So lets
+consider a single side in this discussion.</p><p><a name="hnd"></a></p></div><div class="subsection"><a name="Handlers"></a><h3>Handlers</h3><p>Sandesha2 adds three handlers to the execution chain of Axis2. Two of
+these handlers are added to a special user phase called 'RMPhase' of in and
+out flows. Other handler is added to the predispatch phase of the inFlow.
+These handlers and their functions are given below.</p><p></p><p><b>SandeshaInHandler</b></p><p>This is added to the 'RMPhase' of the inFlow. Since RMPhase is a user
+phase, this handler will only be invoked for messages that are aimed at RM
+enabled service. This handler will identify the type of this message. The
+type can be an application message (a message that has to be delivered to the
+service) or a RM control messages. Sandesha2 has a special set of classes
+called message processors which are capable of processing each type of
+message. Depending on the type, the message is send through the
+'processInMessage' method of the message processor which will do the further
+processing of it.</p><p></p><p><b>SandeshaOutHandler</b></p><p>This handler is responsible for doing the basic outFlow processing. This
+will first generate an ID called the Internal Sequence ID which is used to
+identify the sequence this message should belong to. All the messages having
+the same Internal Sequence ID will be send within a single sequence. An
+Internal Sequence ID will have a corresponding Sequence ID which would be
+obtained after the Create Sequence message exchange. In the client side the
+Internal Sequence ID is the combination of the wsa:To address and a special
+value given by the client called Sequence Key. In the server side the
+Internal Sequence ID is a derivation of the Sequence ID value of the messages
+of the incoming sequence.</p><p>Before sending the message through other handlers the SandeshaOutHandler
+will send it throgh the 'processOutMessage' method of the respective message
+processor.</p><p></p><p><b>SandeshaGlobalInHandler</b></p><p>This handler is added to the predispatch phase of the inFlow. Since this
+is a global phase, this handler will be called for each and every message
+that comes to the Axis2 system. To maximize performance the very first
+function of this handler is to identify weather the current message is
+processable by it. It checks weather the message is intended for a RM enabled
+service and if so check the message type to further verify weather it should
+be processed globally. This handler was placed to perform functions that
+should be done before the instance dispatching level of Axis2. Some of those
+are given below.</p><p>Detecting duplicate messages and dropping them.</p><p>Detecting faults that occur due to RM control messages and reporting
+them.</p><p>Answering to acknowledgement requests of the dropped application
+messages.</p><p></p></div><div class="subsection"><a name="Sender"></a><h3>Sender</h3><p>Sender is responsible for transmission and retransmission of messages. The
Sender is a separate thread that keeps running all the time. At each
-iteration Sender checks the Sandesha2 storage to see weather there are any
-messages to be sent. If there are any, then they are sent. If a message sent
-does not have to be retransmitted the Sender deletes this entry from the
-storage. Or else the entry is only modified, and will be sent at some other
-time. How exactly this happens will be explained later in this document.</p><p><a name="msgprocessors"></a></p></div><div class="subsection"><a name="Message_Processors"></a><h3>Message Processors</h3><p>Sandesha2 have a set of message processors each implementing the
-MessageProcessor interface. Each message processor is responsible for
-processing a certain type of message. For example CreateSequenceProcessor
-will process incoming CreateSequence messages and Acknowledgement processor
-will process incoming Acknowledgement messages. Please check the <a href="">class diagram</a> to see all the MessageProcessors.</p><p><a name="inorder_invoker"></a></p></div><div class="subsection"><a name="InOrderInvoker"></a><h3>InOrderInvoker</h3><p>InOrderInvoker is another separate thread that get started by the
+iteration Sender checks weather there is any messages to be sent. If there is
+any, it is sent to the destination. Sender also identifies messages that has
+to be retransmitted and keep re-sending them until a limit decided by
+Sandesha2 policies (explained later) is exceeded.</p><p><a name="mp"></a></p></div><div class="subsection"><a name="Message_Processors"></a><h3>Message Processors</h3><p>Sandesha2 have a set of classes called message processors each
+implementing the MessageProcessor interface. Each message processor is
+responsible for processing a certain type of message. For example
+CreateSequenceProcessor will process CreateSequence messages and
+AcknowledgementProcessor will process Acknowledgement messages. The message
+processor interface define two methods for processing incoming messages and
+outgoing messages.</p><p><a name="ioi"></a></p></div><div class="subsection"><a name="InOrderInvoker"></a><h3>InOrderInvoker</h3><p>InOrderInvoker is another separate thread that get started by the
Sandesha2 system. This is started only if Sadesha2 has been configured to
-support InOrder Invocation delivery assurance. InOrderInvoker is responsible
-for invoking messages of a sequence in the order of message numbers.</p><p><a name="storage"></a></p></div><div class="subsection"><a name="Sandesha2_Storage_Framework"></a><h3>Sandesha2 Storage Framework</h3><p>Sandesha2 storage framework can be considered as the cornerstone of
-Sandesha2 system. This was designed to support the RM Message exchange while
-being independent of the storage implementation used. Two main storage
-implementations are InMemory storage implementation and Database based
-storage implementation.</p><p>Storage framework define several beans that extend the RMBean abstract
-class. Currently there are five RMBeans. They are as follows:</p><ol>
+support in-order delivery assurance. InOrderInvoker makes sure that it invoke
+messages of a sequence only in the order of message numbers.</p><p></p><p><a name="sf"></a></p></div><div class="subsection"><a name="Storage_Framework"></a><h3>Storage Framework</h3><p>Sandesha2 storage framework is one of the most important parts of the
+Sandesha2 system. This was designed to support the RM message exchange while
+being independent of the storage implementation used. The storage framework
+defines a set of interface and abstract classes that can be implemented by a
+particular storage implementation. Sandesha2 system comes with an in-memory
+storage implementation. There can be other implementations based on different
+databases and persistence mechanisms.</p><p>Following diagram gives a brief view of the Sandesha2 storage
+framework.</p><p><img alt="Storage" src="images/storage.jpg"></img></p><p></p><p>Storage framework define several beans that extend the RMBean abstract
+class. They are given below.</p><ol>
<li>CreateSequenceBean (fields - InternalSequenceID, CreateSequenceMsgID,
SequenceID)</li>
- <li>SenderBean (fields - key, internalSequenceID, msgNo, msgID, msgType,
- send, resent, sentCount)</li>
- <li>NextMsgBean (fields - sequenceID, nextMsgToInvoke)</li>
- <li>InvokerBean (fields - key, sequenceID, msgNo)</li>
- <li>SequencePropertyBean (fields - sequenceID, propertyName,
- propertyValue)</li>
-</ol><p>Each storage implementation should have five BeanManagers that define how
-to manage each of these beans. There are five BeanManager interfaces that
-define how the managers should be defined. Also there is a StorageManager
-interface that define methods to create each of these BeanManagers. Another
-interface called Transaction has general transaction methods such as commit
-and roleback.</p><p>Collectively each Sandesha2 storage implementation should have following
+ <li>SenderBean (fields - messageContextRefKey, internalSequenceID,
+ messageNumber, messageID, messageType, send, resent,
+ sentCount,timeToSend)</li>
+ <li>NextMsgBean (fields - sequenceID, nextMsgToProcess)</li>
+ <li>InvokerBean (fields - invoked,messageContextRefKey, sequenceID,
+ msgNo)</li>
+ <li>SequencePropertyBean (fields - sequenceID, name, value)</li>
+</ol><p>There are five bean manager interfaces corresponding to each of above
+beans.</p><ol>
+ <li>CreateSequenceBeanMgr</li>
+ <li>InvokerBeanMgr</li>
+ <li>NextMsgBeanMgr</li>
+ <li>SenderBeanMgr</li>
+ <li>SequencePropertyBeanMgr</li>
+</ol><p>Sandesha2 also define a StorageManager interface that define methods to
+create each of these bean managers and to create a Transaction object which
+should implement the Transaction interface. Transaction interface define
+commit and rollback methods.</p><p>Collectively each Sandesha2 storage implementation should have following
classes:</p><ol>
<li>An implementation of the StorageManager interface.</li>
<li>Implementations of five Bean Manager interfaces.</li>
<li>An implementation of a Transaction interface.</li>
-</ol><p>After implementing these, the user has to add them to the classpath (may
-be as a .jar) and include the name of the StorageManager implementation class
-in the sandesha2.properties file (This will tell Sandesha2 to use this
-storage implementation as the default). Once this is done Axis2 engine needs
-to be restarted before Sandesha2 can use the storage implementaion as the
-default.</p><p><a name="delivery"></a></p></div><div class="subsection"><a name="Delivery_Assurances"></a><h3>Delivery Assurances</h3><p>You can instruct Sandesha2 to give the delivery assurance you want. The
-basic configurable delivery assurance we provide is the ordering of messages.
-By setting the InOrderInvocation property of Sandesha2.properties file to
-true (the default), you can tell Sandesha2 to invoke messages of a sequence
-in a particular order. This order will be decided based on the
-wsrm:messageNumber. If you set this property to false, Sandesha2 will invoke
-messages as and when they come.</p><p>Note: If you set an invalid value to this property, Sandesha2 will use the
-default.</p><p>The delivery assurance to be used depends on your requirements. If you
+</ol><p>These classes can be packed as a jar archive and added to the
+classpath.The name of the StorageManager implementation class has to be
+mentioned in Sandesha2 policy configurations. This will be picked up after a
+restart of the the Axis2 engine.</p><p><a name="da"></a></p></div><div class="subsection"><a name="Delivery_Assurances"></a><h3>Delivery Assurances</h3><p>Sandesha2 can provide an in-order exactly once delivery assurance. The
+ordering is optional. You can disable it using Sandesha2 policy
+configurations. The ordering is done using the InOrderInvoker thread that was
+introduced earlier. If ordering is enabled, SandeshaInhandler pauses the
+execution of an incoming application messages. Because of this the message
+will not go through rest of the handler chain in the first invocation. It
+also starts the InOrderInvoker thread if it is stopped. This thread goes
+through the paused messages and resume each of them in the order of message
+numbers.If in-order invocation is not enabled the SandeshaInHandler will not
+pause the messages and they will go in their full execution path in a one
+go.</p><p>The delivery assurance to be used depends on your requirements. If you
want the invocation to be as fast as possible, and you do not care about
-ordering, set the property to false. If you want message ordering, then set
-property to true. There could be a considerable performance improvement if
-you set property to false.</p><p>Internally Sandesha2 starts a special thread if in-order invocation is
-required (InOrderInvoker). This thread which is continuously running will
-only invoke the messages in order.</p><p>In the current implementation each message (identified by sequenceID and
+ordering, disable in order invocation. But if you want message to be invoked
+in the order they were sent by the client, you have to enable it. There could
+be a considerable performance improvement if this feature is disabled.
+Specially if majority of the messages come out of order.</p><p>In the current implementation each message (identified by sequenceID and
message number) will be invoked only once. So exactly once delivery assurance
is guaranteed. You cannot ask Sandesha2 to invoke the same message more than
-once.</p><p><a name="example"></a></p></div><div class="subsection"><a name="Example_Scenario"></a><h3>Example Scenario</h3><p>This part explains how Sandesha2 framework work internally for the most
+once.</p><p></p></div><div class="subsection"><a name="Example_Scenario"></a><h3>Example Scenario</h3><p>This part explains how Sandesha2 framework work internally for the most
common RM scenario, which is the sending of a couple of Ping messages from a
client to the server. We will mainly look at how Sandesha2 use its storage to
do the RM message exchange correctly. While going through the following, keep
-in mind the RM Beans and their fields which were mentioned before.</p><p><a name="client_side"></a></p></div><div class="subsection"><a name="Client_side"></a><h3>Client side</h3><ul>
- <li>Client invoke the call.</li>
- <li>SandeshaOutHandler pauses the message and create a new
- CreateSequenceRequest message.</li>
- <li>SandeshaOutHandler adds an entry to the CreateSequenceBeanManager. The
- internalSequenceId is an identifier unique to the whole sequence. For the
- client side this is the concatenation of wsa:To and a constant set by the
- client (SEQUENCE_KEY). The sequenceID property is initially null. The
- createSeqMsgID is the message ID of the created CreateSequence
- message.</li>
- <li>SandeshaOutHandler adds two entries to the SenderBeanManager, one which
- has the send property to 'false' which represents the application
- message, other which has the send property to 'true' which represents the
- CreateSequence message. The Sender thread sends (and retransmits) only
- the CreateSequence message.</li>
- <li>Sometime later the client side receives an CreateSequenceResponse
- message from the server. The SandeshaInHandler which is the Sandesha2
- handler in the InFlow finds this message and delegates the processing to
- the CreateSequenceResponse message processor. It finds the correct
- CreateSequence manager entry using the createSequenceMessageID property
- (the value of the create sequence message ID comes in the relatesTo part
- of the Create Sequence Response message).</li>
- <li>Client updates the sequenceID property of the CreateSequenceBeanManager
- entry. Also the send value of the application message entries are set to
- true, so that the Sender starts sending (and retransmitting) them.</li>
- <li>When the client receives acknowledgements for the messages it sent, the Acknowledgement to the Acknowledgement
- processor, it removes the corresponding entry of that application message
- from the SenderBeanManager.</li>
+the RM Beans and their fields (which were mentioned before) in mind.</p></div><div class="subsection"><a name="Client_side"></a><h3>Client side</h3><ul>
+ <li>Client does the first fireAndForget method invocation of a
+ serviceClient after setting necessary properties.</li>
+ <li>Message reaches the SandeshaOutHandler which detects it as an
+ application message. The processing is delegated to the processOutMessage
+ method of the Application Message Processor.</li>
+ <li>Application Message Processor generate the Internal Sequence ID as
+ explained earlier. It understands that this is a new sequence and
+ generate a Create Sequence Message for it. The Application Message get
+ paused.</li>
+ <li>SandeshaOutHandler adds an entry to the CreateSequence bean manager
+ representing the newly created Create Sequence message. This entry has
+ three properties.The sequenceID property is initially null. The
+ createSeqMsgID is the message ID of the created CreateSequence message.
+ The internalSequenceID property get the generated Internal Sequence ID
+ value.</li>
+ <li>SandeshaOutHandler adds two entries to the SenderBeanManager. One which
+ has the send property to 'false' represents the application message,
+ other which has the send property to 'true' represents the CreateSequence
+ message. The Sender thread sends (and retransmits) only the
+ CreateSequence message.</li>
+ <li>After some time the client side would receive a Create Sequence
+ Response message from the server. The SandeshaInHandler delegates the
+ processing to the CreateSequenceResponse message processor. It finds the
+ correct CreateSequence manager entry using the createSequenceMessageID
+ property (which is in the relatesTo entry of the response message).</li>
+ <li>Client updates the sequenceID property of the CreateSequence bean
+ manager entry. Also the send value of the application message entries are
+ set to 'true'. The sender start transmitting and retransmitting
+ application messages.</li>
+ <li>When the client receives acknowledgements for the messages it send,
+ they are delivered to the Acknowledgement Processor which removes the
+ corresponding application message entries from the Sender bean
+ manager.</li>
<li>If an acknowledgement says that all the sent messages (up to last
message) were successfully received, the Acknowledgement processor
- creates an TerminateSequence message and adds a corresponding entry to
- the Sender table.</li>
-</ul><p><a name="server_side"></a></p></div><div class="subsection"><a name="Server_side"></a><h3>Server side</h3><ul>
+ creates a Terminate Sequence message and adds a corresponding entry to
+ the Sender bean manager.</li>
+</ul></div><div class="subsection"><a name="Server_side"></a><h3>Server side</h3><ul>
<li>Server receives a CreateSequence message. It generates a new sequence
- ID and creates a new CreateSequenceResponse message containing this ID.</li>
- <li>Server adds an entry to the NextMessageBeanManager. The initial value for
- nextMessageToInvoke is 1.</li>
- <li>Server adds an entry to the SenderBeanManager (of server side) representing the application message. The
- send value is true. The CreateSequenceResponse message is sent by the
- Sender.</li>
+ ID and creates a new Create Sequence Response message containing this
+ ID.</li>
+ <li>Server adds an entry to the NextMessage Bean Manager. The initial value
+ for nextMessageToInvoke property is 1.</li>
+ <li>Server adds an entry to the SenderBeanManager (of server side)
+ representing the application message. The send value is'true'. The
+ CreateSequenceResponse message is sent by the Sender.</li>
<li>After some time the server receives an application message. The server
side SandeshaInHandler delegates this to the ApplicationMessageProcessor
- which creates an Acknowledgement and sends it. If InOrder invocation is
- enabled, an entry is added to the InvokerBeanManager representing this new appication maessage.
- <p>Lets consider the message number of this message as 2.</p></li>
+ which creates an acknowledgement and sends it. If in-order invocation is
+ enabled, an entry is added to the InvokerBeanManager representing this
+ new application message.
+ <p>Lets assume that the message number of this message is 2.</p>
+ </li>
<li>The InOrderInvoker which keeps looking at the InvokerBeanManager
entries sees that there are entries to be invoked.</li>
<li>The InOrderInvoker checks the entry of the NextMessageBeanManager of
@@ -172,11 +209,12 @@
number 2 is present in the invokerBeanManager entries, the invocation is
not done.</li>
<li>After some time, application message 1 also comes. Now the Invoker sees
- this entry and invokes the message. It also updates the nextMessageToInvoke property of
- NextMessageBeanManagerto 2. The invoker again checks whether the new entry for the NextMessageToInvoke
- (2) is present in the InvokerBeanManager entries. Since this is present
- it is also invoked. The value is again updated (to 3) but no invocation
- is done since an entry is not found.</li>
+ this entry and invokes the message. It also updates the
+ nextMessageToInvoke property of NextMessageBeanManagerto 2. The invoker
+ again checks whether the new entry for the NextMessageToInvoke (2) is
+ present in the InvokerBeanManager entries. Since this is present it is
+ also invoked. The value is again updated (to 3) but no invocation is done
+ since an entry is not found.</li>
<li>Some time later the server may receive an TerminateSequence message. It
can partly remove the resources allocated for the sequence. The other
part of resources (which is required by the InOrderInvoker) is removed
Added: webservices/sandesha/site/sandesha2/images/architecture.jpg
URL: http://svn.apache.org/viewcvs/webservices/sandesha/site/sandesha2/images/architecture.jpg?rev=397118&view=auto
==============================================================================
Binary file - no diff available.
Propchange: webservices/sandesha/site/sandesha2/images/architecture.jpg
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: webservices/sandesha/site/sandesha2/images/storage.jpg
URL: http://svn.apache.org/viewcvs/webservices/sandesha/site/sandesha2/images/storage.jpg?rev=397118&view=auto
==============================================================================
Binary file - no diff available.
Propchange: webservices/sandesha/site/sandesha2/images/storage.jpg
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org