Pull MEP

There are two perspectives on the Pull MEP, that we need to choose from:

Option 1. Pulling is only intended to accommodate MSH connectivity restrictions,

e.g. lack of static IP address, firewall restrictions, intermittent availability, etc.

In such cases, the pulling is an MSH-level mode of operation, which could

remain opaque to the application layer (or user layer). E.g., a sender party

would submit a message to an MSH, and not even be aware whether this message will be

pushed or pulled (the way this party interacts with its MSH is an implementation issue.)

COnsequence: When this mode is on between MSH1-MSH2, MSH1 will pull all messages

intended to it from MSH2, regardless of the party that submitted.

No need to provide a "partyId" parameter.

Option 2. Pulling is also intended to accommodate back-end communication,

i.e. may be controlled by parties who submit messages for sending, or who want to

decide whether their received messages would be pulled or not.

COnsequence: Pulling may be done at PartyId granularity. The MEP mode is decided

between two parties (by agreement, which of course needs be consistent with connectivity

constraints). MSH2 may queue messages intended for party A to pull, while pushing

messages intended for party B. (A and B being served by same MSH1)

ebxml-msg message