[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 34 - Proposal for vote
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]