Summary of Multihop Issues
description
Transcript of Summary of Multihop Issues
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)