Re: [wsbpel] Issue - 152 - New Proposal to Vote

[Francisco Curbera <curbera@us.ibm.com>]

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
      .