[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]