On Dec 19, 2006, at 8:12 AM, Ignacio Silva-Lepe wrote:
I'm assuming the goal of supporting conversational callbacks
is to allow a callback invocation to occur on a client component
instance that contains state that existed when the correspon-
ding forward invocation went out. This to me means that the
client component instance behaves as a conversational ser-
vice for callback purposes, which is consistent with the spec
requirement that the callback interface be marked as conver-
sational. This in turn means that the client component could
be marked as having conversational scope, which implies that
the conversational container must keep track of it for this case.
However, in this case, when the first callback arrives, it must
find an already associated instance, unlike the case of a for-
ward conversational invocation. Consider a client component
C that implements a method m1. m1 invokes a method m2,
which has a callback method cb1 implemented by C, where
C also has conversational scope (in addition to implemen-
ting the conversational callback interface). Since the invo-
cation of cb1 must occur on a stateful instance, then it must
find an associated instance. Thus, the execution of m1,
which sets up the state used by cb1, must occur in the con-
versation that involves cb1. In other words, the conversation
that involves cb1 must exist at the point m1 is invoked.
This seems to be saying that m1 needs to be conversational
as well, and that its conversation id must be used in the in-
vocation of cb1.
The spec needs some work in this area. Assuming the following:
C --- m1-----> T
C <--m2------- T
T would not have to be conversational since I think it should be
possible to call to services of other scopes, e.g. composite scoped.
An area not really addressed in the spec is what happens during the
callback to C through m2. Specifically, what instance of C the
request is dispatched to. We should clarify this in the spec. My
inclination would be the following:
1. The only guarantee made is that the callback be dispatched back to
a service on component C
2. This dispatch can be either to the conversational instance C or,
if C has expired, to a "callback handler"
3. This "callback handler" would be a new concept. It would be a
class that was set using the service reference API and would have to
implement the callback service interface and have a no-args ctor
4. This callback handler could be generalized to other scopes as
well, not just conversations. It would be responsible for taking some
type of business action or correlating state.
What do you think?
Jim
This in turn seems to imply that m1's inter-
face needs to be conversational, and that the conversation
id needs to be available to the callback invocation handler
for cb1, which seems to suggest the need for conversation
id propagation for this case as well.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
