t effort was too successful, cr
eating the false impression that OLE was designed solely for Office.
In fact, OLE is also a standard for communication between applications from different vendors. But during our informal testing of OLE features in several applications, we found that intra-Office OLE works better than cross-application OLE. The lesson is that, as with most standards, vendors may claim OLE 2 capabilities without having
all
the specified features.
Inside the Component Object Model
The underlying object standard of OLE is COM, which defines a language-independent binary interface for objects that allows them to behave in consistent ways. COM also handles all the communications between components. While COM can be used by itself for custom development, it is more commonly the basis of an integrated OLE solution that uses a variety of OLE services.
In addition to the binary object specification itself, COM includes the following features:
COM functions
:
The COM function library provides a number of useful routines for software developers. In general, these functions begin with "Co" and have names like CoInitialize and CoCreateInstance.
Marshaling:
COM handles the process of packaging, sending, and unpackaging interface parameters across process, machine, and network boundaries. Marshaling and unmarshaling are basically synonyms for packaging and unpackaging. The actual transport mechanism is provided by the operating system itself and is not considered part of COM. Locally, COM uses a process called "lightweight" remote procedure calls (LRPCs); remotely, it uses the industry standard Distributed Computing Environment (DCE) RPC.
Structured storage:
COM provides a full-featured system for handling storage and stream objects in a robust, persistent, hierarchical manner. In general, a single structured storage object is like an entire disk volume: It has something that maps out the contents (like a file
allocation table), one or more storage objects (analogous to root directories and subdirectories), and one or more stream objects (similar to files in directories). Structured storage objects can be aggregated and nested, and they can exist inside a disk file, in memory, or even as database records.
In addition to these file system-like features, structured storage also provides complete transaction processing that you can use, for example, to implement Undo operations. OLE also provides a default implementation of structured storage called compound files, from which OLE compound documents are derived.
The flexibility of COM structured storage is helpful in enabling legacy applications with OLE; they often have proprietary storage models that can be difficult to reimplement. Structured storage also offers a major improvement over dealing with file systems directly, particularly when multiplatform solutions are required. While COM structured storage is fundamental when implementing OLE servers, i
t can also handle custom storage needs.
Monikers:
As the word implies, a moniker is a name for a specific COM object. Like a fully qualified filename, which includes drive and path information, a moniker contains information about an object as well as the instructions for connecting to it. Monikers can be serialized into stream objects. This consistent access mechanism allows applications to automate connections to objects. COM provides built-in implementations for File, Item, and Composite monikers and allows developers to easily create their own implementations. One example is the new URL moniker, which holds a uniform resource locator that allows client applications to access server resources on the Internet using a variety of protocols.
Uniform data transfer:
Uniform data transfer (UDT) is an important mechanism in any component-based software. COM insures that OLE services using the clipboard, performing drag-and-drop operations, and doing OLE automation al
l use compatible data formats.
Version management:
Using a COM interface creates a contract between the object provider and consumer. It's important that this contract not be broken as objects evolve. COM interface version management allows adding services to objects without breaking existing applications.
On to OLE
OLE is a set of object services built on top of COM. The first service distributed by Microsoft was OLE documents. Microsoft heavily marketed this service to end users, and it's what most people still think of when they hear the term OLE.
The next OLE technology was OLE automation, initially useful only from Visual Basic. Next was OLE controls--internally, a hybrid of OLE documents and OLE automation. Now we have general-purpose, industry-specific, and even Internet-related services, as follows:
OLE documents:
OLE documents (sometimes called OLE compound documents) are a form of compound document that incorporate data
created in any OLE-enabled application. The most common example is probably an Excel spreadsheet object embedded in a Word document, but a virtually unlimited number of scenarios is possible. Several OLE subservices are at work here: the object linking and embedding itself (from which OLE originally got its name but which is now a historical footnote); use of property sets within the compound documents; and the ability to edit the objects in-place. Yet another service, drag-and-drop, originated with OLE documents but has recently been extended to places like the new Windows shell, so it's better to think of drag-and-drop as a separate OLE service.
Application programs that create compound documents are called
OLE containers
and applications that furnish objects are called
OLE servers
. It's possible for an application to be both an OLE container and an OLE server, which is the case with both Microsoft Word and Excel.
Linking and embedding:
In addition to static informat
ion like the worksheet mentioned earlier, OLE documents can also incorporate live elements such as multimedia and external services (stock market and sports information feeds, for example). If an object is linked, it still resides outside the compound document, typically on a server where multiple users have access to a single version. What's more, when you update the source object, documents that include links back to the source are automatically updated, too.
Embedded objects are contained within and actually travel with the compound document. The data in such objects becomes part of the container program's data file. The original data file becomes irrelevant.
Linking and embedding
also lets you convert the same object to different types. This means multiple applications can work with the same object, so it isn't necessary for all users to have the same OLE server.
Property sets:
OLE documents define an extension to structured storage that provides a metho
d for storing information about objects; this information can be distinct from the objects themselves. Property sets are extensible but in general have a defined data structure, a common format, a defined header, and built-in support for localized dictionaries. The only predefined property set is Document Summary Information, which contains relatively static attributes like author, subject, and date of creation, as well as dynamic attributes like word and page count. All major Microsoft applications of the past several years have provided this information. You can access it from the Summary Information selection on the File menu in Windows 3.1 or from the Summary tab of the document's Properties page in the new Windows shell. If you use this summary information, you may have also noticed that support for the Document Summary Information property set is integrated into the new Windows shell: From the shell, select a document and choose Properties from the context menu; you'll see additional Summary and Statist
ics tabs that aren't provided for other file types such as .TXT files.
Visual editing:
Also called in-place activation, visual editing is the name for the process of editing a server object inside an OLE container. It includes support for what amounts to bringing up the server application inside the container. To do this, it's necessary to merge the menus of the two applications, display the OLE server's docked or floating toolbars, handle keyboard integration for hot keys and accelerators, and provide for frame adornments--for example, the top and left rulers used in most drawing applications--where applicable. This lets you remain in a familiar host application without having to activate and switch to another application.
OLE automation:
While OLE documents are primarily about user involvement, OLE automation is all done under the hood. Controlling applications work with objects and with associated commands that are exposed by server applications. With automation, OLE
's original linking-and-embedding paradigm starts to get lost: While a controller may obtain a pointer to an object in a server, it does so merely to get and set the server's properties and methods and not to create a persistent storage object.
It's possible to serve any object that can be created in code: result sets returned from database queries, real-time data, or--perhaps more powerfully--internally developed business objects for things like orders and invoices.
OLE controls:
An important type of OLE automation object capable of reacting to external events, OLE controls work in many recent 32-bit Windows development tools. They are also part of Microsoft's plans for the Windows user interface: The next version of the Internet Explorer will be able to host OLE controls for creating Windows-based Internet applications.
Internally, OLE controls are compound document objects that are controlled via OLE automation objects. They combine the features of both major OLE servi
ces (though this is mostly transparent to users).
OLE drag-and-drop:
Available in both OLE documents and OLE controls, drag-and-drop is now also a key function in the Windows 95 user interface. Essentially, it is another OLE service. So far, Microsoft has defined three types:
Inter-window:
Lets you drag objects from one application window and drop them into another--one way of embedding an object using OLE documents.
Inter-object:
Lets you drag objects and drop them inside other objects.
Dropping onto icons:
Lets you drag objects in the Win 95 desktop and drop them onto resource icons such as printers and mailboxes. Some new OLE controls, like the RichText control that ships with 32-bit versions of Windows, support drag-and-drop operations on the desktop.
Industry solutions:
Microsoft sells vertical-market OLE services. These have been codeveloped with leading companies in specific industries. These industry standa
rds make it possible to create reusable Line-Of-Business objects (LOBjects). So far, Microsoft has released specifications for the following industries:
-- WOSA/XRT (extensions for real-time market data)
-- OLE for Health Care
-- OLE for Insurance
-- OLE for Retail/POS
-- OLE for Design and Modeling
Other OLE services:
In addition to industry-specific services, Microsoft has provided specifications for more general-purpose OLE transactions. Microsoft's own products are starting to incorporate these specifications. SQL Server 6.0, for example, uses OLE database technology, which is sometimes called SQL OLE. Similarly, OLE messaging is a key component in Microsoft's new Exchange mail server.
Microsoft will soon incorporate Network OLE into its 32-bit OSes. Network OLE is an extension of COM that uses remote procedure calls; this will mostly be transparent to OLE-enabled applications, which will get this new capability for free without having to m
ake any changes. (For the latest on Network OLE, go to the
FTP site
.)
OK, Everybody, on Four
Application developers' support for OLE has varied by industry. The first non-Microsoft vendors to get on the bandwagon were graphics vendors. Corel's flagship CorelDraw, for example, has been an OLE document container for several releases. Visio Inc.'s Visio, a technical drawing program, was another early OLE document container and server. Ironically, Visio was also the first shipping OLE automation server, beating Microsoft's Office applications by several months and actually doing a better job of providing a useful object model to developers.
For many software vendors, OLE's complexity was daunting at first. It wasn't until Microsoft encapsulated high-level support for OLE in Visual Basic, and in the Microsoft Foundation Classes (MFC) class library that ships with Microsoft Visual C++, that many companies were willing to integrate OLE services into their applications
. Companies that sell development tools--compilers, class libraries, and so on--have had a more difficult time because they often must implement OLE support from scratch.
Thus, you can't always tell what being OLE-enabled means. When a product is labeled "Supports OLE," it may be an OLE document container or, more commonly, a server. It likely doesn't support OLE automation. Win32 applications are generally more predictable, however, due to Microsoft's requirement that an application include specific OLE functions in order to earn the Windows 95 logo. The sidebar
"The OLE Experience"
offers hands-on examples of the kinds of inconsistencies that may await a typical user of OLE-enabled applications.
Clearly, software vendors continue to add support for OLE. But they're doing it in inconsistent ways, preventing true integration and communication from becoming a reality.
WHERE TO FIND
Lotus Development Corp.
Cambridge, MA
Phone: (800) 343-5414 or (617) 577-8500
Fax: (617) 693-3512
Internet:
http://www.lotus.com
OLE's Missing Links
