ISSUE 56: Need to clarify definition of Bidirectional Interfaces -Proposal text

Folks, 

Here is the proposal text for Issue
56 

-----------------------------------------------------------------------------------------

Preamble.  In the Issue text, Tom
Rutt posed 3 questions, which are not answered by the current specification,

each of which needs an answer - following
that is formal specification text which is proposed to be added to

the specification.

1) Does every operation type invoked
onto the "service interface" 

direction have the potential to have
correlated callback interface 

operations in the opposite direction?

Answer: 

In principle, any one of the forward
interface operations may cause zero, one or many invocations on the callback

interface by the service provider.  For
each of the forward service operations, any of the operations on the

callback interface may get invoked,
in any order.

This is a case of "maximum flexibility,
minimum information".  The service provider gets to use the callback
interface

in any way that makes sense - but it
gives the client a hard time in working out what will happen for a given
invocation.

For the client to get more information,
extra metadata is required which is not captured by SCA today.

2) Does every operation invocation invoked
onto the callback interface 

have to be considered as a callback
for an operation invocation on the 

service interface? 

Answer:

Every invocation on an operation of
the callback interface is considered to be the result of some operation

invoked on the forward service interface.

3) How can it be specified (at design
time) which operation types defined 

in the callback interface description
can be correlated with which 

individual operation types defined in
the service interface description? 

Answer:

This kind of metadata about the service
and the callback must be provided outside the standard SCA metadata.

It could be done through informal documentation.
 It could be done by more formal means (one possibility might

be to use abstract BPEL to indicate
the sequencing of messages).  SCA leaves this open to the creator
of the

callback interface and the service that
uses it.

The problem in the general case is to
convey alternatives.  In the simplest case, one forward call results
in exactly

one invocation of the callback interface
(see Isseue 33 and the "long running request/response" pattern
as an example

of this).  However, there are plenty
of existing examples of asynchronous sequences much more complex than this.

Even ordering a book with Amazon has
this potential for complex interactions - one request to order a set of
books

results (usually) in at least 2 responses
- one accepting the order and one indicating dispatch of the package.  However,

not all the order may get dispatched
at once and a sequence of messages for each dispatch can occur.  It
is also 

possible that one or more books is not
available for some lenghy period, in which case a callback message is

sent which gives the client the opportunity
to cancel that part of the order.  OK, this is all done with email,
but it is

possible to see that similar sequences
could apply to order processing offered as Web services.

-----------------------------------------------------------------------------------------

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.  For a given invocation
of a service operation,

which operations are invoked on the
callback interface, 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.

-----------------------------------------------------------------------------------------

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