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: Issue 34 - Proposal for vote


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]