sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Simplifying Clarification of Bidirectional Interface tohelp resolve SCA Assembly Issue 4
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 12 Feb 2008 09:11:26 +0000
Tom,
I disagree on exactly this point.
Given the open style of bidirectional
interfaces in the Assembly specification, I believe that in general there
IS a need for correlation between service
invocations and the resulting callback invocations.
The problem is simply that callbacks
allow for 0..n callback operations to occur for any given service
operation. These callback invocations
are asynchronous and can occur at any time.
So, if ever a client invokes more than
one forward service operation on a given bidirectional service, then
the client has the problem of working
out to which service operation a particular callback message relates.
There is no guaranteed order here.
"ConversationID" will not
help. The conversationID is always the same for one particular client
and one
service that it uses. It will
not enable the client to identify the original request when a callback
operation is
invoked.
The only alternative mechanism that
I can see is to require correlation data in the body of the messages
themselves. This too has its drawbacks.
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
Tom Rutt <tom@coastin.com>
12/02/2008 00:54
Please respond to
tom@coastin.com |
|
To
| tom@coastin.com
|
cc
| sca-assembly@lists.oasis-open.org
|
Subject
| Re: [sca-assembly] Simplifying Clarification
of Bidirectional Interface to help resolve SCA Assembly Issue 4 |
|
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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]