http://www.microsoft.com/TechNet/technol/ole/prodfact/compnts.htm (PC Press Internet CD, 03/1996)
Posted Date: February 14, 1995
Gregory Leake
Product Manager, Microsoft Developer Relations
This article was reproduced from the November 1994 issue of the Microsoft Developer Network News, a publication of the Microsoft Developer Network.
The software industry has a tendency to get caught up in technical debates and complex language. In the process, software product discussions often fail to address the most important point of all-what are the benefits to customers?
This is exactly what has happened with object technology, a term that has been slapped onto every type of software product imaginable, from operating systems and word-processing applications to development tools. Thousands of applications and software development tools employ the term "object-oriented" in advertisements and packaging, not unlike the thousands of consumer products that overuse the words "healthy" and "green."
But the object experts have failed to address the most fundamental question: Why should users and developers care?
In many cases, products that claim to offer benefits because they are object-oriented simply don't. The proponents of object technology and object-oriented programming have not been able to present objective evidence that the technology itself-as opposed to products that claim to use it-provides tangible benefits to users or corporate developers implementing business rules for an application.
Corporate developers, after all, want to build custom applications that meet specific business requirements. They need to build these applications quickly and efficiently, and if a development tool meets this requirement, they really don't care whether it supports object capabilities. In fact, many probably find object-oriented programming (OOP) languages difficult to learn and even harder to integrate into existing business systems.
And users focus on the quality of their applications, and the extent to which these applications make them more productive and more resourceful employees. They don't care if their favorite applications are object-oriented or not.
But there is a new technology that focuses on direct and tangible customer benefits, and that has direct relevance for both users and corporate developers.
Although many refer to this technology as another form of object technology, it really isn't about objects at all. It concerns components. The technology is OLE, and it is about to transform the software industry into a component industry.
You may be wondering exactly why components matter if objects don't. First consider the basic differences between a component and an object. An object is a piece of software source code-or a specification that can be used to build part of an application. A component, on the other hand, is not merely a specification, it is an actual working software module.
An analogy is the difference between a stereo component, such as a tape deck, and an engineering specification for the tape deck. The specification contains complex information that is useful for engineers, but it is of little use for consumers trying to put together a home stereo system. The component itself, the tape deck, is very useful for consumers and can provide immediate value.
OLE and the underlying Component Object Model (COM) together represent a binary interface standard that allows software to be manufactured and sold as components. The time for such a technology has come, and the benefits are so extensive that it is hard to believe the technology is just now being incorporated into mainstream software.
To see what a binary interface standard for components can do for an industry, you need look no further than the hardware industry.
Like any manufacturing industry, computer vendors such as Compaq and IBM have a well-defined assembly process where they buy raw materials from many different vendors based on price and quality, and assemble these materials into innovative products called computers.
The raw materials they buy are components-individual parts of the computer such as disk drives, memory chips, CPUs, monitors, and keyboards. Because the industry has well-defined standards for the design of such components, computer manufacturers can buy, for example, video monitors from any vendor and know that the monitors will work with their computers.
This allows computer manufacturers to choose which monitor vendor will be their supplier based on the price and quality of the different vendors' monitors. It also makes it possible for the computer vendor to concentrate on building computers as opposed to building monitors or other components.
The existence of design and interface standards for components allows the computer hardware industry to adopt a structure of specialization-different vendors concentrate on building and selling specialized components in high volume. This not only enables less expensive and more efficient assembly of products, it also improves the quality of the end product.
Computer software, on the other hand, is currently made in exactly the opposite manner. Independent software vendors and corporate developers build monolithic applications consisting of many different modules and features that they themselves have designed and manufactured.
To understand where the software industry is today, imagine a computer hardware industry without the standards that define how hardware components fit and work together.
In such an environment, Compaq would build every single component for its computers, including disk drives, CPUs, memory chips, and even monitors. If Compaq wanted to get out of the video monitor business and concentrate on building other components, they could hire a contractor to design and build their monitors.
These monitors, however, would still be tied to their computers and would not work with any other type of computer. The monitor cables would be unique, the connectors would be unique, and in fact the very way the monitor exchanged data with the computer would be unique to the Compaq brand of computers.
Now imagine that a technology akin to object-oriented programming arrives for the manufacture of computer hardware. Using such an analogy, the OOP technology would allow Compaq to define the internal specifications for its monitor in a modular fashion. With such an engineering specification, it could then contract another company to make its monitors. This contractor would learn how to use the specification (defined in the OOP-style language) to build Compaq-compatible monitors.
Suppose, however, the contractor also wanted to build monitors for Toshiba. Toshiba, using the same OOP technology, could supply the monitor company with the engineering specifications for building a Toshiba-compatible monitor. Again, the specification would be defined in the OOP-style engineering language, and the monitor contractor, having already learned this specification language for Compaq monitors, would be able to start building Toshiba monitors.
But the monitor company would still have two completely incompatible specifications, and would have to set up two manufacturing lines to build these two types of monitors. Despite sharing a common specification language, the monitors would not share a common interface allowing for a mix and match of components. The cables would be different, the connectors would be different, and the way the monitors communicated with the computers would be different.
This analogy demonstrates that OOP falls significantly short of creating an efficient market where buyers and sellers can supply components that are guaranteed to work with each other.
The lack of interface standards within OOP languages prevents the creation of such a component market. The OOP languages have merely defined a way to specify internal engineering details for objects; they have not provided a standard way for the objects to connect. All OOP objects are dependent on the implementation of other components-they only connect to components with which they were specifically designed to work.
OOP languages are, in effect, just a different piece of machinery for producing software parts, but they say nothing about how these parts will interface with the outside world.
Now let's move beyond the computer hardware analogy and examine how OLE will actually bring the benefits of a component marketplace to the software industry.
OLE is a technology built on top of the Component Object Model, which allows independent software vendors to build specialized software components that interface in a common way with other software components. By using the standard OLE interfaces, software vendors can create their own innovative, unique, and value-added components that can plug into other vendors' components. The different software vendors don't even need to communicate with each other to exchange specifications or in any way coordinate the design and assembly of their specialized software components. They just need to build components that adhere to the OLE interface standards.
OLE is designed to enable the software industry to achieve a component market that provides higher rates of innovation, more specialized customer solutions, higher quality applications, and a faster, less expensive development process.
Instead of building all components of a custom solution from scratch, corporate developers can purchase software components from specialized component vendors. For instance, they might buy a financial analysis component or a charting component for use in a custom application. They can integrate these components into a custom application using a tool such as Visual Basic or any other Microsoft or third-party development environment supporting OLE component integration.
This allows corporate developers to deliver the application in much less time and at a greatly reduced cost. In the process, users of the application get a higher quality product because it incorporates best-of-breed components.
In addition, business applications assembled using OLE components are more flexible. Corporate developers constantly face the challenge of managing applications with very short life cycles. They often have to replace applications with completely new applications because the business requirements have changed.
With modular software applications built using OLE components, changing an application to meet new needs is easier because a new component from the same vendor can be purchased and plugged into the application to extend its functionality. Similarly, a component from a different vendor with new capabilities can be substituted for an older component. This makes system maintenance much easier and extends the life of the application.
OOP fails in all of these respects because it defines no standard interface for components-so a component built using an OOP language will not necessarily plug into other components, even if they are designed in the same OOP language!
All major Microsoft applications already support OLE. More than 300 other software vendors, including all of the largest vendors, have announced support for OLE. There are more than 400 shipping applications that support OLE-applications that users and management information systems (MIS) groups can purchase and plug together as if they were specifically designed for each other.
In addition, a new class of components is on the horizon. These components, called OLE Controls, aren't monolithic applications such as spreadsheets and word processors, but instead are smaller components geared to meet specialized needs.
These will include database query components, mainframe connectivity components, messaging components, imaging components, and just about any other type of software component that might prove useful to users and corporate MIS. (For more information, see the following articles in the Developer Network News: "OLE Comes to Custom Controls" by Solveig Whittle, May 1994; "Converting VBX Controls to OLE Custom Controls" by Erick Smith, July 1994; and "OLE Controls to Ease 32-Bit Migration" by Dale Rogerson, September 1994.)
OLE Controls are written to the OLE standard. They will be able to plug into any OLE-enabled application, or can be used within any OLE-enabled development tool. OLE Controls and other OLE-enabled software components will allow corporate developers to build custom business applications using their choice of high-quality, prefabricated components.
With the introduction of OLE, the age of component software is just beginning.
Gregory Leake is a product manager in the Developer Relations group at Microsoft.
Go To TechNet Home Page 
Go To Microsoft Home Page