Re: [sca-j] ISSUE 95: Proposed direction for resolution

[Simon Nash <oasis@cjnash.com>]

Apologies for the delayed response.  Comments inline.

   Simon

Bryan Aupperle wrote:
> 
> Overall I like the direction
> 
> Comments/questions below <bea>...,</bea>
> 
> Bryan Aupperle, Ph.D.
> STSM, WebSphere Enterprise Platform Software Solution Architect
> 
> Research Triangle Park,  NC
> +1 919-254-7508 (T/L 444-7508)
> Internet Address: aupperle@us.ibm.com
> 
> 
> *Simon Nash <oasis@cjnash.com>*
> 
> 12/08/2008 10:03 AM
> 
> 	
> To
> 	sca-j@lists.oasis-open.org
> cc
> 	
> Subject
> 	[sca-j] ISSUE 95: Proposed direction for resolution
> 
> 
> 	
> 
> 
> 
> 
> 
> The following is a high-level sketch of a proposed direction for resolving
> issue JAVA-95.  Comments and suggested improvements are most welcome.
> 
>  1. Rename CONVERSATIONAL scope to STATEFUL scope.
> 
>  2. Remove @Conversational and @EndsConversation from interfaces.
> 
>  3. Introduce a new annotation @Correlation(name) for parameters of
>     service methods of STATEFUL-scoped implementations.  When a method
>     of a STATEFUL-scoped implementation is dispatched by the SCA runtime,
>     the set of names and values identified by its @Correlation
>     annotations is used to attempt to locate an existing matching instance
>     in the component's correlated instance pool.  If a matching instance
>     is found, it is used for the method dispatch.  If no matching instance
>     is found, a new instance is created and placed in the correlated
>     instance pool, identified by the correlation set of names and values.
> 
> <bea> I understand this as the set of named correlation parameters asts 
> as a key for identifying an instance and that there must be some named 
> parameter overlap across the different operations of the service.
 >
Yes, that's the intention.

 >                                                                    I
> also would expect the name to be the externally visible parameter name.
 >
What do you mean by the externally visible parameter name?  In Java,
parameter names aren't available by introspection unless the class is
compiled with debug information.  I was not assuming any constraint
on what could be specified for this name.

> Can a return value be annotated (allowing the service to define the 
> correlation key)?</bea>
> 
I thought about this.  It could be useful to support the following
pattern:
1. The service provides a "create()" method that creates, initializes
    and returns a new correlated instance.  Any parameters passed on
    create() are used to initialize the instance.
2. Subsequent invocations by the client use the instance that was
    created in step 1.
3. If create() was not called, the instance will be implicitly
    created as part of step 2.  The service can choose (in business
    logic) to either allow or disallow this implicit creation.

>  4. Introduce a new annotation @EndCorrelation for service methods of
>     STATEFUL-scoped implementations.  When an @EndCorrelation method
>     is dispatched and returns to the SCA runtime, the instance that was
>     used for the dispatch is removed from the pool of correlated instances.
> 
>  5. Introduce a new annotation @StartCorrelation for service methods of
>     STATEFUL-scoped implementations.  When a @StartCorrelation method
>     is dispatched by the SCA runtime, an existing instance must not be
>     used for the dispatch, even if it matches the correlation set data.
>     If a matching instance is found, the SCA runtime MUST throw a
>     ServiceRuntimeException.
> 
>  6. A method with no @Correlation annotations implies @EndCorrelation.
>     It will always create a new instance because it has no correlation
>     set data that can be used to match an existing instance in the
>     correlated instance pool.
> 
> <bea> I understand creating a new (effectively stateless) instance, but 
> why end some existing instance (and for that matter which existing 
> instance should be ended)?</bea>
> 
Sorry that this was not clear.  I meant that the newly created instance
that's used to dispatch this method will automatically be released when
this method returns.

>  7. Rename @ConversationAttributes to @CorrelationAttributes.
> 
>  8. Remove Conversation class and @ConversationID annotation.
> 
>  9. Remove stateful callbacks.
> 
> <bea> Why not allow @Correlation annotations on the callback interface? 
>  Since the implementation is now in control of an instance's lifetime 
> (it exists until returning from an @EndCorrelation method or the 
> response is delivered asynchronously), it should be relatively clear how 
> to program this. </bea>
> 
Again, sorry that this was not clear.  I meant that the existing defintion
of stateful callbacks (using conversational interfaces) would be removed.
I agree that @Correlation annotations should be allowed on callback
implementation methods (not the callback interface) and the semantics
would be the same as for implementation methods of the forward interface.
However, I would not describe this as "stateful callbacks".

> 10. Remove isConversational() and getConversation() from CallbableReference.
> 
> 11. Remove getConversationID() and setConversationID() from 
> ServiceReference.
> 
> 12. Remove ServiceReference class.
> 
> 13. Remove ConversationEndedException.
> 
>   Simon
> 
> 
> ---------------------------------------------------------------------
> 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
> 
>