Re: [ebxml-bp] Proposal for correlation mechanism in ebBP / WSDL mapping (v II)

[Mayilraj Krishnan <mkrishna@cisco.com>]

JJ
Runtime correlation approach seems to be wise and logically
composable.
Given that WS-Addressing have been submitted as "Member
submission", I am sure
it will go through lot of changes.
Mostly we can expect lot of debate, further work  on endpoint references
vs 
WSDL "service" element and its usage patterns.
By following this runtime correlation approach, hopefully  don't
need to do any changes 
in the specification/schema after WS-Addressing published as W3C
standard.
Probably  at 3.0 time, we can do the correlation through reference
(context mechanism).

Do you see any benefit of having WS-Addressing message information
headers in operation activity?
Probably these headers  could have  more broader applicability in
BSI/ebxml stack? I am not sure..
But something for us to think.

Thanks
Mayilraj  


At 01:54 PM 8/19/2004 -0700, Jean-Jacques Dubray wrote:

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">

<!--based on my understanding this is used as an addressing mechanism, i.e. replyTo -->

                                    <!--initiating 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>

    <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>

       <!-- we do not need to force the element syntax here we could agree on the first

element -->

<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