Microsoft's launch of OLE 2.0 could change the way we work with software. The vision promised by OLE 2.0 is one of many vendors delivering small, functional software components to create an integrated, customized environment for the user. In a way, application suites fly in the face of this vision. They are, after all, a return to the monolithic approach: one vendor supplying a set of huge, multifeatured applications. It's reminiscent of the way software was sold when mainframes and minicomputers were king.
Clearly, major vendors are now committed to OLE 2.0 as a mechanism to more tightly integrate their application bundles. Therefore, OLE 2.0 may fuel, somewhat ironically, the phenomenal success of office suites, rekindling the notion of a monolithic model of software development.
Using classic object-oriented programming met
hodology, OLE 2.0-aware applications can browse each other to discover usable objects. Instead of launching an entire application ˆ la OLE 1.0, you can work with an application's component parts. OLE 2.0 could call up your spreadsheet's @function engine from within your word processor, for example, to sum a table's rows of numeric information.
Office bundles can use this same approach to streamline the software architecture and make the bundled applications interact more efficiently. For instance, applications in Microsoft Office share a spelling checker, conversion filters, a graphing component, an organizational chart tool, an equation editor, and Microsoft Query.
Microsoft plans to implement OLE 2.0 on three platforms: Windows 3.1, Windows NT, and the Macintosh. In a networked environment, this would allow you to build custom networked applications, using local software components when necessary and perhaps even sharing components across the network and across platforms.
At some point,
you'll probably buy and build software the same way that an audiophile today puts together a home entertainment system--by mixing and matching the very best interconnectable components from a variety of suppliers. You would lay the foundation by buying your favorite bare-bones text, table, and graphics editors (which may be offered as a bundle with your PC's operating system/graphical desktop).
You would then add some separately purchased tools. You'd probably begin with a spelling checker and a thesaurus, an E-mail module, and perhaps other specialized tools, such as a text searcher/file indexer, a sound and video annotator, and a speech-recognition module.
Those who build in-house corporate systems will follow a similar paradigm, using network- and OLE 2.0-aware tools tied together with a global scripting language. Each of the pieces will work smoothly with the others and will be provided, presumably, by a teeming third-party component market.
The healthy component market for Visual Ba
sic is a case in point. Small developers are busily creating custom controls for adding specific functionality--such as image management or telephony features--to a mainstream programming environment. Visual Basic provides a set of generic capabilities, and third parties are filling the gaps in creative ways.
But, given the marketing muscle of major Windows vendors and the runaway success of single-vendor office bundles, is this vision of component software viable? Customers will probably feel more comfortable turning to an established vendor and buying all the pieces as an integrated whole. Customers don't care about the state of the market; they want software that works. One vendor providing all the components can ensure that the entire process comes together without incompatibilities and unforeseen glitches.
The future of OLE 2.0 is quite interesting to contemplate. We'll soon see whether OLE democratizes the software industry by encouraging the development of specialized software components,
or if--in the ongoing battle of feature one-upmanship--powerful vendors provide most of the major tools themselves and tie them all together into application bundles. A new architecture, perhaps, but monolithic software just the same.