On Dec 21, 2006, at 8:03 AM, Ignacio Silva-Lepe wrote:
Actually, the picture that corresponds better to the situation
I was trying to present is as follows:
---m1--> C ----m2--> T
C <--cb1--- T
I agree that T should not have to be conversational, although the
runtime would need to make sure that the necessary conversation
id is available when cb1 is invoked.
I was not yet considering an expired C. But in order for there to be
a C (that may expire) that has the state that cb1 is interested in,
and that is accessible to T, two things need to happen:
a) When C is instantiated, it needs to be associated with an id that
can be used to retrieve this instance when cb1 is invoked
b) This association needs to be known by the time m1 is invoked
on C so that m1 can set up any state that is going to be used
by cb1
So, my first thought was that it seems like m1 (and thus its
interface) need to be conversational.
The implementation of C need not be conversational, even if its
interface is marked as such and vice versa. If the implementation is
a scope other than conversational, it will be responsible for
managing state (the runtime will still need to propagate the
conversation id). It is also possible for C to implement two
services, one conversational and the other non-conversational. We
should not need to do anything special in the runtime other than
ensuring id propagation as the current scope container architecture
should handle this.
Assuming C's scope is conversational, what I described earlier should
hold. If T's scope is conversational, a second conversation is in
effect between C and T. If T is of another scope, we should probably
default to routing back to the same instance of C although that would
be an implementation detail and could not be counted on since C could
expire (in which case a handler would be dispatched to). My
inclination is that If someone wants to guarantee the callback cb1 to
invoke on the same instance of C, they should make T conversational.
Does this correspond to what you are thinking?
There may be other ways of
achieving the goal of having the instance that m1 sets up associated
with the conversation id used by cb1 though, but I have not thought
of any yet.
Also, in order for cb1 to retrieve the appropriate instance of C, the
corresponding conversation id needs to be available at the time the
target invoker tries to retrieve the instance of C, which may need
some collaboration by cb1's callback invocation handler.
Yes as an implementation strategy.
On 12/20/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
