Re: [sca-assembly] Simplifying Clarification of Bidirectional Interfaceto help resolve SCA Assembly Issue 4

[Tom Rutt <tom@coastin.com>]

I would like to add one clarificaton

My point is that bidirectional interfaces and their callback intefaces 
do not require correlation between operations on
the two directional interfaces.

Any such correlation across operation invocations can use the 
Conversation mechanism, which does carry a conversation id
for this correlation.  It is redundant and complicating to also have a 
callbackID for cross operation correlation for bidirectional interfaces.

Tom

Tom Rutt wrote:
> This email proposes a clarifying interpretation of the
> definition of Bidirectional interface, which would simplify
> the resolution of Issue Assembly-4
> (http://www.osoa.org/jira/browse/ASSEMBLY-4 )
>
> Section 8.2 of the Assembly WD02 defines Bidirectional
> Interface. The second paragrapn (lines 2222-2224) currently
> states”
> “
> An interface element for a particular interface type system
> must allow the specification of an optional callback
> interface. If a callback interface is specified SCA refers
> to the interface as a whole as a bidirectional interface.
> “
>
> Lines 2231-2237 currently state the following;
> “
> If a service is defined using a bidirectional interface
> element then its implementation implements the interface,
> and its implementation uses the callback interface to
> converse with the client that called the service interface.
>
> If a reference is defined using a bidirectional interface
> element, the client component implementation using the
> reference calls the referenced service using the interface.
> The client component implementation must implement the
> callback interface.
> “
>
> This simple definition only implies that a Bidirectional
> Interface has two separate interface types, with opposite
> directionality for client and server.
>
> Any infrastructure a service is bound to must support the
> correlation of an operation invocation with the receipt of
> the response for that operation, as defined within the a
> single interface type (e.g., for WSDL Soap bindings this is
> done thru the use of http request/response message pairs).
>
> However, there is nothing in the definitions quoted above
> that implies that the infrastructure must correlate the
> invocation of an operation type on the callback interface
> with an earlier invocation of another operation type on the
> service interface of a bidirectional interface.  In fact,
> the notion of callbackID (which appears in the Java
> Annotations and API spec), does not appear in the Assembly
> spec.
>
> The notion of bidirectional interface / callback interface
> can be greatly simplified if the assembly spec clarifies
> that the infrastructure has no requirement for correlating
> the invocation of an operation on a callback interface with
> the invocation of an operation on the service interface. With this 
> simplifying clarification, any required
> correlation can be provided by the application specific
> design of the service and callback interfaces (e.g, the
> Purchase order number from the service interface operation
> invocation message would appear as a parameter in the
> callback interface operation invocation message for any
> subsequent invoice).
>
> All that is required for the infrastructure binding of a
> bidirectional interface, is for it to be able to “wire” the
> bidirectional interface’s service and callback interfaces
> in a paired and complimentary manner.
>
>
> Tom Rutt
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133