On 17/11/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Nov 16, 2006, at 11:11 PM, Pete Robbins 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 The definition of scopes was originally in the Java C&I spec, then it was removed with the intention of putting it in Assembly. The spec group then decided it need to go back to the individual language specs. I haven't had the chance to update the Java spec but I intend to do so over the next few days. I'll post a write-up on the wiki for feedback comments.
Great! I'm trying to find the right words for the C++ C&I spec and trying to keep as close to Java as possible. Currently I have @Scope "Stateless" or "Composite" on an implementation and the @Conversational on an interface. Jim
>> 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. > > (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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Pete
