OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [ebxml-msg] scenario: relaying acks - more detail


Scenario:
-------------
Relayed ack

Summary:
---------------

In this scenario each leg in the communication between two endpoints is made reliable independent of the others. The end-to-end reliability is secured by relaying reliability signals between the legs (so a better name for this scenario would be relayed reliable messaging). 
For the intermediairies the relaying means that they will copy each incoming reliability signal to an outgoing sequence to the next hop, which might be another intermediary or the endpoint. 

Assumptions:
--------------------

- WS-RM is used to support the RM functionality

- Each intermediary knows the next hop for each ebMS message

- Only core V3 functionality is required at the endpoints


Detailed description:
------------------------------

The communication using intermediaries involves three components, at each endpoint a WS-RM enabled MSH and one or more intermediaries which are a special kind of MSH's. The difference between endpoint and intermediary is the way they handle the WS-RM signals, the endpoints handles them according to the core specification and the intermediary as described here.

As the intermediary has to relay the reliability signals between two legs in the communication it must have an administration of the legs and accompanying sequences and how those legs/sequences are related. This administration, the SequenceTable, can be modeled as a collection with each entry in it containing the source MSH, the sequence related to the source, the destination MSH and the sequence related to the destination. Both source and destination can be either an endpoint or another intermediary.

Upon arrival of a CreateSequence signal an entry in the SequenceTable is created. Because the CreateSequence signal has no information about the ultimate destination only the source and sequence can be set. To set the other two fields the destination has to be known and a sequence to it established. The intermediary will know this information after the first ebMS user message is sent on the newly created sequence. Based on that message it will be able to determine the next hop and set up a sequence to it by sending a CreateSequence. This way the entry is completed and all subsequent reliability signals can be relayed to the correct destination.

Attachment components.png shows the components playing a role in the relayed ack scenario.

Example
-------------

The attachment example_seq_diagram.png shows a sequence diagram for this scenario with one intermediary. In the messages.zip archive you'll find examples of messages exchanged between endpoint and intermediaries. In these example message there's no security used.

Evaluation
---------------

+ Flexible because reliability is realised per leg;

+ No additional functionality required on endpoint other than core specification; 

+ All intermediaries have the functionality; 

- Intemediaries modify SOAP headers;

- No end-to-end security possible on reliablity signals;


PNG image

PNG image



messages.zip


On 29 dec 2007, at 10:57, Sander Fieten wrote:

Scenario:
-------------
Relayed ack 

Summary:
---------------

In this scenario intermediaries only acknowledge a message when they have received the acknowledgement from the next hop, which might be another intermediary or the ultimate destination. By "relaying" the acks an end-to-end reliability is created because a message will only be acknowledged as it is acknowledged by the ultimate destination.

 

Assumptions:
--------------------

 

- The sender does not have to know the ultimate destination (MSH URL) of its messages;

 

- WS-RM is used to support the RM functionality;

- The communicationpath between the two endpoint MSH's contains one or more intermediaries;

Description:
------------------

 

Each intermediary must have a sequence relation table, let's say the SRT,  in which it relates sequence id's for which it receives messages to sequence id's which it uses to send messages. 

Now when a CreateSequence RM signal is received by the intermediary the sequence id for the new sequence is added to the SRT without a related "sending sequence id". The related (sending) sequence id can't be set at this point because we don't know the ultimate destination of this sequence. This will only be known at the arrival of the first ebMS user message. 

So when the first ebMS user message arrives the next hop on the communication path is determined by the intermediary and a new WS-RM sequence is set up with the next hop by sending a CreateSequence signal to it. The resulting sequence id is added to the already created entry in the SRT. Now all WS-RM signals, including the acknowledgments, can be relayed between the two sequences.
 
Evaluation:
----------------

 

Advantage of this solution is that it does not require additional processing on the endpoints to get end-to-end reliability. Because the intermediary relays everything based on its SRT it also works using asynchronous intermediaries
The main drawback is that because the RM path being divided into separate legs there's no end-to-end security on the RM level. 

 

----
Sander Fieten
IT Architect

FIETEN IT
t:  +31 6 51507886




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]