RE: [ebxml-msg] " updates for MEP section" corrected one more time...

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

After off-line talk with Dale, here is one more update (hopefully last on this topic) that seems to address the concern about supporting – and controlling -  the MEPs that were (implicitly) supported by ebMS2, down to the “MSH signals” allowed or not allowed on a response message.

 

Mostly – as in my two previous sendings on this - , tightening our previous MEP definitions, and adding a small section on “aggregate MEPs” which we had in early drafts, but without expanding on it as much as for “simple MEP” definitions.

 

As an example on how some previous ebMS2 MEPs are indicated in V3 (relying on P-Mode for this.) We assume guaranteed delivery is required:

The two first ones are most important:

 

(in ebMS2 CPA) syncReplyMode=none:

In V3:

ebMS MEP=One-way Push (over SOAP One-way)

            [P-Mode.reliability with WS-Reliability] replyPattern= “Callback”, with possible alternate address

            [P-Mode.errorHandling] report.asResponse = “false”,

 

(in ebMS2 CPA) syncReplyMode=mshSignalsOnly:

In V3:

 

ebMS MEP=One-way Push (over SOAP Request-response)

            [P-Mode.reliability with WS-Reliability] replyPattern= “Response”,

            [P-Mode.errorHandling] report.asResponse = “true”

 

And if this is within the context of an asynchronous request-response business transaction:

 

ebMS MEP=Two-way Push (with same P-Mode parameters for each leg of the MEP)

 

 

(in ebMS2 CPA) syncReplyMode=signalsAndResponse:

In V3:

 

ebMS MEP=Request-Reply

            [P-Mode.reliability with WS-Reliability] replyPattern= “Response”,

            [P-Mode.errorHandling] report.asResponse = “true”

 

(in ebMS2 CPA) syncReplyMode=responseOnly:

In V3:

ebMS MEP=Request-Reply

            [P-Mode.reliability with WS-Reliability] replyPattern= “Callback”, with possible alternate address

            [P-Mode.errorHandling] report.asResponse = “false”,

 

Jacques

 

 

Proposal for addressing Dale's comments on MEPs:

 

0- section 2.1.2: (tighter definition)

 

L354:

remove "and not to carry... Deliver operation. An example is the ebMS PullRequest signal."

Add after L357: "A signal message that contains an eb:PullRequest element is also called a Pull Signal message."

 

 

1- section 2.2.1: (tighter definition)

 

- L400-411: replace with:

"An ebMS Message Exchange Pattern (MEP) is an abstract description of a typical exchange of ebMS Messages between two MSHs, which involves at least one ebMS User Message. An MEP instance is an actual message exchange that conforms to the pattern described by the MEP. The ebMS MEPs definitions in this document are only concerned with two types of ebMS Messages: User messages and Pull Signal Messages. Instances of such MEPs may involve or cause the transfer of other Signal Messages (e.g. Errors) but these are not taken into account in the MEP definition. More precisely, an MEP instance also defines an exchange of ebMS Message units, each one of which  MUST satisfy at least one of the following statements:

- The ebMS Message unit occurs in the first message exchanged in the MEP instance, which is either a Pull Signal Message or a User Message.

- If the ebMS Message unit is a User Message unit, then it refers the ID of a previously sent Message Unit in the same MEP instance, using eb:RefToMessageId."

 

- add at the end of 2.2.1:

"Note that an Initiator MSH need not be a Sending MSH if, for example, the message unit

is an ebMS Signal Message unit, as the Sending and Receiving roles are defined only with regard to the transfer of ebMS User Message units.  In fact, the Initiator MSH is also a Receiving MSH when sending a Pull Signal message."

 

2- section 2.2.2.1 (tighten SOAP One-way MEP def)

 

remove second bullet (the one with subcases (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."

 

3- improve MEP definitions:

 

section 2.2.3.1

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

- L461: remove the second part of the sentence: "and MUST NOT be referred....user message."

- add at the end of 2.2.3.1:

"Note: In case the One-way Push MEP is carried over a SOAP Request-Response, the response message MAY carry an ebMS Signal Message such as an error message, or other SOAP headers. Such an option is controlled by the MSH (see section "Processing Modes"). However, the response message MUST NOT carry an ebMS User Message."

 

section 2.2.3.2:

- L468: replace "sends a PullRequest signal message unit" with "sends a Pull Signal message"

- L470: remove "and MUST NOT be referred....user message unit."

- L471: replace "PullRequest signal" with "Pull Signal message".

 

4- Support for "aggregate ebMS MEPs":

Defines most common aggregate MEPs:

 

- Add a 2.2.4. section: "Aggregate ebMS Message Exchange Patterns" with text:

 

"The following aggregate ebMS MEPs are expected to be among the most common ebMS MEPs that use more than one SOAP MEP instances between the Initiator MSH and the Responding MSH. Each one of them combines the choreographies of two simple ebMS MEP instances although their use of eb:RefToMessageId is different:

 

- The Two-way Push MEP: composes the choreographies of two One-way Push MEPs in opposite directions, the User Message unit of the second referring to the User Message unit of the first.

 

- The Push-and-Pull MEP: composes the choreography of a One-way Push MEP followed by the choreography of a One-way Pull MEP, both initiated from the same MSH (Initiator). The User Message unit in the pulled message  must refer to the previously pushed user message.

 

- The Pull-and-Push MEP: composes the choreography of a One-way Pull MEP followed by the choreography of a One-way Push MEP, both MEPs initiated from the same MSH. The User Message unit in the pushed message  must refer to the previously pulled message.

 

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 any further restriction on how an ebMS One-way Push maps to SOAP:

e.g. if a SOAP Request-response may be used, or only a SOAP One-way MEP, possibly constrained further for WS-I BP1.1 compliance."

- 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. errorHandling.report.asResponse = true/false)

- whether  an error generated on reception of a message must be returned to sender or to a third party over a new SOAP MEP. (e.g. errorHandling.report.byCalling = <URL>).

- whether  an error generated on reception of a message must be notified to Consumer and/or Producer 

(e.g. errorHandling.report.notifyConsumer, errorHandling.report.notifyConsumer)"