AIC Functional Components

Architecture of AIC

• The AIC-AL (Application Library) used by applications

• The AIC-CL (Client Library) that is used by management applications to gain access to information on managed objects

• The AIC Host Services which are AIC facilities resident within an implementation of AIC on a given node

These interfaces are described in later Chapters.

The AIC Host services are key functional parts of any given AIC implementation. They are services required for the core API to work.

Functional Overview: AIC-AL

It is possible to register functions against a management object. The application library must provide a background mechanism that invokes registered functions. This mechanism will run any polling or threshold function that it finds registered against an object every polling period. The polling frequency will be fixed within an application process (for example, every 60 seconds). The polling mechanism must be operated to ensure that the next period starts as close to the intended time as possible (as defined by the polling frequency; for example, the next period starts 60 seconds after the start of the last one). This is to take account of the possibility of the work of each period (number of functions to invoke) taking a significant portion of the time (say 5 seconds) between periods (in this case, the next polling period should start in 55 seconds).

The application library must support the ability to register a function for an object, called a doAction function, which can be invoked on demand against that object. The purpose of the function is left to the application programmer to decide - it is generic.

The application calls of the API must be serviced within the application library. The objects created via the API must be easily accessible to the application that created them and create no additional communications overhead when accessed.

It should be understood that there are no formal semantics for the management objects created, or the actions associated with them. Each is intended to be general purpose, and it is not necessarily possible to 'assume' semantics. In this regard, the programmer implies semantics in use of the API.

Functional Overview: AIC-CL

The get functions all have the same basic structure - they use the location string to identify which object to access, they provide an area of memory to contain the requested item, and they return an integer status value. The get operations are subject to a security model that authenticates and authorizes users. The memory allocated for requested value is the responsibility of the application programmer, and AIC will not free or allocate any memory across the defined API. set operations are launched against a named object in the same way as a get operation, but with the exception that the only local result is the returned error code. Each set operation will provide the value to be set.

The AIC-CL will provide multi-valued get operations, which return a result-set. Additional APIs are provided to traverse such a result-set.

There is a mechanism in AIC-CL to invoke a remote function registered (via AIC-AL) inside the application. This function is called a DoAction function, and a single string parameter can be passed.

All AIC-CL operations against an application must be secured. A plug-in security mechanism is provided to do this.

Functional Overview: AIC Host Services

The first and possibly most important function is that of security. The AIC security functionality is intended to be dynamically selectable when this is supported on a given architecture. In practice this means the ability to at worst stop an AIC application and its supporting services, copy in the new security model, and then restart immediately using the new model. The security model should support the concepts of multi-level access defined on an object level, but also at the user and application level (this is covered in more detail in AIC Security). Authentication and authorization must take place on the same host as the target application.

The next function is that of intermediary between AIC-AL and AIC-CL. It is required that direct accesses from an AIC-CL to an AIC-AL implementation should be rejected immediately. This is for two reasons. The first is to allow for some intelligence in the timing and volume of requests targeted at an application. The second is to support the security model in which no authentication or authorization is assumed to be performed outside the machine hosting the application¹.

Applications can fail in totality, so a mechanism is needed to detect this condition. Each AIC-AL initialized by an application on a host is required to be sent a heartbeat token at a configurable interval. If it does not respond to a configurable number of these, it is deemed to be no longer functioning. Note that the function of this heartbeat is more to detect the total absence of the AIC-AL rather than identify subtleties in the health of a registered application².

AIC requires that the application should be protected as far as possible from undue loads imposed by external requests for information. In this standard, this is referred to as cacheing. A cache will have an associated age and will only need refreshing from an application when a request is launched against that application and the cache is too old (that is, timed out). The time out functionality should be specifiable at two levels. The first is the time out for an application known to be running still. The second is the time out for an application known, by the use of the internal heartbeat mechanism, to have failed. It is intended that the second time out be specified to be longer than the first to enable post mortem flushes of AIC objects.

Locations for objects uniquely identify objects to an application and machine, but within a specific machine there needs to be a name mapping function to perform the mapping between an AIC application name and the physical address of the application process. In some implementations, this function may be quite limited, depending on the communication methods used. This function is also used to support the need to know which applications are currently running on a specific machine.

Finally, there is functionality required to propagate events to a management framework of some kind. That framework is not necessarily required to have any component part resident on the application machine. This implies the need to possibly propagate the events generated within an AIC-AL to an external intermediary using an AIC communication mechanism (which must be present on the application host in any case).

Summary: Enterprise use of AIC

AIC must be capable of being used in a multi-process environment, where numerous processes are using the AIC library. Each of the processes may have numerous threads which may wish to use AIC. Therefore this should be supported and the appropriate locking mechanisms implemented within AIC. Possible problem scenarios that should be handled might be simultaneous attempts to initialize the AIC-AL from within a single process.

AIC should be capable of handling processes on multiple hosts and be able to uniquely identify specific objects in a given application on any host.

Finally, the AIC specification provides no barrier to scalability in a large deployment, and implementations are required to retain this behavior.

Footnotes

1.

The communication within a machine is assumed to be secure, but that outside of a machine is not.

2.

A way of doing this is for an application to create an AIC object that it updates regularly. The object value can then be polled at a regular interval, partly governed by caching timeouts, and a failure to update can be taken as a sign of the failure of at least one thread of the application. This is not mandated by the AIC standard because of it's highly intrusive nature, but can be implemented as required by an application programmer.