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

[Simon Nash <NASH@uk.ibm.com>]

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