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: Simon Nash <NASH@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 8 Jul 2008 15:26:48 +0100
Mike,
I believe we agree on the concepts but
we are not yet agreed on the form of words that should be added to the
spec.
I'm surprised that you think the whole
area of callbacks should be covered by a top-level MAY. This needs
some discussion. I'd be interested to hear other views on this.
I would like the words in the added
paragraph to be normative and fairly explicit. Your latest revised
proposed text still uses non-normative language, and I'm not comfortable
that adding the words "and their timing" is sufficiently precise
to cover all the different interaction sequences between forward and callback
invocations. Specifcally, the distinction between "callback
before invocation completion" and "callback after invocation
completion" doesn't appear in your proposed words.
Here's a revision of my words, updated
to clarify these points.
"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 an invocation of any operation on the service interface
to be followed by zero, one or many invocations of any of the operations
on the callback interface. These callback operations can be invoked
either before or after the operation on the service interface has returned
its result.
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."
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
08/07/2008 12:26
|
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 |
|
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
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]