Simon,
I'm breaking my reply into two parts, each dealing with one of the
issues you raised originally:
Simon Laws wrote:
1/ Stateful Callbacks - Given the the following scenario where the
ConversationalClient has a reference to a ConversationalService
@Remotable
@Conversational
public interface ConversationalCallback {
...
}
@Remotable
@Conversational
@Callback(ConversationalCallback.class)
public interface ConversationalService {
....
}
@Scope("CONVERSATION")
public class ConversationalClientImpl implements ConversationalClient,
ConversationalCallback {
@Reference
protected ConversationalService conversationalService;
....
}
@Scope("CONVERSATION")
public class ConversationalServiceImpl implements ConversationalService {
@Callback
protected ConversationalCallback conversationalCallback;
...
}
In the current implementation the specification has been interpreted to mean
that the "client" component, i.e. the component implementing the callback
interface, must be marked as having conversational scope if it is required
that callback messages return to the same instance of the client component
that originated the conversational call. Is this the correct interpretation
of the specification, in particular Section 1.6.7.1 of the SCA Java
Annotations and APIs V1.0 specification.
Strictly speaking, Conversation SCOPE is independent of the
@Conversational marking of interface(s) for a service.
To clarify: It is possible to implement Conversational interfaces using
code that is itself stateless (ie does not matter which implementation
instance receives a given message), since the code can be written to
look up the conversation ID and save/retrieve conversation state data
using some backing store. For long running conversations, this design
pattern is usually preferable since the container is not burdened with
maintaining a lot of quiescent instances and the state data is "backed up".
However, Conversation scope is a very useful way of marking
implementations which have to deal with Conversational interfaces, since
it removes the need for the programmer to do explicit management of
state. Marking an implementation with conversational scope is a request
that the container of the component performs the state management.
The only way to guarantee that the same client instance and the same
server instance are involved for every operation of an interface
involving a callback is to mark both the client implementation and the
server implementation with Scope "CONVERSATION". This must be in
addition to both the "call" interface and the "Callback" interface being
marked with @Conversational. In implementation terms, I then view this as:
a) The @Conversational marking ensures that a unique ID is associated
with the messages transmitted from Client to Provider and with the
messages from the Provider to the Client (note in the callback case, the
callback operations are in principle completely asynchronous in relation
to the call operations - and the number and type of callback operations
for a given call operation is completely variable)
b) The @Scope("CONVERSATION") marking on both the client implementation
and on the provider implementation then flags up to the container(s)
that the instances on each end have an extended lifecycle associated
with the conversational interfaces and that the conversation ID should
be used by the container to select the appropriate instance to receive a
message.
An errata is in process of being raised against the Java Annotations and
APIs spec to make a clarification along the lines I've written here -
I'd appreciate feedback on whether my words here are clear and would
improve the spec if added there.....
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
