[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Re: Issue 34 - Proposal for vote
I have no problem with using additional specs, so long as they are relevant and (hopefully) make BPEL easier to use. I knew WS-MD had been submitted to the W3C but was unaware of any additional activity. Thanks for the clarification Ron! John ________________________________ From: Steve Ross-Talbot [mailto:steve@enigmatec.net] Sent: Wed 5/19/2004 1:46 PM To: Ron Ten-Hove Cc: Francisco Curbera; John Evdemon; ygoland@bea.com; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Re: Issue 34 - Proposal for vote John, If WS-MD becomes a standards (modulo whatever renaming) and is available and meets the requirements for WS-BPEL then do you think it makes sense to use it? If not then why not? Cheers Steve T On 19 May 2004, at 21:31, Ron Ten-Hove wrote: > John, > > WS-MD is what used to be called a W3C Note, but what is now called > a W3C Member Submission. The W3C is now free to form a Working Group, > if it so wishes, to turn it into a W3C recommendation. > > Cheers, > -Ron > > John Evdemon wrote: > >> Is WS-MD a standard? >> John >> >> ________________________________ >> >> From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] >> Sent: Wed 5/19/2004 12:23 PM >> To: Francisco Curbera >> Cc: wsbpel@lists.oasis-open.org; ygoland@bea.com >> Subject: Re: [wsbpel] Re: Issue 34 - Proposal for vote >> >> >> Paco, >> >> I do not understand what delaying a couple of months will >> accomplish. >> >> Supposing that in the next couple of months WS-Addressing is >> submitted to a standards-setting organisation, it will still take >> many months before it emerges as a standard [1]. It will be of no use >> to this TC, which cannot take dependencies on works-in-progress, >> unless we are willing to delay our work accordingly. >> >> As you point out, flexibility and compatibility are important. The >> current direct incorporation of WSA for endpoint references certainly >> restricts flexibility, and provides only compatibility with a >> proprietary, closed, non-standard specification. It certainly cannot >> accomodate anything like WS-MD. >> >> Yaron's URI proposal minimizes the coupling between the endpoint >> reference type employed by the binding and the BPE language. >> Design-wise, this is a Good Thing. It also addresses a very common >> use case, where endpoint references are embedded in messages. >> >> To promote flexibility and compatibility, implementations should >> be free to support various endpoint reference types. At least four >> different endpoint references types are on the table: >> >> >> * WS-Addressing * WS-Message Delivery * Binding protocol-supplied >> endpoint reference info >> >> * Message-supplied URI >> How should we support these? And how does delaying two months >> change these requirements? I sincerely doubt there will be an >> "industry convergence" in the that period. >> >> Best regards, >> -Ron >> >> [1] This will likely take years, unless WS-A is decoupled from >> WS-Policy and all the other specifications involved, many of which >> are non-standard. >> >> Francisco Curbera wrote: >> >> >> >> My vote is with Dieter's position, which he stated t the last call: >> there >> is no compelling reason that I can think of to close issue 34 now as >> opposed to, say, a couple months from now; but if we rush this issue >> now we >> are potentially (likely) creating a new conflict between BPEL and >> whatever >> referencing mechanism that eventually emerges as the industry >> consensus. >> Recent submissions to W3C have made many of us hopeful that some >> clarification of this space may be on the horizon. >> >> Regarding the proposal below: we need to insist on flexibility and >> compatibility with established service referencing mechanisms used >> by the >> industry. This TC seems to have come to the realization that, >> lacking an >> industry-wide consensus, real implementations may have to address >> service/process instances in different ways (of which URI hackery is >> one >> possibility); this means that defining a reference to be a URI is >> not good >> enough. Flexibility, extensibility and openness are critical >> requirements >> missing from the URI-only proposal. >> >> Of course, we will not need to define any ad-hoc BPEL solution if we >> give >> the industry a chance to converge on an interoperable mechanism. >> Since we >> have time to revisit this issue later, this seems to me the wisest >> thing to >> do by far. >> >> Paco >> >> >> >> >> >> Ron Ten-Hove >> >> <Ronald.Ten-Hove@ To: ygoland@bea.com >> >> Sun.COM> cc: >> wsbpel@lists.oasis-open.org >> Subject: >> [wsbpel] Re: Issue 34 - Proposal for vote >> 05/18/2004 04:33 >> >> PM >> >> >> >> >> >> >> >> 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 >> . >> >> >> 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 >> . >> >> >> >> > > > 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]