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]
