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


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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]