More thoughts on relayed reliable messaging scenario

Relayed reliable messaging 
scenario

 

Here are some further thought 
about the relayed reliable messaging scenario. 

Key elements:

-         
End-to-end reliable messaging based on propagating 
acknowledgments

-         
Optional end-to-end security using a separate WSSE 
header

-         
No assumption that all messages sent on a sequence have to 
be delivered ultimately at a single MSH.

-         
An MSH can be Intermediary or Endpoint depending on ebMS 
header content. 

-         
Extensible to support message batching 

 

Introduction

The discussion will refer to 
three levels of connections:

  
HTTP 
  transport connections. 
  
SOAP 
  messaging.  
  
ebMS 
  end-to-end messaging

 

In the following diagram, arrows 
1, 2, 3 and 4 are level 1 connections. Arrows 5 and 6 are level 2 connections. 
Arrow 7 is an ebMS end-to-end level 3 connection:

 

 

A SOAP messaging connection can 
involve multiple (non-ebMS aware) SOAP intermediaries. An ebMS intermediary is 
viewed as an endpoint from the SOAP messaging perspective. An end-to-end ebMS 
message that crosses n ebMS 
intermediaries is composed of n+1 
SOAP message connections. 

 

Addressing

  
Addressing 
  at HTTP transport level involves a mapping from next-SOAP node URIs to IP 
  addresses 
  
Addressing 
  at SOAP message level can be based on processing WS-A header elements like wsa:To, wsa:Action 
  
Addressing 
  at ebMS level for end-to-end messaging is based on processing ebMS header 
  elements such as eb:To/eb:PartyId.

 

Reliable messaging

  
Higher-level 
  protocols compensate for any unreliabilities at the HTTP connection level. 
  
WSRM 
  can be used for reliability at each SOAP message connection level. 
  
End-to-end 
  ebMS reliability is achieved by marking received SOAP messages that are 
  forwared as delivered only when the next hop has acknowledged receipt.

 

This proposal is compatible with 
WSR as alternative reliable messaging spec.

 

Security

1.      
The HTTP transport can be secured using TLS

2.      
The SOAP message connection can be secured using a 
WS-Security header block. The target of this header block is the ebMS 
intermediary (for all SOAP connections other than the last).  The full SOAP header (including WS-A, 
WS-RM and ebMS extension blocks) and all payloads are signed (or whichever 
headers RSP wants people to sign). This WSSE header block is created by the 
initial sending endpoint and validated and discarded by each subsequent ebMS 
node (intermediary or endpoint). Each ebMS intermediary again applies WSSE SOAP 
message security (on all headers) before it forwards a message.  

3.      
The end-to-end ebMS message connection can be secured using 
a separate WSSE header, targeted at the final ebMS recipient. This header 
encrypts the business documents (in the SOAP body and/or in the MIME 
attachments) and signs these business documents and the ebMS header. It does not 
sign the WS-A and/or WS-RM headers, as these are processed at the SOAP message 
connection level. Any ebMS intermediary must not process this end-to-end 
security header, but copy it to the forwarded message.

 

In some communities there may not 
be a need for the “end-to-end security” provided by the separate WSSE header, if 
the Intermediaries are known and are trusted to perform TLS and WSSE validation 
of incoming messages. In that case only the special forwarding functionality is 
needed.

 

Reliable Secure Profile

The use of WS-A WSRM and the SOAP 
message WSSE headers should comply with the upcoming Reliable Secure Profile. 
This is possible if the RSP does not prevent:

·        
The “ack on successful forward” semantics of relayed 
reliable messaging.

·        
The presence of a second WSSE header.

 

Sequence lifecycle 
messages

Any pair of ebMS nodes, endpoints 
or intermediaries, is free to establish any number of reliable sequences. These 
sequences can be established “just-in-time” or “ahead-of-time” (see http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/27235/ebMS-end2end-RM-scenario4.doc). 

 

Since reliable sequences are 
established at SOAP message level, not ebMS level, the sequence lifecycle 
messages need not be bundled with any ebMS headers.  They can be routed across non-ebMS 
intermediaries that can process WS-Addressing headers. No special functionality 
is required.

 

Any node needs only set up a few 
reliable sequences to any ebMS node it connects to, one for each set of reliable 
messaging parameters (e.g. At-Least-Once or At-Most-Once, various retry 
intervals). In the following diagram, the Intermediary can reuse a reliable 
connection to “Receiver C” to send messages from “Sender A” and messages from 
“Sender B”. This assumes we can generalize “Sequence Mapping” to “Message 
Mapping” (see below). This is a major advantage over the end-to-end reliable 
messaging scenario.  Assume an 
intermediary that acts as a central business activity monitoring facility for n business partners. Assume k sets of reliable messaging parameters, 
then the community needs to set up 2 * k 
* n reliable messaging sequences. In situations with end-to-end sequences, 
there will be a need for k * n* (n-1) sequences. Practical values for k will be just a handful, but the values 
for n may be in the hundreds or 
thousands, so this is a huge practical advantage. 

 

 

 

Relayed acknowledgment

The scenario assumes that all 
incoming reliable messages are not acknowledged “on receipt”, but “on 
delivery”.  Whatever mechanism is 
used to establish whether the message is successfully delivered should be 
extended such that “reliably forwarded” is a kind of successful delivery.

When Intermediary receives an 
acknowledgment for Message 1 on Int-C from Receiver C, the MSH should mark 
Message 1 on A-Int from Sender A as “delivered”. Subsequent SOAP messages with 
WSRM header blocks like the following will then get confirmation on successful 
delivery of this message.

 

<?xml version="1.0" encoding="UTF-8"?>

<wsrm:Ackrequested>

    
<wsrm:Identifier>A-Int</wsrm:Identifier>

</wsrm:Ackrequested>

 

Message mapping table

The SequenceTable proposed in http://lists.oasis-open.org/archives/ebxml-msg/200801/msg00009.html 
assumes a one-to-one mapping between sequence ids. This can be generalized to a 
Message Mapping table: 

 

  
  

    
      
From

    
      
Sequence

    
      
Message-Number

    
      
To

    
      
Sequence

    
      
Message-Number

  

    
      
Sender A

    
      
A-Int

    
      
1

    
      
Receiver C

    
      
Int-C

    
      
1

  

    
      
Sender A

    
      
A-Int

    
      
2

    
      
Receiver C

    
      
Int-D

    
      
2

  

    
      
Sender A

    
      
A-Int

    
      
3

    
      
Receiver D

    
      
Int-D

    
      
1

  

    
      
Sender B

    
      
A-Int

    
      
4

    
      
Receiver D

    
      
Int-D

    
      
2

 

The MSH needs to implement some 
trigger mechanism such that receipt acknowledgments for forwarded messages 
result in marking incoming messages as marked. This is the area where WSRM 
processors will need to be modified to be used by ebMS intermediaries.

Note that the IDs in this table 
are WSRM MessageIds, not ebMS MessageIds.

 

Mixed Intermediaries / 
Endpoints

In situations where Intermediary 
is an Endpoint for some messages and an intermediary for others, the MSH can 
mark received messages as delivered immediately. No entry is added to the 
Message Mapping Table.

 

The decision whether to forward 
or deliver can be based on ebMS header data, such as eb:To/eb:PartyId.  Basically any pattern that can be used 
to decide on routing can be used here. Delivering instead of forwarding becomes 
a kind of routing decisions.

 

Local configurability

This proposal supports a 
“localized” configuration where many important connection configuration changes 
about an Endpoint need only be accounted for at the “last” Intermediary.  An eb:To/eb:PartyId or eb:Service can migrate from one MSH to 
another just by notifying the nearest Intermediary. See http://lists.oasis-open.org/archives/ebxml-msg/200802/msg00025.html 
for discussion.

 

Sample messages

A sample ebMS message from Sender 
A to Intermediary, sent over A-Int is shown:

 

<?xml version="1.0" encoding="UTF-8"?>

<S:Header 
xmlns:S="http://www.w3.org/2003/05/soap-envelope"

    
xmlns:wsa="http://www.w3.org/2005/08/addressing"

    
xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">

    
<wsse:Security

        
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

        
actor="intermediary">

        
<!-- This is the security block 
targeted at the next ebMS node. It signs the SOAP header including all WS-A and 
WS-RM headers, ebMS header and all encrypted payloads.  -->

    
</wsse:Security>

    
<wsse:Security

        
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

        
actor="receiver">

        
<!-- This is the security block 
targeted at the ultimate ebMS node. It can be used to sign and encrypt the ebMS 
and payloads, not any WS-A and WS-RM headers as those are per 
hop-->

    
</wsse:Security>

    
<wsa:To>http://int.com/msh</wsa:To>

    
<wsa:Reply-To>

        
<wsa:Address>http://senderA.com/msh</wsa:Address>

    
</wsa:Reply-To>

    
<wsrm:Sequence>

        <!--  
The message is sent on a sequence between Source and Intermediary 
-->

        
<wsrm:Identifier>A-Int</wsrm:Identifier>

        
<wsrm:MessageNumber>1</wsrm:MessageNumber>

    
</wsrm:Sequence>

    
<eb:Messaging xmlns:eb=":http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">

        
<eb:UserMessage>

            
<!-- ebMS user message. Must be 
unencrypted to support routing at intemediary  -->

        
</eb:UserMessage>

    
</eb:Messaging>

</S:Header>

 

 

This message is forwarded from 
Intermediary to Receiver C, sent over Int-C. Note that both WSSE are addressing 
the same WSSE endpoint, but in different roles:

 

<?xml version="1.0" encoding="UTF-8"?>

<S:Header 
xmlns:S="http://www.w3.org/2003/05/soap-envelope"

    
xmlns:wsa="http://www.w3.org/2005/08/addressing"

    
xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">

    
<wsse:Security

        
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

        
actor="intermediary">

        
<!-- This is the security block 
targeted at the next ebMS node, which happens to be the true endpoint in this 
case. Intermediary signs the SOAP header including all WS-A and WS-RM headers, 
ebMS header and all encrypted payloads.  
-->

    
</wsse:Security>

    
<wsse:Security

        
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

        
actor="receiver">

        
<!-- This is the security block 
targeted at the ultimate ebMS MSH. It can be used to sign and encrypt the ebMS 
and payloads, not any WS-A and WS-RM headers as those are per 
hop-->

    
</wsse:Security>

    
<wsa:To>http://receiverC.com/msh</wsa:To>

    
<wsa:Reply-To>

        
<wsa:Address>http://int.com/msh</wsa:Address>

    
</wsa:Reply-To>

    
<wsrm:Sequence>

        
<!--  The message is sent on a sequence 
between Source and Intermediary -->

        
<wsrm:Identifier>Int-C</wsrm:Identifier>

        
<wsrm:MessageNumber>1</wsrm:MessageNumber>

    
</wsrm:Sequence>

    
<eb:Messaging xmlns:eb=":http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">

        
<eb:UserMessage>

            
<!-- ebMS user message  -->

        
</eb:UserMessage>

    
</eb:Messaging>

</S:Header>

 

Batching and 
Un-Batching

 

The Message Mapping Table and modified “Mark Delivered” 
semantics discussed before assumes a one-to-one mapping between incoming and 
forwarded messages.  This mechanism 
can be generalized to support batching (combining multiple messages and sending 
them in one larger message) or unbatching (splitting large messages and sending 
them as separate message)

 

An intermediary can combine multiple incoming messages 
(with multiple eb:Messaging elements) 
in a single larger message. The following table shows that three incoming 
messages are forwarded in a single message. Once that message is acknowledged, 
the three incoming messages can be marked delivered

 

  
  

    
      
From

    
      
Sequence

    
      
Message-Number

    
      
To

    
      
Sequence

    
      
Message-Number

  

    
      
Sender A

    
      
A-Int

    
      
1

    
      
Receiver C

    
      
Int-C

    
      
88

  

    
      
Sender A

    
      
A-Int

    
      
2

    
      
Receiver C

    
      
Int-D

    
      
88

  

    
      
Sender A

    
      
A-Int

    
      
3

    
      
Receiver C

    
      
Int-C

    
      
88

 

I’m not sure if end-to-end security is possible with 
batching, since we can’t have multiple WSSE headers all targeted at the same 
endpoint, more thinking to do …

 

The reverse (splitting) is a bit more complex, a message 
should only be marked delivered when all parts into which it is split before 
forwarding are acknowledged …