The previous installment of The autonomic computing edge was the first in a series that focuses on the autonomic computing architecture. That article discussed an integrated view of four important aspects of autonomic self-managing systems: self-configuring, self-healing, self-optimizing, and self-protecting -- sometimes called "self-CHOP." This article continues the autonomic architecture series by examining the architectural building block called a touchpoint.
I'll describe what a touchpoint is, how touchpoints encapsulate managed resources and some things to consider when designing touchpoints. Now, let's sharpen your edge on touchpoints.
In an autonomic computing system, touchpoints represent the manageability interfaces for the things that are managed. We call these things manageable resources. A touchpoint enables these resources to be managed in a single, standard manner, regardless of the type of resource. That is, a single standard manageability interface, as provided by a touchpoint, can be used to manage routers, or servers, or application software, or middleware, or any other manageable resource. This is one of the key values of autonomic computing: a single manageability interface, rather than the numerous sorts of manageability interfaces that exist today to manage various types of resources.
Figure 1, from the Autonomic Computing Blueprint (see Resources for a link), illustrates the touchpoint building block in relation to other building blocks in a self-managing autonomic system.
Figure 1. Touchpoints in a self-managing system
The Autonomic Computing Blueprint (see Resources) defines a touchpoint and offers the illustration included here as Figure 2:
A touchpoint is an autonomic computing system building block that implements sensor and effector behavior for one or more of a managed resource's manageability mechanisms. It also provides a standard manageability interface.
Figure 2. Touchpoint
Some key concepts about touchpoints are discussed next.
Manageability Interface: As described earlier, a touchpoint exposes a standard manageability interface, including a sensor interface and an effector interface. The sensor and effector are detailed in Figure 3 and described next.
The sensor interface enables an autonomic manager to retrieve information from the touchpoint. As illustrated in Figure 3, the sensor supports two methods, called interaction styles, for retrieving data: request-response, for solicited (queried) data retrieval and send-notification for unsolicited (event-driven) data retrieval.
The effector interface enables an autonomic manager to manage the touchpoint, and it also supports two interaction styles: perform-operation is used to control the behavior of the touchpoint (for example, to alter state data values or send commands); solicit-response enables the touchpoint to "call out" to its manager.
Figure 3. Touchpoint sensor and effector interface detail
The manageability interface also exposes information about the manageable resource details, such as identification information for the manageable resources and metadata about the data associated with the manageable resources, such as metrics, configuration, and other state data.
Various mechanisms can be employed in the manageability interface: the touchpoint can send events, provide data when queried, accept commands, and perform call-outs to other components, as described in the previous sensor and effector discussion. The mechanisms used to realize these functions of the standardized manageability interface within a particular touchpoint (for a particular set of resources) may vary and might include the use of log files, specific programming interfaces relevant for the manageable resources, or other functional workings. But whatever mechanisms are used, their function is to map from the management capabilities of the manageable resources to the standard manageability interface exposed by the touchpoint.
Touchpoint scope: As illustrated in Figure 2, the touchpoint consists of all of the related manageable resources, the manageability interface mechanisms, and the standard manageability interface (that includes managed resource details and sensor and effector interfaces). The touchpoint is not just the manageability interface atop the manageable resources, but rather the encapsulated view of the manageability interface for the entire collection.
This leads to the iconic representation for a touchpoint depicted in Figure 4. This icon represents touchpoints in architectural diagrams of self-managing autonomic systems, like those in Figure 1.
Figure 4. Touchpoint icon
Encapsulated resources: A touchpoint encapsulates one or more resources. When multiple resources exist in a touchpoint, they may have relationships with one another. Common relationships include hosts and uses relationships. A touchpoint contains one primary resource called the root manageable resource (depicted in Figures 2, 3, and 4 as the larger yellow box inside the touchpoint); typically, this root manageable resource will contain or host other manageable resources. The next section explores touchpoints and resources in more depth.
As just described, a touchpoint is likely to encapsulate multiple related resources. Each of these manageable resources can expose its own manageability interface within the touchpoint so that the resources can be managed individually.
Consider, for example, a touchpoint for an application server. The root manageable resource in the touchpoint might be the instance of the application server itself. That application server hosts applications, so each of the applications would be contained (hosted) manageable resources, related to the application server root managed resource through a hosting relationship.
In this case, the touchpoint could expose a manageability interface for each of the individual applications hosted by the application server, allowing each application to be managed individually (for example, configuring each application independently). In addition, the application server itself (the root manageable resource) can be managed; the management operations performed on the application server might in turn affect the hosted applications (for example, configuring the application server to maximize performance or minimize resource usage could in turn result in changes in the environment in which the applications operate).
Consider a second example of a database server. The root manageable resource in the touchpoint could be the instance of the database server itself. That database server hosts databases, which in turn can host or use tables and table spaces. Each of these entities could expose its own manageability interface.
For example, a particular autonomic manager might manage only certain types or instances of databases (say, customer order databases), whereas another autonomic manager might manage other databases, or might manage the database server itself (with management of the database server affecting its related database, table and other related resources similarly to the example just provided for an application server).
In addition, other management functions -- perhaps embedded self-management functions contained within the database server touchpoint itself -- might directly manage other resources such as tables and table spaces.
In both of these examples, multiple related resources are encapsulated within a single touchpoint, with the touchpoint providing the common manageability interface. Yet, the individual resources also can expose their own individual manageability interfaces, which are likely to be different than those of other manageable resources encapsulated within the touchpoint. This offers flexibility to the touchpoint designer as well as flexible mechanisms for autonomic managers that manage touchpoints.
Considerations for touchpoint designers
As noted earlier, touchpoints provide a standardized manageability interface for resources. As just described, related resources typically are grouped together within a single touchpoint while maintaining the individual resource manageability interfaces. These individual resource manageability interfaces, of course, comprise portions of the touchpoint and offer the same standardized manageability interface with a single resource scope.
Autonomic computing is all about system management, and touchpoints are all about manageability interfaces for manageable resources. Touchpoints do not address functional characteristics or interfaces for resources; they address only the manageability interfaces. That is, touchpoints do not provide the mechanisms to access databases by inserting, deleting, modifying, and querying the database content (mechanisms such as SQL for relational databases provide these functions); rather, touchpoints provide the mechanisms to manage the databases and their related resources.
The use of standards lets touchpoint designers use common frameworks when developing standards. The Web Services Distributed Management (WSDM) standard offers one important framework for manageability interfaces. This standard was discussed in a previous installment of The autonomic computing edge. With established standards for manageability interfaces, touchpoint designers can expect that tooling for touchpoint development is on the horizon. Appropriate tooling that leverages common frameworks can make the process of developing touchpoints more straightforward and automated.
Touchpoints are one of the five building blocks of the autonomic computing architecture. Touchpoints encapsulate sets of related manageable resources and expose a common manageability interface for the resources. The touchpoint manageability interface includes sensor and effector interfaces. Autonomic managers take advantage of the common manageability interface to manage some or all of the resources of a touchpoint.
Touchpoints form a foundation for self-managing autonomic systems by standardizing the manageability interface for manageable resources. Future installments of The autonomic computing edge will examine other architectural building blocks and how they can be composed together with touchpoints to form self-managing autonomic systems.
- Read more about autonomic computing standards in the previous issue of The autonomic computing edge column on developerWorks.
- For more on the Web Services Distributed Management standard, see "Autonomic computing and Web Services Distributed Management: Autonomic computing just got a little wiser" (developerWorks, June 2005)
- Learn how to use the IBM Touchpoint Simulator to Simulate autonomic resources in your IT system (developerWorks, April 2005).
- Don't miss any of Brent's earlier edginess; read the other installments of The autonomic computing edge.
