On 8/20/07, Mike Edwards <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> 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
