[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bpel] NEW ISSUE: Long-Running Request-Response Operations
Hi Anish, it sounds like a step in the same direction, although I do not
yet fully understand all the consequences of specifying
wsam:NonAnonymousResponses - I can imagine what the interaction may look
like when the operation implemented by the BPEL process is exposed as a
service with a Web service binding.
Now what would it look like if two BPEL processes are directly wired within
the same composite?
(1) How do I let the calling component's runtime know that the operation
is long-running?
(2) How should that operation be invoked in a non-blocking way (here
from a calling process' runtime)?
(Embedded image moved to file: pic13375.jpg)
Kind Regards
DK
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Anish Karmarkar <Anish.Karmarkar@oracle.com> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Dieter Koenig1/Germany/IBM@IBMDE |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Danny van der Rijn <dannyv@tibco.com>, sca-bpel@lists.oasis-open.org |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|01.11.2007 07:30 |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [sca-bpel] NEW ISSUE: Long-Running Request-Response Operations |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Dieter,
Does the WS-Addressing WS-Policy assertion wsam:NonAnonymousResponses
[1] help here?
That assertion says that the effective ReplyTo and FaultTo EPRs must be
non-anonymous. I.e., reply is sent over a separate connection. That
means in the HTTP case, the HTTP response (not the WSDL response) to the
request is sent right away (relatively) and the WSDL response is sent in
a separate HTTP connection asynchronously to the non-anon ReplyTo.
-Anish
--
[1]
http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/#wspolicynonanonresponses
Dieter Koenig1 wrote:
> 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
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
