Distributed Objects (CORBA and OLE/ActiveX)

NEWS BLOGS FORUMS NEWSLETTERS RESEARCH EVENTS DIGITAL LIBRARY CAREERS

IMMERSE YOURSELF:

Storage & Servers

Distributed Objects (CORBA and OLE/ActiveX)
February 8, 1999

Compound-Document Middleware: OLE and OpenDoc

7.4 Compound Document Middleware: OLE
and OpenDoc

7.4.1 Overview

A compound document is essentially a container for data that comes from a variety of sources such as text editors, spreadsheets, graphics, multimedia information and other applications. The software tools that create different components of a compound document are referred to as applications. For example, consider a compound document that consists of Microsoft Word text, Lotus spreadsheets, and Powerpoint graphics. In this compound document, Microsoft Word, Lotus, and Powerpoint are all considered as applications. The objective of the compound-document standards and associated middleware is to provide seamless integration of a wide variety of objects to form a document. We will review two promising middleware products for compound documents: Object Linking and Embedding (OLE) from Microsoft and OpenDoc from Components Integration Laboratories (CI Labs).

7.4.2 Microsoft’s Object Linking and Embedding (OLE)

Microsoft introduced Object Linking and Embedding (OLE) technology in 1990 as its basic strategy for integrating multimedia data types with multiple applications for compound documents. Basically, OLE allows objects from one application to be included in another application. The objects can be graphs, drawings, pictures, tables, spreadsheets, text, selected cells of a spreadsheet, sound bites, video segments, and anything else that can be controlled or displayed by an application. Instead of access to the structured data stored in databases, OLE is suited for access to the unstructured data located in documents or other "flat" files. For example, OLE can be used to access a segment of a video application from a Visual Basic application, and then display the video segment based on the Visual Basic application.

OLE allows access to objects from other applications in two manners:

l Object linking. A placeholder (link) of the needed object is placed in the container application. The actual object is not copied. The linked object is accessed at run time, thus the latest value of the object is retrieved. An object can be linked into many applications simultaneously. For example, let us assume that a greeting sound object is linked into several Visual Basic applications that play the greeting message whenever a user logs on to any of these applications. The greeting message is modified for holidays and/or emergencies. The appropriate greeting message will be played whenever any of these applications run.

Message Broker: Another Kind of Broker

A broker mediates between clients and servers (i.e., instead of a client directly connecting to a server, it first connects to a broker that in turn finds a suitable server). The concept of a broker is independent of the implementation of the broker. For example, the best-known implementation of the broker architecture is the object- request broker (ORB) as presented in OMG CORBA specification. In CORBA, the ORB mediates the interactions between remote objects. Another type of broker, called a message broker, is being presented as a viable implementation of the broker architecture.

A message broker is not restricted to objects. Instead, it delivers messages between disparate applications, including legacy applications. The underlying technologies used by the message broker may consist of RPCs or MOMs, although MOM does appear to fit this model quite well. The basic idea of a message broker is that it can provide brokerage services asynchronously and, if needed, support a "publish/subscribe" model. The message broker can also be rule-based, i.e., you specify the rules to be used by the middleware to perform certain actions. See, for example, NeoNET (http//www.neonsoft.com). Message brokers can be very effective in a wide range of distributed applications including group communications, integration of existing applications, and large scale workflow.

The Gartner Group is advocating message brokers as key to the future success of distributed computing. The Gartner Group predicts that by 1998, message brokers will be as widespread as database gateways and data warehouses (Source: Bort, J., "Can Message Brokers Deliver?" Applications Software Magazine, June 1996, pp.70—76).

l Embedding. The data of the needed object is copied into the container application. Naturally, once embedded, the container application only accesses the embedded object. For a new copy of the needed object, the object has to be reembedded. For example, the greeting message will have to be reembedded into all container applications whenever the greetings change.

The trade-offs between these two options are obvious. Linking allows maximum flexibility in accessing the latest data of an object and also minimizes storage requirements, because only one copy of the object exists. However, linked objects suffer in performance, owing to dynamic linking. A potential risk in object linking is that the link may be lost if the linked object is moved or if the container application is run on another computer. With object embedding, you never have to worry about losing the data, and the performance is improved. However, some objects can take too much space (10 seconds of sampled sound can run over 100 KB). The actual process of linking and embedding objects by using OLE depends on the applications being used. The process is based on pointing and clicking on the OLE icon and then following intuitive steps.

OLE has evolved and continues to evolve. OLE 1 was based on a protocol built on top of DDE (Dynamic Data Exchange) and was somewhat limited in its capabilities. OLE 2.0, introduced in 1993, provides many new features and is based on a new object-encapsulation technology known as the Component Object Model (COM). The main architectural components of OLE 2.0 are (see Figure 7.14):

l Component Object Model (COM). COM specifies the interfaces between component objects of a compound document. Conceptually, COM is similar to CORBA in the sense that it separates the interfaces from the implementations. COM is now known as DCOM (Distributed Common Object Model), owing to the emphases of OLE on distributed environments. DCOM, in addition to its role in OLE, is the foundation of the ActiveX technology that is expected to be used in Microsoft’s next-generation operating system (see Section 7.6 for a discussion of ActiveX).

l Structured Storage System. This component provides an internal directory for organizing the contents of a compound document.

Figure 7.14 OLE 2.0 Components

l Uniform Data Transfer Model. This component allows users to transfer data uniformly through copy and paste, drag and drop, or API calls.

l Compound -Document Management. This component seamlessly integrates data of different formats (e.g., sound clips, spreadsheet cells, bit maps) within a compound document.

l Automation and Scripting. This component allows applications to expose their COM interfaces so that other applications and scripting languages can use OLE objects.

In summary, OLE provides an architecture for compound documents. It includes facilities for defining object interfaces independent of the implementation and includes method invocation and object encapsulation (some of these capabilities are primitive because OLE does not support inheritance and polymorphism). Microsoft is including OLE in its enterprisewide distributed-object computing strategy known as ActiveX (see Section 7.5 for ActiveX details). Programming details of OLE are beyond the scope of this book and can be found in Object Linking and Embedding: Programmer's Reference, Microsoft Corporation. The book by Brockschmidt [1995] contains a great deal of technical information about OLE.

7.4.3 OpenDoc

OpenDoc is a set of APIs and software for compound documents. OpenDoc, originated by Apple, is similar in scope and function to OLE 2.0 and is considered as an alternative to OLE 2.0 (see, for example, Orfali [1994]). At present, OpenDoc is managed and promoted by Components Integration Laboratories (CI Labs)–established in September 1993 jointly by Apple, IBM, Oracle, Novell, Taligent, Sunsoft, Word Perfect, and Xerox.

The CI Labs technology includes:

l Apple’s OpenDoc software for Windows, OS/2, UNIX, and Macintosh.

l IBM’s System Model (SOM), a CORBA-compliant architecture, for dynamic object linking.

l Apple’s Bento technology for handling multimedia information

l Apple’s Open Scripting Architecture (OSA) for the coexistence of scripting systems from multiple suppliers.

Figure 7.15 shows the components of OpenDoc. Let us briefly review these components:

l System Object Model (SOM) provides interoperability of OpenDoc objects in the same address space (local objects), across address spaces (remote objects) on the same machine, or across machines. As stated previously, SOM is CORBA compliant, so it allows object communications across machines and supports static as well as dynamic method invocation (see the discussion on CORBA).

l Bento Storage, named after Japanese plates with compartments for different foods, provides containers for different objects. Bento containers allow applications to retrieve and store collections of objects.

l Uniform Data Transfer Model provides transfer of data via copy and paste, drag and drop, and linking.

l Compound-Document Management supports OpenDoc "parts" which are the basic building blocks of OpenDoc. OpenDoc compound documents are composed of parts–each document has a top-level part in which other parts are embedded, each part contains data (e.g., video parts contain video clips) and parts can contain other parts.

l Open Scripting Architecture is based on the Mac AppleScript. It defines about a dozen polymorphic commands for parts (e.g., "delete" could mean delete a word or a video image depending on the type of part that receives the command.

Figure 7.15 OpenDoc Components

CI Labs intends to make source code for the OpenDoc technologies available to the industry. CI Labs also plans to make OpenDoc compatible with OLE, i.e., an OpenDoc container would see an OLE object as an OpenDoc part, and vice versa. OpenDoc is targeted for deployment on Microsoft Windows, OS/2, Macintosh, and UNIX. Information about OpenDoc can be found in Orfali [May 1995, March 1995].

7.4.4 Compound-Document Middleware Summary and Trends

OLE and OpenDoc share the same goals and provide the same basic functionalities. However, at present, OLE and OpenDoc have several differences. Some differences are at the core (e.g., OLE does not support inheritance, polymorphism, and multiple machine documents while OpenDoc does), while others are behavioral (double clicks to select an object versus moving the cursor to the right spot for object selection). In addition, there are differences in suppliers (OLE is provided by Microsoft while OpenDoc is vendor independent). OLE is much more used than OpenDoc for obvious reasons (Microsoft’s presence on the desktops may have something to do with it!). However, it is expected, and hoped, that these two technologies will interoperate with each other. In either case, use of CORBA for object invocation appears to be imminent (OpenDoc uses CORBA-compliant middleware, and bridges between COM/DCOM to CORBA are commercially available). In addition, OMG’s Common Facilities are expected to provide compound-document objects.