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]
