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