Columns

Consuming components

• By John D. Williams
• January 1, 1900

In August, I was at the TOOLS USA 2000 conference where I spent a lot of time asking people what they needed to help them consume a purchased component. The answers were as varied as the developers who gave them. Everyone had their own opinion about what documentation they'd like to see. However, there were some common themes. The first had to do with what you need to make an intelligent purchasing decision. Others hotly debated the value and need for certification of components. Finally, the question of choice was raised as a key issue for the component marketplace.

What do you believe you need to make an intelligent decision in purchasing a component? The answer varies with the complexity of the component you are purchasing. What is needed to understand and use a GUI component is not identical to what is needed to understand a complex business framework. In past columns, I've used a simple, three-level scheme to categorize components: GUI, infrastructure and domain. While one could use a more complex framework, this one will do for this discussion. As we go through the things you might want to come with a component, consider their appropriateness for the different levels of components.

One of the first responses to my original question was a declaration that use cases were absolutely essential documentation for a component. Let me note that the respondent spent his time surveying domain components and frameworks. Others suggested that components should come with all types of UML models to help users understand the components' organization and function. This makes a lot of sense for domain-level components. It may also be very appropriate for infrastructure components. However, it is unlikely that anyone using a GUI component would bother to look at UML. They don't today, and they likely won't in the future.

Most developers want better documentation. Some want online documentation, while others want embedded documentation. The real question, though, is: What needs to be documented? One suggestion was layered documentation for APIs, which provides a high-level view of an API and the ability to peel back that layer to reveal slightly more detailed information and, at the lowest layer, provides complete API information. This helps developers understand a component quickly and reveals detailed information only as needed, to help assess a component's ability to meet requirements.

Others suggested that the documentation include throughput and performance information, such as CPU and memory requirements as well as resource usage. This may be difficult to provide in any meaningful way without a reference platform, particularly for characterizing components that can be deployed on multiple platforms. Often, this becomes a true systems engineering issue. For suppliers of components, this could present legal landmines. What if a customer expects you to guarantee the performance of your component? Can that actually be done? On the other hand, the performance of a component may be a key factor in its selection.

Everyone agreed it is important for components to be explicitly clear about their dependencies. You expect to find this type of information for domain and infrastructure components, since they can often be found as parts of an application framework. Unfortunately, vendors have not always made dependencies clear. I remember using a C++ library years ago and being unpleasantly surprised when my attempt to include one object from the library unexpectedly loaded in almost all the rest of the library just so one object could work.

There was also a debate over the need for tests or examples. Some developers thought that numerous working examples done across multiple domains were far more useful than any structured tests. I sympathize with this point of view. Like many developers, I've learned a lot about writing code by reading the code of others. Working examples provide clear guidance on how to use a component and to provide the developer with confidence in the component. On the other hand, structured tests with data and test harnesses can provide a rigor for validating a component that you can't get from examples alone. Examples aren't exhaustive and aren't intended to be. Testing can tell you more about the characteristics of a component and its appropriateness for reuse.

Numerous developers expressed interest in seeing interface contracts specified. The idea is that contracts will clearly define what an interface does. For example, you can specify pre- and post-conditions. Interface contracts help components be well-behaved and minimize problems caused by unexpected behavior. Other developers were simply looking for consistency in interfaces. For example, did the vendor mix add and insert, or did they consistently use one or the other? Consistency in terms, naming and style were all considered hallmarks of well-written code. Let me suggest that most developers would really like to have both. They are not mutually exclusive.

Some developers were interested in the number of versions of a component that were available. For example, all liked the idea of a free evaluation copy. They also felt that it was helpful to have versions that may differ in number of features or performance characteristics. This segmentation allowed them to select a component of the appropriate price/performance type for their need.

One area of consternation for developers was the subject of categories. How do you categorize a component so that developers can find it? This is not simple. Developers may describe a problem in different ways, or they may discover a use for a component that was not envisioned by the vendor. Making the connection between the vendor's and developer's perceptions is a real challenge. Furthermore, the answer to a developer's need might actually be a set of components. How do you create categories that allow you to find the set of components that solves a particular problem? It is not clear if there is any single taxonomy scheme that will answer all these needs. More work needs to be done in this area.

Certification of components is a subject that stirs a lot of debate. Is certification really needed or desired? Many large IT shops say yes. They want standards that guarantee the quality of what they buy. However, Sam Patterson, president of Component Source, points out that "certification is not equal to quality." Something could be certified to conform to certain specifications and still be poorly constructed. Have you ever seen Windows 98 certified software that crashes? Do you know a homeowner whose home passed building codes, but still has severe problems? "What developers want is a good experience,"said Patterson. They don't want a component to mess up their development environment when they load it in. If they decide to uninstall the component, it should behave and not trash the system. Standards are helpful, but what companies really want are standards from firms that define a systems base architecture. For example, this means companies such as Microsoft and Sun need to be the ones that define standards that support interoperability. They can shape what it means to be a well-behaved component.

Finally, the need for more choice in components was raised as an important issue. Developers want variety when selecting components. For the component market, this is an issue of critical mass. How many components are needed to fuel the rapid growth of components? According to Component Source's Patterson, the market needs to reach 20,000 to 40,000 components to achieve critical mass. Today there are about 4,000 components available in the market. In general, the number of components available for sale is doubling every year. However, the number of EJB components has begun to triple during the past few months. At the current rate, we may achieve critical mass by 2003.

So what does all this mean? What is necessary to make a component truly consumable? "The component that makes it easiest to use wins," said Ron Schultz, senior VP of technology and architecture at Check Solutions. I think he is right. Visual Basic took off as a development environment because it made development easier than it had been. Components that are easy to consume will get used. Those that make a developer's life difficult will have a much harder time in the marketplace. What do you want to see in the components you buy?