I still don't really know what you mean, invocation between nodes in the same JVM are working now aren't they with the changes a while back to the local sca binding? Could you come up with a test case or something that shows what you want to fix? I've been cleaning some of this up a bit while on holiday as it relates to the dynamic imports i've also been working on but I wont be able to commit again for a week or so now and i don't want to doing this if you want to change it all again.
...ant On Mon, Feb 22, 2010 at 6:50 PM, Raymond Feng <[email protected]> wrote: > The purpose is to come up a consistent story for binding.sca and > SCAClientFactory to leverage the endpoint registry to determine the > appropriate strategy to make invocations to a target component under the > following situations: > > * Local interface > * By-reference invocation > > * Remotable interface > * Co-located target component that allows pass-by-reference invocation > * Co-located target component that requires pass-by-value invocation > * Remote invocation via the protocol stack > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Sunday, February 21, 2010 5:35 PM > To: <[email protected]> > Subject: Re: [2.x] In-VM invocation between components > >> On Sat, Feb 20, 2010 at 1:09 PM, Raymond Feng <[email protected]> wrote: >>> >>> Hi, >>> >>> We have been discussing when we can make in-VM calls (without going >>> through >>> a protocol stack) between two SCA components (more precisely, an endpoint >>> reference to an endpoint) for binding.sca. I start to realize that the >>> criteria can be as simple as the following: >>> >>> * The target endpoint of an endpoint reference has to be accessed locally >>> (not serialized) in the endpoint registry that the client (a Node or an >>> SCAClientFactory) connects to. >>> >>> Why? Because that's the only case we can get the invocation chain of the >>> target endpoint in-memory. If the endpoint description is serialized into >>> the registry from another one (no matter if it's from the same JVM, a >>> different JVM or a different machine), we cannot access the invocation >>> chain >>> directly without going through a protocol stack. >>> >>> The in-VM invocation between the endpoint reference and endpoint can be >>> further divided into a few cases: >>> >>> 1) A local interface is used. Then the source interface has to be a >>> compatible subset of the target interface. To support the >>> pass-by-reference >>> semantics, all the input/output/fault types have to be compatible within >>> the >>> same databinding type system (for Java classes, the same classloading >>> space). >>> >>> 2) A remotable interface is used. >>> a) If the allowsPassByReference flag is set to true, we can check to see >>> if the source interface is a compatible subset of the target interface in >>> the "local" way. If they can allow "pass-by-reference", we don't have to >>> copy the data and an in-VM called can be made to flow the message from >>> the >>> endpoint reference invocation chain to the endpoint invocation chain. >>> Otherwise, we need to copy the data across the type systems and make an >>> in-VM call. >>> b) If the allowsPassByReference flag is set to false, we need to copy >>> the >>> data across the type systems and make an in-VM call. >>> >>> Invocations to any endpoints that are foreign (remote) to the local >>> endpoint >>> registry have to go through a protocol stack. >>> >>> Now the algorithm to determine if we can make "in-VM" calls between the >>> endpoint reference and endpoint should be simple: >>> * For an endpoint with remote flag set to true (when it's deserialized), >>> we >>> cannot make in-VM calls. >>> * For an endpoint with remote flag set to false (the default when it's >>> published to the local endpoint registry), we can choose to make in-VM >>> calls. >>> >> >> From a quick read of that it sounds like you want to change the way >> something is working but I'm not sure exactly what, could you say what >> it is you want to change? >> >> ...ant > >
