OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


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?


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?


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?

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]