OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Initial example violates SA00049?


Alex, Thomas et. al,

WS-I Basic Profile 1.1 does not have any such restriction.  See: http://www.ws-i.org/Profiles/BasicProfile-1.1.html
It calls for unique names for operations within a specific portType (as operation overloading was not quite inline with interop goal of WS-I). 
But no such restriction on operation names across different portTypes.

Same goes for the names of Faults. Multiple fault definitions in a portType cannot have the same "name" but two different portTypes in a WSDL may
use the same name for a fault. 

In general it makes sense to use the same fault across different interfaces (portTypes in WSDL 1.1).
No point in inventing a different name for a fault like NullPointerException.
Do we want to force people to use different names for a Null pointer Exception?
New name for each port type for the same fault?    That seems bad modeling to me.
We need to be able to reuse the common faults (and their names) across multiple interfaces.

In the case of initial example in 5.1 both faults named "cannotCompleteOrder" are referring to the same message type "pos:orderFaultType" (see below).
I.e. it is the same exact fault! Forcing them to be named different is criminal. 


It seems we need to eliminate this restriction from BPEL, and provide a way to reuse the same faults across interfaces (just as WSDL does).

    !-- portTypes supported by the purchase order process -->
    <wsdl:portType name="purchaseOrderPT">
         <wsdl:operation name="sendPurchaseOrder">
        <wsdl:input message="pos:POMessage"/>
        <wsdl:output message="pos:InvMessage"/>
        <wsdl:fault name="cannotCompleteOrder"
           message="pos:orderFaultType"/>
         </wsdl:operation>
    </wsdl:portType>

         <!-- portType supported by the shipping service -->
    <wsdl:portType name="shippingPT">
         <wsdl:operation name="requestShipping">
        <wsdl:input message="pos:shippingRequestMessage"/>
        <wsdl:output message="pos:shippingInfoMessage"/>
        <wsdl:fault name="cannotCompleteOrder"
              message="pos:orderFaultType"/>
         </wsdl:operation>
    </wsdl:portType>


Regards,
Prasad

-------- Original Message --------
Subject: Re: [wsbpel] Initial example violates SA00049?
Date: Thu, 20 Jul 2006 15:22:05 -0700
From: Alex Yiu <alex.yiu@oracle.com>
To: Thomas Schulze <ThomasSchulze@de.ibm.com>
CC: wsbpel@lists.oasis-open.org, Alex Yiu <alex.yiu@oracle.com>
References: OFB99DE239.58A80A52-ONC12571B1.00763042-C12571B1.007723B0@de.ibm.com"><OFB99DE239.58A80A52-ONC12571B1.00763042-C12571B1.007723B0@de.ibm.com>

Thomas,

Thanks for the reply.

I would double check with WS-I people as well. Most likely, I would open 
a clarificaiton issue.

Two more data points to consider:
- Does WS-I have a similar restriction? If not, we may have problems in 
taking WS-I complaint WSDL pattern?
- With <throw>, one can associate one faultName with more than one 
faultMessageType already.  Then, what does this restriction buy us?

Most likely, I would open issue to request a clarification on that front.

Thanks!

Regards,
Alex Yiu


Thomas Schulze wrote:

>Hi Alex,
>
>I think SA00049 (that's the current SA code; I changed the subject, too)
>and the current wording in the spec in paragraph 10.3 is very clear. It
>requires uniqueness of the QName "{ns of the portType}faultName" and NOT
>only uniqueness of the faultName inside a portType. We don't like to change
>this.
>
>In the initial example the two mentioned portTypes are declared in the same
>targetNamespace "http://manufacturing.org/wsdl/purchase" and both declare
>the faultName "cannotCompleteOrder". This means the faultName QName
>
>      {http://manufacturing.org/wsdl/purchase}cannotCompleteOrder
>
>is NOT unique and thus, the initial example is not valid according to the
>current spec. That's why I propose to just fix the initial example.
>
>In case you'd like to change this rule in the spec, you should open a new
>issue.
>
>Best regards/Mit freundlichen Grüßen,
>
>       Thomas Schulze
>
>
>
>                                                                           
>             Alex Yiu                                                      
>             <alex.yiu@oracle.                                             
>             com>                                                       To 
>                                       Thomas Schulze/Germany/IBM@IBMDE    
>             19.07.2006 19:25                                           cc 
>                                       wsbpel@lists.oasis-open.org, Alex   
>                                       Yiu <alex.yiu@oracle.com>           
>                                                                   Subject 
>                                       Re: [wsbpel] Initial example        
>                                       violates SA00050?                   
>                                                                           
>
>
>Hi Thomas and others,
>
>
>Quick gut feeling response.
>
>I don't think the example violates the fault naming requirement imposed by
>the spec.
>
>"This results in a fault identified in WS-BPEL by a QName formed by the
>target namespace of the corresponding portType and the fault name. To
>ensure uniqueness, this uniform naming mechanism MUST be followed  even
>though it does not match the WSDL’s fault-naming model ..."
>
>IMHO, it does NOT imply or enforce that the faultName QName must be unique
>by across all portTypes.
>
>However, I agree that the underlined sentence sounds a bit ambiguous to me.
>That is what is the uniqueness it is referring to???
>
>"This results in a fault identified in WS-BPEL by a QName formed by the
>target namespace of the corresponding portType and the fault name. To
>ensure consistent fault identification, this uniform naming mechanism MUST
>be followed  even though it does not match the WSDL’s fault-naming model
>..."
>
>**IF** the sentence did enforce that the faultName QName must be unique by
>across all portTypes, the semantic would be very strange. When mapped to
>OOP world, interfaces of the same package cannot throw the same Exception?
>
>Thomas ... if you disagree with my interpretation, we may need to open our
>last BPEL issue on that. (sorry to john and diane in advance)
>
>Thanks!
>
>
>Regards,
>Alex Yiu
>
>
>Thomas Schulze wrote:
>      The initial example in 5.1 introduces the WSDL fault
>      'cannotCompleteOrder'
>      two times, one for portType 'purchaseOrderPT' operation
>      'sendPurchaseOrder'
>      and one for portType 'shippingPT' operation 'requestShipping'. This
>      violates SA00050 (v26 of the SA List):
>
>      "In the case of a request-response invocation, the operation might
>      return a
>      WSDL fault message. This results in a fault identified in WS-BPEL by
>      a
>      QName formed by the target namespace of the corresponding portType
>      and the
>      fault name. To ensure uniqueness, this uniform naming mechanism MUST
>      be
>      followed even though it does not match the WSDL’s fault-naming
>      model."
>
>      Should this be fixed before the freeze? If yes, some adaptions to 5.6
>      are
>      necessary, too...
>
>      Best regards/Mit freundlichen Grüßen,
>
>             Thomas Schulze
>  
>


Alex Yiu wrote:

Thomas,

Thanks for the reply.

I would double check with WS-I people as well. Most likely, I would open a clarificaiton issue.

Two more data points to consider:
- Does WS-I have a similar restriction? If not, we may have problems in taking WS-I complaint WSDL pattern?
- With <throw>, one can associate one faultName with more than one faultMessageType already.  Then, what does this restriction buy us?

Most likely, I would open issue to request a clarification on that front.

Thanks!

Regards,
Alex Yiu


Thomas Schulze wrote:

Hi Alex,

I think SA00049 (that's the current SA code; I changed the subject, too)
and the current wording in the spec in paragraph 10.3 is very clear. It
requires uniqueness of the QName "{ns of the portType}faultName" and NOT
only uniqueness of the faultName inside a portType. We don't like to change
this.

In the initial example the two mentioned portTypes are declared in the same
targetNamespace "http://manufacturing.org/wsdl/purchase" and both declare
the faultName "cannotCompleteOrder". This means the faultName QName

     {http://manufacturing.org/wsdl/purchase}cannotCompleteOrder

is NOT unique and thus, the initial example is not valid according to the
current spec. That's why I propose to just fix the initial example.

In case you'd like to change this rule in the spec, you should open a new
issue.

Best regards/Mit freundlichen Grüßen,

      Thomas Schulze



                                                                                      Alex Yiu                                                                  <alex.yiu@oracle.                                                         com>                                                       To                                       Thomas Schulze/Germany/IBM@IBMDE                19.07.2006 19:25                                           cc                                       wsbpel@lists.oasis-open.org, Alex                                         Yiu <alex.yiu@oracle.com>                                                                             Subject                                       Re: [wsbpel] Initial example                                              violates SA00050?                                                                                                                                                                                                                                                                                                                            

Hi Thomas and others,


Quick gut feeling response.

I don't think the example violates the fault naming requirement imposed by
the spec.

"This results in a fault identified in WS-BPEL by a QName formed by the
target namespace of the corresponding portType and the fault name. To
ensure uniqueness, this uniform naming mechanism MUST be followed  even
though it does not match the WSDL’s fault-naming model ..."

IMHO, it does NOT imply or enforce that the faultName QName must be unique
by across all portTypes.

However, I agree that the underlined sentence sounds a bit ambiguous to me.
That is what is the uniqueness it is referring to???

"This results in a fault identified in WS-BPEL by a QName formed by the
target namespace of the corresponding portType and the fault name. To
ensure consistent fault identification, this uniform naming mechanism MUST
be followed  even though it does not match the WSDL’s fault-naming model
..."

**IF** the sentence did enforce that the faultName QName must be unique by
across all portTypes, the semantic would be very strange. When mapped to
OOP world, interfaces of the same package cannot throw the same Exception?

Thomas ... if you disagree with my interpretation, we may need to open our
last BPEL issue on that. (sorry to john and diane in advance)

Thanks!


Regards,
Alex Yiu


Thomas Schulze wrote:
     The initial example in 5.1 introduces the WSDL fault
     'cannotCompleteOrder'
     two times, one for portType 'purchaseOrderPT' operation
     'sendPurchaseOrder'
     and one for portType 'shippingPT' operation 'requestShipping'. This
     violates SA00050 (v26 of the SA List):

     "In the case of a request-response invocation, the operation might
     return a
     WSDL fault message. This results in a fault identified in WS-BPEL by
     a
     QName formed by the target namespace of the corresponding portType
     and the
     fault name. To ensure uniqueness, this uniform naming mechanism MUST
     be
     followed even though it does not match the WSDL’s fault-naming
     model."

     Should this be fixed before the freeze? If yes, some adaptions to 5.6
     are
     necessary, too...

     Best regards/Mit freundlichen Grüßen,

            Thomas Schulze
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]