On Nov 15, 2006, at 8:02 AM, Ignacio Silva-Lepe wrote:
The C&I spec seems to imply that a conversation involves a single
service component and that's what I have been assuming so far, but
I would like to make sure that the restriction indeed applies.
There can be multiple component implementation instances. The
boundaries of a conversation are determined by the last remotable
service the request passed through. We will likely need an
interceptor to handle this.
If the restriction does apply then we'll need to be careful about
which
conversation id is the current thread when a client makes an
invocation to guarantee that not more than one component is
invoked with the same conversation id.
If the restriction turns out not to apply, then some issues arise,
including:
- the scope and placement of the @Session annotation - currently
this annotation is to be specified in the implementation of a
component but it specifies attributes pertaining to the entire
conversation (btw, it may be good to rename this annotation
to @Conversation or @ConversationScope)
I think it should be renamed to @Conversation but still be specified
on the implementation since it is more about the latter's contract
with the container. I'll get that as an issue in the spec.
- coordinating the end of a conversation - when a service component
in a conversation ends the conversation, presumably all other
components will not be in the conversation any more; this may not
be very difficult but only worth doing if required
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
