[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NEW ISSUE: Long-Running Request-Response Operations
(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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]