OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]