Columns

Taking Stock of Component Technology
David Chappell - June 1999

COM is arguably the most widely used, most complete component technology in the world today. For the last several years, both COM and Distributed COM have been included in every Microsoft operating system shipped. In other words, COM and DCOM have been ubiquitously available for some time. Thousands of smart developers and architects have had time to understand and apply these technologies in a large number of projects. Other technologies such as CORBA and various Java-based options are also in use today.

It's time to take stock. Component supporters (like me) have talked endlessly about their potential benefits, but the rubber has met the road and the skid marks are visible. What has actually happened? What are components good for? And which of their promised benefits have turned out to be unattainable?

What Components Are Good For

I'd argue that the most important benefit we' ve received from component technology is the discipline of modularity it imposes. By allowing (and sometimes even forcing) designers and developers to create impassable interfaces between distinct chunks of functionality, COM and other component technologies make for better, more reliable code. This enforced modularity is also among the chief benefits of conventional object technology, and so it shouldn't be surprising that it has turned out to be so important for components, too.

Because they're so strongly interface oriented, component technologies also allow building wrappers around existing applications. It's probably fair to say that CORBA-based products have been used for this more than COM, although both technologies allow it. The reason for this disparity is that CORBA-based products are available on a much broader range of operating systems than COM and DCOM, which remain mostly locked into Windows and Windows NT. Given that the majority of legacy applications run on non-Microsoft operating systems, it's not surprising that COM isn't too popular as a wrapper technology. Still, being able to wrap and effectively access existing apps is a useful thing, and component technologies have proven quite successful at doing it.

While COM isn't widely used to wrap legacy applications, it has proven very useful for exposing the services of newly built apps. This is usually done through what Microsoft confusingly calls Automation, but it's really just COM. Because they offer this ability, the great majority of desktop apps today can be treated as "components". On Microsoft platforms, exposing services via COM interfaces has become the standard for new applications, something that's unquestionably a good thing.

And just as COM has been used for exposing an application's services, it's also proven useful for defining new application programming interfaces. Microsoft now defines most new Windows and Windows NT APIs using COM. Perhaps the most important recent example is ActiveX Data Objects (ADO), the successor to the aging ODBC API. Over time, it's possible that the dominant means for accessing the services provided by Microsoft operating systems will be through COM.

Finally, as with object technology before it, components have been heralded as a way to provide code reuse. One component technology, COM-based ActiveX controls, has proven very successful for low-level, client-side code reuse, especially for things such as GUI elements. There's a large third-party market in ActiveX controls today, the providers of which seem to keep Visual Basic magazines afloat with their advertising. Many, perhaps most, VB developers building client-side code rely on COM-based components for at least part of their application. Given the number of VB developers in the world today, this makes ActiveX controls almost certainly the largest example of component-based code reuse in our industry.

What Components Can't Do (So Far)

Despite these successes, there's no way around the fact that components haven't lived up to their promise in every area. The biggest and most painful failure has been that large-scale reuse of business logic on either clients or servers hasn't materialized. ActiveX controls are very popular for encapsulating some things, but reusable business functions aren't one of them. While component technologies such as COM and the more recent Enterprise JavaBeans (EJB) provide sufficient packaging to allow this, no real market has emerged.

Why is this? The most obvious explanation is that it's just too difficult to create truly reusable business logic. Building a generalized component is significantly harder than building one focused on a particular application, and guessing what features will be needed in the future is inherently problematic. Even worse, business requirements change so quickly that even a well-designed component can find itself overtaken by events. And finally, there are the well-known difficulties in changing the behavior of developers and their managers, difficulties that have sometimes proven insurmountable.

As a result, there' s essentially no third-party market for server-side business components, something that's very disappointing to long-time component boosters like me. The EJB crowd is still hoping to bring about this market in the Java world, but I'm skeptical of their chances. Why would independent software vendors who wouldn't build COM-based components flock to EJB as a foundation? COM and the COM-based Microsoft Transaction Server (MTS) have shipped with every copy of Windows NT for more than two years, while EJB has achieved nowhere near this level of market penetration. Furthermore, EJB isn't completely standard yet, so building truly portable components that will run on any vendor's implementation is challenging. If a market for reusable server-side business objects were possible today, that market would have emerged on Microsoft platforms. Even if software vendors do step up to the plate, however, the showstopping problem still seems to be the incredible difficulty of building truly reusable business logic.

One more broken promise is also worth mentioning here. Components were supposed to make development easier, yet all of this turned out to be more complicated than we expected. With COM, the tools have gotten steadily better, ameliorating some of the pain. And Java makes component development easier, too, regardless of the approach being used. But straight ahead component development with C++ is not for the faint of heart, whether COM or a CORBA-based product is used.

Looking Ahead

Component technology, specifically COM and DCOM, must be judged a success. Developing software in the Microsoft world today all but requires using COM in some way, a reality that shows no sign of wavering. And the changes it has brought are unquestionably progress.

Are the weaknesses of components, the promised benefits that haven't yet materialized, just temporary? I hope so, but my hope is based on emotion, not reason. While component development does get easier every day, the evidence so far leads me to doubt that we'll ever achieve large-scale reuse of business objects. The problem isn't fundamentally technical. We have the technology but rather a human problem rooted in the difficulty of both understanding what we need today and predicting what we'll need tomorrow.

Yet even though all the benefits of components haven't come to pass, they're still a crucial part of software's future. The reason for this is simple: enterprise software development is heading into a bifurcated world, where developers build new business logic either on Microsoft platforms or on the Java platform. Both of these approaches depend on components: COM and MTS in the Microsoft world, EJB and others in the Java world. Whether we like it or not, component technology will be with us for many years to come.