The structure of a CORBA application, although more complex
than an ordinary application, is in itself rather simple.
There is one server, and there is at least one client.
A client is connected with the server by means of a software
bus, the object request broker (ORB in short).
Both the client and the server must have some means to
communicate with the ORB.
With CORBA this comes almost for free.
However, it is the programmr's task to write the code for
registring the server with the ORB, and the code
that allows the client to identify and connect to the server object.
The broker abstraction
- initialization -- connect to ORB and BOA
- run the server -- the operator method
- server -- write object reference to file
- client -- create object from reference
slide: The broker abstraction
The server must initialize the ORB as well as an object adapter,
that is needed to translate the calls for the server object coming from
the ORB to function or method invocations in the language in
which the object is written.
CORBA-2.0 comes the BOA (Basic Object Adapter).
For later versions of CORBA the POA (Portable Object Adapter)
Unfortunately there is still a difference in how
the ORB and BOA are initialized and accessed between
the various ORB products.
For example IOANA Orbix allows for binding a server object
by means of a server name, which is unfortunately not standard CORBA.
The examples that come with Orbacus use an explicit conversion
from a string object identifier to an object reference,
which is standard but rather low-level.
To factor out the code needed to access ORB and BOA, I have written
a simple broker class that encapsulates the
initialization of ORB and BOA (the latter for the server only),
that starts the server's event loop.
Moreover it provides, for the server, a shorthand for
writing an object reference to a file, and for the client
a shorthand for creating an object reference from a
file containing an object identifier.