Issue 12 - Long-Running Request-Response Operations

[Alex Yiu <alex.yiu@oracle.com>]

Issue entered:
http://www.osoa.org/jira/browse/BPEL-12

Regards,
Alex

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