| In order for autonomic managers and their associated elements to work together in an autonomic architecture, there must be a set of tools that provide the basic structure. There are presently seven core capabilities available to developers: -
Policy Determination -
Solution Knowledge -
Common System Administration -
Problem Determination -
Autonomic Monitoring -
Complex Analysis -
Transaction Measurement Now let us review each of core capabilities in some detail. Policy Determination Achieving the objectives of an autonomic architecture requires an understanding of the specific policies under which it will operate. The policies will determine the decisions that autonomic managers will make. A policy defines the criteria. As shown in Figure 8.4 below, the policies are key parts of the decision-making process. Figure 8.4. An example of a policy-based autonomic manager and its stored components. By defining policies in a uniform way, they can be shared across the individual components of an autonomic manager to enable entire systems to be managed as defined by a set of common policies. 
We must be careful to be certain of the term "policy." In IT, it can mean different outcomes to different forms of interpretation. Some examples follow in Table 8.1. Table 8.1. Examples of Policy | Policy | Example | | Service Level Agreements | The customer report must be printed and delivered to the customer department by 9:00 a.m. each day | | Security Policy | Identify sign-on by retina scans—report any variances. Set code level RED if variance detected above 1% | | Business Process Policy | For all customers who have orders worth greater than $50,000 each day—apply discount of 5% for all orders over this limit |
The secret to clarity and simplicity is commonality. The specification for autonomic policy definition includes the following common approach: -
A format and schema for specifying user requirements and criteria. -
A distribution mechanism for sharing policies among autonomic managers. -
Specification of configuration parameters for managed elements (files, databases, servers, etc.). Solution Knowledge This is one of the most important areas and one of the most difficult to manage externally. The IT industry has thousands of different software tools that provide installation, configuration, and maintenance functions for all types of solutions, platforms, and operating systems. The many different types of formats, parameters, return codes, and other data contribute greatly to the IT complexity that we now face. Add to these scenarios different protocols from the Internet with Web services and their associated software, and the problem is even larger. To address this problem will require a standard approach provided by solution knowledge software. This software captures the configuration and installation requirements in a consistent manner. This data can be used in other areas of autonomic computing, such as optimization and self-healing. Solution knowledge contains many types of data from multiple points such as operating systems, application languages such as Enterprise Java Beans, HTML pages, system utilities, and database tables and performance data. The solution knowledge standards define a set of constructs for providing installable units and design patterns that make standards possible. An installable unit will consist of a descriptor that describes the content and the actual artifact that is to be installed. An artifact can be software that is to be installed. The descriptor and the artifact comprise the package, similar to a Java archive file. The target environment is called the hosting environment, where the artifact is to be installed. There are three categories of installable units: -
The smallest installable unit— This unit contains one artifact. -
A container installable unit— This unit contains several artifacts for a container. -
Solution module installable unit— This unit contains multiple types of container units in a block. There are other tools available in the solution knowledge component that will aid the definition of configuration and maintenance processes: -
An installed database of units— This is a database that stores configuration details about installed units and their hosting environments. -
Deploy Logic— This is the software functionality that distributes the installable unit. -
An installer unit database— This is a library of installable units. -
An installer— This required software functionality allows the artifacts to be installed in the designated hosting environments. -
A dependency checker— This software checks whether the dependency of an artifact meets the requirements of the designated hosting environment. With these tools available, developers can prepare and plan the installing, configuration, and maintenance of the many products that are available and in use at IT installations. Common System Administration A common console technology represents the look and feel for a particular application. These standards ensure that screens will be similar to one another in looks and will be indistinguishable from one another, in terms of control characteristics, naming conventions, etc. Basic intent for these standards is to ensure that the user finds navigating through the screens easy and not complex. The goal of the autonomic common console is to provide that single approach that provides all the administrative functionality to manage servers, storage, and related software, be it individual systems or products. These administrative functions cover a wide range from initial setup to monitoring in real time, configuration, and control. This common console functionality is a standard that has been defined by IBM for IBM products. It will evolve and be made available to independent software vendors (ISVs) to integrate this into their products, thus establishing the necessary standards. A common console approach consists of a framework and a set of specific components. For example, administrative activities are executed in the autonomic architecture as portlets. The success of the common console approach will be determined by how other ISVs and manufacturers adopt and embrace the approach. Standards and agreement will take time to evolve. Problem Determination The different components of autonomic systems base their actions on what they detect, observe, or analyze in the managed element. Examples of these actions are optimizing, healing, and protecting. Problem determination is an important function for achieving these objectives. Therefore, there is a basic core need to provide problem determination in the autonomic manager. If there is a problem detected, the autonomic manager must take action. The data to make the determination of the problem is available in multiple types—for example, legacy systems data, such as logs, traces, and memory dumps. The diversity is enormous. Solving this problem will require a standardized approach in the autonomic architecture. To filter and process the multiple types of legacy data, the architecture will provide plug-in adapter/agent infrastructure that will translate to the autonomic standard format. The data needs to be processed in a common way such as collecting all the required data and normalizing it in terms of format and content. This requires a set of base data that must be collected or created when the problem occurs. It provides the starting point for the problem determination. Autonomic Monitoring Autonomic monitoring is the process of providing the autonomic managers with the capability of gathering and filtering data from the sensors. With this data, autonomic managers can perform a range of analyses and actions to be taken within the architecture. This can be achieved with the following functionality: -
Built-in sensor filtering functions. -
A common approach to capturing the data from the managed element sensors. This will involve the use of industry standards, such as Windows Management Instrumentation, JMX industry standards, CIM, and SNMP. -
A set of predefined resource models that enable the combination of different pieces of sensor data to describe the state of the resource. Resource models describe the business-relevant "logical objects" from the perspective of the common problems associated with the objects. Software is available to create new models. -
A methodology to integrate policy knowledge. -
Methods to plug in specific types of analysis engines that provide root cause analysis and automate the instructions to start corrective action. The reference model component of the autonomic monitoring function will provide a number of integrated best practices data that will facilitate management, such as: -
A log of the performance data related to each business object. -
Proactively managing the application through a set of predefined problem signatures. -
Continuously interpreting the quality of the business object against a set baseline and reports the variances. Complex Analysis All autonomic managers need the capability of performing complex analysis of data and initiating actions based on that data from the sensors. In addition, the managers can draw on the stored knowledge data. There will be large amounts of data to be processed and shared among the many autonomic managers in the architecture. The data will vary according to type; while some data will remain static and unchanged, other types will be dynamic. An autonomic manager's ability to quickly detect and analyze this data is crucial for the successful operation of the architecture. Common data analysis tasks will include data classification—such as static or dynamic—the clustering of data to illustrate complex states within the autonomic manager, and analysis to detect previous situations, predicted workloads, throughput, and so on. This will lead to problem determination and solution, followed by optimization and resource leveling. The technology behind complex analysis is a rule-based language that supports reasoning through declarative, and some procedural, rules based on the collected and stored knowledge data. The underlying rule engines uses scripting as well as forward-based and backward-based inferencing using "if-then" type rules, predicates, and fuzzy logic. Application classes can be imported directly into the rulesets so that data can be accessed using the sensors and control actions taken using the effectors. The rules language has been designed to simulate the Java programming language, as many corporations now use that software and are familiar with it. XML is also used for ruleset representation. These two well-used languages allow portability in exchange for productivity improvement. When more complex analysis is needed, other technology components can be called on, such as JavaBeans, to access data from legacy flat files and relational databases to filter and transform the data into templates for use within the autonomic manager. Other technologies include the use of machine learning beans, software agents, neural networks, decision trees, and Bayesian classifiers to perform statistical analysis using numerous generic algorithms. As a core autonomic technology, complex analysis is a vital component of the autonomic manager. Transaction Measurement Autonomic managers will need to know the flow of transactions across an autonomous architecture. This is important in the management of resources. Appropriate resources need to be in the right place at the right time. By monitoring these measurements, autonomic managers can change the resources to ensure optimal system performance. When transactions increase suddenly, restrictions in processing will occur. Transaction queues will build up and resources directed to that problem with instructions to solve it. The problem of transaction management and measurement is expanded when there is a cluster or mix of servers. Because of existing complexity restraints in the IT infrastructure, it may be difficult to exactly identify where the problem originates. The problem gets even bigger when there are hundreds or thousands of servers involved spread over geographical areas. Today, it is extremely difficult for system administrators to manage this type of problem with conventional tools and techniques. Sheer hard work and step-by-step tracing is necessary. Furthermore, the average utilization of most installed distributed systems is very poor. Many e-business applications are incapable of handling large and sudden increases in transaction volumes—"server crash" is a frequent phrase used in the media to identify this problem. The problem can be addressed by implementing an end-to-end transaction measurement infrastructure together with a distributed workload capability. The goal behind this approach is a policy defined—similar to the approach defined earlier. Defined goals can be implemented, for example: When all input transaction levels exceed 5,000 per second, initiate eUtility level 1 setup for extra processing cycles. In an autonomic architecture, the key issue is to understand the transaction workflow and map the service requirements classes to that topology. When an understanding of the transaction environment is achieved, the autonomic managers can commit sufficient resources—at high priority when necessary—to the workload and manage changes over time to ensure optimum performance. | 
