sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] ISSUE 56: Need to clarify definition of BidirectionalInterfaces - Additional Discussion
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 8 Jul 2008 12:26:23 +0100
Folks,
There are several bones in here that
I'd like to pick out, marked inline as
<mje> ... </mje>
A suggested revision of the wording
I previously proposed follows - removing anything about correlation and
adding in words about timing and lack
of constraints....
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 and a single invocation of an operation on
the callback interface can result from one or from many invocations of
any of the operations on the service interface.
For a given invocation of a service operation, which operations are invoked
on the callback interface, the number of operations
invoked, their sequence and their timing are not constrained by SCA and
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
Simon Nash/UK/IBM@IBMGB
07/07/2008 12:31
|
To
| "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [sca-assembly] ISSUE 56: Need to
clarify definition of Bidirectional Interfaces - Additional Discussion |
|
I believe we were moving towards an emerging consensus on last week's call
that the question of whether the Assembly spec should mandate, prohibit
or permit per-message correlation IDs should be the subject of another
issue, and that the resolution to issue 56 should focus on normative rules
for how SCA runtimes should support callbacks.
<mje> Agree </mje>
Here's my attempt at the latter:
<mje>
Not sure where to put this
comment - so up front seemed as bad a place as any ;-) I'm OK with
having RFC2119 language, but I think I'd prefer a style where we say something
like "an SCA runtime MAY support bidirectional interfaces" and
then go on to describe the characteristics of bidirectional interfaces
without RFC2119 language embedded. The runtime then does not get
to pick and choose - implement all that is required or none. The
problem with the language as below is that the application programmer is
left uncertain as to what they can rely on, It is much easier to
understand that you get all or nothing.
</mje>
"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. SCA runtimes MUST allow a single invocation
of an operation on the service interface to make zero, one or many invocations
of any of the operations on the callback interface. SCA runtimes
MAY also allow operations to be invoked on the callback interface following
completion of an invocation of an operation on the service interface.
<mje>
OK, my first surprise when
reading this carefully is the interpretation or meaning given to the term
"invocation".
The way it is used here
is to imply that "invocation" is being used in the sense of "the
time span of the call made to the service implementation code when the
initial service operation is invoked" (in Java terms, the span
of the method call which implements the service operation).
This was a surprise to
me. I can see how such a meaning then gives rise to the second sentence
above.
However, this was never
my understanding of how async, callback-based services were intended to
work. For me, the initial forward service request is merely the initiator
of some sequence that is potentially long drawn-out in time. It is
my expectation that 99% of the time, the initial forward service call is
done and dusted before the first of any callback operations gets invoked.
If it were likely that the response messages could be produced during
the life of the forward service invocation call, then I don't know why
I would use an asynchonous pattern at all. The whole point of the
async pattern is that the responses are likely to take a while - and it
does not seem reasonable to keep the initial invocation "alive"
for this period.
For me, if we really want
to get into specifying the detail, the timing of the response messages
relative to the forward invocation MUST also be completely free. I
would require an SCA runtime that supports callbacks to permit the callback
operations to occur at any time after the initial invocation - and that
the runtime MUST permit callback messages to be returned aftern the initial
invocation is "complete" (we'd have to define that term - at
the very least it would mean the release of the binding and underlying
transport resources for the forward call).
I'm OK for some runtime
not to support callbacks at all, but if they are going to be supported,
then the time sequencing must be free, decided by the application code
and any services that it might depend on.
</mje>
For a given invocation of a service operation, which operations are invoked
on the callback interface, when these are invoked, 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."
<mje>
I agree with this - but
I have this previously unstated view that not only are the operations,
timing, sequence not described by SCA - they are also NOT CONSTRAINED by
SCA, which is what is behind my comment on the previous paragraph.
</mje>
Regarding correlations, I don't think it would be proper for the Assembly
spec to direct other SCA specs using RFC2119 language of the form "....such
mechanisms SHOULD be provided both by Bindings and by Client API specifications".
This is a misuse of RFC2119, and it is also loose enough that it
could cause serious problems if these other specs were to define such facilities
with inconsistent or incompatible semantics. If an SCA correlation
mechanism is required (as opposed to allowing use of transport-level correlation
facilities), the Assembly spec should define its semantics and conformance
points, and leave other specs to indicate how it is supported by specific
bindings and implementation types.
<mje> I agree that
we should move the discussion of correlations elsewhere</mje>
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
07/07/2008 10:17
|
To
| "OASIS Assembly"
<sca-assembly@lists.oasis-open.org>
|
cc
|
|
Subject
| [sca-assembly] ISSUE 56: Need to clarify
definition of Bidirectional Interfaces - Additional Discussion |
|
Folks,
In last weeks' TC conf call, the discussion of Issue 56 was lively and
important.
The discussion closed with the following motion on the table:
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 and a single invocation of an operation on
the callback interface can result from one or from many invocations of
any of the operations on the service interface.
For a given invocation of a service operation, which operations are invoked
on the callback interface, the number of operations
invoked, how they are correlated, 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. "
I'd like to concentrate on the one aspect of this proposal that I think
is not good - the outlawing of means for the correlation
of callback operations with forward operations.
First, I'd like to (again) discuss the impact that this has on applications.
If the system (SCA) provides no means for the
correlation of the callback operations, then it is left to the application
writer(s) - in particular to the designer of the forward and
callback interfaces.
Without any system provided correlation, the interface designer has to
anticipate the correlation needs of the client (in
particular) - and must place elements into the business data that provide
this correlation capability. This will often go
beyond a simple parameter such as (say) "Order ID", since if
the forward service interface provides multiple operations
relating to an order, the callback messages may well have to carry something
like a "Request ID" in order to make it
clear to the client that a given response relates to a particular request
that the client made - without this the client may
have real problems working out the true meaning of the callback operation.
I note that a single, consistent, system provided means of correlation
of this type is preferable to the alternative of every
designer having to work it out for themselves.
Second, I note that numerous transport mechanisms including Web services
and JMS (and related messaging subsystems)
provide a capability of marking a response message with an ID which indicates
the request message that it relates to.
It is notable that the designers of these transport mechanisms considered
it important to have this function, which has
the capability of permitting the client to establish which to original
message a response relates, without the need to sort
through the business data.
I believe that it is reasonable for SCA to provide SCA applications with
mechanisms to access this capability of underlying
transports, without the need for the applications having to resort to transport-specific
APIs.
So, in summary, I continue to support the notion of SCA-provided correlation
mechanisms - and that the Assembly specification
should assert that such mechanisms SHOULD be provided both by Bindings
and by Client API specifications.
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]