Level: Introductory developerWorks staff (dwinfo@us.ibm.com), Editorial Staff, IBM
25 Jan 2005 This question and answer article features Thomas Studwell, a Senior Technical Staff Member for Autonomic Computing Technology at IBM. developerWorks talked with Thomas about current efforts and strategies for creating open, autonomic computing standards.
developerWorks: Tell us about what you do at IBM.
Thomas Studwell: I work in the Autonomic Computing Architecture and Development group, which is responsible for developing and maintaining the autonomic computing architecture. My specific job is to promote the autonomic computing technologies that IBM develops into open standards. So, I take the technology that we develop and find the right place to standardize these technologies and work with the appropriate people to get these standardized; either by influencing existing standards or by creating new committees to develop new standards.
DW: So, in other words, you're the chief strategist responsible for pushing for standardization of autonomic computing technologies?
TS: Well, we do have a group responsible for overall strategy in autonomic computing architecture. We also have groups throughout IBM who are responsible for overall standards strategy. I bridge the gap to develop the standards strategies that specifically relate to autonomic computing technologies; what should and shouldn't be standardized, and how to go about it.
DW: Where does the autonomic computing group fit in IBM?
TS: Administratively, we report to the Software Group, reporting to Steve Mills. But, we started out as an EBO (Emerging Business Opportunity) because we are a cross-IBM initiative. Virtually all of IBM's products need to have some aspect that addresses autonomic computing. Our group works with all the product groups and brands within IBM.
DW: Would you give the readers who may be new to the autonomic computing concept an idea of what autonomic computing is and why it is important?
TS: The main goal that we have with autonomic computing is to bring self management to new IT equipment and also to existing IT equipment that has been developed over decades. To a large extent, even the older equipment is useful and is still used at customer locations .
DW: Like legacy mainframes?
TS: Yes, mainframes and PCs. In fact, I would say to a larger extent PCs tend to get older quicker than the mainframes. So the industry has been very creative at solving specific problems that the various business users and consumers of IT have encountered. Except for one -- in the process of developing specific technologies, specific tasks, the thing that has tended to be overlooked is that as we have put all these different pieces together, the complexity increases. With each new kind of device that gets added into the infrastructure, the complexity of the entire system actually goes up and is multiplied by the complexity of that particular device.
It doesn't take too many layers to start becoming so unwieldy that consumers of IT have ended up having to devote considerable percentages of their IT resources, specifically people, to maintaining their IT infrastructure rather than developing and expanding that infrastructure. The role of autonomic computing is to take the model that exists in the human body. Autonomic systems that are self-regulating aspects of various body functions -- like the iris of the eye closing down when there's too much light focused on it or the respiration rate increasing when someone is working harder -- taking that concept and applying it to the IT infrastructure so that computing systems can be more self-managing.
DW: It comes back to CHOPs idea.
 |
Self-CHOPs
Autonomic computing means that applications, systems, and networks become more self-managing. This self-management involves four qualities: self-configuration, self-healing, self-optimizing, and self-protection. Hence, the Self-CHOP characteristics.
|
|
TS: The CHOPs idea is a good representation of the various perspectives on the kinds of problems that would be self-managing. We have the characteristics of self-configuring, self-healing, self-optimizing, and self-protecting; this is where the CHOP acronym comes from, but the representation is a circle. This graphic is shown with well defined edges between each quadrant of the circle. But, in fact, those are all interrelated in a number of aspects. When you start digging into the technology to provide any one of those, those same technologies also serve the other quadrants as well.
It is a good way to visualize the different aspects of self-management, but it shouldn't be taken so literally as to think that a particular technology addresses only one of those quadrants. Especially autonomic computing, which tends to establish the basic hygiene and plumbing, if you will, that is necessary for self-management; that same plumbing serves many purposes.
To finish the answer, for example, to deploy upgrades to CRM with current technologies, there would be a significant amount of offline testing that would need to be performed, and manual intervention by IT experts as they try to piece the new upgrade into their existing business processes. Whereas, the goal with autonomic computing is that once the infrastructure is set up for self-configuration, as new updates become available, the changes needed within the infrastructure to apply the new update would be virtually obvious to the management system and then be able to flow into the system in a much more straightforward manner.
This, in turn, allows enterprises to deploy new solutions much more quickly, at a much lower cost and more reliably.
DW: Can an autonomic computing system be a proprietary system?
TS: Right from the outset, the concept of autonomic computing proposed by Paul Horn, the head of IBM's research organization, recognized that in order for autonomic computing to be effective, it has to be applied across the entire infrastructure within an enterprise. And virtually every enterprise is made up of heterogeneous systems. Even when a single supplier or contractor sets up an enterprise's IT infrastructure, pieces of that infrastructure come from a variety of suppliers, and each one of the suppliers has their own unique way of managing their pieces. If the pieces are not able to be managed in a centralized way, then the notion of self-managing systems just falls apart.
|
Paul Horn on autonomic computing
As senior vice-president and director of IBM Research (with 3,000 researchers at eight labs), Dr. Paul M. Horn has overseen such technological breakthroughs as supercomputer Deep Blue, the first-ever copper chip, the giant magneto-resistive head, and strained silicon microchip technology. One of his current focuses is to facilitate the ongoing challenge for the IT industry to craft autonomic computing systems. In Autonomic Computing: IBM's Perspective on the State of Information Technology, Horn presents a vision of autonomic computing that cites:
...the difficulty of managing today's computing systems goes well beyond the administration of individual software environments. The need to integrate several heterogeneous environments into corporate-wide computing systems, and to extend that beyond company boundaries into the Internet, introduces new levels of complexity. . . . As systems become more interconnected and diverse, architects are less able to anticipate and design interactions among components, . . . Soon systems will become too massive and complex for even the most skilled system integrators to install, configure, optimize, maintain, and merge. . . . The only option remaining is autonomic computing -- computing systems that can manage themselves given high-level objectives from administrators.
|
|
The fact that the IT world is heterogeneous implies or essentially establishes that the interfaces and means to manage individual components need to rely on open, standardized interfaces. Of course, there are a lot of different ways to achieve standardization.
DW: What are the different ways to go about standardizing autonomic computing?
TS: Typically, when people talk about standardization, they think in terms of formal, standards-accredited bodies like IEEE, ANSI, or ISO. While these do, in fact, serve very important roles for standardization, they are not the only means for standardization. Basically, a standard is one in which the majority of the participants in the industry, in whatever industry we're talking about, agree to use a single common form for communication or interaction between the various components within the industry so that standards are useful when the majority of the participants within the industry recognize the single form. It doesn't require a fully accredited standards body to do that.
An example of that is the Windows® operating system. That is not standardized by any organization other than a single company that produces that platform. It is fact that the industry has chosen to use this platform and it has become a very pervasive operating system, especially for client devices. As such, it is a standard.
Linux is another example. There is no accrediting body for standardization. There is a single organization that holds the right to use the term Linux and they, in turn, bless Linux implementations by reviewing them. So there is a Linux standard, if you will.
DW: This would be the alliance approach to standardization?
TS: Basically, the different types of standardization that exist are de jure, that's Latin for "by right," which is how accredited standards bodies are described; the world recognizes that that particular body has the right to establish standards in a particular area. ANSI, IEEE, ISO are all de jure standards organizations.
The other general type of standardization is de facto and that is the case where it is a standard by fact. There may not be an accredited body that produces this standard, but a significant percentage of the participants in this industry use that particular implementation. The fact is that if everyone uses it, it is a de facto standard.
There are many ways of creating de facto standards. One example I gave earlier is a single company producing a popular product; everybody uses it and therefore it becomes a standard. The IBM PC was a product of that sort; there was no standards organization that established it. IBM produced a platform that was very successful and they published the interfaces so that many companies could participate in creating PC-related products and, as a result, it became a standard. Parts of that have subsequently become formalized in standards organizations like IEEE, but the fact of the matter is that it started out from a single company.
If we carry this one example further, with the second generation of the IBM personal computer interfaces, it was recognized that it was important to standardize these quickly. Consequently, an alliance or consortium of companies was formed, called the PC Interconnect Special Interest Group (or PCI SIG), and that became an industry-recognized body that was responsible for formalizing the specifications for the PCI Bus. That's how the standards that exist today were formalized. It's not an accredited body, but it is recognized for formalizing that aspect.
Another more current example would be the Storage Area Networking Industry Association (SNIA). It is responsible for developing specifications for interoperability of storage-area networking devices and is recognized by the rest of the industry as the authoritative source for specifications related to Storage Area Networking.
DW: And the Global Grid Forum?
TS: The Global Grid Forum (GGF) is another consortium and is focused on grid technology. It started out as more of an academic consortium, but as that technology matured and became promising from a business perspective, it gained focus from companies that are predominantly interested in developing products for businesses using those grid technologies.
GGF is interesting because its processes tend to be less formal, which allows it to develop specifications quickly; but, it generally lacks the rigor of some of the other formalized standards bodies. What we tend to see, then, is that specifications that are developed by GGF, as they mature and become useful, are evolved into other specifications that are formalized elsewhere.
A good example is the OGSI, the Open Grid Services Infrastructure developed by the GGF; it was useful but wasn't as scalable as was needed by business-critical applications, so a lot of work was done by IBM and other companies to develop those specifications into a more rigorous set of specifications. As a result, a number of work groups and technical committees were formed in OASIS to standardize things like WS-Resource Framework, WS-Notification -- those are then going to become the basis for future grid systems.
DW: What existing standards fit into your current strategy?
TS: The organizations we work most closely with are the DMTF, the Distributed Management Task Force, which is an industry consortium related to the basic management capabilities of resources; and OASIS, where a significant percentage of Web services standardization is taking place. We do a lot of work with OASIS.
The organization we work with that is responsible for the formal specifications for a lot of Web services and Services Oriented Architecture (SOA) technologies is the World Wide Web Consortium (W3C).
Those three organizations are probably the most predominant ones we work with; and of course, you mentioned GGF, which is also significant mainly because it is a proving ground for grid, a technology that is going to be the basis for utility computing and is key to our on demand strategy.
DW: You mentioned Web services. Is that a new focus for standards? What areas does that include?
TS: New, well . . . .
DW: I guess that needs to be in some kind of timeline context?
TS: I have a long timeframe orientation -- people with a short timeframe orientation would say that Web Services have been around for years. Probably three years. [Laughs.] To talk about standards, generally you measure time in glacial terms.
DW: And that's probably relative too.
TS: It is particularly interesting working in this area because I've worked with standards for a number of years. When people in our organization who haven't worked with standards say "We've submitted a specification to a standards body. Does that mean we can start using it?" I say, "No, we'll probably see it as a standard in about two years."
A good example of this is the Web Services Distributed Management Technical Committee (WSDM TC) of OASIS. The committee draft was recently completed and is out for member review. This work started in Spring 2003. And this was one we thought would go very quickly.
We're just now kicking off a new work group within OASIS that is probably going to start within the next couple of months. If we're very good, we should be able to get something done in nine months. My experience is that it generally takes much longer than that.
DW: Like a year and a half to get something like that started?
TS: Yes.
DW: What other things has your group been instrumental in kicking off recently?
|
WSDM Technical Committee
The Web Services Distributed Management Technical Committee of OASIS (Organization for the Advancement of Structured Information Standards) is defining two sets of specifications:
- Management Using Web Services, or MUWS, Version 1.0 defines how to represent and access the manageability interfaces of resources as Web services, forming the foundation of enabling management applications to be built using Web services and allows resources to be managed by many managers with one set of instrumentation.
- Management Of Web Services, or MOWS, Version 1.0 defines the manageability model for managing Web services as a resource and how to describe and access that manageability using MUWS.
|
|
TS: This past year we've been really focusing and spending a lot of effort on the WSDM Technical Committee and the reason for that is that, as I said earlier, a lot of the technologies that autonomic computing develops is basic plumbing, basic specifications for management of devices and once those are in place, we can start moving up the stack as it were. So managers for self-management can use those interfaces for the whole management problem. The work that was done in WSDM and recently published, while the specification that this committee drafted is two different specifications, the input that came from IBM actually corresponds to between 16 to 22 separate IBM internal specifications. So there's a lot of internal work that eventually, once it gets distilled, influences these various organizations and ends up becoming one or two or more externally published specifications.
We spent a lot of time and resources with WSDM because we knew that it was key for establishing a new way of providing management. And of course, because it is based on Web services, which is the future we're going to build on, that was a great place to establish a toehold.
There are other areas (specifically in DMTF) that we are focusing on now to establish management capabilities within various resources so they can be self managed. There are basic management capabilities within the devices, generally providing configuration updates and that sort of thing. Much of that is proprietary now and needs to be standardized.
We focused on WSDM in the middle of last year, and the autonomic computing group published a set of specifications related to solution installation; the ability to deploy software components that are made of a number of interrelated components but may need to be deployed not only on a single system but across a heterogeneous system. We did a lot of work, not only within IBM, but with our partners to develop a set of specifications that we finished last year and made publicly available on W3C. It's not a standard; it's a stake in the ground that says that these business partners have agreed to use this set of specifications and to provide these specifications to the industry on a royalty-free license basis. It's de facto in the sense that there are a number of companies using them and they are available to the industry, but it's not formalized enough to gain broad industry support. It is, however, enough to show the industry that it is an important piece of work, a good piece of work, and could form the basis for standardization.
DW: What's next?
TS: What we're doing next is, when we published the Solution Installation specifications last year, we made a call to the industry to form a work group to formalize this set of specifications (or to formalize a set of specifications that satisfy the same requirements). We've been working with a number of competitors and partners to kick off that work group. The key thing about this is that we're going to formalize a specification related to the deploying of software on multiple heterogeneous platforms and that specification is referenced in other works that are going on in the industry.
|
Installable Unit Deployment Descriptor, IUDD
The IUDD specification is designed to define the schema of an XML document describing the characteristics of an installable unit of software that are relevant for its deployment, configuration, and maintenance. IUDDs are intended to describe the aggregation of installable units at all levels of the software stack, including middleware products aggregated together into a platform; and user solutions composed of application-level artifacts that run on such a platform.
|
|
The work we're doing is called the Installable Unit Deployment Descriptor. It can form a basis that will be referenced in a number of works. For example, GGF has a committee doing some work called the Configuration Description, Deployment and Lifecycle Management, CDDLM, which included a specification for describing the software that gets deployed on a system. This completely overlaps the work we're doing. We worked with that technical committee to have them agree that they would take a look at refactoring their specification to reference that aspect, which is to be standardized in this new work group. So we get a lot more mileage out of a specification and almost immediately achieve broader acceptance by having this single specification. And there are other workgroups that can reference this same type of information.
DW: As a technology professional who is on the cutting edge of autonomic computing, what general advice would you give a developer who wants to understand the big picture and incorporate autonomic concepts into existing systems or into designs for new systems?
TS: I would say that the good thing about our organization is that IBM has recognized that there are many things you need to do to be successful in this business. One of the reasons IBM is so successful is that it is big enough that it can afford to do all the things that need to be done.
One of those things was to spend a lot of energy developing the Autonomic Computing Toolkit (see Resources) published on developerWorks and the corresponding Emerging Technology Toolkit published on alphaWorks. These toolkits are developed specifically to help developers jumpstart with the technology.
It's published specifically to say, "Look, we've developed some examples of how this technology could be used and we've provided some code to show you how to do it." At a minimum, developers have what they need to understand the technology and it may be enough to get them started on their products.
We have a very well-organized group in autonomic computing; it was recognized from the outset that we needed to have a tool group provide that toolkit for support. To me, that is key to the success of the standardization strategy because it's one thing to bring a specification to a work group, but it's something else entirely to go there and say, "I have this specification and I have working code that you can download."
DW: It's a "show me" sort of a thing.
TS: Right. In standardization, especially software standardization, working code is vital to the success of the effort.
DW: Before we wrap this up, could we talk a bit about how all this ties into the on demand effort?
TS: On demand is an IBM initiative. It is a view of how enterprises are going to be run in the future. In order to have an effective on demand environment, enterprises have to have the confidence that when they have the demand, they will have the reliable available IT resources to meet that demand. And they can't have an army of IT professionals checking each instance when they experience a demand surge. By definition, those on demand resources have to be self-managing and self-configuring. If a problem crops up, they have to recognize that and heal themselves.
Autonomic computing is one of those essential technologies that has to be in place to ensure the success of an on demand environment.
DW: Any final thoughts?
TS: I talked earlier about Paul Horn saying that open standards were important. Everyone nods their heads when you say something like this, but one thing that I have found, that surprised me in working with this group, is that this organization carries this message religiously. Everyone in this organization understands that the technologies we're developing can't be proprietary and have to be open. The process of developing the technology involves, right from the get-go, an understanding that this technology isn't something that we're going to keep inside, but is something we must propagate throughout the industry. This group has been the most supportive organization I've ever seen with respect to standards. They understand it is the key to success.
Resources - To read more technical documentation, how-to articles, education, downloads, and product information about autonomic computing, visit the developerWorks Autonomic computing zone.
- You can download the Autonomic Computing Toolkit to take advantage of the tools discussed in this article.
- Keep up with news, documentation, and downloads at the IBM Autonomic computing home page.
- For more on the WS-Resource Framework (which defines a family of specifications for accessing stateful resources using Web services), read Web Services Resource Framework (developerWorks, March 2004).
- Paul Horn presents his vision of autonomic computing in The Vision of Autonomic Computing.
- The articles An autonomic computing roadmap and Understand the autonomic manager concept (developerWorks, February 2004) provide information about self-CHOP.
- The Installable Unit Deployment Descriptor Specification, available at the W3C, is a specification designed to define the schema of an XML document describing the characteristics of an installable unit of software that are relevant for its deployment, configuration, and maintenance.
- To learn more about the challenges of working with next-generation autonomic computing systems, read Meet the experts: Ric Telford on the state of autonomic computing today (developerWorks, November 2004).
- Visit the WSDM Technical Committee at OASIS for a look at Web services distributed management standardization efforts.
- The Distributed Management Task Force directs the development of management standards and integration technology for enterprise and Internet environments, providing standards for common management infrastructure components for instrumentation, control, and communication in a platform-independent and technology neutral way.
About the author
Rate this page
| 
