You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ignacio Silva-Lepe <is...@gmail.com> on 2006/12/04 15:50:14 UTC
Re: conversational infrastructure
As it turns out, there's a problem with 7 below. The key to a
ConversationSequenceInterceptor is that the same instance is
used for all conversational operations except the ones that end
the conversation, with this instance maintaining a flag to determine
whether the conversation is starting or not. However, since
interceptors are part of a chain, if we try to use a single instance
of a given interceptor for more than one operation, we are effectively
merging the corresponding chains at the point the interceptor is
inserted. In our case, the interceptor is being inserted at the head,
so we basically bypass all other interceptors for all chains but the
last one. In the sample, one of the operations happens to be one-way
but its non-blocking interceptor is being bypassed and so we lose
its async behavior.
I am checking in a fix that moves the behavior provided by the
conversational interceptors (as well as the wire post processor) to
the AbstractOutboundInvocationHandler and that disables the wire
post processor by removing its entry from core/implementation.scdl.
On 11/27/06, Jim Marino <jm...@myromatours.com> wrote:
<snip/>
>
> 7. I added two interceptors that will be inserted into invocation
> chains between conversational implementations.
> ConversationSequenceInterceptor will be inserted into all operations
> except ones marked @EndConversation. This interceptor tracks the
> conversation sequence the operation is invoked in (start or
> continue). This is necessary so the scope container knows whether to
> create a new instance or return an existing one (since conversation
> ids may be reused). Each operation for a wire receives the same
> instance of the ConversationSequenceInterceptor, which is inserted in
> the wire post-process phase by ConversationWirePostProcessor. For
> operations marked with @EndConversation, a ConversationEndInterceptor
> is inserted.
<snip/>
>
Re: conversational infrastructure
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
I tried using separate instances, but they all need to share the
common knowledge of the conversation's state. I suppose they
could all be given a single object encapsulating this knowledge,
but at the time it seemed to me to complicate matters, as it
seems to me we already have one such common object, the
invocation handler.
In addition, if we end up deciding to keep the interceptors, we
should also make sure that they are inserted at a single set
of chains along the path between client and service.
On 12/4/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Thinking abut this some more...Shouldn't we just insert different
> instances of the start/continue interceptor and have those instances
> share a common marker for the wire? The end conversation interceptor
> would remain the same. I'm trying to avoid placing more logic in the
> handlers (which are already kind of bloated) since this is a separate
> concern.
>
> Jim
>
> On Dec 4, 2006, at 8:32 AM, Jim Marino wrote:
>
> > The problem with moving this into the invocation handler is that we
> > need a mechanism to track state for whether the client believes the
> > conversation has begun. For example:
> >
> > interface ConverSationalService {
> >
> > void operation1();
> > void operation2();
> > void end();
> > }
> >
> > Calling operation1 or operation2 will start the conversation, and
> > subsequent calls to those two will continue the conversation. We
> > will need to come up with a mechanism for handling this. Are you
> > proposing to create a type of key class that contains the
> > conversational key value and a flag of its sequence? If we do this,
> > we can continue to use the interceptors as they become stateless.
> >
> > Jim
> >
> > On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
> >
> >> As it turns out, there's a problem with 7 below. The key to a
> >> ConversationSequenceInterceptor is that the same instance is
> >> used for all conversational operations except the ones that end
> >> the conversation, with this instance maintaining a flag to determine
> >> whether the conversation is starting or not. However, since
> >> interceptors are part of a chain, if we try to use a single instance
> >> of a given interceptor for more than one operation, we are
> >> effectively
> >> merging the corresponding chains at the point the interceptor is
> >> inserted. In our case, the interceptor is being inserted at the head,
> >> so we basically bypass all other interceptors for all chains but the
> >> last one. In the sample, one of the operations happens to be one-way
> >> but its non-blocking interceptor is being bypassed and so we lose
> >> its async behavior.
> >> I am checking in a fix that moves the behavior provided by the
> >> conversational interceptors (as well as the wire post processor) to
> >> the AbstractOutboundInvocationHandler and that disables the wire
> >> post processor by removing its entry from core/implementation.scdl.
> >>
> >>
> >> On 11/27/06, Jim Marino <jm...@myromatours.com> wrote:
> >> <snip/>
> >>
> >>>
> >>> 7. I added two interceptors that will be inserted into invocation
> >>> chains between conversational implementations.
> >>> ConversationSequenceInterceptor will be inserted into all operations
> >>> except ones marked @EndConversation. This interceptor tracks the
> >>> conversation sequence the operation is invoked in (start or
> >>> continue). This is necessary so the scope container knows whether to
> >>> create a new instance or return an existing one (since conversation
> >>> ids may be reused). Each operation for a wire receives the same
> >>> instance of the ConversationSequenceInterceptor, which is
> >>> inserted in
> >>> the wire post-process phase by ConversationWirePostProcessor. For
> >>> operations marked with @EndConversation, a
> >>> ConversationEndInterceptor
> >>> is inserted.
> >>
> >>
> >> <snip/>
> >>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: conversational infrastructure
Posted by Jim Marino <jm...@myromatours.com>.
Thinking abut this some more...Shouldn't we just insert different
instances of the start/continue interceptor and have those instances
share a common marker for the wire? The end conversation interceptor
would remain the same. I'm trying to avoid placing more logic in the
handlers (which are already kind of bloated) since this is a separate
concern.
Jim
On Dec 4, 2006, at 8:32 AM, Jim Marino wrote:
> The problem with moving this into the invocation handler is that we
> need a mechanism to track state for whether the client believes the
> conversation has begun. For example:
>
> interface ConverSationalService {
>
> void operation1();
> void operation2();
> void end();
> }
>
> Calling operation1 or operation2 will start the conversation, and
> subsequent calls to those two will continue the conversation. We
> will need to come up with a mechanism for handling this. Are you
> proposing to create a type of key class that contains the
> conversational key value and a flag of its sequence? If we do this,
> we can continue to use the interceptors as they become stateless.
>
> Jim
>
> On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
>
>> As it turns out, there's a problem with 7 below. The key to a
>> ConversationSequenceInterceptor is that the same instance is
>> used for all conversational operations except the ones that end
>> the conversation, with this instance maintaining a flag to determine
>> whether the conversation is starting or not. However, since
>> interceptors are part of a chain, if we try to use a single instance
>> of a given interceptor for more than one operation, we are
>> effectively
>> merging the corresponding chains at the point the interceptor is
>> inserted. In our case, the interceptor is being inserted at the head,
>> so we basically bypass all other interceptors for all chains but the
>> last one. In the sample, one of the operations happens to be one-way
>> but its non-blocking interceptor is being bypassed and so we lose
>> its async behavior.
>> I am checking in a fix that moves the behavior provided by the
>> conversational interceptors (as well as the wire post processor) to
>> the AbstractOutboundInvocationHandler and that disables the wire
>> post processor by removing its entry from core/implementation.scdl.
>>
>>
>> On 11/27/06, Jim Marino <jm...@myromatours.com> wrote:
>> <snip/>
>>
>>>
>>> 7. I added two interceptors that will be inserted into invocation
>>> chains between conversational implementations.
>>> ConversationSequenceInterceptor will be inserted into all operations
>>> except ones marked @EndConversation. This interceptor tracks the
>>> conversation sequence the operation is invoked in (start or
>>> continue). This is necessary so the scope container knows whether to
>>> create a new instance or return an existing one (since conversation
>>> ids may be reused). Each operation for a wire receives the same
>>> instance of the ConversationSequenceInterceptor, which is
>>> inserted in
>>> the wire post-process phase by ConversationWirePostProcessor. For
>>> operations marked with @EndConversation, a
>>> ConversationEndInterceptor
>>> is inserted.
>>
>>
>> <snip/>
>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: conversational infrastructure
Posted by Jim Marino <jm...@myromatours.com>.
Yep you're right - I had a brain spasm. InvocationHandler sounds like
the best option and we can deal with the expirations like we discussed.
Jim
On Dec 4, 2006, at 9:37 AM, Ignacio Silva-Lepe wrote:
> Hmm, maybe I am missing something, but doesn't an
> invocation handler get called for any operation and then it
> decides what chain to follow?
>
>
> On 12/4/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> Maybe I wasn't clear from this post...I don't think it can.
>> Invocation handlers are per operation as well so they can't share
>> state that is per client. The semantics of start/continue/stop are
>> that multiple operations could call start and the client needs to
>> track where it is in the conversation. So, we need a marker for if
>> the conversation has begun for the client instance. Right now,
>> invocation handlers don't have per-client state and this really seems
>> like a different concern than an invocation handler, which is to
>> create a message and fire it down the chain. Do you think it would be
>> better to have the start/continue interceptor per chain and have
>> interceptor instances share a marker per wire (I just sent another
>> note on that)?
>>
>> Jim
>>
>>
>> On Dec 4, 2006, at 9:24 AM, Ignacio Silva-Lepe wrote:
>>
>> > Yeah, my current feeling is that the invocation handler can keep
>> > track of the state of the conversation as well as the interceptor
>> > does at the moment.
>> >
>> >
>> > On 12/4/06, Jim Marino <jm...@myromatours.com> wrote:
>> >>
>> >> The problem with moving this into the invocation handler is
>> that we
>> >> need a mechanism to track state for whether the client believes
>> the
>> >> conversation has begun. For example:
>> >>
>> >> interface ConverSationalService {
>> >>
>> >> void operation1();
>> >> void operation2();
>> >> void end();
>> >> }
>> >>
>> >> Calling operation1 or operation2 will start the conversation, and
>> >> subsequent calls to those two will continue the conversation.
>> We will
>> >> need to come up with a mechanism for handling this. Are you
>> proposing
>> >> to create a type of key class that contains the conversational key
>> >> value and a flag of its sequence? If we do this, we can
>> continue to
>> >> use the interceptors as they become stateless.
>> >>
>> >> Jim
>> >>
>> >> On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
>> >>
>> >> > As it turns out, there's a problem with 7 below. The key to a
>> >> > ConversationSequenceInterceptor is that the same instance is
>> >> > used for all conversational operations except the ones that end
>> >> > the conversation, with this instance maintaining a flag to
>> >> determine
>> >> > whether the conversation is starting or not. However, since
>> >> > interceptors are part of a chain, if we try to use a single
>> >> instance
>> >> > of a given interceptor for more than one operation, we are
>> >> effectively
>> >> > merging the corresponding chains at the point the interceptor is
>> >> > inserted. In our case, the interceptor is being inserted at the
>> >> head,
>> >> > so we basically bypass all other interceptors for all chains but
>> >> the
>> >> > last one. In the sample, one of the operations happens to be
>> one-
>> >> way
>> >> > but its non-blocking interceptor is being bypassed and so we
>> lose
>> >> > its async behavior.
>> >> > I am checking in a fix that moves the behavior provided by the
>> >> > conversational interceptors (as well as the wire post
>> processor) to
>> >> > the AbstractOutboundInvocationHandler and that disables the wire
>> >> > post processor by removing its entry from core/
>> implementation.scdl.
>> >> >
>> >> >
>> >> > On 11/27/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> > <snip/>
>> >> >
>> >> >>
>> >> >> 7. I added two interceptors that will be inserted into
>> invocation
>> >> >> chains between conversational implementations.
>> >> >> ConversationSequenceInterceptor will be inserted into all
>> >> operations
>> >> >> except ones marked @EndConversation. This interceptor tracks
>> the
>> >> >> conversation sequence the operation is invoked in (start or
>> >> >> continue). This is necessary so the scope container knows
>> >> whether to
>> >> >> create a new instance or return an existing one (since
>> >> conversation
>> >> >> ids may be reused). Each operation for a wire receives the same
>> >> >> instance of the ConversationSequenceInterceptor, which is
>> >> inserted in
>> >> >> the wire post-process phase by
>> ConversationWirePostProcessor. For
>> >> >> operations marked with @EndConversation, a
>> >> ConversationEndInterceptor
>> >> >> is inserted.
>> >> >
>> >> >
>> >> > <snip/>
>> >> >
>> >> >>
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: conversational infrastructure
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
Hmm, maybe I am missing something, but doesn't an
invocation handler get called for any operation and then it
decides what chain to follow?
On 12/4/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Maybe I wasn't clear from this post...I don't think it can.
> Invocation handlers are per operation as well so they can't share
> state that is per client. The semantics of start/continue/stop are
> that multiple operations could call start and the client needs to
> track where it is in the conversation. So, we need a marker for if
> the conversation has begun for the client instance. Right now,
> invocation handlers don't have per-client state and this really seems
> like a different concern than an invocation handler, which is to
> create a message and fire it down the chain. Do you think it would be
> better to have the start/continue interceptor per chain and have
> interceptor instances share a marker per wire (I just sent another
> note on that)?
>
> Jim
>
>
> On Dec 4, 2006, at 9:24 AM, Ignacio Silva-Lepe wrote:
>
> > Yeah, my current feeling is that the invocation handler can keep
> > track of the state of the conversation as well as the interceptor
> > does at the moment.
> >
> >
> > On 12/4/06, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >> The problem with moving this into the invocation handler is that we
> >> need a mechanism to track state for whether the client believes the
> >> conversation has begun. For example:
> >>
> >> interface ConverSationalService {
> >>
> >> void operation1();
> >> void operation2();
> >> void end();
> >> }
> >>
> >> Calling operation1 or operation2 will start the conversation, and
> >> subsequent calls to those two will continue the conversation. We will
> >> need to come up with a mechanism for handling this. Are you proposing
> >> to create a type of key class that contains the conversational key
> >> value and a flag of its sequence? If we do this, we can continue to
> >> use the interceptors as they become stateless.
> >>
> >> Jim
> >>
> >> On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
> >>
> >> > As it turns out, there's a problem with 7 below. The key to a
> >> > ConversationSequenceInterceptor is that the same instance is
> >> > used for all conversational operations except the ones that end
> >> > the conversation, with this instance maintaining a flag to
> >> determine
> >> > whether the conversation is starting or not. However, since
> >> > interceptors are part of a chain, if we try to use a single
> >> instance
> >> > of a given interceptor for more than one operation, we are
> >> effectively
> >> > merging the corresponding chains at the point the interceptor is
> >> > inserted. In our case, the interceptor is being inserted at the
> >> head,
> >> > so we basically bypass all other interceptors for all chains but
> >> the
> >> > last one. In the sample, one of the operations happens to be one-
> >> way
> >> > but its non-blocking interceptor is being bypassed and so we lose
> >> > its async behavior.
> >> > I am checking in a fix that moves the behavior provided by the
> >> > conversational interceptors (as well as the wire post processor) to
> >> > the AbstractOutboundInvocationHandler and that disables the wire
> >> > post processor by removing its entry from core/implementation.scdl.
> >> >
> >> >
> >> > On 11/27/06, Jim Marino <jm...@myromatours.com> wrote:
> >> > <snip/>
> >> >
> >> >>
> >> >> 7. I added two interceptors that will be inserted into invocation
> >> >> chains between conversational implementations.
> >> >> ConversationSequenceInterceptor will be inserted into all
> >> operations
> >> >> except ones marked @EndConversation. This interceptor tracks the
> >> >> conversation sequence the operation is invoked in (start or
> >> >> continue). This is necessary so the scope container knows
> >> whether to
> >> >> create a new instance or return an existing one (since
> >> conversation
> >> >> ids may be reused). Each operation for a wire receives the same
> >> >> instance of the ConversationSequenceInterceptor, which is
> >> inserted in
> >> >> the wire post-process phase by ConversationWirePostProcessor. For
> >> >> operations marked with @EndConversation, a
> >> ConversationEndInterceptor
> >> >> is inserted.
> >> >
> >> >
> >> > <snip/>
> >> >
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: conversational infrastructure
Posted by Jim Marino <jm...@myromatours.com>.
Maybe I wasn't clear from this post...I don't think it can.
Invocation handlers are per operation as well so they can't share
state that is per client. The semantics of start/continue/stop are
that multiple operations could call start and the client needs to
track where it is in the conversation. So, we need a marker for if
the conversation has begun for the client instance. Right now,
invocation handlers don't have per-client state and this really seems
like a different concern than an invocation handler, which is to
create a message and fire it down the chain. Do you think it would be
better to have the start/continue interceptor per chain and have
interceptor instances share a marker per wire (I just sent another
note on that)?
Jim
On Dec 4, 2006, at 9:24 AM, Ignacio Silva-Lepe wrote:
> Yeah, my current feeling is that the invocation handler can keep
> track of the state of the conversation as well as the interceptor
> does at the moment.
>
>
> On 12/4/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> The problem with moving this into the invocation handler is that we
>> need a mechanism to track state for whether the client believes the
>> conversation has begun. For example:
>>
>> interface ConverSationalService {
>>
>> void operation1();
>> void operation2();
>> void end();
>> }
>>
>> Calling operation1 or operation2 will start the conversation, and
>> subsequent calls to those two will continue the conversation. We will
>> need to come up with a mechanism for handling this. Are you proposing
>> to create a type of key class that contains the conversational key
>> value and a flag of its sequence? If we do this, we can continue to
>> use the interceptors as they become stateless.
>>
>> Jim
>>
>> On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
>>
>> > As it turns out, there's a problem with 7 below. The key to a
>> > ConversationSequenceInterceptor is that the same instance is
>> > used for all conversational operations except the ones that end
>> > the conversation, with this instance maintaining a flag to
>> determine
>> > whether the conversation is starting or not. However, since
>> > interceptors are part of a chain, if we try to use a single
>> instance
>> > of a given interceptor for more than one operation, we are
>> effectively
>> > merging the corresponding chains at the point the interceptor is
>> > inserted. In our case, the interceptor is being inserted at the
>> head,
>> > so we basically bypass all other interceptors for all chains but
>> the
>> > last one. In the sample, one of the operations happens to be one-
>> way
>> > but its non-blocking interceptor is being bypassed and so we lose
>> > its async behavior.
>> > I am checking in a fix that moves the behavior provided by the
>> > conversational interceptors (as well as the wire post processor) to
>> > the AbstractOutboundInvocationHandler and that disables the wire
>> > post processor by removing its entry from core/implementation.scdl.
>> >
>> >
>> > On 11/27/06, Jim Marino <jm...@myromatours.com> wrote:
>> > <snip/>
>> >
>> >>
>> >> 7. I added two interceptors that will be inserted into invocation
>> >> chains between conversational implementations.
>> >> ConversationSequenceInterceptor will be inserted into all
>> operations
>> >> except ones marked @EndConversation. This interceptor tracks the
>> >> conversation sequence the operation is invoked in (start or
>> >> continue). This is necessary so the scope container knows
>> whether to
>> >> create a new instance or return an existing one (since
>> conversation
>> >> ids may be reused). Each operation for a wire receives the same
>> >> instance of the ConversationSequenceInterceptor, which is
>> inserted in
>> >> the wire post-process phase by ConversationWirePostProcessor. For
>> >> operations marked with @EndConversation, a
>> ConversationEndInterceptor
>> >> is inserted.
>> >
>> >
>> > <snip/>
>> >
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: conversational infrastructure
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
Yeah, my current feeling is that the invocation handler can keep
track of the state of the conversation as well as the interceptor
does at the moment.
On 12/4/06, Jim Marino <jm...@myromatours.com> wrote:
>
> The problem with moving this into the invocation handler is that we
> need a mechanism to track state for whether the client believes the
> conversation has begun. For example:
>
> interface ConverSationalService {
>
> void operation1();
> void operation2();
> void end();
> }
>
> Calling operation1 or operation2 will start the conversation, and
> subsequent calls to those two will continue the conversation. We will
> need to come up with a mechanism for handling this. Are you proposing
> to create a type of key class that contains the conversational key
> value and a flag of its sequence? If we do this, we can continue to
> use the interceptors as they become stateless.
>
> Jim
>
> On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
>
> > As it turns out, there's a problem with 7 below. The key to a
> > ConversationSequenceInterceptor is that the same instance is
> > used for all conversational operations except the ones that end
> > the conversation, with this instance maintaining a flag to determine
> > whether the conversation is starting or not. However, since
> > interceptors are part of a chain, if we try to use a single instance
> > of a given interceptor for more than one operation, we are effectively
> > merging the corresponding chains at the point the interceptor is
> > inserted. In our case, the interceptor is being inserted at the head,
> > so we basically bypass all other interceptors for all chains but the
> > last one. In the sample, one of the operations happens to be one-way
> > but its non-blocking interceptor is being bypassed and so we lose
> > its async behavior.
> > I am checking in a fix that moves the behavior provided by the
> > conversational interceptors (as well as the wire post processor) to
> > the AbstractOutboundInvocationHandler and that disables the wire
> > post processor by removing its entry from core/implementation.scdl.
> >
> >
> > On 11/27/06, Jim Marino <jm...@myromatours.com> wrote:
> > <snip/>
> >
> >>
> >> 7. I added two interceptors that will be inserted into invocation
> >> chains between conversational implementations.
> >> ConversationSequenceInterceptor will be inserted into all operations
> >> except ones marked @EndConversation. This interceptor tracks the
> >> conversation sequence the operation is invoked in (start or
> >> continue). This is necessary so the scope container knows whether to
> >> create a new instance or return an existing one (since conversation
> >> ids may be reused). Each operation for a wire receives the same
> >> instance of the ConversationSequenceInterceptor, which is inserted in
> >> the wire post-process phase by ConversationWirePostProcessor. For
> >> operations marked with @EndConversation, a ConversationEndInterceptor
> >> is inserted.
> >
> >
> > <snip/>
> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: conversational infrastructure
Posted by Jim Marino <jm...@myromatours.com>.
The problem with moving this into the invocation handler is that we
need a mechanism to track state for whether the client believes the
conversation has begun. For example:
interface ConverSationalService {
void operation1();
void operation2();
void end();
}
Calling operation1 or operation2 will start the conversation, and
subsequent calls to those two will continue the conversation. We will
need to come up with a mechanism for handling this. Are you proposing
to create a type of key class that contains the conversational key
value and a flag of its sequence? If we do this, we can continue to
use the interceptors as they become stateless.
Jim
On Dec 4, 2006, at 6:50 AM, Ignacio Silva-Lepe wrote:
> As it turns out, there's a problem with 7 below. The key to a
> ConversationSequenceInterceptor is that the same instance is
> used for all conversational operations except the ones that end
> the conversation, with this instance maintaining a flag to determine
> whether the conversation is starting or not. However, since
> interceptors are part of a chain, if we try to use a single instance
> of a given interceptor for more than one operation, we are effectively
> merging the corresponding chains at the point the interceptor is
> inserted. In our case, the interceptor is being inserted at the head,
> so we basically bypass all other interceptors for all chains but the
> last one. In the sample, one of the operations happens to be one-way
> but its non-blocking interceptor is being bypassed and so we lose
> its async behavior.
> I am checking in a fix that moves the behavior provided by the
> conversational interceptors (as well as the wire post processor) to
> the AbstractOutboundInvocationHandler and that disables the wire
> post processor by removing its entry from core/implementation.scdl.
>
>
> On 11/27/06, Jim Marino <jm...@myromatours.com> wrote:
> <snip/>
>
>>
>> 7. I added two interceptors that will be inserted into invocation
>> chains between conversational implementations.
>> ConversationSequenceInterceptor will be inserted into all operations
>> except ones marked @EndConversation. This interceptor tracks the
>> conversation sequence the operation is invoked in (start or
>> continue). This is necessary so the scope container knows whether to
>> create a new instance or return an existing one (since conversation
>> ids may be reused). Each operation for a wire receives the same
>> instance of the ConversationSequenceInterceptor, which is inserted in
>> the wire post-process phase by ConversationWirePostProcessor. For
>> operations marked with @EndConversation, a ConversationEndInterceptor
>> is inserted.
>
>
> <snip/>
>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org