After looking at (the previous) version 0.9 of the C&I spec and a discussion with Jim and Mike Rowley on the conversational services section, I am going to try to summarize my current understanding, Jim, Mike, please jump in if I mis-state or forget to mention something here.
A conversation is indicated by a @Conversational annotation on an interface and a @Scope annotation on an implementation. The interface annotation denotes the contract with a client. The implementation annotation pertains to the maintenance of its instance state with two basic cases: (1) when the @Scope is conversational then the container keeps track of instance state, as well as handling conversation id creation and propagation, (2) when the @Scope is not conversational (i.e., it is stateless, request, or composite), the implementation must keep track of its state, based on the conversation id, which is still handled by the container. Notice that all this seems to apply to Java interfaces only. Similar statements should also apply to WSDL interfaces as well, which is after all another way to specify a contract with a client. It is also worth mentioning that it does not seem to make sense to annotate an implementation as having conversational when it does not implement a conversational interface. Otherwise, it would not be clear what conversation id to maintain its instances for. A conversation is an interaction between two parties: a client and a service components. Each conversation is indicated by a (possibly distinct) conversation id. Depending on whether the service component is remotable or not, a conversation id is auto-propagated to it by the container. That is, in a conversation A->B, where B is defined by a conversational interface, if B is remotable then a new conversation id is created if one did not exist between A and B, regardless of whether A is conversational or not, or remotable or not. But if B is not remotable and A is conversational, then when there was no prior conversation between A and B, and A invokes B as part of a conversation with a client, then A propagates the conversation id from that client. Using the example in Fig. 1, Sec 1.5.2 of the 0.9 C&I spec, the following pattern is illustrated: A->B->C<-A. Here, B and C are non-remotable and conversational, which means that any conversation id from A is propagated from A to B to C and from A to C, meaning that A uses the same instance of C as B does. In particular, if A is conversational and invoked by a client, then it propagates the client's id as above. If a is non- conversational and it invokes B and C in sequence, then it would still propagate the same conversation id to both. A service component implementation can also use a @Conversation annotation (previously called @Session) to indicate conversation attributes such as maxIdleTime and maxAge. These attributes apply to each instance of the component (i.e., for each individual conversation). Notice that if two components participate in the same conversation (by virtue of having the same id propagated to them) they may still time out independently as given by their respective attribute values. For instance, in the example of Fig. 1 above, B may have a maxIdleTime of 100ms and C 500ms. If the conversation initially touches B but does not touch it again for at least 100ms, then B will time out regardless of whether the conversation continues to touch C. And when the conversation tries to touch B again, an exception is thrown. Ok, this does not claim to be a complete replacement of Sec. 1.5.2, but it tries to clarify some of the main elements of it. The intention is to try to have a more concrete basis on which to start implementing conversational services in Tuscany. As the work progresses and people participate in the discussion we may be able to come up with a (more) complete understanding that we can feed back to the spec. On 11/15/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:
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] > >
