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: New Issue: Clarification for Section 10.4 Given R18 Resolution


New Issue: Clarification for Section 10.4 Given R18 Resolution
Justification/Description: When R18 was resolved another section was 
impacted but not addressed by those approved changes. See current text 
in Section 10.4:

    (existing)
    WS-BPEL treats faults based on abstract WSDL 1.1 operation
    definitions, without reference to binding details. This limits the
    ability of a WS-BPEL process to determine the information
    transmitted when faults are returned over a SOAP binding.

Reference R18 resolution located at: 
http://www.choreology.com/external/WS_BPEL_review_issues_list.html#IssueR18

    Change 10.3, page 86 from

        In WSDL it is possible to declare an operation that declares
        more than one fault using the same data type. Certain WSDL
        bindings do not provide enough information for the WS-BPEL
        process to infer which fault was intended. In this case, the
        WS-BPEL process MUST infer the first fault declared for the
        operation that matches the transmitted data. A result of this
        requirement is that a process may have different behavior when
        deployed against different bindings. 

    To:

        In WSDL it is possible to define an operation that declares more
        than one fault using the same data type. Certain WSDL bindings
        do not provide enough information for the WS-BPEL processor to
        determine which fault was intended. In this case, the WS-BPEL
        processor MUST select the fault that:

            * Matches the transmitted data and
            * Occurs first in lexical order in the operation definition

        A result of this requirement is that a process, which uses the
        <catch> construct based on faultName and deals with such an
        operation definition, may have different behavior when deployed
        against different bindings. 

    and section 3, P. 11 change to

        While WS-BPEL attempts to provide as much compatibility with
        WSDL 1.1 as possible there are three areas where such
        compatibility is not feasible.

            * Fault naming with its restriction, as discussed later in
              this document (see section 10.3 Involving Web service
              operations)...

Proposed solution:
Take an abbreviated approach for Section 10.4 and reference 10.3.

    Change from: WS-BPEL treats faults based on abstract WSDL 1.1
    operation definitions, without reference to binding details. This
    limits the ability of a WS-BPEL process to determine the information
    transmitted when faults are returned over a SOAP binding.

    Change to: WS-BPEL treats faults based on abstract WSDL 1.1
    operation definitions. This limits the ability of a WS-BPEL process
    to determine the information transmitted when faults are returned,
    such as for a SOAP binding (See Section 10.3, Invoking Web Services
    Operations - Invoke for fault treatment).





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