Yes, I agree with the nit wrt the interface. One issue with
the @Scope("CONVERSATIONAL") annotation is that,
as I try to point out below, in my mind it does not make
sense to use this kind of scope independently of the
interface annotation. Do you agree?On 11/17/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Nov 16, 2006, at 1:26 PM, Ignacio Silva-Lepe 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. This may be nit-picking but the conversation is only indicated by @Conversational; @Scope is just used as a way for an implementation to specify to the container how it should manage its state (or not in the case of stateless). > 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. Yes we need a way to attach that to WSDL. I believe this has already been raised as an issue. > 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] >> > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
