Ignacio and I had a chat on non-blocking and conversational support
today for those interested:
isilval__: hi jmarino, you there?
[11:25am] jmarino: hey Igancio, will you be around in 30mins? I'm otp
[11:25am] isilval__: sure, I'll be here
[11:38am] isilval__ left the chat room. ("Trillian (http://
www.ceruleanstudios.com")
[11:48am] isilval__ joined the chat room.
[11:48am] jmarino: Hi Ignacio
[11:48am] isilval__: hi Jim, had to rebootm, but I'm back
[11:48am] isilval__: reboot ...
[11:49am] jmarino: k I'm free if you are to chat
[11:49am] isilval__: yes, I was thinking about starting to prototype
local stateless callbacks in chianti based on the discussion so far
[11:50am] jmarino: yea that sounds good. Do you want to walk through
a couple cases now and we can discuss?
[11:50am] jmarino: I looked at your preso more on the plane back
yesterday
[11:50am] isilval__: sure, you have something in mind?
[11:51am] jmarino: sure I have a few questions maybe we could start
there?
[11:51am] isilval__: ok
[11:51am] jmarino: just as a warning I'm a bit jet-lagged so I may be
a bit incoherent
[11:51am] isilval__: yeah, jet lag can do that to you ...
[11:52am] jmarino: so the first question was regarding the need for a
non-blocking invoke on the target invoker. I'm wondering if we need
that or we can use what is there and return void
[11:52am] jmarino: the reason I ask is I'm trying to limit the number
of combinations
[11:53am] isilval__: right, except that the method in TargetInvoker
returns Object
[11:53am] jmarino: yes so I was thinking just null, which is never
returned to the client
[11:53am] isilval__: and the actual target invoker may want to be
able to tell the difference to know what to do
[11:54am] isilval__: in the local case it may want to dispatch to the
work manager
[11:55am] jmarino: the target invoker (ti for short so I don't have
to type) is created by the target side. So, wouldn't always be local
or always be remote?
[11:55am] jmarino: for example, the target is a component or it is a
reference
[11:56am] isilval__: hmm, maybe I misunderstand, I thought the ti was
configured into the wire invocation handler
[11:56am] jmarino: it is but it is determined by the target. The ti
is created by the target and then put on the client side
[11:57am] jmarino: the runtime does this when it connects the two
sides of the wire
[11:57am] isilval__: ah, ok
[11:57am] jmarino: the ti is then passed in the invocation as part of
the message
[11:57am] jmarino: at the end, there is an interceptor which pulls it
from the message and invokes the ti
[11:58am] isilval__: ok, but it still needs to know that this
invocation unwinds right away and does not wait for the target
[11:58am] jmarino: right so the ti is per operation as well
[11:58am] jmarino: it should know that when it is created by the runtime
[11:59am] isilval__: ah yes, I remember being a bit confused about
that in the code
[11:59am] isilval__: ok, so then there would be different kinds for
different types of operations
[11:59am] jmarino: yea it is kind of complex. it would be good to see
if we can simplify some things as we go through this too
[11:59am] jmarino: yes different kinds per operation
[11:59am] isilval__: but they all implement only one invoke
[12:00pm] isilval__: that sounds doable
[12:00pm] isilval__: as long as we can capture the variability
[12:01pm] isilval__: we can go as you propose and see how far it
takes us
[12:01pm] jmarino: yea hopefully we can do that. Right now we create
a target invoker by passing a java.lang.Method. This may be
problematic....
[12:01pm] jmarino: we may need to have a generic representation of
the operation, including whether it is async
[12:02pm] jmarino: if that is the case, then we can fix that as we go
through
[12:02pm] isilval__: right now it can tell by introspecting its
interface and checking whether it has a callback annotation ...
[12:03pm] isilval__: that could be messy
[12:03pm] jmarino: yea I think that is problematic...
[12:03pm] jmarino: one is the knowledge of the annotation. The other
is for non-Java
[12:03pm] jmarino: I think we need to have a general service contract
representation
[12:04pm] jmarino: so for instance, on Component we have
TargetInvoker createTargetInvoker(String serviceName, Method
operation); which is a problem
[12:04pm] isilval__: is that something that can be deferred?
[12:04pm] jmarino: we could. As long as we can differentiate the
async vs. sync
[12:04pm] jmarino: Looking at it, I'm not sure we can though
[12:05pm] isilval__: you mean in general?
[12:06pm] jmarino: If we can defer it, I think it would be good to do
that. The problem I'm starting to think about is how does the
Component know it is an async or sync operation that it is creating
the ti for.
[12:07pm] isilval__: well the service interface must have a callback
associated with it
[12:07pm] jmarino: yes. I think the problem is say for
org.apache.tuscany.spi.component.Reference....
[12:07pm] isilval__: can we get at the service interface from the name?
[12:08pm] jmarino: let me check something quickly...
[12:09pm] jmarino: sorry.. was just digging through code
[12:09pm] jmarino: ok we do have ServiceContract
[12:10pm] jmarino: we could get it from there
[12:10pm] jmarino: for example
org.apache.tuscany.core.implementation.JavaServiceContract
[12:10pm] jmarino: there's a WSDL one as well
[12:12pm] jmarino: does that make sense?
[12:12pm] isilval__: not sure why Reference is involved
[12:12pm] jmarino: a Reference can also create a ti (Reference ==
ExternalService )
[12:12pm] jmarino: can you open
org.apache.tuscany.spi.component.Reference ?
[12:12pm] isilval__: ah yes
[12:13pm] isilval__: ok
[12:13pm] jmarino: that has createTargetInvoker(String serviceName,
Method operation); as well
[12:13pm] jmarino: operation is represented as a Method
[12:13pm] jmarino: eventually, we should probably change that to
something more generic
[12:14pm] jmarino: originally we had a generic one, went to methods
because it was simpler and now I think it may be problematic
[12:14pm] isilval__: so the client is creating a ti for the async
invocation of an operation with a callback
[12:15pm] isilval__: and it needs to create an async ti
[12:15pm] jmarino: what happens is the runtime processes a model in a
couple of steps...
[12:15pm] jmarino: the first is to load from XML to an in-memory model
[12:15pm] isilval__: right
[12:15pm] jmarino: then the model is processed and built (the
builders)...
[12:16pm] jmarino: at that point the components are created with
inbound and outbound wires...
[12:16pm] isilval__: so it's the in-memory model of the client
component that is creating the ti
[12:16pm] jmarino: the wires are not connected. they are basically
dangling
[12:16pm] isilval__: right
[12:16pm] jmarino: then there is the connect phase which attaches
inbound and oputbound
[12:16pm] jmarino: at that point the tis are created
[12:17pm] jmarino: one other thing may happen
[12:17pm] jmarino: if the ti is optimizable, the
WireInvocationHandler may clone it and hold on to it on the proxy
[12:17pm] jmarino: that is at the first invoke
[12:17pm] jmarino: if it is not cacheable, it just uses the "master" ti
[12:18pm] isilval__: sounds like it could be cacheable
[12:18pm] jmarino: for many things it can. For some things it can't.
E.g. if I call from a module-->session scope component it can't be
cached
[12:18pm] jmarino: the other way around it can be
[12:18pm] isilval__: I see
[12:19pm] jmarino: so I'm wondering whether we see how far using
Method will take us and if we need to change it we can
[12:20pm] jsdelfino joined the chat room.
[12:20pm] jsdelfino left the chat room.
[12:21pm] jmarino: what do you think?
[12:21pm] isilval__: yeah we can try that
[12:22pm] jmarino: k have another question. You mentioned about
redoing the one way. Could you explain a little?
[12:22pm] isilval__: well, one-way does something similar and it may
also vary depending on local/remote
[12:23pm] isilval__: ie, it may not need to spawn a new thread if remote
[12:23pm] jmarino: so since the ti is always determined by the target
we should be ok right?
[12:23pm] isilval__: sounds like it
[12:24pm] isilval__: perhaps that could be our very first baby step
[12:24pm] isilval__: to see if we can redo one-way this way
[12:24pm] jmarino: that would be good.
[12:24pm] isilval__: and then we'll deal with the actual callback
[12:24pm] isilval__: let me try to prototype that
[12:25pm] jmarino: so we have an AsyncInterceptor in there. Youd'
change it to a ti?
[12:25pm] isilval__: right
[12:26pm] isilval__: instead of spawning right away, the ti would
spawn right before the invoke
[12:26pm] isilval__: ie, the invocation chains would happen sync'ly
[12:27pm] jmarino: right
[12:27pm] jmarino: would we start with a local Java component or try
a remote thing?
[12:28pm] isilval__: for one-way, the local seems to be the more
involved
[12:28pm] jmarino: k so which do you prefer to start with?
[12:28pm] isilval__: local
[12:29pm] jmarino: k so we'll have to change JavaAtomicComponent
around a little
[12:29pm] jmarino: and there is a PojoInvoker
[12:29pm] isilval__: PojoInvoker can stay as it is for sync
[12:30pm] jmarino: yes right
[12:30pm] isilval__: and we could something like AsyncPojoInvoker
[12:30pm] jmarino: yep
[12:30pm] jmarino: I've got a few changes to commit in it related to
constructor injection tonight. Perhaps I could get those in tonight
and then you start prototyping. I'll apply patches for you
[12:31pm] isilval__: sounds good
[12:31pm] jmarino: k what I can also do is make sure I'm on IRC and
GoogleTalk since I imagine there will be a bunch of questions that
come up
[12:31pm] jmarino: do you use googletalk?
[12:31pm] isilval__: I'll be in tomorrow and monday and then out on
vacation tue-fri next week
[12:32pm] isilval__: yes, that would be good
[12:32pm] jmarino: k I'll be here tomorrow and monday to. I'm back in
San Fran now
[12:32pm] jmarino: k so I'll check those things in tonight and we'll
keep moving through this
[12:32pm] isilval__: sounds good
[12:33pm] jmarino: also, do you mind if I post this to the list since
Meeraj and Jeremy were also interested?
[12:33pm] isilval__: I was going to ask about that
[12:33pm] isilval__: sure, that would be good
[12:34pm] jmarino: Jeremy is on the Axis binding right now but I
think we may be able to get him to deal with some of the Method
stuff. Meeraj had some interest as well...there's certainly enough
work to go around
[12:34pm] isilval__: I'm still seeing build issues with binding
integration test
[12:34pm] jmarino: oh jaxb?
[12:34pm] isilval__: yeah
[12:35pm] jmarino: I don't know what happened there. You may just
want to comment it out and post the problem to the list. I can take a
look at it or Jeremy or Raymond will
[12:35pm] jmarino: I think Sun's maven repo is iffy
[12:36pm] isilval__: yeah, I'll take another look at that thread to
make sure I'm not missing anything and post to the list if I still
can't build
[12:36pm] jmarino: k in the meantime I'll be on IRC here if you have
questions
[12:36pm] isilval__: great, thx
[12:36pm] jmarino: thanks too for jumping in
[12:37pm] isilval__: sure, should be fun
[12:37pm] jmarino: yea looking forward to seeing this get in since I
think it is going to be one of the "wow" features
[12:38pm] isilval__: cool
[12:38pm] jmarino: k ttyl
[12:38pm] isilval__: ttfn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
