Title: [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:
"
type="cite">
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
