ebxml-msg — archive

RE: [ebxml-msg] Messaging Spec v1.092

From: System
To: [email protected]
Date: Mon, 07 Jan 2002 11:26:00 -0000

MHonArc v2.5.2 -->

ebxml-msg message

Subject: RE: [ebxml-msg] Messaging Spec v1.092

From: "Burdett, David" <[email protected]>
To: 'David Fischer' <[email protected]>,Martin W Sachs <[email protected]>, Jacques Durand <[email protected]>
Date: Mon, 07 Jan 2002 08:23:44 -0800

Title: RE: [ebxml-msg] Messaging Spec v1.092

David, you said ...

>>>Now, someone else please take the SOAP box.<<<

So I suppose it's my turn ...

Firstly, I totally agree with what you said in your email.

As I have said many times before I am in favor of a method by which two parties can exchange data that records how they have agreed to exchange messages or perhaps do business together.

However, by requiring that there is a pre-existing agreement in place between the two parties that defines the parameters that configure how each MSH works (whether virtual or a CPA document is irrelevant), we severely limit the applicability of the ebXML Messaging spec in situations where a lightweight protocol is required. In fact without a negotiation protocol, you **cannot** use the existing ebXML spec for spontaneous exchange of messages.

This lack of spontaneity will, in my opinion, lead to the lack of adoption of the reliablility and security aspects of the ebMS spec by the wider W3C/SOAP/XML Protocol/Web Services community - which will be a shame. There is a need for an open standard for secure, reliable messaging between applications within an enterprise, to meet the requirements of Web Services. The current ebMS spec does not meet this need and is really only a B2B spec.

To fix this problem, the next version of the ebMS spec needs a protocol for secure reliable messaging that requires NO prior negotiation. You should be able to just send one message securely and reliably and expect a response in the same form.

If two parties have agreed that they want to constrain their interaction to working in a particular way, then using a CPA to record their "agreement" and then referencing that agreement in the message through a CPAId makes sense.

With this approach I think you would get the separation of ebMS and CPP/CPA that both David and I think we need.

However, unlike David, I will vote for the current spec since it does meet a useful need within its niche.

Regards

David