[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]