Comments inline
On Jul 10, 2006, at 1:39 PM, Ignacio Silva-Lepe wrote:
Hi Jim,
An inline comment on your first point.
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, July 10, 2006 10:19 AM
Subject: Re: Support for callbacks
Hi guys,
I won't be able to make IRC today but please feel free to go
ahead and discuss conversations. I've looked at Igancio's slides
(thanks, these are really extensive!) and I think adding the
callback wire to the reference is a good way to start with and
see where we get. I'll respond it more detail, but I think there
are a number of things we have to work out:
1. How to dispatch to the correct callback instance. In the
simple case when the callback interface is implemented by the
client, we could have the TargetInvoker use
PojoAtomicComponent.getInstance(), which delegates to a scope
container, in this case a conversational one that could serialize
and deserialize state if needed (or a stateless container if it
is a stateless callback). In the remote case, the binding would
be responsible for setting the correct conversation id in
WorkContext from protocol specific information so that the scope
container can determine the correct instance.
The difficulty comes in when ServiceReference.setCallback() is
used by a client to manually set the instance, in which case it
is not the original client. We need to have some way to correlate
back to the correct callback instance. We could model this in
JavaAtomicComponent or we could perhaps do something where a
dynamic component is created on the first cann to setCallback for
a component type and instances are managed like any other
component instance. I initially liked the former, but the problem
is we will also impact scopes since we would need to have
something like getCallbackInstance(..). If we could do it where
callback invocations happen just like any other service
invocation, I think we will be able to keep things simpler.
Perhaps I am missing something, but here are my thoughts on this
case. First,
my assumption is that by using setCallback the client is explicitly
saying which
actual object instance is to be called back, and so there is no
need to deal
with stateful/stateless, the callback object is right there.
I think we need to account for long-running conversations and server
crashes. I was thinking this would involve persisting the instance
and dealing with state (we made it serializable in the spec to
support that case).
Second, I was assuming
that the target invoker (the one that makes the non-blocking invoke
on the
transport in slide 4) would have access to the request context and
thus be able
to retrieve the callback object that way, at which point it could
set it on the
callback target invoker (C in slide 4), which in turn would be
registered with
the transport's callback (e.g., an Axis2 callback or a JMS
MessageListener).
This, for the remote case. For the local case, the callback target
invoker
(C in slide 2) should be able to also retrieve the callback object
from the
request context prior to invoking it.
---------------------------------------------------------------------
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]
