Ok, so we are agreeing that C has a (service) contract with T
by virtue of the callback interface (that defines cb1), and that
contract is conversational and it does not pertain to any
other client.
You are also saying that the conversation id to be used by
m1 to set up state, and by cb1 to use that state, can be created
by a new kind of interceptor attached to the inbound invocation
chain for m1. This interceptor would only be created if C has
conversational scope. Also, this interceptor would be attached
to the inbound invocation chain of every method implemented
by C, not just m1. If C does not have conversational scope, then
it is up to C to create the conversation id. The conversation id
is created by the interceptor only if there is not one already in
the work context. Let me know if this is not what you mean.
In addition, I think we'll need to maintain two conversation ids
in the work context, a call forward id (which we currently maintain)
and a callback id. Otherwise we won't be able to correlate properly
with the callback state at C and the call forward state at T. In
particular, if T is conversational, then when m1 calls m2, two ids
need to be conveyed, one newly created for the call forward
conversation between C and T, and the one created for the
callback. This is because I am assuming that only one id can
be used to identify a component's state in its container.
Also notice that the new interceptor creates a conv id in addition
to the creation of a (forward) conv id currently done by the
outbound invocation handler. And notice that the outbound
invocation handler creates a conv id based on whether there is
a conv contract on the wire, and the new interceptor creates
a conv id based on whether the component has conv scope,
which seems a bit asymmetric.
On 1/8/07, Jim Marino <[EMAIL PROTECTED]> wrote:
On Jan 8, 2007, at 8:18 AM, Ignacio Silva-Lepe wrote:
> Hmm, the premise of your scenarios is actually what I am trying
> to figure out. In either of the two scenarios you assume that C's
> contract is conversational. C's contract with whom?
I have a feeling we are not using the same terminology and that is
causing confusion. We need to be specific here: there are two
contracts. The service contract is between the service implementation
and the client. The scope is the contract between the implementation
and the container. For example, it is possible to have a
conversational service contract and stateless scope.
> The real
> requirement is that we support cb1, and thus its interface, as
> conversational. Does the fact that cb1's interface is conversational
> mean that C has a conversational contract with any client?
No, just the callback
> If this is not true then we still need to determine how a conversation
> id can be available to m1 by the time it is invoked. Note that I am
> not assuming that m1, and thus its interface, is conversational.
It is also possible to have a conversational scoped component with a
stateless service contract
> Rather, I am trying to figure out if it makes sense to make it so
> to support the cb1 requirement.
Given C is conversational scoped in the following scenario:
--m1-->C---m2-->T
C<--cb1--T
The wiring fabric determines that an interceptor needs needs to be
placed on the inbound chain for C that creates and sets
conversational id in the current context if not present. Two
outcomes will happen depending on the client that invokes m1. If the
client is conversation scoped, a conversation will be set up between
it and C and that will follow the original scenario I outlined a
while back (cb1 is not guaranteed to dispatch back to the same
instance C but we do so as an implementation strategy, invoking a
handler of impl C expires). If the client is not conversation scoped,
it can either choose to set the conversation id "manually" through
the Java API or not do anything. If it decides to do nothing, a new
conversation will be created for every invocation of operations on C.
In the last case, invocations of cb1 will route back to the same
instance for the lifespan of the m1 invocation.
Does this make any sense or am I just completely missing the point?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
