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 externally.

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.

Interoperability

Swapping Implementations

It is the intention of this specification that implementations of AIC be swappable without change to the applications containing AL or CL APIs.

The linkage from the AL and CL API's shall be to shared libraries.

The library names for these shared libraries will be:


 

AICALxxx 

AICCLxxx

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 version.

These libraries must have the following characteristics:

Thread-safe
Linked dynamically (that is, file is replaceable)
Utilize no global resources on a machine
Can be utilized multiple times on a host without programs interfering with each other
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.

Scalability

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.

Contents

Next section

Index