So, are the multiple complementation instances also of one or more types? You don't seem to be saying otherwise. I guess this is probably motivated by transactions, with a conversation id playing the role of a transaction context?
It may be useful to try to attach (some of) these properties to the conversation id, although if we really have more than one service component type (or perhaps even if there is just one) then there is no single set of properties. For instance, if I can tell that there is a single maxAge value for a conversation, then then the conversation id (or context) can be a good place to maintain this value and enforce it at each client and service instance. I am kind of thinking out loud here, but I am trying to make sense of requirements like starting a new conversation at a reference invoke after a conversation has ended. Thoughts? On 11/15/06, Jim Marino <[EMAIL PROTECTED]> wrote:
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]
