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

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

Simon Nash wrote:
> 
> 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. 

I'm curious as to how could a SCA runtime prevent such a thing (looking 
at it from a testability POV too), unless the SCA runtime prevents the 
service from making any calls anywhere, which seems unlikely.

> 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.
> 

I'm not sure what's the distinction between the two (MUST and MAY) is.
Is the difference the 'completion' part?

> 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."
> 

+1

> 
> 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/
> 
> 
> 
> 
> 
>