30 likes | 136 Views
ebMS3 Routing scenarios. Part 2. MSH intermediary. PUSH Scenarios. MSH A. MSH B. (MessageID-preserving Forward). M1. M1. 1-way from A to B 1-way/push: A-Int 1-way/push: Int-B Int only forwards the message M1. HTTP 200. (status codes / Faults are only for each leg). M1.
E N D
ebMS3 Routing scenarios Part 2
MSH intermediary PUSH Scenarios MSH A MSH B (MessageID-preserving Forward) M1 M1 • 1-way from A to B • 1-way/push: A-Int • 1-way/push: Int-B • Int only forwards the message M1 HTTP 200 (status codes / Faults are only for each leg) M1 • 1-way from A to B, end-to-end reliable • 1-way/push: A-Int • 1-way/push: Int-B • Int forwards theasynchronous • RM Ack M1 HTTP 200 HTTP 200 (forward the RM Ack) RM Ack1 RM Ack1 M1 M1 • 1-way from A to B, robust • 1-way/push: A-Int • 1-way/push: Int-B • Int forwards the HTTP status code / • SOAP fault (forward M1, wait for the status code / Fault and forward it) HTTP 500 / Fault HTTP 500 / Fault
MSH intermediary PULL Scenarios MSH A MSH B (MessageID-preserving Forward) PullRequest • 1-way from B to A, pulled • Two “synchronized pulls” • 1-way/pull: A-Int, synchronized with: • 1-way/pull: Int-B PullRequest (forward the PullRequest, wait for the pulled msge) M1 M1 • Reliable variant: • Replace “M1” by “M1 + RM Ack” • Optional RM Ack for M1 is pushed • from A to B PullRequest (PullRequest is NOT forwarded) • 1-way from B to A, pulled / decoupled • Two non-synchronized pulls, only connected by an MPC in intermediary • 1-way/pull: A-Int, decoupled from: • 1-way/pull: Int-B PullRequest Whatever message in the Intermediary MPC PullRequest M1 (M1 posted in the Intermediary MPC) Whatever message, here M1 • Reliable variant: • No end-to-end reliability, but for each leg • Intermediary must have RM capability