Server architecture

The OAF 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 .oafinfo 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.

Figure 1. OAF architecture

The idea behind this is that when you make a request on the ActivationContext (like query), it will: