[omniORB] Collocation: call on servant directly or via object reference ?

[Duncan Grisby]

On Saturday 6 July, Brecht Vermeulen wrote:

> The situation is as follows (simplified): a CORBA server has two
> different CORBA objects with different IDL interfaces and one object
> needs to call operations on the other.
> 
> What are the advantages/disadvantages of using calls directly on the
> servant (via C++ pointer) or operations on a CORBA object reference
> (obtained via _this() e.g.) ?

One advantage of calling through the object reference is that your
application code doesn't have to care whether objects are colocated or
not -- it becomes a deployment detail. Other advantages are that you
get the benefit of the POA's policies, like single threadedness, and
the ability to hold calls, activate objects on demand, etc. Calling
directly to the servant is faster. Direct calls also allow you to
call methods that aren't declared in IDL; whether you consider that a
good thing or not depends on your perspective.

> As far as I remember I think that omniORB shortcuts local collocated
> calls but are both options than exactly the same (in speed,
> functionality, ...) ? Is there e.g. POA functionality that could be used
> extra if using CORBA operations ?

omniORB makes local calls as efficient as possible, in the sense that
it doesn't use the network stack during the call. (In fact, in some
situations, omniORB 3 does use the TCP loopback in local calls;
omniORB 4 always uses more efficient means.)  The calls are still
significantly slower than raw method calls, however, due to all the
extra checking that goes on to adhere to the POA policies and
semantics.

In omniORB 4, I added a hack that adds a POA policy to shortcut local
calls, so they don't go through all the normal POA checking. That
makes them very nearly as fast as virtual function calls, but means
they are not fully standards compliant.

In summary, there's no single correct answer -- you have to choose
based on what you require in your application.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --