Re: [sca-assembly] ISSUE 56: Need to clarify definition of BidirectionalInterfaces - Proposal text

My apologies.  I accidentally left
some redundant text in the proposed resolution.  Here's the correct
version.

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 

<scn>, and a single invocation of an operation on the callback interface
can result from 

one or many invocations of any of the operations on the service interface</scn>.

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. 

    Simon

Simon C. Nash, IBM Distinguished Engineer

Member of the IBM Academy of Technology

Tel. +44-1962-815156  Fax +44-1962-818999

Simon Nash/UK/IBM@IBMGB

01/07/2008 15:01

To

"OASIS Assembly" <>

cc

Subject

Re: [sca-assembly] ISSUE 56: Need to
clarify definition of Bidirectional Interfaces  - Proposal text

Please see proposed additions in both the preamble and spec text, marked
with <scn>....</scn>. 

    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

01/07/2008 14:23

To

"OASIS Assembly"
<> 

cc

Subject

[sca-assembly] 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 

<scn> or combination of operations</scn> 

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. 

<scn>An operation on the callback interface may or may not be a direct
result of some operation invoked on the forward service interface.</scn>

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 

<scn>, and a single invocation of an operation on the callback interface
can result from 

one or many invocations of any of the operations on the service interface</scn>.

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 

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