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:
-
Application federated name (see
Object Naming Conventions
on Object Naming Conventions).
This will typically be the application group.
-
Application requested name - the name used in
AICAL_Libstart()
to request an application name.
Used so it is possible to tell when multiple
instances of an application have been started.
-
Unique application name (unique on the given host)
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:
-
The status of the application is marked as "down"
-
Any data in the
object cache is available only as long as the "dead cache timeout"
-
An event is raised3
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.