The call should still go through the SOAP stack, but it will just be via local
Java transport instead of http 
or https.

See http://www-unix.mcs.anl.gov/~gawor/developer_notes.php under "Local
Invocations".

Adding missed email comment from Joe Link:

does going through the soap layers imply serialization?  if so, i'd
think that's what you want to avoid at all costs.

From the URL in comment #1:

"Services in the container can be invoked locally. Local invocations work just like remote invocations (all 
handlers are called, messages get serialized/deserialized) but messages do not travel over the network 
- everything happens in memory."

I think the major problem is the contexts that are assumed by the services.  Hacking around that to, for 
example, establish an appropriate security context would be a royal pain.  The performance gain from 
doing so would probably not justify the effort.

The link to the documentation has changed.  It's now a part of the main doc
instead of a personal page of Jarek's:

http://www-unix.globus.org/toolkit/docs/development/3.9.5/common/javawscore/developer/#LocalInvocations

I guess local transport doesn't work without a pre-existing MessageContext. 
Jarek said the core code could probably be altered to not require this, but the
priority for making the changes is pretty low right now.  I'm going to mark this
as INCOMPLETE and save my changes to a branch.  I'll also create an enhancement
request for this and set that as a dependency.

Local transport was implemented in globus_4_0_branch by caching the message
context. The trunk has the fix for 2926, so local transport just works in HEAD.