ebXML MEPs: some questions

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

Title: ebXML MEPs: some questions

COmments on current eMS 3 draft, and questions:

1. Sectionn 6.1 (titled "assumed SOAP MEPs")
should not make mention of RMP. (just replace RMP by MSH ?)

2. An observation on our definitions of ebXML MEPs  that I think need be sharper:

- about the Push MEP, as currently drafted (6.2.1) section says "no SOAP response is expected", meaning I guess only a SOAP One-way MEP canbe used. If so we should make it more explicit. If so also, when using reliability no Response replypattern can be used, which is OK so far.  But more on this below.

- The way the Unidirectional Push and the Bidirectional Synchronous MEP (section 6.3.1) definitions are worded is a little ambiguous. The expression "...the MSH returns / does not return a SOAP response..." is stronger than just "returning/not an ebXML message in a SOAP Response" (defined here as a SOAP message with ebMS-qualified headers) .

 Taken textually, the current definition means that the only difference between Unidirectional Push and Bidirectional Synchronous, is the SOAP MEP being used. So we could have  an ebXML  Bidirectional Synchronous MEP with a SOAP response that may contain a SOAP fault, or some reliability  or security headers, yet does not have any ebXML semantics (no ebMS headers). Is that really what we meant? Intuitively, isn't such an MEP expected to contain an ebMS message in the Response leg as well as in the Request?

The implications of either solution are the following:

-Solution A: we stick to current definitions. Then the meaning of these ebXML MEPs is kind of contrived: when sending an ebXML message that does not expect a business response, a user could use either the Push MEP or the Bidirectional Synchronous MEP, and  decide to go with the latter just because it allows some form of SOAP responses not allowed by the former  (e.g. SOAP faults, or reliability Response pattern), not because of a need for that MEP at ebXML message level.

-Solution B:  we define these MEPs as having really some ebXML semantics (in terms of presence  or not of ebMS headers in these messages). Then it follows that a Unidirectional Push could be implemented either on a SOAP One-way or on a SOAP Request-response provided that in the latter case, no header  or body with ebMS elements is allowed in the response - but some other headers allowed - e.g. a reliability reply, or a SOAP fault in the body). In the case of Bidirectional Synchronous, we would then require that the SOAP response always contains an ebMS message.

Thoughts?

Jacques