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/21 07:39:13 UTC
svn commit: r395785 - in /webservices/sandesha/trunk/xdocs:
architectureGuide.html images/architecture.jpg images/basicArchitecture.png
images/storage.jpg
Author: chamikara
Date: Thu Apr 20 22:39:11 2006
New Revision: 395785
URL: http://svn.apache.org/viewcvs?rev=395785&view=rev
Log:
Updated architecture guide
Added:
webservices/sandesha/trunk/xdocs/images/architecture.jpg (with props)
webservices/sandesha/trunk/xdocs/images/storage.jpg (with props)
Removed:
webservices/sandesha/trunk/xdocs/images/basicArchitecture.png
Modified:
webservices/sandesha/trunk/xdocs/architectureGuide.html
Modified: webservices/sandesha/trunk/xdocs/architectureGuide.html
URL: http://svn.apache.org/viewcvs/webservices/sandesha/trunk/xdocs/architectureGuide.html?rev=395785&r1=395784&r2=395785&view=diff
==============================================================================
--- webservices/sandesha/trunk/xdocs/architectureGuide.html (original)
+++ webservices/sandesha/trunk/xdocs/architectureGuide.html Thu Apr 20 22:39:11 2006
@@ -5,7 +5,7 @@
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<title>Sandesha2 Architecture guide</title>
- <meta name="generator" content="amaya 9.2.1, see http://www.w3.org/Amaya/"
+ <meta name="generator" content="amaya 9.2.2, see http://www.w3.org/Amaya/"
/>
</head>
@@ -15,152 +15,217 @@
<h2>Content</h2>
<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>
- </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>
+ <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="#da">Delivery Assurances</a></li>
+ <li><a href="#ps">Policy Support</a></li>
+ <li><a href="#tm">Transaction Model</a></li>
+ <li><a href="#es">Example Scenarios</a></li>
</ul>
<a name="intro"></a>
+
<h2>Introduction</h2>
-<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>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). <VERIFY> 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. RM Source is
-required to send each message one or more times. RM Destination sends back
+<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>
+to RMD, RMS sends a TerminateSequence message. If RMD receives this message
+it can free any resources allocated for this sequence. Otherwise reaource
+deallocation will happen based on a timeout.</p>
-<p>Following popular diagram explains the most basic operations of the RM
-Source and the RM Destination.</p>
+<p>Following diagram explains operation of the RMS and the RMD.</p>
<p><img alt="WS-RM Model" src="images/RMModel.jpg" /></p>
+<a>Sandesha2 support two reliable messaging specifications. It fully support
+WS-ReliableMessaging Feabruary 2005 specification which was created by
+collaboration of several companies. Later this specification was submitted to
+OASIS and currently being standerdised under the OASIS WS-RX tecnical
+committee. Sandesha2 support upto the revision <VERSION NO> of the
+specification being developed under this technical committee.</a> <a
+name="architecture"></a>
-<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>
-<a name="architecture"></a>
-<h2>Basic Architecture of Sandesha2</h2>
+<h2>Architecture</h2>
-<p><img alt="Basic Architecture" src="images/basicArchitecture.png" /></p>
+<p><img alt="Architecture" src="images/architecture.jpg" /></p>
<p></p>
-<p>Above diagram gives the basic architecture of Sandesha2. Let's try to
-understand each part of this in detail.</p>
-<a name="handlers"></a>
-<h3>Handlers</h3>
+<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>
+<a name="hnd"></a>
+
+<h2>Handlers</h2>
+
+<p>Sandesha2 adds three handlers to the excution 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>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>
-<a name="outhandler"></a>
-<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>
-
-<a name="inhandler"></a>
-<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>
-
-<a name="globalinhandler"></a>
-<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></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 throgh 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
+wil 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 plased 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>
-<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>
-<a name="msgprocessors"></a>
+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>
+<a name="mp"></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>
-<a name="inorder_invoker"></a>
+<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>
+<a name="ioi"></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>
-<a name="storage"></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>
+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>
+<a name="sf"></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
+perticular 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" /></p>
+
+<p></p>
<p>Storage framework define several beans that extend the RMBean abstract
-class. Currently there are five RMBeans. They are as follows:</p>
+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>
+ <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>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>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 roleback methods.</p>
<p>Collectively each Sandesha2 storage implementation should have following
classes:</p>
@@ -170,98 +235,114 @@
<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>
-<a name="delivery"></a>
-<h3>Delivery Assurances</h3>
+<p>These classes can be packed as a jar archieve 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>
+<a name="da"></a>
-<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>
+<h3>Delivery Assurances</h3>
-<p>Note: If you set an invalid value to this property, Sandesha2 will use the
-default.</p>
+<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>
+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>
-<a name="example"></a>
+
+<p></p>
+<a name="ps"></a>
+
+<h3>Policy Support</h3>
+
+<p></p>
+
+<h3></h3>
+<a name="es"></a>
+
<h2>Example Scenario</h2>
<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>
-<a name="client_side"></a>
+the RM Beans and their fields (which were mentioned before) in mind.</p>
+
<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>
+ <li>Client does the first fireAndForget method invocation of a
+ serviceClient after setting necessary properties.</li>
+ <li>Message reaches the SandeshaOutHandler which detects ie as an
+ application message. The processing is deligated 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>
+ creates a Terminate Sequence message and adds a corresponding entry to
+ the Sender bean manager.</li>
</ul>
-<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 appication maessage.
+ <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
@@ -269,11 +350,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/trunk/xdocs/images/architecture.jpg
URL: http://svn.apache.org/viewcvs/webservices/sandesha/trunk/xdocs/images/architecture.jpg?rev=395785&view=auto
==============================================================================
Binary file - no diff available.
Propchange: webservices/sandesha/trunk/xdocs/images/architecture.jpg
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: webservices/sandesha/trunk/xdocs/images/storage.jpg
URL: http://svn.apache.org/viewcvs/webservices/sandesha/trunk/xdocs/images/storage.jpg?rev=395785&view=auto
==============================================================================
Binary file - no diff available.
Propchange: webservices/sandesha/trunk/xdocs/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