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] Issue - 110 - Proposal for Vote


Danny, I added a sentence with RFC 2119 "MUST" language for static
analysis.

Part 1.
In section 10.2, add the following sentence to the end of paragraph
starting with "Correlation set names are used in invoke, ...":
--------------------------------------------------------
The pattern attribute of invoke is only allowed for request-response
operations, and disallowed when a one-way operation is invoked. Any
violation of this rule MUST be detected during static analysis.
--------------------------------------------------------

Part 2.
The values of the pattern attribute are changed from
"out"|"in"|"out-in" to "request"|"response"|"request-response",
respectively (all occurrences in examples):
 - in section 10.2, change "out" to "request" (4x)
 - in section 10.2, change "in" to "response" (1x)
 - in section 13.3.1, change "out" to "request" (4x)
 - in section 16.1.3, change "out" to "request" (2x)

The explanation in section 10.2 almost matches already; change one
sentence in the paragraph starting with "Correlation set names are
used in invoke, ..." from:
--------------------------------------------------------
Finally, in the case of invoke, when the operation invoked is
synchronous request/response, a pattern attribute is used to indicate
whether the correlation applies to the outbound (request) message,
the inbound (response) message, or both.
--------------------------------------------------------
to:
--------------------------------------------------------
Finally, in the case of invoke, when the operation invoked is
synchronous request/response, a pattern attribute is used to indicate
whether the correlation applies to the outbound message ("request"),
the inbound message ("response"), or both ("request-response").
--------------------------------------------------------

Part 3.
The consolidated syntax of invoke is (duplicate in 6.2 and 11.3 :-)
as follows:
--------------------------------------------------------
<invoke partnerLink="ncname" portType="qname"? operation="ncname"
        inputVariable="ncname"? outputVariable="ncname"?
        standard-attributes>
standard-elements
<toPart part="ncname" fromVariable="ncname"/>*
<fromPart part="ncname" toVariable="ncname"/>*
<correlations>?
   <correlation set="ncname" initiate="yes|no"?
      pattern="request|response|request-response"?/>+
</correlations>
<catch faultName="qname"? faultVariable="ncname"?
                          faultMessageType="qname"?
                          faultElement="qname"?>*
   activity
</catch>
<catchAll>?
   activity
</catchAll>
<compensationHandler>?
   activity
</compensationHandler>
</invoke>
--------------------------------------------------------

Kind Regards
DK



                                                                           
             Danny van der                                                 
             Rijn                                                          
             <dannyv@tibco.com                                          To 
             >                         wsbpeltc                            
                                       <wsbpel@lists.oasis-open.org>       
             08.12.2005 18:37                                           cc 
                                                                           
                                                                   Subject 
                                       Re: [wsbpel] Issue - 110 - Proposal 
                                       for Vote                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           






Dieter Koenig1 wrote:
      So here is 110 again, now as an official Proposal for Vote.

      Part 1.
      In section 10.2, add the following sentence to the end of paragraph
      starting with "Correlation set names are used in invoke, ...":
      --------------------------------------------------------
      The pattern attribute of invoke is only allowed for request-response
      operations, and disallowed when a one-way operation is invoked.
      --------------------------------------------------------

RFC 2119 "MUST" language for static analysis?

      Part 2.
      The values of the pattern attribute are changed from
      "out"|"in"|"out-in" to "request"|"response"|"request-response",
      respectively (all occurrences in examples):
       - in section 10.2, change "out" to "request" (4x)
       - in section 10.2, change "in" to "response" (1x)
       - in section 13.3.1, change "out" to "request" (4x)
       - in section 16.1.3, change "out" to "request" (2x)

      The explanation in section 10.2 almost matches already; change one
      sentence in the paragraph starting with "Correlation set names are
      used in invoke, ..." from:
      --------------------------------------------------------
      Finally, in the case of invoke, when the operation invoked is
      synchronous request/response, a pattern attribute is used to indicate
      whether the correlation applies to the outbound (request) message,
      the inbound (response) message, or both.
      --------------------------------------------------------
      to:
      --------------------------------------------------------
      Finally, in the case of invoke, when the operation invoked is
      synchronous request/response, a pattern attribute is used to indicate
      whether the correlation applies to the outbound message ("request"),
      the inbound message ("response"), or both ("request-response").
      --------------------------------------------------------

      Part 3.
      The consolidated syntax of invoke is (duplicate in 6.2 and 11.3 :-)
      as follows:
      --------------------------------------------------------
      <invoke partnerLink="ncname" portType="qname"? operation="ncname"
              inputVariable="ncname"? outputVariable="ncname"?
              standard-attributes>
      standard-elements
      <toPart part="ncname" fromVariable="ncname"/>*
      <fromPart part="ncname" toVariable="ncname"/>*
      <correlations>?
         <correlation set="ncname" initiate="yes|no"?
            pattern="request|response|request-response"?/>+
      </correlations>
      <catch faultName="qname"? faultVariable="ncname"?
                                faultMessageType="qname"?
                                faultElement="qname"?>*
         activity
      </catch>
      <catchAll>?
         activity
      </catchAll>
      <compensationHandler>?
         activity
      </compensationHandler>
      </invoke>
      --------------------------------------------------------

      Kind Regards
      DK




                   Alex Yiu

                   <alex.yiu@oracle.

                   com>
      To
                                             Dieter
      Koenig1/Germany/IBM@IBMDE
                   07.12.2005 17:59
      cc
                                             wsbpeltc

                                             <wsbpel@lists.oasis-open.org>,
      Alex
                                             Yiu <alex.yiu@oracle.com>


      Subject
                                             Re: [wsbpel] Issue - 110 -
      Proposal
                                             for Vote












      Hi DK,

      Just a reminder of what I mentioned in the conf call:
      (4) I would prefer keeping "inputVariable" and "outputVariable"
      (that
      is not renaming to "requestVariable" and "responseVariable").
      Reasoning:
      As Danny mentioned, it would be odd to use a "requestVariable"
      attribute
      on a ONE-WAY operation. As Dieter himself mentioned, the
      inputVariable
      and outputVariable do match the input/output in WSDL definition.
      (5) We need to incorporate the latest syntax fromPart and toPart in
      the
      updated proposal with consolidated <invoke> syntax.

      Thanks!

      REgards,
      Alex Yiu


      Dieter Koenig1 wrote:


            As discussed in the last call and f2f meeting, I am resending
            the original
            proposal for vote:
            (1) replace the terms "asynchronous" and "synchronous" in
            references to

      the

            pattern attribute with "one-way" and "request/response",
            respectively
            (2) restrict the use of the pattern attribute to invokes of
            request-response operations only, i.e. do not use pattern
            together with
            one-way operations
            (3) replace pattern="in|out|out-in" with
            pattern="request|response|request-response"

            Part (1) has been done already for the whole spec in response
            to the
            resolution of issue 122.
            Part (3) had been withdrawn by Yaron at the f2f meeting - we
            may discuss
            this part and amend the proposal ...

            Kind Regards
            DK

            ----- Forwarded by Dieter Koenig1/Germany/IBM on 17.11.2005
            17:52 -----




                        "Yaron Y. Goland"



                        <ygoland@bea.com>



            To



                        16.09.2004 03:15          wsbpeltc




            <wsbpel@lists.oasis-open.org>



            cc



                        Please respond to



                             ygoland
            Subject



                                                  [wsbpel] Issue - 110 -
            Proposal for



                                                  Vote


















            Replace Section 11.3 with:

            BPEL processes can call Web Services to perform work on their
            behalf
            (see Partner Link Types, Partner Links and Endpoint
            References). A BPEL
            process invokes a web service using the invoke activity.

            <invoke partnerLink="ncname" portType="qname"?
            operation="ncname"
                        requestVariable="ncname"?
            responseVariable="ncname"?
                        standard-attributes>
                        standard-elements
                        <correlations>?
                             <correlation set="ncname" initiate="yes|no"?

            pattern="request|response|request-response"/>+
                            </correlations>
                        <catch faultName="qname" faultVariable="ncname"?
                                      faultMessageType="qname"?>*
                                activity
                        </catch>
                        <catchAll>?
                                activity
                        </catchAll>
                        <compensationHandler>?
                              activity
                        </compensationHandler>
            </invoke>

            The invoke activity is used anytime a BPEL process wishes to
            send a
            message to another web service. In the case of a one-way
            message
            exchange pattern (MEP) the invoke activity will return as soon
            as the
            message is sent. In the case of a request/response MEP the
            invoke
            activity will not return until the response is received, this
            behavior
            applies even if the underlying request/response MEP is
            asynchronous.

            On a one-way MEP the requestVariable attribute is used to
            specify the
            message to be sent. The responseVariable attribute is not used
            as no
            response is sent to a one-way MEP. On a request/response MEP
            the
            requestVariable attribute is used to specify the message to be
            sent and
            the responseVariable attribute is used to record the response
            that is
            returned.

            The partnerLink, portType and operation attributes play their
            usual
            roles of identifying exactly what message is to be sent and to
            whom.

            Correlation sets MAY be used on invoke activities to coordinate
            with
            stateful partner processes. See Correlation for more
            information.

            The invoke activity has an in-line fault handler. The in-line
            fault
            handler allows the invoke activity to handle any WSDL fault
            messages
            that may be received in response to a request/response MEP
            directly
            within the invoke activity itself. If the invoke activity's
            fault
            handler does not catch a WSDL or other fault then the fault
            will be
            thrown to the scope that encloses the activity (see Scopes and
            Fault
            Handlers).

            Note that a WSDL fault is identified in BPEL by a qualified
            name formed
            by the target namespace of the corresponding portType and the
            fault
            name. This uniform naming mechanism must be followed even
            though it does
            not accurately match WSDL’s fault naming model. Because WSDL
            does not
            require that fault names be unique within the namespace where
            the
            service operation is defined, all faults sharing a common name
            and
            defined in the same namespace are indistinguishable in BPEL. In
            WSDL 1.1
            it is necessary to specify a portType name, an operation name,
            and the
            fault name to uniquely identify a fault. This limits the
            ability to use
            fault-handling mechanisms to deal with invocation faults.

            Finally, the invoke activity has an in-line compensation
            handler. This
            compensation handler can be invoked either explicitly or by the
            default
            compensation handler of the enclosing scope (see Scopes and
            Compensation
            Handlers).

            Semantically, the specification of local fault and/or
            compensation
            handlers is equivalent to the presence of an implicit scope
            immediately
            enclosing the activity and providing those handlers. The name
            of such an
            implicit scope is always the same as the name of the activity
            it encloses.

            The following example shows an invocation with a nested
            compensation
            handler. Other examples are shown throughout the specification.

            <invoke partnerLink="Seller" portType="SP:Purchasing"
                        operation="SyncPurchase"
                        requestVariable="sendPO"
                        responseVariable="getResponse">
                  <compensationHandler>
                        <invoke partnerLink="Seller"
            portType="SP:Purchasing"
                             operation="CancelPurchase"
                            requestVariable="getResponse"
                            responseVariable="getConfirmation">
                  </compensationHandler>
            </invoke>

            Section 10.2

            From: Finally, in the case of invoke, when the operation
            invoked is
            synchronous request/response, a pattern attribute is used to
            indicate
            whether the correlation applies to the outbound (request)
            message, the
            inbound (response) message, or both.

            To: Finally, in the case of invoke, when the operation invoked
            is a
            request/response message exchange pattern, a pattern attribute
            is used
            to indicate whether the correlation applies to the request
            message, the
            response message, or both.

            Entire Spec:

            A global replace of inputVariable with requestVariable and
            outputVariable with responseVariable as well as a global
            replace of all
            values of pattern from in|out|out-in to
            request|response|response-request.

            Schema:

            tInvoke

            From: <attribute name="inputVariable" type="NCName"
            use="optional"/>
                  <attribute name="outputVariable" type="NCName"
            use="optional"/>

            To: <attribute name="requestVariable" type="NCName"
            use="optional"/>
                <attribute name="responseVariable" type="NCName"
            use="optional"/>

            tCorrelationWithPattern

            From: <enumeration value="in"/>
                  <enumeration value="out"/>
                  <enumeration value="out-in"/>

            To: <enumeration value="request"/>
                <enumeration value="response"/>
                <enumeration value="response-request"/>

            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 mail list, you must leave the OASIS TC that
      generates this mail.  You may a link to this group and all your TCs
      in
      OASIS
      at:
      https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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