Re: [sca-j] Inspiration or Hallucination? A proposal to resolve issues 25, 46and 10

[David Booz <booz@us.ibm.com>]

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:booz@us.ibm.com


                                                                           
             Jim Marino                                                    
             <jim.marino@gmail                                             
             .com>                                                      To 
                                       Simon Nash <NASH@uk.ibm.com>        
             07/16/2008 11:46                                           cc 
             AM                        sca-j@lists.oasis-open.org          
                                                                   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