The previous column ("Autonomic computing: The state of the union") was a departure from the norm, introducing the fictional character Otto Nomic, who offered his own version of the state of the union of autonomic computing. Otto failed to be picked up by any major syndicate, so this Edge article returns to our roots, describing the latest developments in autonomic computing. In this article, your beloved columnist Brent Miller is joined by Mark Weitzel, an autonomic computing tooling architect. We will discuss tooling called the Autonomic Integrated Development Environment (AIDE), software that lets you build components that can snap into self-managing autonomic systems.
With apologies to a great movie, Field of Dreams, we will describe:
- How AIDE can assist you in realizing the dream of "If you build it, management will come."
- How AIDE can help you "go the distance" more rapidly when building components with autonomic manageability capabilities.
- How the resulting self-managing autonomic components, when used by a system administrator, can help to "ease his pain."
We'll promise to reduce additional movie references as we discuss how AIDE enables you to put a sharp autonomic computing edge on products that you can develop.
The Autonomic computing architecture
As described in "An architectural blueprint for autonomic computing" (see Resources):
This blueprint organizes an autonomic computing system into the layers and parts shown in Figure 1. These parts are connected using enterprise service bus patterns that allow the components to collaborate using standard mechanisms such as Web services. The enterprise service bus integrates the various blueprint building blocks, which include:
- Touchpoints (also called manageability endpoints) for managed resources
- Knowledge sources
- Autonomic managers
- Manual manager
Figure 1. Autonomic computing reference architecture
The lowest layer contains the system components, or managed resources, that make up the IT infrastructure. These managed resources can be any type of resource (hardware or software) and may have embedded self-managing attributes. The next layer incorporates consistent, standard manageability interfaces for accessing and controlling the managed resources. These standard interfaces are delivered through a touchpoint. Layers three and four automate some portion of the IT process using an autonomic manager.
A particular resource may have one or more touchpoint autonomic managers, each implementing a relevant control loop. Layer 3 in Figure 2 illustrates this by depicting an autonomic manager for the four broad categories that were introduced earlier (self-configuring, self-healing, self-optimizing and self-protecting). Layer four contains autonomic managers that orchestrate other autonomic managers. It is these orchestrating autonomic managers that deliver the system-wide autonomic capability by incorporating control loops that have the broadest view of the overall IT infrastructure. The top layer illustrates a manual manager that provides a common system management interface for the IT professional using an integrated solutions console. The various manual and autonomic manager layers can obtain and share knowledge via knowledge sources.
Of particular interest for this article is the topic of touchpoints (also called manageability endpoints), which can be built in a standard manner using AIDE. This tooling enables you to build the standard manageability interfaces to access and control the managed resources, as described in the preceding citation from "An architectural blueprint for autonomic computing." AIDE lets you produce standard manageability endpoint interfaces that map to your manageable resource's internal interfaces and lets you describe the manageability capabilities of your managed resource.
Before going further into how to use AIDE to create touchpoints for manageable resources, we will first discuss the importance of standard interfaces, both architecturally and in implementations.
The importance of standard interfaces
An earlier Edge column ("The 'Standard' way of autonomic computing") cited this quotation from the United States government's National Institute of Standards and Technology (NIST): "Standards are essential elements of information technology -- hardware, software, and networks. Standard interfaces, for example, permit disparate devices and applications to communicate and work together." This is particularly important in the area of systems management in which multiple management and manageability interfaces proliferate. When these interfaces are standardized, interoperability of management tools can be achieved.
Web Services Distributed Management (WSDM) from OASIS offers such a standard manageability interface. As described in the announcement for WSDM 1.0, "WSDM enables management applications to be built using Web services, allowing resources to be controlled by many managers through a single interface." Interoperability increases as more components are built with these standard manageability interfaces. As described next, tooling can help to accelerate that adoption while also providing consistency in the resulting implementations.
Standard interface definitions enable interoperability in heterogeneous environments; however, those standard interfaces must be instantiated -- that is, built with real, working code -- to actually realize the benefits of standards.
Building the code that implements standard interfaces can be done in multiple ways. One way is to sit down with the standard specification and begin to write the code that implements it. If everyone who implements the standard does this and does it faithfully, then the benefits of the standard can be realized. It is important to note though that each party who implements the standard is duplicating the work of others.
Another way to achieve this instantiation is to use tooling to help produce the code that implements the standard. This is a common practice for software development in general and it applies equally well for this application. The use of tooling to implement standard manageability interfaces offers these benefits:
- Consistency -- the code produced as a result of using tooling is uniform.
- Validation -- the tooling can be used to perform development-time verification for logic and data.
- Productivity -- tooling typically can automate much of the code generation process so that the developer needs to write much less code from scratch (often, the developer just needs to supply specific names and values to be inserted into a code template and logic for custom modules such as implementations for certain internal interfaces).
- Migration -- when standards specifications change as they inevitably do over time, the changes required to match updated standards versions can be contained within the tooling, thus removing the need to change every individual implementation to match the new standard.
AIDE is a set of tooling that offers these benefits for building implementations of standard WSDM manageability interfaces for both existing and new components. Now we'll discuss AIDE in more detail.
Using AIDE to build self-managing autonomic components
In the last several months, there have been a number articles published on developerWorks that provide detailed examples of using the AIDE tooling. In "Hit the ground running with AIDE: Building a touchpoint," Stephen Morris explains the basics of building a touchpoint. Leigh Williamson of IBM's WebSphere team partnered with Mark Weitzel and Dan Jemiolo of IBM Tivoli's Autonomic Computing group to demonstrate a WSDM manageability endpoint for Java™ 2 Platform, Enterprise Edition (J2EE) in "WSDM for J2EE provides next-generation management." Both of these examples were built using AIDE, which is available at IBM alphaWorks.
Tools play an important part of the development process. When applied to the management space, tools let the developer "build in" management aspects from the outset. AIDE is the first step in creating an environment in which the management aspects of a resource can be constructed and used throughout the entire development process.
One of the key design goals of AIDE was to keep the definition of the management aspects distinct from how they are realized. In essence, AIDE lets you define a model of a resource's manageability. This is similar, in one sense, to CIM or JSR77, but it differs in that the model is the underlying core of the tooling. For example, AIDE uses the model to drive the generation of code and other artifacts for use in the Autonomic Integrated Runtime Engine (AIRE), which is a WSDM 1.0-compliant run time. AIRE is a run-time framework for the WSDM-enabled IT resource. IBM is in the process of donating this code to open source and is working closely with the Apache Muse community.
AIDE creates the definition of a resource's manageability aspects in two ways. First, a management interface is defined. AIDE has chosen to use the same terminology as the WSDM specification, calling these management interfaces "capabilities." In this section, we examine the model files that are similar to those in the article "WSDM for J2EE provides next-generation management."
Manageability capabilities represent the properties, operations, and events of a resource. In addition, the autonomic computing team provides the ability to declare dependencies on another resource's management interface. These extensions are named call outs because the resource is declaring that in order to be effectively managed, it will "call out" to another resource.
Capabilities are intended to be reusable. For example, the manageability capabilities defined by the WSDM specification are provided by the tooling. Ideally, capabilities will expand into other industry segments, and standards bodies will agree upon the management capabilities of like things such as the JSR77 so that interfaces used within the tooling also can be standardized. In these cases, artifacts might already exist that can be used as a starting point; for example, a Java class or XML schema. These can be imported into the editor to begin the definition of the management interface, as shown in Figure 2.
Figure 2. Choices for creating a capability from an existing artifact
Figure 3 shows the editor used to build out the management capabilities details. The editors in AIDE follow a general pattern of opening with an overview page, then presenting tabs along the bottom for each of the major sections. Pressing the Details... button or selecting the tab on the bottom lets the user navigate to the information. Also provided is a source page. Currently, the source page is a read-only page that shows the serialized form of the models. It is provided as an easy mechanism for developers familiar with the Eclipse Modeling Framework (EMF) to understand the underlying model format.
Figure 3. Capability editor overview page
One of the unique aspects of the AIDE tooling is that it provides the ability to capture additional information about resources. For example, it is often desirable to declare that a particular property is read-only. This and additional metadata are shown in Figure 4.
Figure 4. Capturing metadata about a resource property
The initial focus of AIDE was to provide tooling to create WSDM-based manageability endpoints. The definition of these endpoints represents an aggregated set of manageability interfaces; as such, they have no properties or operations of their own because these are provided by their capabilities. Figure 5 shows the overview page of AIDE's Touchpoint Type editor.
Figure 5. AIDE Touchpoint Type building overview page
The Touchpoint Type, also known as the manageability endpoint type, contains all the manageability capabilities required by WSDM and also the manageability capability defined to represent the J2EE server. This editor has built-in awareness of the WSDM specification and helps the user create well-formed manageability endpoints. For example, because the WSDM specification declares identity to be a required management capability, the tooling automatically adds this to the definition.
One interesting feature of the AIDE tooling is that it allows one capability to define extensions to another capability. Two examples of this are metrics and relationships. When the metrics or relationships capabilities are added to a touchpoint type, they contribute a unique view to help further define their management aspects. Anyone providing a capability may choose to take advantage of this feature of the tooling. Figure 6 shows the custom editor that is provided with the capability for relationships.
Figure 6. AIDE custom editor added by WSDM relationships capability
After the management capabilities of a resource are defined, they can be used to produce artifacts that are used to drive the run time, AIRE. Many different deployment environments for management capability may exist; for example, an application server or an OSGi run time. Each of these environments has different styles of deployment, such as WARs or EARs files versus bundles.
To facilitate a wide variety of use cases, the tooling provides the ability to describe the generation options for code and deployment. This is accomplished by creating an implementation model based on one or more touchpoint types. The implementation model is a separate design-time artifact that drives the generation of code, WSDL, and metadata. Figure 7 illustrates the implementation editor for manageability endpoints.
Figure 7. AIDE implementation editor for manageability endpoints
In the example used in the "WSDM for J2EE" article, multiple touchpoint types have been aggregated into a single deployment unit for deployment into an application server. Because WSDM often wraps existing management behavior and APIs, AIDE provides control for the ways in which a resource's state is accessed. For each attribute in the touchpoint types, the developer can specify that the generation framework should create an access method for custom coding. This is the "Backed by Java Method" option.
Sometimes it is necessary to override the default behavior provided by the framework for Endpoint Reference (EPR) creation. For each capability, the developer can specify a custom class that is invoked to create the EPR at run time.
When the code for a resource is actually created, the code generation framework starts with the implementation model and proceeds through each of the contained touchpoint types. The tooling automatically handles the standard capabilities defined by WSDM and will "hook" those into the generated code. For each capability that the developer provides, a Java method is created for each operation in the manageability interfaces. Figure 8 illustrates the stop method.
Figure 8. Java method code generation example
Notice how the Eclipse workbench is leveraged by tapping into the "Tasks" view. Each method that needs to be implemented by the user is commented with the "//TODO" task marker, making navigation to the method quick and easy.
AIDE allows for easily testing the implementation of the manageability endpoint. For example, if the endpoint was generated for deployment into an application server, the option to "Run on Server" from the implementation's context menu can be selected. This runs the endpoint directly in the development environment. If the debugging option is used, the developer can debug the endpoint directly in the development environment!
One final tool that can be used is the Manageable Resource Explorer. This view lets the user inspect and manipulate the underlying resource by setting properties and invoking operations. Figure 9 shows the explorer used in conjunction with the debug perspective. The explorer is tied into the standards properties view to make it easy to see the state of the resource.
Figure 9. Manageable Resource Explorer used in conjunction with debug perspective
The AIDE tooling lets the developer quickly build, test, and deploy WSDM-compliant manageability interfaces. Its robust set of editors and code generators minimize the burden of understanding the complex standards for IT management. In this article, we've described how tooling can be used to realize the standard interfaces necessary for systems management in a heterogeneous environment. In other words, "If you build it, management will come" -- and AIDE helps you build it.
This overview of AIDE is complemented by other developerWorks articles for readers who want to explore AIDE in more detail.
The next installment of the Autonomic Computing Edge will return to one of the fundamental aspects of the autonomic computing architecture, Common Base Events, to examine what's new in the world of standard event representation. The article will look at the WSDM Event Format (WEF) and how that compares to Common Base Events, and you'll see what's up with the recently published Common Base Events Best Practices Guide.
Learn
-
"Autonomic Computing: The State of the Union" (developerWorks, January 2006): Get an introduction to the fictional character "Otto Nomic," who shares his view of the past, present, and future of autonomic computing.
-
"An architectural blueprint for autonomic computing:" In this blueprint, find out more about the autonomic computing architecture.
-
"Hit the ground running with AIDE, Part 1: Building a touchpoint" (developerWorks, April 2006): See this tutorial for details of building a manageability endpoint (touchpoint) with tooling.
-
"WSDM for J2EE provides next-generation management" (developerWorks, March 2006): This article demonstrates a WSDM manageability endpoint for J2EE.
-
"The 'Standard' way of autonomic computing" (developerWorks, March 2005): This article describes the importance and use of standards for autonomic computing.
-
National Institute of Standards and Technology: See this site for an excellent discussion of the importance of standards.
-
WSDM Technical Committee: This OASIS committee defines and publishes the WSDM standard.
-
Autonomic Computing Toolkit: The Toolkit includes information about the Common Base Event, including the recently published Best Practices Guide.
Get products and technologies
-
AIDE toolkit: This toolkit is a set of tools for creating WSDM-compliant interfaces for managed resources.
-
IBM trial software: Build your next development project with trial software, available for download directly from developerWorks.
Discuss
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
