Oils of OLE

ENT, August 20, 1997 by Eric Anderson

If you've delayed getting your hands into OLE for any of the following reasons -- "It's too complicated," "It's slow and bloated," "It runs only on Wintel platforms," or "I don't need to embed my objects into anyone else's objects" -- you'd better refresh your excuses list: None of these holds water anymore. If your excuse has been that your components need to work across the network, Distributed Component Object Model (DCOM), available for Windows NT and Windows 95, provides the solution.

Over the past month, I've had a chance to use the OLE features of the latest crop of RAD tools, including Visual Basic V5.0 from Microsoft Corp. and Delphi V3.0 from Borland Int'l Inc. (Scotts Valley, Calif.). To make things more interesting, I've also spent time testing DCOM on both Windows NT and Windows 95. The transparent use of OLE across the wire, combined with much better OLE development tools, takes OLE from the cabalistic realm of component creators and makes it a must-know technology for any Win32 programmer.

Personally, I never had much interest in OLE, because I don't spend a lot of time developing shrink-wrap software packages or general-purpose ActiveX controls. To me, OLE was for embedding third-party elements into a word processor or spreadsheet. While OLE was originally an acronym for Object Linking and Embedding, it is now simply a name for all of the technologies based on Microsoft's COM standard. In addition to the places where OLE is obviously warranted, OLE/COM can and should be used anywhere you've used a DLL function library in the past.

Can you imagine creating a robust product using a thousand development teams working in a thousand different locations, with no direct communication between the teams? How about if each team releases new versions of its portion of the product without consulting any other team? "Impossible," you say -- to which I say, "Microsoft Word." Sure, the whole core Word team works for Microsoft, but what about Visio, CorelDraw, the CASE tool you're using, the macro language you bought, and all those neat Word add-ons you've downloaded. They all are released and updated separately from Word, with nary a call to Redmond. And (for the most part) everything keeps on working.

In fact, Microsoft developed OLE partially to solve its own component distribution and versioning issues, and we simply get the benefits of Microsoft's work. While using COM may seem like overkill for the first iteration of a product, COM may keep developers from killing each other by the third release. COM gracefully allows multiple versions of object interfaces to exist, without requiring any changes to existing programs. It is perfectly acceptable for different programs to use different interface versions for the same component. When you compare COM to industry-darling Java on the crucial and often overlooked issue of component versioning, it is clear which technology is mature.

Maybe you're realizing that OLE may be important even if you are not developing Word plug-ins. Let's take a careful look at the other common myths about OLE.

* OLE is too complicated. COM isn't rocket science, but great tools make a major difference. As an relative OLE novice, I was able to create a DCOM database application that ran across the network on machines that didn't have database access. Time: One day of reading (on COM concepts and Delphi's COM encapsulation) and 30 minutes of coding using Delphi V3.0.

* OLE is slow and bloated. Well, OLE does include a lot of services for free, and it's true that the OLE implementation of Microsoft Foundation Classes (MFC) has significant overhead. The binary COM standard, however, has as little overhead as necessary to perform its function. MFC simply offers one implementation of OLE services; Microsoft's Active Template Library and Borland's Delphi V3.0 offer tighter implementations.

* COM runs only on Wintel platforms. Even this refrain is becoming less true all the time. DCOM has been ported to the Mac, Digital is porting COM to UNIX, and the Object Management Group is creating a specification for CORBA-COM interaction.

* OLE is a local technology. DCOM, formerly Network OLE, is here and it works. Once you've written a COM object, you may enable access to the object from the entire networked universe with a few mouse clicks. Microsoft Transaction Server adds control, robust transactions, and scalability for your OLE object servers.

If your interest in OLE/COM has been piqued, I highly recommend you read the compelling article "What OLE Is Really About," available on Microsoft's Web

site, by OLE team member Kraig Brockschmidt, the author of Inside OLE 2.

The article is the clearest and most complete summary of OLE technologies you'll find. Brockschmidt seems to believe that Microsoft developed OLE as a gift to the development community to engender competition and to keep Microsoft from driving the industry. Brockschmidt must have sold some snake oil in his day, though, because I came away convinced.