I have also changed the non-blocking interceptor to propagate
conversation ids to support async ops.
An issue that comes up with this is that if a conversational
service also uses async ops (e.g., one-ways), the corresponding
implementations (client and/or service) need to be careful about
concurrency. For instance, in the loan app sample, I made the
cancel op a one-way. The client applies for a loan, displays the
loan app, cancels it and displays again. So now the cancel thread
is competing with the main thread for access to the service. The
simple fix in the sample is to hold the main thread to let the cancel
thread complete, which is impacting the client code.
The spec(s) does not seem to be clear about whether the
infrastructure must provide support to relieve the user from dealing
with concurrency. For the remote case, the various bindings can
provide support depending on policy and some handshaking with
the core. For instance, for ws WS-RM can be used to provide
ordering support but even that may not be sufficient in the face of
potential races into an Axis2Reference. For the local case, it may
be possible to provide some ordering support on a per conversation
basis by sequencing invocations (a la WS-RM) but it's not clear
the current architecture is there for this requirement. That is, an
invocation handler may be able to behave as a conversation source
for sequencing, but since there is a separate target invoker per
operation, something would need to happen to get them in order.
In any case, this are just some spur-of-the-moment thoughts. Others
may have different ideas about whether or how to handle this issue.
On 11/13/06, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:
I have checked in code to complete a minimal implementation of
conversational services, including a sample adapted from the C&I
spec. Still not using UUID for conversation ids, need to change.
Rick, you can go ahead and test it (I did not include the sample
in the main pom, you can run it from its own dir though).
On 11/11/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
>
> On Nov 11, 2006, at 6:16 AM, Ignacio Silva-Lepe wrote:
>
> > The C&I spec defines a conversational interface as annotated with
> >
> > @Scope("session")
> >
> > but since we are also considering HTTP Session scopes, it seems
> > that using @Scope("CONVERSATIONAL") would make things
> > clearer. Notice that earlier in the spec (sec 1.2.1.4) the annotation
> > @Scope("CONVERSATION") is used in passing, so it looks like
> > the spec needs to be revised anyway.
> I think I may have missed a couple of places in the spec where things
> should have been changed from "session" to "conversation". We also
> need a description for scopes to be placed back in the Java C&I spec
> (it was originally in, moved to Assembly, and then the spec group
> decided to move it back to the respective C&I specs) so I'll include
> this in that proposal.
>
> Jim
>
> > For the current SCA/Java implementation of conversational services
> > just getting under way, the current thought is to use
> > @Scope("CONVERSATIONAL")
> >
> > On 11/11/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >>
> >> Quick question: Is there an annotation that marks an interface as
> >> conversational?
> >>
> >> Cheers,
> >>
> >> --
> >> Pete
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
