updates for MEP sections

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Proposal for addressing Dale's comments on MEPs:

 

 

1- section 2.2.1:

add at the end:

"Note that an Initiator MSH need not be a Sending MSH if, for example, the MEP starts with an ebMS signal message unit, as the Sending and Receiving roles are defined only with regard to the transfer of ebMS user message units.  As an example, the Initiator MSH is also a Receiving MSH when sending a PullRequest signal."

 

2- section 2.2.3.1

Remove the 3rd case of SOAP binding for One-Way Pull Message Exchange Pattern (SOAP response)

 

3- section 2.2.2.1 (SOAP One-way MEP)

remove second bullet with cases (a)(b)(c) and replace with : "In case a two-way underlying protocol is used, the message returned on the back channel does not contain a SOAP envelope except in case a SOAP Fault is returned, in which case it does not contain any SOAP header block unrelated to the Fault."

(the use of SOAP 1-way vs SOAP request-response

 

4- Say more about support for "aggregate ebMS MEPs" in Part 1:

Remove the requirements of  “no external referencing” we have today for simple MEPs:

- in 2.2.3.1: remove L460-461 "To conform to this MEP... any subsequent message."

- in 2.2.3.2: remove L469-472  "To conform to this MEP the user messge...

and MUST NOT be referred to....MUST NOT include eb:RefToMessageId element."

- in 2.2.3.3: remove L481: "the ebMS Request MUST NOT relate...(no eb:RefToMessageId element),"

- Add a 2.2.4. section: "Aggregate ebMS Message Exchange Patterns" which is a summary of what we had in an early draft before we decided to move it to Part 2:

"The previous simple ebMS MEPs may be composed into larger MEPs - aggregate MEPs -, that involve several SOAP MEPs. The composed simple MEP instances must be correlated using eb:RefToMessageId, so that a message of a simple MEP instance refers to a message of the previous simple MEP instance. The following are three aggregate ebMS MEPs, not exclusive of others:

- The Two-way Push MEP: involves two One-way Push MEPs in opposite directions, the message of the second referring to the message of the first.

- The Push-and-Pull MEP: involves a One-way Push MEP followed by a One-way Pull MEP, both MEPs initiated from the same MSH. The pulled message  must relate to the previously pushed message using eb:RefToMessageId.

- The Pull-and-Push MEP: involves a One-way Pull MEP followed by a One-way Push MEP, both MEPs initiated from the same MSH. The pushed message  must relate to the previously pulled message using eb:RefToMessageId.

The two last MEPs handle asynchronous exchanges where one party is constrained in terms of addressing or connectivity capability."

 

5- Section 3.1:

- add in the P-Mode.protocol bullet:

"This feature also indicates whether an ebMS One-way Push maps to a SOAP One-way MEP or to a SOAP Request-response MEP. The latter case is required if extra SOAP headers such as reliability headers are to be returned over the response."

- add in the P-Mode.errorHandling bullet:

"This P-Mode feature must define reporting mode parameters that will allow a Receiving MSH to decide:

- whether  an error generated on reception of a message must be returned as response over the same SOAP MEP. (e.g. reportAsResponse = true/false)

- whether  an error generated on reception of a message must be returned to sender over a separate SOAP MEP initiated by the Receiving MSH. (e.g. reportAsCallback = true/false). This parameter should provide as option an alternate destination URL for the error message.

- whether  an error generated on reception of a message must be notified to Consumer  (e.g. reportAsNotification = true/false)"