OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

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

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


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

     And then I woke up :-)  What do you think... was this inspiration or


     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:

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]