[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 152 - New Proposal to Vote
Hi Alex, I guess everyone is already tired as of this issue as we both are, but here we go again... Flexibility is great but, as we learned from the WSDL case, it burdens implementations with additional, often unnecessary complexity and muddles the cleanliness of the design. Your explanation below only confirms this. It is bad enough that we need to wrapper EPRs, but it the politics of the moment didn't allow for more. Now you want a second level of indirection so in addition opening the wrapper to retrieve the epr data, one has to interpret that data conditionally based on the presence of yet a second piece of information (the attribute in question). This is really ugly, and an unnecessary burden to place on BPEL users and implementers (even if optional, one must be ready to follow your little algorithm to decipher the epr). If what you want to do is use the WSDL service element as an EPR that is fine, but you need to figure out how to assign clear semantics to it (use WSDL extensibility for example); solving that problem is WS-MD's business, not BPEL's. Paco Alex Yiu <alex.yiu@oracle. To: Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM> com> cc: Francisco Curbera/Watson/IBM@IBMUS, wsbpel@lists.oasis-open.org, Alex Yiu <alex.yiu@oracle.com> 09/02/2004 07:23 Subject: Re: [wsbpel] Issue - 152 - New Proposal to Vote PM 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 .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]