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

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

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