On Jan 5, 2007, at 1:41 PM, Ignacio Silva-Lepe wrote:
> 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?
I may not be following the issue (it's been some time and I don't
remember what point 2 is ;-) ) but I'm not seeing the problem. Let's
take two scenarios:
1. C's service contact and scope are conversational. In this case,
implementation instances are managed by ConversationalScopeContainer.
The wiring infrastructure must ensure that the correct invocation
handlers and interceptors are set up in the invocation chains to
associate the conversational id with the current WorkContext as a
request moves through m1. If the client that invoked m1 is non-
conversational (it could be a component with another scope or non-
managed code), an id will need to be created (an interceptor can do
this on the target inbound wire) and associated with the WorkContext.
The ConversationalScopeContainer will then use the current work
context to retrieve the id and delegate to the Store to retrieve the
correct implementation instance. For the callback cb1, the
infrastructure will route back to the same conversational instance
unless it is expired, in which case a handler will be called.
2. C's service contract is conversational but its scope is not. In
this case, the callback will delegate to the AtomicComponent which
will then delegate to its associated scope container. The scope
container will use whatever the current context is to return a
particular implementation instance. The implementation can use the
ServiceReference API to retrieve the current conversational id. This
means that the wiring infrastructure may still need to propagate the
current conversational id. This can be determined in ConnectorImpl or
a preferably a WirePostProcessor, which can interpose interceptors if
necessary.
> 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.
It wouldn't be the interface but the implementation C's scope. We
already track this metadata which we would use in setting up
invocation chains as mentioned above.
> 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.
I was assuming the invocation over m1 would create the conversation
id when it hits the inbound wire. However, this only happens if C's
scope is conversational. Also, this to me is a *component
implementation* detail and not something that should be expressed by
the interface.
> 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.
I think we are conflating the concepts of a conversational interface
and conversational scope. The conversational interface is a contract
the service implementation must support with the client.
Conversational scope is a contract the component implementation has
with the runtime. The wiring fabric should not really care about the
interface at this point but should instead key off scope.
> 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]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
