Re: [sca-assembly] ISSUE 56: Need to clarify definition of BidirectionalInterfaces - Additional Discussion

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

+1

Martin Chapman wrote:
> 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:NASH@uk.ibm.com]
>     *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" <sca-assembly@lists.oasis-open.org>
>     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:  mike_edwards@uk.ibm.com
> 
> 
>     ------------------------------------------------------------------------
>     /
>     /
> 
>     /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/
> 
> 
> 
> 
> 
>