RE: [sca-assembly] ISSUE 56: Need to clarify definition of Bidirectional Interfaces - Additional Discussion

Title: Message

I 
think the correlation topic should be separated out into a separate issue as it 
warrants much deeper thought.

My 
view on the topic is that we need to distinguish between SCA runtime provided 
correlation, and application correlation based on content of application data in 
messages.

An SCA 
service/callback should be able to mark its interface as requiring SCA Runtime 
correlation, which requires support in its bindings.

I am 
very scared of SCA saying anything about application correlation, which to me 
includes c+i specs. The reason for this is that one must not assume that both 
parties are in the same language and understand the correlation mechanism 
without some extra meta-data.

 

Martin.

 

 

  

  
-----Original Message-----
From: Simon Nash 
  [mailto:] 
Sent: 07 July 2008 12:31
To: 
  OASIS Assembly
Subject: Re: [sca-assembly] ISSUE 56: Need to clarify 
  definition of Bidirectional Interfaces - Additional 
  Discussion

I believe we 
  were moving towards an emerging consensus on last week's call that the 
  question of whether the Assembly spec should mandate, prohibit or permit 
  per-message correlation IDs should be the subject of another issue, and that 
  the resolution to issue 56 should focus on normative rules for how SCA 
  runtimes should support callbacks. 

Here's my attempt at the latter: 

"In a bidirectional interface, the service interface can have more than 
  one operation defined, and the callback interface can also have more than one 
  operation defined.  SCA runtimes MUST allow a single invocation of an 
  operation on the service interface to make zero, one or many invocations of 
  any of the operations on the callback interface.  SCA runtimes MAY also 
  allow operations to be invoked on the callback interface following completion 
  of an invocation of an operation on the service interface. 
  

For a given invocation of a service 
  operation, which operations are invoked on the callback interface, when these 
  are invoked, the number of operations invoked, and their sequence are not 
  described by SCA.  It is possible that this metadata about the 
  bidirectional interface can be supplied through mechanisms outside SCA. 
   For example, it might be provided as a written 
description attached 
  to the callback interface." 

Regarding correlations, I don't think it would be proper for the 
  Assembly spec to direct other SCA specs using RFC2119 language of the form 
  "....such mechanisms SHOULD be provided both by Bindings and by Client API 
  specifications".  This is a misuse of RFC2119, and it is also loose 
  enough that it could cause serious problems if these other specs were to 
  define such facilities with inconsistent or incompatible semantics.  If 
  an SCA correlation mechanism is required (as opposed to allowing use of 
  transport-level correlation facilities), the Assembly spec should define its 
  semantics and conformance points, and leave other specs to indicate how it is 
  supported by specific bindings and implementation types. 

    Simon 

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM 
  Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999 
  

  
    
    

      Mike 
        Edwards/UK/IBM@IBMGB 
        
07/07/2008 10:17 

      
        
          
          

            
              
To

            "OASIS Assembly" 
              <> 
          

            
              
cc

            
          

            
              
Subject

            [sca-assembly] ISSUE 56: Need to 
              clarify definition of Bidirectional Interfaces - Additional 
              Discussion

        
          
          

            
            

Folks, 

In last weeks' TC conf call, the discussion of 
  Issue 56 was lively and important. 

The discussion closed with the following motion on 
  the table: 

Proposed text for the Assembly specification (CD-01), to be added 
  after line 2333 

"In a bidirectional interface, the service interface can have more 
  than one operation defined, and the callback interface can 
  
also have more than one operation 
  defined.  A single invocation of an operation on the service interface 
  can cause 
zero, 
  one or many invocations of any of the operations on the callback interface and 
  a single invocation of an operation on 
the callback interface can result 
  from one or from many invocations of any of the operations on the service 
  interface. 
For a 
  given invocation of a service operation, which operations are invoked on the 
  callback interface, the number of operations 
invoked, how they are correlated, and their 
  sequence are not described by SCA.  It is possible that this metadata 
  about 
the bidirectional interface can be supplied through mechanisms 
  outside SCA. For example, it might be provided as a written 
description attached to the 
  callback interface. " 

I'd like to concentrate on the one aspect of this proposal that I 
  think is not good - the outlawing of means for the correlation 
of callback 
  operations with forward operations. 

First, I'd like to (again) discuss the impact that 
  this has on applications.  If the system (SCA) provides no means for the 
  
correlation of the callback operations, then it is left to the application 
  writer(s) - in particular to the designer of the forward and 
callback interfaces. 
    

Without 
  any system provided correlation, the interface designer has to anticipate the 
  correlation needs of the client (in 
particular) - and must place elements into the 
  business data that provide this correlation capability.  This will often 
  go 
beyond a simple 
  parameter such as (say) "Order ID", since if the forward service interface 
  provides multiple operations 
relating to an order, the callback messages may well have to carry 
  something like a "Request ID" in order to make it 
  
clear to the client that a given 
  response relates to a particular request that the client made - without this 
  the client may 
have real problems working out the true meaning of the callback 
  operation. 

I 
  note that a single, consistent, system provided means of correlation of this 
  type is preferable to the alternative of every 
  
designer having to work it out for 
  themselves. 

Second, I note that numerous transport mechanisms including Web 
  services and JMS (and related messaging subsystems) 
  
provide a capability of marking a 
  response message with an ID which indicates the request message that it 
  relates to. 
It is 
  notable that the designers of these transport mechanisms considered it 
  important to have this function, which has 
the capability of permitting the client to 
  establish which to original message a response relates, without the need to 
  sort 
through the 
  business data. 

I believe that it is reasonable for SCA to provide SCA applications 
  with mechanisms to access this capability of underlying 
  
transports, without the need for the 
  applications having to resort to transport-specific APIs. 
  

So, in summary, I continue to 
  support the notion of SCA-provided correlation mechanisms - and that the 
  Assembly specification 
should assert that such mechanisms SHOULD be provided both by 
  Bindings and by Client API specifications. 
  

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: 
   

  
  

  
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 
  

  
  

  
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