| 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
|