On 8/20/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
>
> 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]
>
> Mike
Thanks for the clarification. I think the separate discussion of
@Conversational and @Scope("CONVERSATION") provides a good basis for
clarification in the specifications. So a further small point of
clarification on this topic.
This is about understanding the behavior of the callback and is regardless
of the @Scope annotations of client and service provider ends of our
callback scenario
Scenario1
=======
Callback is @Conversational / Service Provider is @Conversational
This relates to your point a). The conversation will encompass the client
(in as much that it initiates the conversation and provides a conversation
id), the service provider and any callbacks. The net result is that state
maintained by the client based on the original conversation id is accessible
to the callback based on the conversation id it is provided with. Also the
service provider is able to correlate state across calls to it based on the
same conversation id.
Scenario2
========
Callback is @Conversational / Service Provider is not @Conversational
Is this valid/sensible? Is the client able to correlate callbacks with the
original request based on conversation id in this case or must it rely on
callback id, i.e. the conversation id is simply for correlating one callback
with the next?
Regards
Simon
