Alex,
+1 from me. This is a good mechanism for accomodating multiple EPR
vocabularies, and is consistent with how we manage multiple expression
languages.
-Ron
Alex Yiu wrote:
Hi, all,
After weeks of internal and external discussion, here is our viewpoint
derived from Ron's original idea [opaque or anyType of endpoint
reference - EPR].
We think: just the URI may be too simple for some advanced cases, while
explicit WSA dependency is not appropriate for the openness of the BPEL
spec.
Introducing a wrapper:
I think we should borrow the same spirit of pluggability of expression
and query language here. We allow different expression languages to be
used within BPEL by providing the namespace URI of that language in the
right places.
-----------------------------------
<xs:element name="service-ref" type= tns:ServiceRefType />
<xs:complexType name="ServiceRefType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="1" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="reference-scheme" type="xs:anyURI"
use="required"/>
</xs:complexType>
-----------------------------------
The partnerlink should contain this "service-ref" element for the
endpoint references of partnerRole or myRole.
e.g.:
<service-ref reference-scheme="http://foo.org">
<foo:barEPR xmlns:foo="http://foo.org"> ... </foo:barEPR>
</service-ref>
Summary:
We agree with Ron that it may take more than few months for the
industry to converge on ONE single addressing or EPR scheme. Instead of
keep delaying BPEL TC itself, we should make leave it open. And let the
industry take its own course to find out its convergence point.
BPEL spec should be as flexible as possible to allow the convergence
happen.
Even after the industry has converged into one addressing or EPR scheme
in future, we may still need to face the versioning issue.
For WSA alone, we already have two versions floating around.
http://schemas.xmlsoap.org/ws/2003/03/addressing
http://schemas.xmlsoap.org/ws/2004/03/addressing
WSA by itself already presents us the version conversion problem. The
solution of this problem would require the semantics listed above.
Thanks!
Regards,
Alex Yiu
|