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.
|