Summary of Multihop Issues

1. Summary of Multihop Issues ebMS F2F May 2008

2. Agenda • Types of nodes • Configuration for toPartyMSH or nextMSH • Routing issues • Routing of User Messages • Routing of CS Request and Response • Routing of signals • Reliability issues • Configuration (Retries, Interval) • Security

3. Types of nodes • Endpoints • First node (Sender) • Last node (Recipient) • Intermediaries • First intermediaries • Last intermediaries • Intermediaries other than first or last • Any node • Any node other than first node (Sender) • Any node other than last node (Recipient) • Addressability • Addressable (in “public” space) or non-addressable • Mechanisms: DNS-URL; WS-Addressing; ebMS header data

4. Reliable Messaging Options • RM-transparent (RM-T): • Intermediaries have no RM functionality beyond routing RM traffic • No local or end-to-end reliable messaging configuration • Lightweight Relayed Acks (LRA) • Intermediaries need limited local “binding” knowledge • “In-Sequence From-Int maps to Out-Sequence Int-To” • Resends triggered by Sender, acks returned as-is • Intermediary does not assign sequence numbers • Sender determines when message has failed ((1+Retries) *Interval) • Generalized Relayed Acks (GRA) • Completely separate reliable sequences • Message to message binding • Separate retry configuration parameters, failure determination • Hybrid scenario (H) • Generalized relayed acks without ack-on-delivery, instead has delivery failure notification

5. Two types of configuration • End to end “toParty MSH” configuration • Based on business agreement • PartyId, Service, Actions, choreographies • End-to-end security • Reliability, ExpiryTime (RM-T, RA) • Local “nextMSH” configuration • Push or Pull • Asynchronous or synchronous (for signals and/or responses) • URL • TLS Client and Server authentication • In CPA, contents of <eb:Transport> element • Reliability, ExpiryTime (H)

6. Message Routing Issues

7. One Way User Message Routing • Point-to-point messaging • Bilaterally agreed P-Mode configuration • “nextMSH” URL = “toPartyMSH” URL • Messaging via Intermediaries • Rule set <eb:UserMessage /> pattern  nextMSH • <eb:To/eb:PartyId /> • <eb:To/eb:PartyId, eb:Service /> • <eb:To/eb:PartyId, eb:AgreementRef, eb:ConversationId /> • Or: WS-Addressing <wsa:To/> • Or: Custom SOAP or HTTP headers, URL query suffix

8. CSRQ Routing: Sender • How does Sender know how to forward route a Create Sequence Request? • Sender may be preconfigured to always send via the same Intermediary • Or, available User Data is used: • CSRQ is created just in time; • MSH finds “nextMSH” settings from P-Mode configuration

9. CSRQ Routing: First Intermediary • How does the First Intermediary know how to forward route a CS Request ? • (LRA/GRA, H). No forwarding. Int sends CSResponse; then waits for first user message with data • (RM-T) First node has added routing data: • URL of last intermediary or Recipient, configuration reference or ebMS user data • Encoded as <eb:Messaging actor=“anyone-but-the-last-node”/> header or otherwise

10. CSRQ Routing: after first Intermediary • Forward routing information will be available • Sender or first Intermediary took care of these • Can be carried in any of the mentioned encoding formats • Last intermediary can remove forward routing information • Assuming it can correlate the CS Response from Recipient • No functionality other than v3.0 Core required for endpoints

11. Create Sequence Response • How does the Recipient return the CS Response? • Using the HTTP back-channel to Sender, if all intermediaries in the i-cloud are “waiting” • Or, Using the HTTP back-channel to last Intermediary • Or (correlation metadata available in wsa:AcksTo, or in ebMS dummy header) as a standalone response SOAP message

12. Create Sequence Response • How do intermediaries route back the CS Response? • On HTTP back-channel if in “all-waiting” • Backward-route information transmitted with incoming message • <adhocns:ReturnUrl /> • <wsa:AcksTo /> • If message with ebMS metadata<eb:Messaging actor=“anyone-but-the-last-node”> the reverse routing information can be computed from forward routing information • E.g. swap <eb:From:F>, <eb:To:T>  <eb:To:F, eb:From:T>

13. Create Sequence Response • First intermediary • Strips reverse routing information, then forwards Create Sequence Response to Sender (RM-T) Or: • Binds In-Sequence to Out-Sequence (RA, H)

14. Routing Signals • ebMS Signal types: • “Backward” signals: eb:Receipt, eb:Error • “Forward” signal: eb:PullRequest • Backward signals • Like routing CS Responses • Forward signals • No user requirement for multihop pull requests? • How about lower-level errors? • (non-ebMS) SOAP faults, HTTP 500, DNS … • Intermediary could translate these to ebMS errors?

15. Reliable Messaging Configuration • Receipt acknowledgment by intermediary means: • Received by Recipient (RM-T, RA) • Received by Intermediary and forwarded (H) • Sender’s Retry, RetryInterval determine time of failure status • True (RM-T, LRA) • False (GRA, H) • Sender does not resend messages that Intermediary received, and is in the process of forwarding • False (RM-T, RA) • True (H)