ebxml-cppa message

Subject: Transport extensibility questions for 2.1

From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: <ebxml-cppa@lists.oasis-open.org>
Date: Thu, 15 Jul 2004 08:57:02 -0700

Title: Message

Hi

I am working on some residual 2.1 extensibility problems that have not been discussed in a while and keeping an eye on what might be required of us for handling ebMS 3.0.

Yesterday ebMS began considering HTTP transfer protocol bindings that are "reversed" from the ordinary as discussed, for example, in

http://www.projectliberty.org/specs/draft-liberty-paos-1.0-errata-v1.0.pdf

For these reversed HTTP bindings, to "send" a request the receiver connects to the "sender's" URL and the request is placed into the HTTP response. When the receiver of this HTTP response (which is a SOAP request) sends its response, it uses a connection to the original sender to POST its SOAP response on a HTTP request.

Because a HTTP response is bound to transfer of a SOAP request, and a HTTP request is bound to a SOAP response, it is clear that this binding is the reverse of the ordinary HTTP binding for the SOAP request-response MEP.

So, suppose we had to express this binding information in CPPA Transport? How should it be done?

In particular, is it time for us to add attributes/elements to HTTP so that we can specify more details to fix the constraints on these bindings? We have previously discussed whether to add the HTTP methods (the verbs, POST, GET etc). To that we could add whether the request or response is being used. And so on.

One question is what our "CanSend" really means. I assumed that the CanSend indicates, for a given service and action, who has the data that is being made available to the other party. If so, then for the reverse binding case, the Sender is the one that needs to advertise its endpoint and protocol information, while the Receiver is the one that connects to that URL and receives the SOAP request in the HTTP body in a HTTP response.

I am soliciting comments on this interpretation first. After we have some comments, then we can continue with how we might wish to extend the 2.1 Transport model.

Bye

Dale Moberg