19. World Wide Web and Object Technology

19.3. Compound document frameworks

Compound document frameworks is the second important paradigm to consider for making Web documents more interactive with active multimedia content. So let's define a compound document framework.

A compound document framework acts as a container in which a continuous stream of various kinds of data can be placed. Each form of content has associated controls that are used to modify the content in-place, and with uniform user interfaces.

It is important to understand the meanings of the different keywords in the above definition. In a sense, a Microsoft Word document is a partial compound document. You can put text, tables, images and drawings in it and Word provides the controls to manipulate each of these. Let's try to define the different functionalities that a compound document provides.

Compound documents:

• provide an intuitive way to group together related objects
• display them seamlessly in a window
• store them in a shared file
• ship them across networks to other desktops or to servers
• maintain persistent client/server links that let those embedded
  components to extract data from servers anywhere in the enterprise

Compound document data can be any of the following:

• Movies, sounds, and animation
• Text documents and spreadsheets
• Database access components
• Networked calendars
• Statistical data
• URLs

Thus, the document becomes the universal client -- the ultimate front-end to servers. The desktop itself is becoming a giant compound document that integrates in a "borderless" manner applications and operating system services. Instead of switching between applications, you manipulate parts of a document. Different types of data in a compound document are contained in different types of 'components'. As defined in the first section of the chapter a 'component' is a smart object that is independent of any applications and can by shipped anywhere and put into a container to co-exist with other components. As we will see, the functionality provided by the compound documents is not enough. Some more support is needed from the underlying framework.

The framework provides -

• an organized environment for running a collection of components and protocols for interaction between them.

• a structured storage capability that enables storage of various types of components in a single document file.

• a scripting and automation facility through which appropriate actions can be specified for specific events.

• a uniform data transfer mechanism that can be used with a variety of protocols - including clipboard, cut-and-paste, drag-and-drop, and linking.

In this section we will look at three existing compound document technologies viz. OpenDoc, Object Linking and Embedding, and Java Beans. It is not possible to explain all of them in detail in such short space, but I will try to give an intuitive idea about each. Again, Orfali, 1996 is an authoritative reference on Compound document frameworks.

OpenDoc is the compound document standard proposed by Component Integration Labs (CI Labs) formed in 1993 by Apple, IBM, and other companies. The Object Management Group(OMG) has adopted OpenDoc as the official compound document standard for CORBA-compliant systems. OpenDoc provides all the facilities and capabilities provided by a compound document framework as mentioned previously. Figure 19.1 shows OpenDoc architecture.

The 'components' in an OpenDoc document are called "parts." A part consists of data stored in compound documents - including text, graphics, spreadsheets, and video, and a "part editor" that manipulates this data. OpenDoc parts can support almost any kind of data. The good thing about parts is that they are not restrained to be rectangular; a part can be any shape. From a client-server point of view, OpenDoc acts as a central integration point for multiple sources of data that reside on different servers. Let's look at the different components of the OpenDoc architecture.

• OpenDoc uses IBM's System Object Model (SOM) as the underlying object bus. SOM is a CORBA- compliant ORB and provides local and remote interoperability for OpenDoc parts. It allows OpenDoc developers to package their parts in binary format and ship them as Dynamic Link Libraries (DLLs).

• OpenDoc provides a structured storage facility called 'Bento'. Bento defines a container format that can be used in files, network streams, clipboards, etc. It allows applications to store and retrieve collections of objects in a single structure file, along with their references to other objects. The Bento container format is platform-neutral; it can store any type of data. Thus it is a carrier for exchanging compound documents between applications running on different platforms.

• OpenDoc provides a uniform data transfer mechanism for transfer across and within the same application. The same method invocations used for document storage can be used to transfer data and parts via drag-and-drop, cut-and-paste, and linking.

• OpenDoc specifies the Open Scripting Architecture (OSA) for defining semantic events and attaching scripts to them. OSA is an extension of Macintosh's Apple Events. Scripting can be used for giving more intelligence to parts, so that they can react to specific events such as creation, editing, etc.

In addition Novell is distributing "ComponentGlue", an interface and library that provide seamless interoperability between OLE and OpenDoc for Windows.

Thus, parts can be linked to corporate databases, work-flow managers, image repositories, email, or the local spreadsheet. The document acts as a repository of client-server relationships or "links" to external data sources and remote functions. More information on OpenDoc can be found at Apple's OpenDoc site.

OLE is the object-based foundation of the Windows platform. It is an integral part of Windows 95. It consists of a number of interfaces that define a set of related functions. OLE architecture is very similar to OpenDoc architecture. There are significant differences we will see in a later section. Following figure illustrates the OLE architecture.

OLE supports two types of compound-document objects: linked or embedded. The difference is in the how and where the actual source of the object's data is stored.

• Linked Objects: When an object is linked, the source data, or link source, continues to reside wherever it was initially created. Only a link to the object and the appropriate presentation data is kept within the compound document. Linked object cannot travel with documents to another machine, unless they are copied explicitly.

• Embedded Objects: A copy of the original object is physically stored in the compound document, as is all the information needed to manage the component. You can edit embedded objects in-place.

OLE provides a complete environment for components and a set of common services that allow these components to collaborate intelligently. Eventually Windows will evolve into a giant collection of OLE interfaces, with COM providing the underlying objet bus and services. Let's look at the individual components of the OLE architecture.

• Object Bus: Microsoft's Component Object Model (COM) provides the object bus for OLE components. It separates interface from implementations and provides a local Remote Procedure Call (RPC) facility. It is called Lightweight RPC, as it does not support remote method invocations. The recently announced Distributed COM model does support remote method calls. COM's object model does not support multiple inheritance. Instead, a COM component can support multiple interfaces.

• Automation and Scripting: OLE's Automation and Scripting services allow server components to be controlled by automation clients (also called `controllers'). An automation controller is typically driven by a scripting language or from a tool such as Visual Basic.

• Structured Storage: OLE provides a Structured storage facility similar to OpenDoc, called Compound Files. Compound files create a "file within a file" by introducing a layer of indirection on top of existing file systems. Compound files break a file into a collection of storages (or directories) and streams (or raw data values).

• Uniform Data Transfer: Like OpenDoc, OLE provides a generalized intercomponent data transfer mechanism that can be used in a wide range of situations and across a variety of media. Data can be exchanged using protocols such as the clipboard, drag-and-drop, links, or compound documents. The actual transfer can take place over shared memory or using storage files.

• Compound Document Service: It defines the interfaces between a container application and the server component that it controls. In this case, a server is a visual component that "serves" a container.

OLE Tools and Foundation Classes

Several visual tools are available for developing OLE-compliant applications. These tools include a C++ class framework called the Microsoft Foundation Classes (MFC), Visual C++, and Visual Basic. Additional tools are available from Borland and other vendors. MFC is a C++ class library for Windows development. Most of this code simply encapsulates the OLE interfaces with C++ classes. MFC supports OLE automation, compound documents, and controls.

The language of choice for OLE development is C++ because it nicely maps to the way OLE interface pointers are implemented. Visual C++ provides a graphic environment for creating OLE applications on top of MFC 3.0 and the OLE Custom Control Development Kit (CDK). The VC++ AppStudio lets you create and edit views, dialog boxes, bitmaps, icons, menus, and other resources. Extensive information on the internals or OLE/COM can be found at Microsoft's OLE Development site.

The third important player to consider in the compound document market is Java Beans. Java Beans is a new API for the Java platform, to provide a software component model for Java. The main goal is to enable developers to write re-usable components once and then run them anywhere.

The Java Beans API will be included in JDK 1.1 which is slated for release some time later this year. According to the Java Beans API specification, a Java Bean is a reusable software component that can be manipulated visually in a builder tool. The builder tools may include web page builders, visual application builders, GUI layout builders, or even server application builders.

There are a range of different kinds of components that can be built as Java Beans:

• Some Java Beans will be used as building blocks in composing applications, e.g. buttons, lists, etc.
• Some Java Beans will be more like regular applications, which may then be composed into compound documents e.g. a Java Beans spreadsheet.

The design center for beans ranges from small controls up through simple compound documents such as Web pages. Java Beans provides APIs that are analogous to an OLE control or ActiveX APIs, but does not provide the full range of high-end document APIs provided by OpenDoc. However, Java Beans can be embedded in platform specific containers such as an OpenDoc document, Netscape Navigator, or even a Word document.

Some of the other goals of the Java Beans APIs are as follows:

• It provides a platform neutral component architecture. When a Java Bean is nested inside another Java Bean it will provide a full functionality implementation on all platforms. However, at the top level, when the root Java Bean is embedded in some platform specific container then the Java Beans API should be intergrated into the platform's local component architecture (e.g. COM for Windows).

• It provides a uniform, high-quality GUI API for different platforms. Platforms will vary in their ability to support the full Java Beans APIs. However, whenever a platform is unable to provide the full functionality it must provide some reasonable, harmless default instead.

• It provides simplicity to component development. It focuses on making small lightweight components easy to implement and use, while making heavyweight components possible.

The Java Beans API makes heavy use of the newly announced APIs such as the RMI specification, Object serialization and others. The API provides following services:

• Component interface publishing and discovery: The publishing system allows components to locate other components and to communicate with them. Java Beans makes use of the RMI specification for remote method calls and Java IDL for interfacing with CORBA-based systems. Java Beans also supports Component Introspection so that it becomes possible to find out the components properties. It makes use of the Java Core Reflection API for this.

• Event handling: Events are a way for one component to notify other components that something of interest has happened. E.g. a click of a button in one component can trigger the update of a graph in another component. The AWT Event model has been updated for Java Beans.

• Object persistence: It allows Java Beans to be stored away as part of the state of their parent container or as a stand alone component having a specific state. The stored component can be retrieved at a later time and its state restored from its serialized state. It uses the object serialization mechanism for serializing and deserializing the object. Object serialization is also used by RMI to marshal and unmarshal the parameters for remote method calls.

• Layout and properties management: It is possible to define the layout of a component in relation to the other components in the container. Properties are named attributes associated with a bean that can be read or written by calling appropriate methods on the bean. Properties of a bean can be changed to customize it.

• Application builder support: Beans are capable of running inside application builder tools and provide custom component editors known as customizers.

• Structured Storage: The Java Beans API also specifies a structured storage mechanism called JAR files (Java ARchives), which are basically compressed files in which an entire compound document can be stored along with its state and restored at a later time.

• Uniform data transfer: The Java Abstract Windowing Toolkit (AWT) has been enhanced to provide support for data transfer through, drag-and-drop and cut-and-paste.

Many vendors have announced that they will support Java Beans in their products and application builder tools. Apple Computer and IBM Corporation are working with JavaSoft to ensure two-way interoperability between JavaBeans and OpenDoc applications, providing an invisible migration to client/server applications.

In addition, JavaSoft will ensure that JavaBeans run seamlessly inside ActiveX containers on Microsoft Windows platforms as well, and with Netscape to ensure that JavaBeans run inside Netscape Navigator's LiveConnect containers.

JavaSoft has recently announced the beta version of the Beans Development Kit (BDK). It can be downloaded from the Java Beans site.

19.3.4. Who will win the battle?

Let us first look at the comparative merits and demerits of the OpenDoc and OLE Compound document frameworks.

• Object Models
• OpenDoc follows the classical object model and extends it to components. An OpenDoc component supports inheritance while an OLE/COM class does not. An OLE component is essentially a black box object.
• OpenDoc uses CORBA as the underlying bus for communication between distributed objects. Distributed OLE is still in the developing stages and is not mature yet. OLE does not support remote method invocations.

• System Services
• OpenDoc supports all the CORBA distributed services such as RDBMS integration, transactions, concurrency, and security, while none of OLE services are distributed.

• Compound Documents
• OpenDoc supports irregularly-shaped parts that help create very seamless looking documents.
• OpenDoc scripting facilities are also superior, in the sense that they let you operate on a part's contents via semantic messages.
• Bento is more portable than DocFiles.

• Supported Platforms
• OLE - Windows, Mac
• OpenDoc - Windows, Mac, OS/2, and various Unixes

From the above list we see that the combination of OpenDoc/CORBA is much superior technically to OLE/COM. Still, OLE leads OpenDoc in the marketplace because of the market share claimed by the Windows platform. Also most of OLE's shortcoming come from the fact that is it does not support distributed objects, which might change very soon with the recent announcement of the Distributed COM by Microsoft.

This is definitely not the end of the battle of compound documents. Java Beans is coming out as the third major contender in the field, with its promise of architecture neutrality, component reuse, and application builder tools. Although it is not a complete compound document framework like OpenDoc and OLE, it holds a lot of promise. No one can say which Compound document standard will win or lose the battle, but it will be an interesting game, where the user has only to gain rather than lose anything.

Copyright © 1996 Ashish B. Shah, All Rights Reserved.

Ashish B. Shah <ashish@csgrad.cs.vt.edu>
Last modified: Tue Oct 29 11:59:59 1996