Application Instrumentation and Control (AIC) API, Version 1.0
Copyright © 1999 The Open Group
Intended Use of AIC
This Chapter details the expected usage of AIC, with a view to setting
out what would constitute an appropriate and inappropriate use.
Complex Data Types
There is no mechanism for handling complex data types. It would be
possible to make use of the strings to represent complex data. To do
this the user would need to marshall the complex data into a string,
export the data through use of AIC, and then unmarshall the data
Due to the expected need to display data externally
(including management vendors intending to produce general purpose
graphical utilities) it is not expected that complex types will be
used. Specifically there is no support for BLOBs (binary large objects)
in this specification.
It is intended that viewing a string will be
sufficient for a person to understand the contents, and that they will
not be encoded.
Business Sensitive Information
AIC is not intended to transport sensitive data. Although there is a
security in place, the actual content of the messages is not mandated
by this standard to be encrypted. The rationale is simply that AIC is
not intended to be used to publish information other than application
management information, so for example publication of customer/account
details would lie outside the scope of AIC.
AIC vs RPC
AIC is not intended as a replacement for RPC or CORBA ORBs. Although it
has some functionality that allows for remote invocation of a locally
defined function, this is intended purely for limited control
functions. For this reason, only one such function is allowed per
object, and although this limitation can be programmed around, it is
not intended that it should.
It is the intention of this specification that implementations of AIC
be swappable without change to the applications containing AL or CL
The linkage from the AL and CL API's shall be to shared
The library names for these shared libraries will be:
where xxx is a number representing the version number
of the library. This version number shall advance only when versions
are delivered that are not upward compatible from the previous
These libraries must have the following characteristics:
Linked dynamically (that is, file is replaceable)
Utilize no global resources on a machine
utilized multiple times on a host without programs interfering with
Have C function prototypes that can be successfully
linked with an Open Group reference program
Transport is Proprietary
Leading on from the previous point, AIC should be viewed as a "Black
Box" implementation at this version of the standard. The data transport
implied by the AIC standard is not required to interoperate with that
from another vendor. The underlying philosophy is that customers are
free to choose a particular AIC implementation, but can only use the
components of that implementation. For example, they cannot "mix and
match" between vendor implementations.
Platform Support and Interoperation
Where a vendor does supply an implementation of AIC, the implementation
must interoperate between all platforms and all language bindings
mandated by the standard. In this version, the API described is purely
C based, but for future versions there will be additional bindings
which must interoperate. If a vendor chooses to implement AIC on a
number of platforms, those implementations must interoperate.
Current AIC reference implementations are considered to be scalable
suitable to purpose and have been tested using in excess of 1,000,000
objects, with 1,000 application threads running. Whilst these are not
proposed as hard implementation limits, they are an example of what are
possible within a reference implementation.
New implementations must
also be scalable suitable to purpose, bearing in mind that the
functional specification presented within this standard does not limit
scalability in any way.
Although there is no mandated limit to how many
objects can or should be handled by an AIC implementation, it is
suggested that less than 10,000 objects be published per host. The
reason is that AIC is a tool for management, not as the primary
mechanism for getting data out of an application.
General Purpose API
AIC is a general-purpose management technology. It is not aimed just at
configuration management, or pulling statistics out of an application.
There is no single management capability intended - the product is
generic. The value is determined by the use of the product. This in
turn is likely to be based upon the level of analysis done to determine
how to apply the technology to an application.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.