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

[Bryan Aupperle <aupperle@us.ibm.com>]

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.  I also would expect the name to be the externally
visible parameter name. Can a return value be annotated (allowing the service
to define the correlation key)?</bea>

  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>

  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>

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