Hi Jim, I dropped the ball on this to go on vacation ... apologies, had a lot of fun though ... :-) Comments inline.
On 12/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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.
I agree with this for the most part, assuming the issue below is addressed. Assuming C's scope is conversational, what I described earlier should
hold.
I may be missing something, but I don't think that your point 2 above (dispatching to the conversational instance) addresses my concern. Specifically, how is the conversational instance of C arrived at? Even if the implementation of C is not conversational, at least there must be a way for the invocation of cb1 to convey a conversation id. How is this conversation id determined? My thought is that marking the callback interface (that includes cb1) as conversational is not enough. The conversation id converyed by the invocation of cb1 must be able to be used to retrieve the relevant state. But this state was put together prior to any callback invocation and so it needs to be associated with a conversation id before any such callback. This is not how conversational invocations work at the moment. Currently, a conversation id is created as a result of a conversational invocation. So if we just do the same, the conversation id conveyed by cb1 won't be created until T calls cb1 for the first time, which is too late. In order to associate the state that cb1 is going to use, the conversation id that is going to be conveyed by cb1 must be created when this state is put together, which is in the invocation of m1. This is what I mean by having to make m1 (and thus its interface) conversational as well. So it seems like, regardless of whether C's implementation is conversational, if C implements a callback interface that is marked as conversational, then the interface that uses the bi-directional (which includes the callback) interface must also be conversational. That, or we need another way to tell the runtime that a conversation id must be created prior to invoking m1. Does this make any sense? 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]
