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

Corrected the subject - s/Issue 5/Issue 
12

  

  
  From: Mike Edwards 
  [mailto:] 
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: 
    

  
    
    

      Anish Karmarkar 
        <> 
        
01/11/2007 06:29 

      
        
          
          

            
              
To

            Dieter Koenig1 
              <> 
          

            
              
cc

            Danny van der Rijn 
              <>,  
          

            
              
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 
  <>               
                        
                        
   
>                   
                        
                        
                        
                        
       
>   To:         Dieter 
  Koenig1/Germany/IBM@IBMDE               
                        
                        
        
>               
                        
                        
                        
                        
           
>   Cc:       
                 
                        
                        
             
>         
                        
                        
                        
                        
                 
>   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