OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: " updates for MEP section" corrected


Proposal for addressing Dale's comments on MEPs (corrected):

 

1- section 2.2.1:

 

- add after L411 a third statement:

"The ebMS message unit is a PullRequest signal message (in which case it is not required

to reference another unit.)"

- modify second statement in L409:

"The ebMS message unit" --> "The ebMS message unit is a user message unit which".

 

- add at the end:

"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 PullRequest signal."

 

2- section 2.2.2.1 (SOAP One-way MEP)

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, in which case it does not contain any SOAP header block unrelated to the Fault."

 

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

section 2.2.3.2:

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

 

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. Their instances use  more than one SOAP MEP instances between the Initiator MSH and the Responding MSH. Each one of these aggregate MEPs combines the choreographies of two simple ebMS MEP 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 message of the second referring to the message 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 pulled user 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 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)"

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]