[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Issue 34 - Proposal for vote
Yaron, A +1 from me, and my thanks. To be clear: these are separate issues, but the solutions could overlap in that they both depend on the type used to represent endpoint references: 34: Change endpoint references to be type xsd:uri. 124: Remove <assign>ment of endpoint references to/from partner links. Add functions to accomplish the same in a direct fashion. As you say, overloading <assign> to manipulate the partner links is poor design. It is confusing, quirky, and inconsistent with the other uses of <assign>. Activities like <setPartnerEndpoint> and <getPartnerEndpoint> are much clearer. -Ron Yaron Y. Goland wrote: > Ron has asked me to open a new issue on the URI function and I have > done so. > > But this still leaves open his proposal. My official counter proposal > to Ron's proposal is that we remove the ability to use assign with > partnerLinks. > > As previously described it is bad design to rely on side effects. As > such I believe it to be bad design to rely on a side effective of > assign as a way of changing partnerLinks bindings. Regardless of how > the endpoint reference debate turns out we shouldn't be using side > effects to manipulate endpoint references. > > Yaron > > Yaron Goland wrote: > >> >> >> 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. >> >>> >> > >> >> To unsubscribe from this mailing list (and be removed from the roster >> of the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]