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

[Simon Nash <NASH@uk.ibm.com>]

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

17/07/2008 19:09

To	sca-j@lists.oasis-open.org
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: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














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