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:
Simon Nash <>
12/08/2008 10:03 AM
To
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
