Spotter two typos in my own message:
1) "result in marking incoming
messages as marked." -> "result in
marking incoming messages as delivered."
2) Last table, batching, third row "Int-D" ->
"Int-C".
From: Pim van der Eijk
[mailto:]
Sent: 26 February 2008
18:12
To:
Subject:
[ebxml-msg] 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 …
