Bonobo Activation ArchitectureThe Bonobo Activation daemon
Bonobo Activation is nothing but a daemon implementing a set of
CORBA interfaces. These CORBA interfaces implement a Name service
for the set of CORBA servers installed on your system. Basically,
Bonobo Activation knows about all the CORBA servers of your system, running or not.
The Bonobo Activation daemon will activate those servers if you ask for them.
The Bonobo Activation daemon features a powerful query langage which
allows you to ask for certain services rather than for certain applications.
C programmers who wish to access these services do not need to make
raw CORBA calls: they can use a set of convenience functions implemented
in the libbonobo-activation library. This library acts as a wrapper on top of the CORBA
server. The API documentation for the libbonobo-activation library is available there.
(XXX: add pointer to the API ref).
Server architecture
The Bonobo Activation server is split in 2 parts: the ObjectDirectory which contains the list
of all servers on a given machine, and the ActivationContext which contains the
list of all ObjectDirectories. It contains by default the local ObjectDirectory
and you can add inside other distant ObjectDirectories.
Each server is described by its .server file which contains among others
the IDL interfaces this server implements, some specific properties and
an IID (Implementation ID). Each IID has to be unique.
Its format is pretty simple:
OAFIID:program_name:UUID
The UUID is supposed to be generated by the uuidgen
program. program_name has to be an ASCII string without
comma (','), square bracket ('[]'), or forward slash ('/') characters.
Each CORBA server on a given machine is thus identified in a unique way.
CORBA servers on different machines are uniquely identified through the
AID (Activation ID). The AID format is also pretty
simple:
OAFAID:[IID,user,host,domain]
user is the user unix login.
host is a DNS domain name or stringified IP
address.
domain is is a string describing what use
area the object has.
One important thing to understand about these AID and IID is that the
ObjectDirectory deals exclusively with IIDs (it is stritcly local) and
the ActivationContext deals with AIDs since it can associate a set of
user, host and
domain to each IID it gets from one of its
ObjectDirectory.
As a result of this architecture, activation requests should go to the
ActivationContext and
registrations to the ObjectDirectory.
The Bonobo Activation architecture
The idea behind this is that when you make a request on the ActivationContext (like query),
it will:
make sure it has an up-to-date list of all the Servers with a call to
ObjectDirectory::get_servers for each of its ObjectDirectory.
loop through this list to try to satisfy the query with the
given requirements and sort-order.
activate the corresponding object with
ObjectDirectory::activate (this is not exactly what happens
since there are optimizations to save this call but the general idea is right).
Async Activation
Bonobo Activation also has a set of asynchronous activation interfaces so that you do not need to block
on activation calls. The CORBA level is pretty simple: the activation context has a set of
_async calls: OAF_ACtivationContext_activate_async
and OAF_ACtivationContext_activate_from_id_async. Both of those calls
take an OAFActivationCallback CORBA object as parameter. This object, which is supposed to
be implemented by client applications (it is actually implemented in liboaf) will receive
CORBA calls when the activation is finished:
module OAF {
interface ActivationCallback {
oneway void report_activation_failed (in string reason);
oneway void report_activation_succeeded (in ActivationResult result);
};
};
Of course, libbonobo-activation provides comvenient wrappers for those CORBA functions. Those are named
bonobo_activation_activate_async and
bonobo_activation_activate_from_id_async.