Re: [wsbpel] Issue 34 - Proposal for vote

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

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