Application Instrumentation and Control (AIC) API, Version 1.0
Copyright © 1999 The Open Group
The purpose of AIC is to provide facilities for sophisticated
management of business applications. With the increased complexity of
technology in the distributed computing environment the management
challenge has increased over time. AIC is aimed at helping to manage
those applications at the complex end of the envelope. These are
multi-threaded, multi-instance, cross platform, long running
applications that the business expects to be up and running for 24
hours of every day, 7 days of a week, all 52 weeks of the year.
Typically they incorporate many processes with some complex interaction
between them to function for the application to keep running. Often
they include multiple locations with multiple time-zones.
The challenge is to rise above single technology silo management into
application management. For this a collection of both traditional agent
technology and information from within the application program is
necessary. The solution must be more than monitoring and must enable
features to affect the run-time behavior of the application (ie
monitoring plus control). With this set of information and a data
visualization product a solution can be generated. It should be
possible to get so business focused that you can model and manage the
business process itself.
As part of their daily routine, IT support staff are constantly
evaluating enterprise-level application problems to determine their
priority and the sequence in which each will be addressed. This
evaluation requires an understanding of the impact of each problem,
which problem affects most users, and which problem affects most sites.
The case that has the most impact on the overall business is generally
considered a priority. Therefore, a fundamental requirement of IT
management today is to prioritize the management of the technical
resources with regard to the business objectives.
The Application Management approach focuses support on the priorities
of the business. One example of this business-focused support is the
concept of Business Process Management. This allows information
technology managers to define the critical resources that create,
affect or deliver a business process or service. Each service is then
given a priority based on its impact on the business. As problems with
the managed resources occur, the business services that are affected by
the problems are highlighted, clearly indicating which problems require
The AIC approach to application management addresses this issue by
attempting to manage that business process in conjunction with the set
of underlying technologies making it function.
the Application - rather than surveying and
reviewing it externally from the outside. This allows real business
information to be available. When a failure occurs, it should be
possible to answer the business managers' first question
what is the economic impact to my business?
with a business - not technical - answer.
The AIC standard is the definition of a two-way interface to be
attached to the side of an application process (program). With this
interface, query and set type functions are possible against the
application whilst it is running. The standard defines an API and
requires developers to add code to their application programs.
Access to real business data allows a whole new audience for
traditional systems and application management technology. This
provides sufficient services that a business operational manager can be
given tools to effectively manage the application process. The two way
interface provides control facilities so that on/off switches, sliders,
dials and other features can be added to the application to affect its
run-time behavior. Control allows the operations manager to
re-configure the application whilst running to maximize resources for
the next business deadline. It also allows changes to be made to react
to changing business conditions (potentially unexpected) during the
The result is that information can be extracted from the application
programs during run time for several different audiences - technology
support staff, development support staff, and business operations staff.
AIC is intended to complement the functions of agents in environments
where management of internally developed applications is required.
Implied in this purpose is the desire to keep the footprint of
additional software on the application machine as low as possible, as
well as make the incorporation of a management API into the code as
simple as possible for a developer. This requires a small learning
curve to see some results, with as little theory as possible needed to
be learnt to get off the starting block.
AIC is aimed at providing a simple API definition for addressing the
above problems with several key principles in mind. These principles
are outlined below:
The API is thread-safe and can be used by multiple threads at
the same time inside an application. All threading issues should be
addressed within the library, with no issues (such as locking) presented
to the developer.
The API should be cross platform. This means
that API calls resulting in network communication across a network can
be on different platforms and this should work transparently to the
developer and end-user.
The API should be portable. The use
and behavior is identical on all platforms.
of a given application are supported. If a developer uses the API in a
program and starts multiple copies of their program, each functions
correctly and can be addressed individually.
application instances, cross-machine syntax and addressing management
objects should be simple. A UNC/URL type mechanism must be provided.
operations are secured.
must be totally dynamic. The internal application structure of
management information must be created at run time not compile time. No
fixed structures are used (for example, like an SNMP MIB definition).
Little or no pointers (handles) should be exposed to the
developer. Minor performance degradation is allowed or preferred over
All API calls must be type safe (where possible),
enforcing as much checking at compile time as possible. This has the
effect of duplicating many API calls (for example the
calls) but increases the reliability.
Protect the application
as much as possible. Attempt to prevent a group of users requesting the
same management information directly from the application. Limit the
maximum amount of extra work the management interface will put on the
Provide as much value with as little code
as possible. The API does this by only requiring 2 API calls to be
added to a program to add some value.
Requires as little
background knowledge to be given to the developer as possible.
Concepts used are not that new, and very little needs to be learned to
be productive. For example, the aim is that the developer does not need
to learn something like SNMP MIB definitions before he/she can start.
below displays the concepts. For a given part of an application process
it is possible to extract data on both sides of that piece of the
process - work queued up, and work successfully processed. If the
component fails, the business economic impact is clear - the management
information queued up is the answer (on the left in this graphic).
shows control features within a process. This component can be switched
on and off. The API provides a facility like this on/off switch to the
business operations manager.
Figure: AIC Concepts - AIC for Component Compute
In summary, the AIC API provides the following features:
Creation of management objects within an application that can
be queried and changed inside the application and external to the
A mechanism for raising alarms from within the
application, which causes an alert to be sent externally
Internal API heartbeat mechanism with an
external co-ordinator. This allows the external process to tell if the
Propagation of management objects to a management framework
Clear architectural integration point for a management framework
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.