Proposal for correlation mechanism in ebBP / WSDL mapping (v II)

Since my last proposal, WS-Addressing has been submitted to the W3C as a note as a basis for a standardization process, and the WS-CAF team indicated that they were adopting it as well. In parallel, and in a rather surprising move, BPEL has dropped the requirement on WS-Addressing, and made it more general, offering WS-Addressing as one possible “service reference” mechanism as part of their service reference container, just like WS-CAF did earlier. Incidentally, BPEL does not seem to support the latest WS-Addressing note as an endpoint should be uniquely identified by an address and a set of properties. There is no service name.

Since that time, I have also been oscillating between whether we needed correlation mechanisms for both run-time (e.g. WS-CTX, WS-Addressing, …) or design time (e.g. specifying correlation sets associated to document formats, WS-CDL). It appears to me that we could safely abandon the design time correlation mechanism because for simple, synchronous, operation mapping (request/response/fault) we do not need any form of correlation and for the complex mapping (involving signals), we can expect that users of the spec will have to somehow align their web services implementation with the BT concepts. It is also clear that vendors will quickly get WS-Addressing in their product suite. So these two fact combined it looks like we should probably just adopt a run-time correlation mechanism.

Here are some modifications to my original proposal

-          a BTA mapped to web services can only be initiated by an ebXML capable party. (replaced:A web service capable party cannot join a MPC with:) Any party, WS-capable or ebXML capable cannot joined arbitrarily an MPC. Participants in a MPC gets added in a cascade fashion via interactions initiated by other participants previously added to the MPC. We may allow an exception when the web service capable party initiates the MPC. Otherwise, I don’t see how we can establish a correlation between the collaboration instance and these parties.

-          Request/Confirm and Information notification may be implemented via a single web service operation invocation. If this operation is synchronous, no further correlation mechanism is necessary.

-          For the moment we will only support an explicit correlation (by value), and will not support a context service (by reference).

The end points will have to support this subset of WS-CTX SOAP extensions

Now, the dilemma is whether to use WS-Addressing as a context mechanism (for which it was not designed) or do we need a broader context mechanism? Initially, we don’t need to carry much in the context so we could just deal with the end points. Since WS-CTX is not ready yet, I suggest that we only support WS-Addressing today. This will be most likely supported by the vendors before WS-CAF is supported.

For the record this is what WS-CTX would have looked like:

<context timeout=”BTA timeToPerform”>

            <context-identifier>BTA instance identifier (guid)</context-identifier>

            <type>http://www.ebpml.org/ebBP/2004</type>

<participating-services>

<service-ref reference-scheme="http://www.w3.org/2004/04/wsmessagedelivery">



                                    

<wsa:EndpointReference>

    <wsa:Address>ebBP collaboration definition URI</wsa:Address>

    <wsa:ReferenceProperties>

<ebBP:BTAInstanceId>GUID</ebBP:BTAInstanceId>

    </wsa:ReferenceProperties>

    <!—optional -->

    <wsa:ReferenceParameters>

<ebBP:CollaborationInstanceId>GUID</ebBP:CollaborationInstanceId>

    <wsa:ReferenceParameters>

    <wsa:PortType>xs:QName</wsa:PortType> ?

    <wsa:ServiceName PortName="xs:NCName"?>xs:QName</wsa:ServiceName> ?

    <wsp:Policy> ... </wsp:Policy>*

</wsa:EndpointReference>

                                    <!—responding party -->

<wsa:EndpointReference>

    <wsa:Address>ebBP collaboration definition URI</wsa:Address>

    <wsa:ReferenceProperties>

<ebBP:BTAInstanceId>GUID</ebBP:BTAInstanceId>

    </wsa:ReferenceProperties>

    <!—optional -->

    <wsa:ReferenceParameters>

<ebBP:CollaborationInstanceId>GUID</ebBP:CollaborationInstanceId>

    <wsa:ReferenceParameters>

    <!— the BSI need to autogenerate a WSDL to fit this part of the end-point ref -->

    <wsa:PortType>xs:QName</wsa:PortType> ?

    <wsa:ServiceName PortName="xs:NCName"?>xs:QName</wsa:ServiceName> ?

    <wsp:Policy> ... </wsp:Policy>*

</wsa:EndpointReference>

</wsdl:service>

</service-ref>

</participating-services>

</context>

Now for WS-Addressing only, when an ebXML capable party is initiating a message as part of a BTA that will be followed by messages returned by the other party (this is a general way to describe that this works for both a request or a response to a request), the initiating party will create a dynamic endpoint reference as follows:

<wsa:EndpointReference>

    <wsa:Address>organization/ebBP/collaboration definition/BTA name [URI]</wsa:Address>

    <wsa:ReferenceProperties>

       

<ebBP:BTAInstanceId>GUID</ebBP:BTAInstanceId>

    </wsa:ReferenceProperties>

    <!—optional since BTA instance should be enough-->

    <wsa:ReferenceParameters>

<ebBP:CollaborationInstanceId>GUID</ebBP:CollaborationInstanceId>

    <wsa:ReferenceParameters>

    <wsa:PortType>BTA name (xs:QName)</wsa:PortType> ?

    <wsa:ServiceName PortName="xs:NCName"?>Collaboration name (xs:QName)</wsa:ServiceName> ?

    <wsp:Policy> ... </wsp:Policy>*

</wsa:EndpointReference>



                                    The WSDL is generated at CPA time based on the operation mapping definition and SOAP binding information provided at that time or part of the CPP (probably the BSI only need to expose one URL). A port type contains all the operations that participate in the BTA mapping.

WS-Addressing specifies fault types as part of the protocol:

Invalid Message Information Header

Message Information Header Required

Destination Unreachable

Action Not Supported

All these faults correspond to a technical error (if received by a BSI).

Let me know if this is acceptable.

Jean-Jacques

ebxml-bp message