[omniORB] A question about stub/skel class roles

[Duncan Grisby]

On Wednesday 10 March, Aaron Van Couwenberghe wrote:

> 	I have just been looking at hacking omniidl to separate the client
> stubs and the server skeletons in its output.

[...]

I'll describe the omniORB classes below. Please don't try to make use
of these details in normal client or server code, since they may
change, and they're definitely not portable between ORBs.

> class foo_Helper  // Perhaps both imp and client side?

This is used by the template which constructs the foo_var type. It's
needed on both sides.

> class foo         // Implementation end, it looks like

Base class for everything to do with foo; needed on both
sides. foo_ptr is typedefed to foo* (although you shouldn't rely on
that).

> class _sk_foo     // Implementation end

Yep. Responsible for dispatching client requests to the implemented
operations.

> class _proxy_foo  // Gosh, I'm at a loss. I would guess imp end

No. This is the main client-side object. When a client holds an object
reference to a foo, they actually have a _proxy_foo C++ object.

> class _nil_foo    // No idea. subclassed from class foo

Used on both sides for a nil object reference. If you say

 foo_var f = foo::_nil()

you get a _nil_foo. Each of _nil_foo's operations throws the
BAD_OPERATION system exception.

> class _lc_sk_foo  // Imp end with lifecycle support?

Yep.

> class _dead_foo   // Erm,.... subclass of foo, something to do with LC

This is used by the LifeCycle code on the server side and is similar
to _nil_foo; each of its operations throws the OBJECT_NOT_EXIST system
exception. It's an artifact of the way object deletion works.

> class _wrap_home_foo // No idea from here out

Another LifeCycle thing on the server side. It is used to cope with
the situation that an object which used to be local becomes remote.

> class _wrap_proxy_foo
> class _lc_proxy_foo

These deal with client side things, but are only needed if the client
can also become a server. _wrap_proxy_foo does the opposite of
_wrap_home_foo -- it copes with objects which move from being remote
to being local. _lc_proxy_foo is a version of _proxy_foo which knows
about _wrap_home_foo.

> class foo_proxyObjectFactory

This is an object which creates _proxy_foo objects (or
_wrap_proxy_foos and _lc_proxy_foos if the LifeCycle support is
activated). It's needed on the client side.


> Gee, looking at the above, with my guesses, there wouldn't be that much of a
> separation. Anyway, could someone tell me whether I'm right about this?  

There is some scope for making a separation, but you may find it
difficult to sort out all the dependencies between different classes.

HTH,

Duncan.

-- 
 -- Duncan Grisby                        --
  -- dgrisby@uk.research.att.com          --
   -- http://www.uk.research.att.com/~dpg1 --