Comment to your @Conversation annotation remark inline.
On 11/17/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
This is a fairly confusing area and I welcome your efforts to clarify this. On 16/11/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote: > > 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), What are the definitions of thes different scopes? I thought the implementation scope was tied to the lifecycle of a service/component? 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 Do you mean interface here rather than implementation? You state above that the @Conversation annotation is on the interface.
Actually, I mean implementation. We may want to make the syntax less ambiguous, for instance using @ConversationScope in this case, similar to a note in version 0.9. But the intent is that the attributes being specified pertain only to the implementation and not to the contract with the client. (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] > > > > > > > > > > -- Pete
