Message Exchange Patterns (MEP)

Holodeck B2B currently supports the One-Way message exchange pattern with two bindings: One-Way/Push and One-Way/Pull as well as asynchronous Two-Way messaging. The P-Mode element mepBinding defines which MEP [binding] is used for a specific message exchange and should contain the URI as defined in the specification to identify the correct binding. It depends on the selected binding which settings need to be configured in the P-Mode and how the information in the P-Mode is used to computed the messaging header.

One Way/Push

MEP Binding URI to use in P-Mode:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/push

In this MEP the initiator is also the sender of the user message, so the information provided in the Initiator element will be used to fill the eb:From element in the messaging header and the information in Responder the eb:To header. Also the security configuration included in the SecurityConfiguration child of the Initiator element will determine which security is applied to the message. The P-Mode must contain the URL of the destination MSH in the Protocol/Address element.

In most cases the response signal message is sent with the HTTP response. It is possible to send the signal message as a separate request from responder to initiator by setting the reply pattern to “Callback” and specifying the ReplyTo URL. No bundling of signals will take place in the One-Way/Push MEP, so the ReplyTo URL must be specified otherwise the response will get lost!

One-Way/Push MEP

One Way/Pull

MEP Binding URI to use in P-Mode:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/pull

In this MEP the initiator is the receiver of the user message, which sends a pull request signal message to the sender of the user message. Because the possible response to the user message requires an additional request Holodeck B2B models this as two flows, one for the pull request and one for the user message.

So for the Pull MEP the information provided in the Initiator element will be used to fill the eb:To element in the messaging header of the user message and the information in Responder the eb:From header.
The SecurityConfiguration configured for the Responder determines how the user message is secured. A PullRequest signal has to be authenticated by the responder before it returns a message. The configuration for this is done using the SecurityConfiguration of the Initiator or (for a specific sub-channel MPC) of a PullRequestFlow.

Again the initiator of the MEP needs to know where to send the initial message and therefor must have the Protocol/Address element set in its P-Mode. In this case however the initiator is the MSH that sends the pull request signal message to the sender of the ebMS user message.

Because the user message is received in a HTTP response the reply pattern for the response signals is always “Callback”. In case of the Pull MEP however the ReplyTo URL does not need to be set. If not set the response signal will be sent piggy backed to the next pull request.

One-Way/Pull

Two Way/Push & Push

MEP Binding URI to use in P-Mode:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/pushAndPush

A two-way MEP consists of the exchange of a request and response message between two trading partners. It can be considered a combination of two one-way P-Modes. The initiator is the trading partner that sends the first message, i.e. triggers the exchange of the request message. It depends on whether Push or Pull is used for this exchange who will be the initiator.

The configuration of a two-way P-Mode consists of the generic configuration for the two involved trading partners which applies to both exchanges and two legs that contain the specific configuration for the request and response messages, like Service and Action values and the URLs where to send messages.

Two-way MEP