Re: [sca-bpel] NEW ISSUE: Long-Running Request-Response Operations

[Dieter Koenig1 <dieterkoenig@de.ibm.com>]

Hi Danny, I cannot see where WSDL semantics would be changed. WSDL
request-response operations do not make assumptions about any binding
specifics, and in particular, about their response time and sync/async
transport layers.

BPEL processes have always been able to implement a WSDL r-r operation in
way that may cause the response to be delivered significantly later.

SCA clients attempting to synchronously invoke such operations will fail
when the implementation returns control e.g. a month later. An alternative
SCA approach must be made available for clients interacting with such
operations.

The point of the issue is that clients invoking such operations first need
to be made aware about their long-running nature. With that, it can be
decided that the usage of e.g. sync SOAP/HTTP bindings is not meaningful
and other async means must be used to invoke the operation.

HTH
Kind Regards
DK



                                                                                                               
  From:       Danny van der Rijn <dannyv@tibco.com>                                                            
                                                                                                               
  To:         Dieter Koenig1/Germany/IBM@IBMDE                                                                 
                                                                                                               
  Cc:         sca-bpel@lists.oasis-open.org                                                                    
                                                                                                               
  Date:       26.10.2007 20:50                                                                                 
                                                                                                               
  Subject:    Re: [sca-bpel] NEW ISSUE: Long-Running Request-Response Operations                               
                                                                                                               





      At this point in time, such long-running implementations of
      request-response operations are NOT SUPPORTED by SCA.

I'm not sure I understand this statement.  Why is it not supported?

It seems to me (without fully understanding your proposal, I admit), that
changing the semantics of a WSDL operation in the SCA-BPEL spec is out of
scope.

Danny

Dieter Koenig1 wrote:



      TARGET: SCA Client and Implementation Model Specification for WS-BPEL
      -
      note that a resolution will likely affect other SCA specifications.

      DESCRIPTION: Consider a WS-BPEL 2.0 process that implements a service
      containing a WSDL request-response operation, using an inbound
      message
      activity (<receive> or <pick>/<onMessage> or
      <eventHandlers>/<onEvent>) and
      a corresponding <reply> activity referencing this operation.
      Furthermore,
      assume that there are long-running activities between the inbound
      message
      activity and the <reply>.

      At this point in time, such long-running implementations of
      request-response operations are NOT SUPPORTED by SCA. As a result,
      the very
      first SCA-BPEL goal ("... use any valid WS-BPEL process definition as
      the
      implementation of a component within SCA") is NOT MET.

      Many concrete WS-BPEL scenarios involving such long-running
      request-response behavior EXIST TODAY - long interrupts may be caused
      by
      timer-driven activities and service invocations bound to asynchronous
      protocols or involving user interactions. Many of these long-running
      processes expose request-response operations as this is a more
      convenient
      modeling style, for example, when the business logic is structured in
      hierarchies of parent and sub-processes. SCA must support using such
      processes as implementations of SCA components.

      As an example, without loss of generality, consider the following
      very
      simple <sequence> containing a <wait> activity delaying the response
      by 14
      days (of course, real-world processes would do useful work here
      instead of
      calling the <wait> activity :-).

        <sequence>
          <receive ... operation="rrOperation" .../>
          <wait><for>'P14D'</for></wait>
          <reply ... operation="rrOperation" .../>
        </sequence>

      The SCA implementation as well as a caller of this operation should
      be made
      aware of the long-running behavior. Note that inspecting the process
      implementation is not sufficient as the long-running nature of
      activities
      may not be visible in the process model. Regardless of the structure
      of the
      SCA assembly (component/service directly/transitively wired
      within/across
      composites), an SCA implementation would want to execute calls to
      this
      operation using some asynchronous means internally.



      PROPOSAL: ********** To Be Discussed **********

      A "longRunning" intent is introduced (policy-related details tbd.),
      which
      indicates the long-running behavior of an operation:
        <operation name="rrOperation" ... requires="sca:longRunning"/>

      Its runtime semantics are defined by the following naming convention
      - a
      request-response operation (with the "longRunning" intent):

        <wsdl:operation name="rrOperation" ...>
          <wsdl:input ... message="x:inputMessage"/>
          <wsdl:output ... message="x:outputMessage"/>
          <wsdl:fault name="fault1" message="x:fault1Message"/>
          <wsdl:fault name="fault2" message="x:fault2Message"/>
          ...
        </wsdl:operation>

      is executed AS IF it was specified as a one-way operation (delivering
      the
      request):

        <wsdl:operation name="rrOperationRequest" ...>
          <wsdl:input ... message="x:inputMessage"/>
        </wsdl:operation>

      AND a set of one-way callback operations (delivering the response or
      fault):

        <wsdl:operation name="rrOperationResponse" ...>
          <wsdl:input ... message="x:outputMessage"/>
        </wsdl:operation>
        <wsdl:operation name="rrOperationFault1" ...>
          <wsdl:input message="x:fault1Message"/>
        </wsdl:operation>
        <wsdl:operation name="rrOperationFault2" ...>
          <wsdl:input message="x:fault2Message"/>
        </wsdl:operation>
        ...

      This naming convention enables an SCA implementation to execute a
      long-running request-response operation in exactly the same way as
      the
      corresponding one-way operations defined in a bidirectional
      interface.

      All existing SCA means (Java APIs etc.) for bidirectional interfaces
      can be
      reused and no new APIs are required.

      The following rules apply to SCA services and references:
        (1) Attach a "longRunning" intent to a request-response operation
      in a
      component's service if and only if its implementation exposes the
      long-running behavior described above.
        (2) Attach a "longRunning" intent to a request-response operation
      in a
      component's reference if and only if its invocation exposes the
      long-running behavior described above.
        (3) Interfaces of references and services are considered compatible
      (eligible for wiring) if both sides match w.r.t. the "longRunning"
      intent
      on their contained operations.



      Kind Regards
      DK


      ---------------------------------------------------------------------
      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