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