[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]