You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Mike Edwards <mi...@gmail.com> on 2007/08/20 12:29:14 UTC
Re: Spec clarification for conversational/callback semantics: Reply
#1
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Spec clarification for conversational/callback semantics: Reply #1
Posted by Simon Laws <si...@googlemail.com>.
On 8/20/07, Mike Edwards <mi...@gmail.com> wrote:
>
> Simon,
>
> Comments replies inline
>
> Simon Laws wrote:
>
> > 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.
> >
>
> Yup, all that is true. This one is easier to understand. Stateful
> service with asynchronous interaction style. eg
> "Place an order for these widgets: 1, 2, 3, 4"
> / "Ack - order # abcd - will give status of widgets when I am able"
> / "Widget 1 ready for dispatch"
> / "Widget 2 ready for dispatch"
> "Status of order abcd?"
> / "Widgets 1 & 2 dispatched - Widgets 3 & 4 outanding"
> / "Widget 4 dispatched"
> / "Widget 3 unavailable in required timeframe"
>
> ...where the receiving service provider itself has to depend on other
> asynchronous providers....
>
> > 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?
>
> On the SCA spec mailing lists, we've dubbed these cases "mixed
> conversational callbacks". They are allowed, but you have to question
> the use cases carefully.
>
> This would say that the original client is not concerned to be able to
> tie the callback invocations to the original call - only to be able to
> tie together a series of callbacks (ie the callbacks share state as far
> as the client is concerned). This might make sense - eg accumulate a
> set of data as the callbacks occur until the conversation ends. If
> there is an unknown number of callback invocations, this might be
> reasonable.
>
> I think there is a need to construct a convincing example here. I
> haven't thought of a good one yet.
>
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Maybe this is more useful in the case where the callback object is not the
original client. The scenario I have in mind is a service that copies data
from one place to another where the callback represents progress updates,
e.g. in order to display a progress bar. It might be that the progress
updates go directly to some GUI connected service that is interested in
being self consistent with itself but is not connected with the original
request. Bit thin I know and I seems just as satisfactory, if not better,
to use conversational interfaces at bother ends.
Anyhow I least I know how you interpret the requirement.
Thanks for that
Simon
Re: Spec clarification for conversational/callback semantics: Reply
#1
Posted by Mike Edwards <mi...@gmail.com>.
Simon,
Comments replies inline
Simon Laws wrote:
> 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.
>
Yup, all that is true. This one is easier to understand. Stateful
service with asynchronous interaction style. eg
"Place an order for these widgets: 1, 2, 3, 4"
/ "Ack - order # abcd - will give status of widgets when I am able"
/ "Widget 1 ready for dispatch"
/ "Widget 2 ready for dispatch"
"Status of order abcd?"
/ "Widgets 1 & 2 dispatched - Widgets 3 & 4 outanding"
/ "Widget 4 dispatched"
/ "Widget 3 unavailable in required timeframe"
...where the receiving service provider itself has to depend on other
asynchronous providers....
> 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?
On the SCA spec mailing lists, we've dubbed these cases "mixed
conversational callbacks". They are allowed, but you have to question
the use cases carefully.
This would say that the original client is not concerned to be able to
tie the callback invocations to the original call - only to be able to
tie together a series of callbacks (ie the callbacks share state as far
as the client is concerned). This might make sense - eg accumulate a
set of data as the callbacks occur until the conversation ends. If
there is an unknown number of callback invocations, this might be
reasonable.
I think there is a need to construct a convincing example here. I
haven't thought of a good one yet.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Spec clarification for conversational/callback semantics: Reply #1
Posted by Simon Laws <si...@googlemail.com>.
On 8/20/07, Mike Edwards <mi...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> 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