TITLE: Long-Running Request-Response Operations
SUBMITTED BY: Dieter Koenig
 
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.