Introduction

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.

Objectives

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 attention first.

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.

AIC can see inside 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 day.

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.

Key Principles

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.
Multiple instances 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.
Naming for application instances, cross-machine syntax and addressing management objects should be simple. A UNC/URL type mechanism must be provided.
All ( get and set) operations are secured.
The library 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 instability.
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 get and set 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 application process.
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).

In addition, 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

Functionality Highlights

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 application
A mechanism for raising alarms from within the application, which causes an alert to be sent externally
Security mechanism
Internal API heartbeat mechanism with an external co-ordinator. This allows the external process to tell if the application dies
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.

Contents

Next section

Index