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