Re: [wsbpel] Issue 34 - Proposal for vote

["Yaron Y. Goland" <ygoland@bea.com>]

I think that depending on side effects usually causes more trouble than 
its worth. If we define the syntax for a partnerLink document and then 
as a consequence of changing that document we change the behavior of the 
partnerLink we will be relying on very messy side effects. We will be 
conflating two different actions - editing a XML document and changing 
partnerLink behavior.

I would propose that instead we introduce two dedicated functions, one 
to set the URI and one to retrieve the URI for a partnerRole on a 
partnerLink. That way we aren't rely on side effects.

	Yaron


Ron Ten-Hove wrote:

>   Yaron,
> 
>     You bring up an excellent point. The ability to copy a URI from a 
> variable into a partner link is important. It is certainly the most 
> direct, easily understood and portable form of endpoint reference available.
> 
>     It should be possible to assign variables of type xsd:uri to partner 
> links (and /vice versa/), and require that the implementation resolve 
> the URI correctly (or complain the prescribed manner). I regard this as 
> an enhancement (and a valuable one) to BPEL, not necessarily an 
> alternative solution to issue 34.
> 
>     However, the idea of combining the two ideas has merit. Rather than 
> using xsd:any for the endpoint reference type, xsd:uri could serve. We 
> could make sure that <assign> explicitly allows assignment of xsd:uri 
> variables to/from partner links. Implementations must be able to resolve 
> the URIs involved to binding-specific endpoint references, as needed by 
> the binding.
> 
>     This would have the added benefit of restoring static type checking 
> to partner link <assign>ments, which is otherwise lost if xsd:any is used.
> 
>     What does the rest of the TC think?
> 
> Best regards,
> -Ron
> 
> Yaron Y. Goland wrote:
> 
>> One of the more common activities, I suspect, in BPEL processes will 
>> be receiving the URI of a service in a message and then sending a 
>> message to that service. If such a basic example cannot be supported 
>> by BPEL in an interoperable way then BPEL is broken.
>>
>> In order to support this example there needs to be a way to set the 
>> URI of a partnerRole. The original specification envisioned that a 
>> role would be described as an endpoint reference using the definition 
>> in WSA and then one could manipulate that endpoint reference by 
>> changing information such as the URI.
>>
>> I understand the group's desire to stay away from the WSA arena but I 
>> don't think gives us permission to ignore this critical use case.
>>
>> However, I think it's worth taking a second to look at endpoint 
>> references. They contain five types of data - address, reference 
>> properties, portType, service-port and policy.
>>
>> Reference properties can be implemented today using a WSDL message 
>> part and correlation sets. So you can get there from here.
>>
>> portType is already defined by the partnerLink the role belongs to.
>>
>> service-port is about dynamic discovery of the kind of information 
>> that had to already be defined by the partnerLink. In a sense the 
>> functionality represented by service-port is an improvement on what is 
>> possibly today but I think BPEL only needs to equal, not necessarily 
>> exceed, what can be done over the wire in Web Services today.
>>
>> policy - If service-port represents the technology of tomorrow then 
>> policy represents the technology of Buck Rodgers. It's going to take a 
>> while before this one gets fully baked and we shouldn't let ourselves 
>> get held up in the meantime. I think we can ignore this one for the 
>> same reasons as service-port.
>>
>> So near as I can tell the only thing in endpoint references that we 
>> really need is the address, e.g. the URI, e.g. the thing you need for 
>> the example I gave above.
>>
>> So why don't we come up with some command that lets a BPEL program set 
>> the URI on a partnerRole and call it a day? When setting the URI 
>> either the deployment system (e.g. the thing that is out of scope) 
>> will have a configuration that will work with the URI or it will 
>> reject it. In other words the BPEL process says "I want to talk to 
>> 'ftp://foo.com/bar'" and either the system through some undefined 
>> means has a configuration it likes for ftp://foo.com/bar including 
>> bindings, policies, etc. and so says 'sure, no problem' or it doesn't 
>> in which case a fault is thrown.
>>
>>         Yaron
>>
>> Ron Ten-Hove wrote:
>>
>>>       [resend; the  proposal is unchanged . This is just to move the 
>>> issue state forward according to protocol]
>>>
>>> *Summary*
>>>
>>> WS-BPEL Issue 34 concerns the inappropriate dependency of the WS-BPEL 
>>> specification on a proprietary specification, namely WS-Addressing 
>>> (henceforth WSA). WS-BPEL uses WSA to provide a vocabulary for 
>>> describing endpoint references.
>>>
>>> It is proposed that the use of WSA-defined variables be replaced with 
>>> opaque variables. Variables of this opaque type will provide 
>>> specified data to provide endpoint reference information, but the 
>>> specifics are left to implementations.
>>>
>>> *Problem*
>>>
>>> The use of WSA is inappropriate; it is a proprietary specification, 
>>> closed (therefore unstable), difficult if not impossible to license 
>>> (given its dependencies on other proprietary specifications). WSA is 
>>> also only defined for SOAP, making it binding specific, which is 
>>> inappropriate given that the TC has consistently avoided including 
>>> binding-specific requirements (e.g., the decision to not incorporate 
>>> WS-I Basic Profile 1.0).
>>>
>>> WSA is used within WS-BPEL to provide an XML vocabulary for providing 
>>> endpoint references. This is required mainly to provide a mechanism 
>>> for dynamic partner link resolution. There are no open standards 
>>> available that provide such a vocabulary (although the W3C has 
>>> published the WS-Message Delivery specification as a submitted note.)
>>>
>>> *Proposal*
>>>
>>> The incorporation of WSA by WS-BPEL should be eliminated. Endpoint 
>>> references should be made opaque (i.e., anyType from XML Schema 1.0): 
>>> the XML type of abstract message parts that provide endpoint should 
>>> be opaque to WS-BPEL, and undefined by WS-BPEL other than some 
>>> general requirements (listed below).
>>>
>>> Implementations of WS-BPEL will need to provide support for one (or 
>>> more) endpoint description vocabularies. Provision for 
>>> interoperability of separate implementations is important, but is 
>>> outside the scope of the WS-BPEL TC in this issue.
>>>
>>> It is anticipated that standards setting organizations will 
>>> eventually provide standard endpoint description vocabularies, and 
>>> that future versions of WS-BPEL will incorporate them while 
>>> preserving backwards compatibility with this initial version of the 
>>> WS-BPEL.
>>>
>>> *Endpoint Reference Requirements*
>>>
>>> The opaque endpoint reference type MUST provide the following:
>>>
>>>     *
>>>
>>>       A representation of addressing information needed by transport
>>>       protocols that can be used by implementation-specific bindings to
>>>       resolve to a communications endpoint.
>>>
>>>     *
>>>
>>>       Support for two distinct address types, mappable to the “myRole”
>>>       and “partnerRole” values of the partnerLink attribute of the
>>>       <assign> <to> element.
>>>
>