1 / 3

ebMS3 Routing scenarios

This document outlines various routing scenarios for Message Service Handlers (MSH) using the ebMS3 protocol, focusing on intermediary push and pull scenarios. It details one-way, end-to-end reliable message forwarding from A to B via intermediary, including asynchronous acknowledgments and error handling with HTTP status codes. It also covers synchronized and decoupled pull requests, highlighting the conditions for reliability and message preservation through intermediaries. The objective is to ensure robust, safe, and reliable message exchanges between systems.

adele
Télécharger la présentation

ebMS3 Routing scenarios

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ebMS3 Routing scenarios Part 2

  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

  3. 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

More Related