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.
2. We need to get the host API supporting callbacks. The reference
would use the host API to register itself as a listener with a
binding as opposed to talking directly with the binding. This will
allow us to decouple the callback infrastructure from particular
bindings. Jeremy may have some thoughts on this.
3. We will need to have a conversational scope container and
persistence service
4. I'd like to hook in Meeraj's work manager into this as well.
5. Also, Ignacio, could you also detail more on if you think
TargetInvoker's need a non-blocking invoke method and why there may
be different ones for Remote and Local?
I'll think about 1 a bit more since these are just some initial
thoughts having gone through the slides. Perhaps we can iterate
through some ideas on the list and I'll be on IRC tomorrow too? Once
we start getting a basic flow, perhaps we could potentially put
things in a sequence diagram to see how things flow, which will also
help us to see areas we can divide up to work on.
Jim
On Jul 8, 2006, at 6:51 AM, Jeremy Boynes wrote:
On Jul 8, 2006, at 4:21 AM, Jim Marino wrote:
Great. Sorry I was out on vacation Friday. One thing we may also
want to look at is having the notion of priority queues. It's
probably something we can add in.
Who knows, Meeraj's implementation may already do that :-)
We may also want to look at Jetty 6 as they have abstracted out
the thread pooling mechanism. I was thinking we would eventually
want to have Jetty as a transport system service and we may want
to control thread pooling from the work manager service (not
necessarily one pool for everything, but one place for
configuration and management of all the pools).
Jetty6 is one of the ones that does this and linking the two
together would be a good way to go.
In the context of an OSGi container, having Jetty and other
transports a system services deployed in different composites
seems like a way to have a really flexible runtime story.
That's probably a different thread :-)
--
Jeremy
---------------------------------------------------------------------
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]
