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:
Compound document data can be any of the following:
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 -
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.
Figure 19.1 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.
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.
Figure 19.2 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.
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.
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:
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:
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:
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.
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