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
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]
> >
> >
>
