I am trying to wrap some legacy server side code as a Orbix
service, using Orbix Version v2.0 for Native C++ on SGI's IRIX.
My legacy code can only handle one client per process -- global
state and such. So one way or another, I have to have a separate
serving process for each new client. There are typically just a
few clients at most running in parallel, but could be a few dozen
in parallel in busy moments.
I have complete control over the client interface that will access
this IDL defined service, so I'm not limited there.
I can imagine two ways to accomplish this:
1) Let orbixd on the server know about the separate serving
processes, one per client, or
2) don't let orbixd know there are separate processes.
In the first case, it seems that I will have to have visibly known
to the Repository at least as many server or marker:server
instances as I allow degrees of parallelism -- so that orbixd can
associate a separate object with each separate process. This
seems a bit messy.
Questions - Does anyone have experience in this, enough to either
know of a not too messy way to handle this, or to know
that I should expect to just "have to deal with it".
In the second case, I'd have a single master process that orbixd
thought held all per-client objects of the new service type, and
that master process would hide the multiprocess nature of the
implementation from orbixd. When a new client requested service,
the master process would first instantiate a service object using
normal Orbix apparatus, and entirely visible to orbixd. But then
if the client actually wanted to do anything interesting (hence
requiring use of the legacy code being wrapped), the
implementation of this service would fork a child to do the dirty
From what I can gather of the interactions between orbixd and the
services it helps get going, this should work. In particular,
orbixd is completely uninvolved with a service object once it gets
connected to its client. In low level socket terms, its seems
like it should be easy -- just fork the process to run the legacy
code, leaving the CORBA socket to the client open just in the
child, and the socket to orbixd open just in the master parent.
Questions - Can this be done? How? Is there an API for it?
Does anyone know of examples of such being done?
How does one handle the normal and abnormal cleanup
and shutdown of a single object instance in this
case, when the lack of connectivity from the active
object to orbixd will once again become painfully