OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sca-bpel] Issue 12: Long-Running Request-Response Operations


Mike, thanks for digging into the potential consequences of this issue from
an SCA-Assembly perspective.

One minor point here: the client-provided interface
 b)  void someOperationResponse( SomeResponseMessageType response ) throws
 OperationException1, OperationException2

must allow delivering either the response (WSDL output) or one of the
exceptions (WSDL faults) *to* the client, so it would probably look like
this:
 b)  void someOperationResponse( SomeResponseMessageType response )
   void someOperationFault1( SomeFault1MessageType fault1 )
   void someOperationFault2( SomeFault2MessageType fault2 )

Kind Regards
DK
                                                                       
 Dieter König                          Mail: dieterkoenig@de.ibm.com         IBM Deutschland Entwicklung GmbH
                                                                       
 Senior Technical Staff Member         Tel (office): (+49) 7031-16-3426      Vorsitzender des Aufsichtsrats:
                                                                             Martin Jetter
                                                                       
 Architect, Business Process           Fax (office): (+49) 7031-16-4890      Geschäftsführung: Herbert Kircher
 Choreographer                                                         
                                                                       
 Member, Technical Expert Council      Tel (home office): (+49) 7032-201464  Sitz der Gesellschaft: Böblingen
                                                                       
                                       Schönaicher Strasse 220, 71032        Registergericht: Amtsgericht
                                       Böblingen, Germany                    Stuttgart, HRB 243294
                                                                       
                                                                       
                                                                       





                                                                       
  From:       "Patil, Sanjay" <sanjay.patil@sap.com>                   
                                                                       
  To:         "Mike Edwards" <mike_edwards@uk.ibm.com>, "OASIS BPEL" <sca-bpel@lists.oasis-open.org>, "OASIS Assembly"
              <sca-assembly@lists.oasis-open.org>                      
                                                                       
  Date:       08.11.2007 00:18                                         
                                                                       
  Subject:    RE: [sca-bpel] Issue 12: Long-Running Request-Response Operations
                                                                       





Corrected the subject - s/Issue 5/Issue 12

 From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
 Sent: Wednesday, Nov 07, 2007 2:38 AM
 To: OASIS BPEL; OASIS Assembly
 Subject: [sca-bpel] Issue 5: Long-Running Request-Response Operations


 Anish,

 (I am copying this email to Assembly as well as BPEL - I think there is an
 Assembly issue lurking here that applies cross-language)

 You are correct in saying that the behaviour sought is like that implied
 by the NonAnonymousResponses assertion.

 Another way of putting things, more in SCA terms, is that these sorts of
 operations actually imply a Callback style of interface.

 This is important, since it means, for example, that the initial request
 operation by the client will complete without a response from
 the service provider (as you say, there is an HTTP response but NOT a WSDL
 response).  The response from the service
 operation arrives later as a separate connection.  This is *precisely* the
 idea behind callbacks and its asynchonous nature
 is then "obvious" to the client, since there is a requirement to provide
 the callback interface to get the WSDL response message.


 OK, so far.

 Client Implementation

 The first implication for me is on the client programming API.  What is
 described in WSDL terms as a Request/Response operation
 is regularly mapped (using Java as the example) to a client API like:

 SomeResponseMessageType response someOperation( SomeRequestMessageType
 request ) throws OperationException1, OperationException2

 ....but in the case of "long running" operations must be mapped to
 something more like:

 a)  void someOperation( SomeRequestMessageType request )

 and

 b)  void someOperationResponse( SomeResponseMessageType response ) throws
 OperationException1, OperationException2

 ...where the client calls a reference with an interface including a) but
 where the client must provide an interface including b)

 There is also the need for a correlation between the original call to a)
 and the callback on b).  This might be achieved through
 an ID being generated by the system when a) is called (would need to be
 returned on the call), which can then be gathered from
 the context when the callback is called.  Or it could be done in the now
 "approved" asynchronous fashion for Java, by returning
 a Future<type x> object from a) - and which would then implement the
 interface b) and get called when the response message
 arrives back at the client.

 Service Implementation

 The second implication for me is on the service implementation.  The
 service implementation must know to "release" the protocol
 stack which made the original service invocation, ideally rapidly after
 the original request arrives.  There is then the need  for the
 protocol stack to make a completely new connection when dealing with the
 response message.

 Now, this could be done via the Binding code - with the simple
 call-and-return style preserved for the service implementation.
 However, this may or may not be a sensible way of doing things.  The
 alternative is that the service implementation takes the
 original request, gets a callback reference stores it and returns rapidly,
 long before the operation is actually complete - the
 callback reference is then used whenever the operation does complete
 asynchronously.  The latter approach would use
 the split interface style of a) and b) above.

 WSDL and Interface handling

 One way of approaching this then is to affect the interpretation of the
 WSDL:

 a) Let's assume that the WSDL operation is request/response

 b) Let's assume that the WSDL operation is marked "long running" (some
 annotation to this effect)

 c) WSDL2LanguageX tools would have modified behaviour when encountering
 this annotation and would generate
 the "dual interface" mapping implied above.  Clearly this does not apply
 to BPEL, which uses WSDL "native".

 d) Clients and Providers in some native language would use the "dual
 interface" form and construct their code
 appropriately, in callback style.

 e) If WSDL is used directly, then its interpretation by runtime and
 binding code will be consistent with the interpretation
 give here.

 f) The WSDL annotation COULD be viewed as a Policy intent - it is just
 that its implications go a bit further than selecting
 an appropriate policyset  for the binding, since it affects the form of
 the client and provider code.  This intent might
 imply the WS-Policy assertion that Anish picks out, in the case of Web
 services.  In the case of JMS and messaging
 subsystems, things might be different (and simpler).


 Conclusion

 I hope that this helps in the debate - it is an interesting problem and a
 common case once we deal with long-running
 business processes.

 Yours,  Mike.

 Strategist - Emerging Technologies, SCA & SDO.
 Co Chair OASIS SCA Assembly TC.
 IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
 Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431
 Email:  mike_edwards@uk.ibm.com

                                                                       
 Anish Karmarkar                                                       
 <Anish.Karmarkar@oracle.com>                                          
                                                                       
                                                                        To
 01/11/2007 06:29                     Dieter Koenig1                   
                                      <dieterkoenig@de.ibm.com>        
                                                                        cc
                                      Danny van der Rijn               
                                      <dannyv@tibco.com>,              
                                      sca-bpel@lists.oasis-open.org    
                                                                   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









 Unless stated otherwise above:
 IBM United Kingdom Limited - Registered in England and Wales with number
 741598.
 Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU












[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]