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: RE: [ebxml-msg] MEP section 2.2, some general questions about conserving ebMS 2.0 modes.




From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Monday, April 17, 2006 1:59 PM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] MEP section 2.2, some general questions about conserving ebMS 2.0 modes.


It seems to me that the 2.2 MEP section needs to be more conservative of former MEP distinctions found useful in production and in ebMS 2.0


For example, we used to have a syncReplyMode value to describe MEP related features in ebMS 2.0


Very popular modes were mshSignalsOnly and none.


In mshSignalsOnly a SOAP request-response MEP was used to support sending an ebMS user message and receiving back an ack or possibly an error.


I suppose we will now make use of some form of reliable messaging in the HTTP response, but we still need a MEP related to  the mshSignalsOnly mode. I am not seeing a candidate here.


<JD> That is still the ebMS One-way Push, over a composable SOAP One-way. This would allow on the SOAP response both a reliability ack, and ebMS errors, while no user message. The binding of these two types of signals to the SOAP response is controlled separately (all signals not treated the same as in ebMS2): reliability Ack is controlled by the reliability contract (P-Mode.reliability) while the reporting of errors is controlled in (P-Mode.errorHandling). While the terms of the reliability contract are well defined and inherited from the related specification (here with WS-Reliability binding), other P-Mode features are not detailed in part 1. For example, an error reporting mode like “OnResponse” would achieve what you want. The plan is to describe this in the ebMS3 adjunct doc, along with guidance on P-Mode representation/content and how this maps to CPPA.


For the value “none”, in effect we are saying that two endpoints are used, and the HTTP response is used at most for SOAP faults. How does this mode get translated?


<JD> Also ebMS One-way Push, over a fault-supporting composable SOAP One-way. In that case, the P-Mode would preclude adding  any [ebMS] SOAP header block in the response (no Ack, no Error)


For the final committee draft and specification, I would like to make certain that we lose no ebMS 2.0 functionality with respect to exchange patterns. All the combinations of syncReplyMode with SOAP over HTTP need to enabled, and where mshSignals, SOAP faults, and other errors need more clarity.

<JD> The P-Mode prescribes these modes. But different signals (controlled by different specifications) will be separately controlled:


ebMS MEP=One-way Push

SOAP binding: SOAP One-way, fault-supporting, composable.

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

            [P-Mode.errorHandling] Errors.reporting = “Callback”, (along with an error URL)


ebMS MEP=One-way Push

SOAP binding: SOAP One-way, composable

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

            [P-Mode.errorHandling] Errors.reporting = “OnResponse”.






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