Previous section.

Application Instrumentation and Control (AIC) API, Version 1.0
Copyright © 1999 The Open Group

Object Naming Conventions

Object Naming Conventions

The naming convention is very important to AIC because the names1 given to management objects provide the sole external mechanism for accessing those objects at a later time. By convention, the name is called the "location in structure" or "location" for short.

At the API level, the naming of objects is similar to the UNC/URL scheme whereby the machine name will be introduced by // and successively lower levels of the hierarchy is delimited by a /. This hierarchy is similar to a tree in form.

Within an application the location is specified from the root of a tree (called local form). Outside the current process, to access the object the machine name and unique application name must be specified (fully qualified form).

ObjectSpecification Description Type
/ The root of the data Local
/base An object called base which is below root in the hierarchy Local
/trades An object called trades which is below root in the hierarchy Local
//trepka/tradecapture/stats/trade An object called /stats/trade which is in the application tradecapture on machine trepka Fully qualified

Table: Object Naming Conventions

Formal Tree Structure

For simplicity, the tree of management objects is referred to often as "the tree" or "a FAT filesystem or UFS filesystem". All these concepts are quick to embrace for a developer. In reality the scheme does not have to formally comply with a real tree as outlined below.

The creation of an object named


does not imply the existence of objects named




Object /a and /a/b are just uniquely named objects. The important aspect of this scheme is the multi-value query operations ( dump, list, traverse, - see AIC API Overview) which use the / as if a formal tree existed.

It is important to note that:

is not valid as no object is specified

is valid, only as a wildcard to dump/list/traverse. (/ is symbolic, not a real object)

Cross Machine Naming

It should be noted that the machine name element of the object specification can be a DNS hostname for a machine as well as the raw IP address of the machine. For example, the following examples are valid:

// //

Naming Convention Rules

The following characters are valid in the above naming convention:

<aic application location>  ::= [/<symbol>]+
<symbol>                    ::= [a-z,A-Z,_] [a-z, A-Z, 0-9]* <aic
client location>            ::= //<hostname>/<appname>/<aic app location>
<hostname>                  ::= [a-z,A-Z] [a-z, A-Z, 0-9, -, _,., ]* 
<application name>          ::= <symbol>

Federated Process Naming

A group of application processes can be associated together using federated naming. When the applications are started, the federated name can be assigned as part of the application process name in the following form:

<federated name>:<application name>

For example, assume an Enterprise Resource Planning (ERP) vendor supplies a package called ABC. The programs forming this package on a server are the processes compute, display and report. If this package uses AIC within each process, a naming scheme for the processes might be as follows:

abc:compute abc:display abc:report

In this way, the entries registered in the name service have both the federated name and the application process unique name. When the name service is queried using the API call AICCL_GetAppInfo(), the processes for a given application can be logically grouped systematically.

The following object specification is valid:


Naming Scheme in a Large Enterprise

It is expected the above scheme is adequate to scale across a large enterprise. No scalability concerns are thought to remain with regards to naming.


Names are not case sensitive in AIC.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index