Previous section.

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

AIC Host Services

Overview

The AIC Host Services are a critical part of the AIC architecture. They are positioned between all applications using AIC and client programs wishing to access the management interface in those applications. Several key features of AIC are provided for example, the security model, the heartbeat mechanism, and logging of alarms generated by applications.
Note:
This Chapter does not mandate any specific architectural approach, but does indicate which functions must be supported to meet the AIC standard.


Figure: AIC Host Services Available on a Machine

A design goal for AIC was "minimal footprint" on a machine. It is therefore suggested that these services should be implemented in as few processes on a machine as possible.

The services must be available on each host running an application.

Name Service Server

This service can be thought of1 as a simple lookup table of running applications using AIC-AL on the node. It must be available on any machine where AIC applications are running. The scope of the service is the current host.

Each application that starts the AIC-AL library is registered in this table. There is an administrative API call AICCL_GetAppInfo() available to query this table externally.

This table holds the following items of information:

An example table is shown below (for a hypothetical ERP vendor ABC).

Federated Name Requested Name Application Name (unique)
ABC Accounting Accounting
ABC Queryr Query
ABC Query Query0

Table: Example of a Name Service Lookup Table

When the heartbeat mechanism can no longer connect to an application that is registered, the entry in the name service is tagged as "down". For a grace period, queries for data from the application are serviced from the cache (if possible - see "Object Cache" in Object Cache). When this period expires, the name must be removed from the name service.

Unique Name Generator

This service is used when the AIC-AL library is started by an application. It generates a unique name for the running program on a given host. The call to AICAL_LibStart() requests an application name. If it is the first request with that name on the given host, it succeeds (that is, the name assigned is that requested, with the proviso that the original name conforms to the naming standard described here). If the name has previously been assigned already, a unique name is generated and returned to the application.

This service uses the Name Service table to determine applications running on the current host. Once a name has been successfully established, it is entered into the Name Service table.

Rules for Assigning Names

Unique name generation follows the following rules:

Requested Name Scenario Name assigned
Application Does not exist yet on this host Application
Application Exists on this host
Only clash is "Application"
Application0
Application Exists on this host
Clashes with:
Application
Application0
Application12

Table: Rules for Assigning Names

Note that a federated name for a process has no impact on unique name generation.

Rules for Re-Assigning Names

When an application stops and its registration in the name server is removed, it must be possible for the application to be re-started and re-connect as the same name. It is feasible that a GUI has been written with an expected unique application name, and failure to re-connect as the same name may present a major problem.

The following rules apply for re-assigning names:

Requested Name Scenario Behavior
Application Previous Application stopped.
AICAL_Close() was used.
On calling AICAL_Close(), the name was gracefully removed from the name service.
Name assigned: Application
Application Previous Application stopped.
AICAL_Close() was not used.
Within "dead cache timeout".
Name exists in the Name Service, but marked as down. Scenario interpreted as a re-connection.
Name assigned: Application
Application Previous Application stopped.
AICAL_Close() was not used. Host services unaware application is "down" as the heartbeat mechanism has not discovered this situation yet.
Unaware application has stopped.
Name assigned: Application0
(as per rules described above)
Application Previous Application stopped.
AICAL_Close() was not used.
After "dead cache timeout".
When dead cache timeout finished, the entry was removed from the name service.
Name assigned: Application

Table: Rules for Re-Assigning Names

Internal Heartbeat Mechanism

This function runs periodically. Each application registered in the name service table is sent a heartbeat token. If the AIC-AL library inside a given application is up and successfully running, the AIC-AL library will return the token. Note that this does not imply the application is functioning, only that the AIC-AL implementation is running.

If the token is not returned in a set period of time (which should be configurable within an implementation), the application is assumed to have stopped. The following actions are taken as a result:

Management Framework Gateway

This function provides an interface to a Systems Management Framework. This presence of this component is not mandated as part of this standard, and an AIC implementation can function without this component present. It is described here to identify an additional implementation option that is available.

The interface works in real time, and processes the two types of request described in Application Event Submission to a Management Environment and Publishing Objects to a Management Environment below.

Application Event Submission to a Management Environment

When an event is created from inside an application using AICAL_RaiseEvent(), or when the heartbeat mechanism detects a process has disappeared, an event will be forwarded to an optionally connected systems management framework as soon as is possible.

AIC Events are discussed in detail in AIC Events, describing AIC Events.

Publishing Objects to a Management Environment

The management object within an application has a property called visibility. This defaults to local. When this property is set to a value other than local, the object is published into a systems management environment if one is connected, and an interface to it is provided in the specific implementation. The representation of an AIC object within a systems management framework is an implementation decision. All publishing tasks that require interaction with a given systems management framework are a function of the "management framework gateway". If no such framework is present, AIC must continue to function efficiently even if an application programmer attempts to publish a number of objects.

This publishing mechanism happens in real time. Changes made to the management object using the API calls AICAL_SetValueXXX() and AICAL_SetStatus() must cause an update to be published out to the management framework. Again, how this is handled in practice is an implementation specific issue

The API call AICAL_SetVisibility() causes the object to be initially created in the remote framework. Calling AICAL_Delete() on an object which is being published into the framework does delete the representation there. Changing the visibility of an object being published (using AICAL_SetVisibility)() to local causes a deletion of the remote representation in the framework.

Swappable Security Component

This service implements the security model on the local machine.

Requests from the AIC-CL client library must go via this security component. The component can be the same security component used by the AIC-CL library (single file). A different component is used for a different security model/implementation. Once successfully checked by the security component, a message is sent into the AIC-AL library.

The assumption is made that the security within the machine is sufficiently good that the Application Library need do no further checks on such messages. Note that if a swappable component is used, additional security must be applied to the component itself to ensure that an unauthorized "pass through" version of the component cannot replace the authorized version.

Both get type calls and set calls require security checks. These checks are carried out external to the application as a AIC Host service on the same machine. This ensures the security package is not linked into the business application.

Object Cache

The object cache service keeps a copy of (caches) all management objects for applications on that node.

The cache initially contains no objects. Data is populated in the cache for an application when the information is requested. If no data is requested, the management object data will never be populated in the cache for that application.

Whenever a query (generated through the AIC-CL library) is received on a machine for any application on that same machine, it will be resolved by the object cache. No query can go direct to an application. Any such queries should be rejected outright.

If the cache needs to be refreshed to resolve any given query, a cache update request will be sent to the application. The full object tree of the application will be refreshed, and the query resolved.

The cache timeout is a configured within an implementation.

When the heartbeat mechanism cannot contact an application, the cache for that application is put on a timer called a "dead cache timeout". When this timer expires, the cache is flushed for data from this application. This timeout value is configured within an implementation.

The "dead cache timeout" allows potential querying of the data to determine why the application stopped. Also administration API calls allow the object tree for a given application to be archived to file.

Alarm Logging

This service will log any alarms generated within AIC on a given host to file.

All components of an alarm are logged. See the description of AIC Events in AIC Events. for details of how events are raised, and their format.

The representation of events in the log file is implementation defined.

Log file management capabilities are implementation defined.


Footnotes

1.
For convenience, it is referred to as a table throughout the remainder of this Chapter, but this does not constrain any implementation options.

2.
The rule is to find the highest number and add 1.

3.
The event description has a fixed format in this scenario. See AIC Events, AIC Events for further information.


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