Summary of Multihop Issues

ebMS F2F May 2008

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

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

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

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)

Message Routing Issues

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

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

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

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

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

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>

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)

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?

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)