[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ISSUE 12: Long-Running Request-Response Operations
FYI - issue BPEL-12 has now been *opened* in the SCA-Assembly TC as
ASSEMBLY-33.
Reference: http://www.osoa.org/jira/browse/ASSEMBLY-33
Kind Regards
DK
----- Forwarded by Dieter Koenig1/Germany/IBM on 04.12.2007 18:35 -----
From: Dieter Koenig1/Germany/IBM@IBMDE
To: sca-bpel@lists.oasis-open.org
Date: 03.12.2007 09:25
Subject: [sca-bpel] Fw: ISSUE 33: Long-Running Request-Response Operations
FYI, I sent the BPEL-12 issue to the SCA-Assembly TC - it is now referred
to as ASSEMBLY-33.
Kind Regards
DK
----- Forwarded by Dieter Koenig1/Germany/IBM on 03.12.2007 09:22 -----
From: Scott Vorthmann <scottv@tibco.com>
To: Dieter Koenig1/Germany/IBM@IBMDE
Cc: <sca-assembly@lists.oasis-open.org>
Date: 02.12.2007 02:24
Subject: ISSUE 33: Long-Running Request-Response Operations
http://www.osoa.org/jira/browse/ASSEMBLY-33
On Nov 29, 2007, at 10:01 AM, Dieter Koenig1 wrote:
>
> (Issue originally raised as [BPEL-12] -- the SCA-BPEL TC decided to
> move it
> over to the SCA-Assembly TC)
>
> -------------------------------------------------------
>
> References:
> Original issue: http://www.osoa.org/jira/browse/BPEL-12
>
> Previous SCA-BPEL email thread:
> http://lists.oasis-open.org/archives/sca-bpel/200710/msg00045.html
> http://lists.oasis-open.org/archives/sca-bpel/200710/msg00061.html
> http://lists.oasis-open.org/archives/sca-bpel/200710/msg00062.html
> http://lists.oasis-open.org/archives/sca-bpel/200711/msg00002.html
> http://lists.oasis-open.org/archives/sca-bpel/200711/msg00027.html
> http://lists.oasis-open.org/archives/sca-bpel/200711/msg00032.html
> http://lists.oasis-open.org/archives/sca-bpel/200711/msg00033.html
> http://lists.oasis-open.org/archives/sca-bpel/200711/msg00038.html
>
> -------------------------------------------------------
>
> TARGET: SCA Assembly Specification - a resolution may affect other SCA
> specifications as well.
>
>
> 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, both 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-
> res
> ponse 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: (I withdraw my original proposal from SCA-BPEL issue
> [BPEL-12],
> introducing a new intent and implementing long-running request-
> response
> operations like separate one-way operations with one-way callback
> operations).
>
> Instead, I would like to "+1" the direction proposed in
> http://lists.oasis-open.org/archives/sca-bpel/200711/msg00002.html (
> WS-Addressing WS-Policy assertion wsam:NonAnonymousResponses)
>
> -------------------------------------------------------
>
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]