Hi,
+1 to Ron.
It is the optional reference-scheme attribute is about providing flexibility
on how to inteprete service-reference and allowing leveraging existing
open standards (e.g. WSDL).
Please see again on the previous message on my proposal:
http://lists.oasis-open.org/archives/wsbpel/200408/msg00067.html
There are two particular points that I would to point out from the
propos
- The value of a service-reference = the child element of the
service-reference + the (optional) reference scheme attribute
- When the BPEL container fails to interpret
the value, it can throw "bpws:UnsupportedReference"
When the child element of the service-reference alone already
provides a clear enough semantics to a BPEL engine, a BPEL engine can
throw the fault mentioned above, if the reference scheme attribute of
any value is used.
Syntax-wise, we want to have the optional attribute to give us the
flexibility when a disambiguating is needed.
Semantics-wise, we allow BPEL engine impl to reject the optional
attribute value, when the child element has a clear enough semantics
and the combination of the attribute and value are illegal to the BPEL
engine impl.
The optional attribute proposal provides the right amount of
flexibility and zero harm to the BPEL spec and implementations.
Thanks!
Regards,
Alex Yiu
Ron Ten-Hove wrote:
Paco,
I'm not sure if you've seen the main argument for having the
reference-scheme attribute (optional or not). Suppose we had a service
reference like the following:
<ServiceRefType>
<wsdl:port name="MyNotificationPort" ...
</ServiceRefType>
The addressing schema to apply is less than clear. If my BPEL run-time
is clever, it might guess that WS-Message Delivery is implied, but it
will be at a loss to figure out which version of WS-MD to use. Also, it
is reasonable to assume that other specifications, trodding the same
ground as WS-MD, will take a similar approach, using wsdl 1.1 ports and
wsdl 2.0 endpoints.
It is for these cases, where the QName of the element enclosed by
the <ServiceRefType> is not sufficient to resolve the endpoint
reference scheme in use, that the reference-scheme attribute is needed.
If we adopt the proposed resolution to the issue 152 (below), how
are we to address the above problem?
Best regards,
-Ron
Francisco Curbera wrote:
Following up on yesterday's discussion I am proposing an alternative
resolution to issue 152. The aim, as it was discussed, is to eliminate
unnecessary and redundant syntax:
The "reference-scheme" attribute will be removed from the
"bpws:service-ref" element wrapper. The schema definition for the
wrapper
will thus be changed to the following:
<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:complexType>
Paco
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.
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.
|