Next in thread →
Next in month →
Re: [sca-j] Inspiration or Hallucination? A proposal to resolve issues 25, 46and 10
Dave,
Yes, this was discussed at the F2F.
There is not much recorded in the chat log as no decisions were made.
I have an action to produce a write-up for the non-conversational
callback case (in two parts: conceptual model and Java APIs) by August
7th.
Option 11b was my attempt to address
the concern about heaviness on the wire.
I agree that samples would be useful.
I'll go back to my previous proposal from March, which had 4 use
cases as illustrations, and show how these would look with this proposal.
I'll send this out early next week.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
David Booz <>
17/07/2008 19:09
To
cc
Subject
Re: [sca-j] Inspiration or Hallucination?
A proposal to resolve issues 25, 46 and 10
Did you get to discuss this hallucination at the F2F?
I didn't see
anything in the minutes (might have missed it).
I certainly have sympathy with some of the ideas, though I'm concerned
that
it makes the stateless cases heavier on the wire than it should be.
There is enough complexity here that a set of samples would be useful.
In
fact, we should start with the samples and then incrementally work back
to
a proposal. Simon, do you have a few app examples in mind already?
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:
Jim Marino
<jim.marino@gmail
.com>
To
Simon Nash
<>
07/16/2008 11:46
cc
AM
Subject
Re: [sca-j]
Inspiration or
Hallucination?
A proposal to
resolve
issues 25, 46 and 10
Hi Simon,
I'm very sympathetic to eliminating many of the Java APIs as it is close
to
the proposal Mike and I made in this respect. However, I have a few
questions. It's early for me so I may have missed some obvious things:
1. Are you proposing CallableReference be passed as part of the service
contract in 11a or passed as part of the invocation context, transparent
to
application code? I think it is the latter but I want to be sure (of course
someone could explicitly pass a CallableReference if they chose to do so)
2. I like the idea of allowing other scopes to implement their own
state
correlation mechanisms you outlined below but I don't think we should
eliminate @EndsConversation as that allows implementations to avoid APIs
(it's less complex) and being unnecessarily tied to an SCA container. I
would, however, potentially also favor inferring the implementation scope
if @EndsConversation were present, saving the implementor the step of doing
this. In fact, forgetting to add @Scope("CONVERSATION") has been
a very
common occurrence with some of the developers I have been working with
and
it has lead to bugs that were initially difficult to track down.
I need to think more about it, but I'm generally open to this and am
willing to help write up a proposal. One thing that would help is to do
so
with some sample code.
Jim
On Jul 16, 2008, at 6:22 AM, Simon Nash wrote:
Jetlag can have interesting effects, such as waking
up early in the
morning with the mind racing at full speed and ideas
coming faster
than I can capture them.
Here's a proposal to resolve issue 25, along the lines
of the action
that I took at the F2F yesterday. The thought
process behind this
also leads to conclusions on how issues 46 and 10
should be resolved,
and suggests a simpler approach for handling conversational
state.
1. Remove ServiceReference and retain CallableReference.
2. CallableReference instances are immutable.
3. A CallableReference instance contains a service
destination
(endpoint), an optional callback destination (endpoint),
and an
identity that can be compared using equals().
4. Each type-safe proxy has an associated CallableReference
instance.
ComponentContext.cast() can be used on a proxy to
obtain its
CallableReference instance. CallableReference.getService()
can be
used to obtain a type-safe proxy for the service destination
of the
CallableReference. CallableReference.getCallback()
can be used to
obtain a type-safe proxy for the callback destination
of the
CallableReference, if it has a callback destination.
The same
CallableReference state is shared between the results
of all these
methods.
5. When making a forward call across a bi-directional
interface, the
CallableReference that made the forward call is passed
by the
infrastructure and is available to the service business
method by
injection of a CallableReference or a type-safe callback
proxy, or
from the RequestContext.
6. When making a callback across a bi-directional
interface, the
CallableReference that made the forward call is passed
by the
infrastructure and is available to the callback business
method by
injection of a CallableReference, or from the RequestContext.
7. The client can correlate between the forward call
and any
callbacks made on behalf of that call by an equals()
comparison of
the CallableReference used to make the forward call
and the
CallableReference received by the callback.
8. If the client wants to associate distinct identities
with
different forward calls, it does this by creating
and using a new
CallableReference for each distinct identity that
is needed. This is
done by calling CallableReference.createCallableReference().
The
result of this method has the same service and callback
destinations
and a different identity for equality comparison purposes.
9. The same mechanism is used to identify conversations.
All calls
made by a client on behalf of the same conversation
use the same
CallableReference instance. A new conversation
is started by
creating and using a new CallableReference instance.
10. A CONVERSATION-scoped implementation uses the
CallableReference
passed with a call to automatically locate the instance
to be used to
dispatch the business method. For COMPOSITE
and STATELESS scopes,
the CallableReference is available to business logic
so that it can
perform its own correlation.
11a. There is no need to mark interfaces as conversational,
as all
SCA calls pass a CallableReference that may be used
to provide
conversational semantics. (Alternative option
11b: retain the
conversational marking of interfaces and only pass
the client's
CallableReference identity if the interface is marked
as
bidirectional or conversational.)
The following can be eliminated from the Java APIs
with no loss of
capability:
a. The ServiceReference interface.
b. The getCallbackReference() method of RequestContext.
c. The isConversational(), getConversation() and getCallbackID()
methods of CallableReference.
d. The Conversation interface.
e. The @Conversational annotation (if option 11a is
chosen).
f. The @ConversationID annotation.
g. The @EndsConversation annotation.
The following should be added:
h. CallableReference.getCallback()
i. CallableReference.createCallableReference
j. An @CallableReference annotation to inject the
CallableReference
that was passed with the forward call or callback
(replaces
@ConverationID).
And then I woke up :-) What do you think...
was this inspiration or
hallucination?
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to 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
Next in thread →
Next in month →