---

2.1 Architectural Overview

   OpenDoc is a collection of related interfaces that enable the 
   interoperability of components in a platform-independent way.  As it is 
   shown in Figure 5, there are different kinds of interfaces OpenDoc must 
   take care of. 

   Think about a business graph component that is dragged into a text part. 

   The following considerations must be covered by an architecture to enable 
   that different components developed by different vendors, can 
   interoperate: 


 


                                             



 
   Figure 5. What a Component Architecture Must Address 


   1.  Compound Document Services dealing with document-wide services: 

       °   Text and graphics are two different types of components with 
           different types of data.  There is a common set of commands such 
           as printing where all components involved in a document must 
           cooperate and react in a homogenous way. 

       °   Both the text and the graphic components, have to interoperate 
           when the document is edited.  They must share common resources. 
           Only one component, for example the text component, can be edited 
           at a time. This component is active and has the focus; that means 
           it is the addressee of all user interface actions.  All keyboard 
           strokes or menu actions must be routed to the component that is 
           edited. 

       °   If the focus is changing because the graphics component is going 
           to be edited, the text component that is already active has to 
           clear its resources before it gives control to the other part. The 
           graphic part which receives control in turn should modify any 
           actions specific items, for example the menu items, to the graphic 
           component. 

       °   If a document is sent to other people, these people must be able 
           to work or at least be able to view the document even if they do 
           not have the same set of part handlers available on their machine. 

   2.  Component Services covering interfaces between components. 

       °   A component may embed other components or not.  A text component 
           should be able to embed other components. 
       °   The embedding component, also called a container, must be able to 
           communicate somehow with the embedded component to get some 
           information and to negotiate about a common layout. 
       °   A text component would usually want to react in different ways if 
           the embedded component is from the same type as the embedding 
           component. If a text component is dragged into a text container, 
           the text should probably be included in the text of the containing 
           part and not become a separate part. 
       °    The same decisions  must be made if a component is embedded by 
           cut and paste.  If the graphic component is pasted into a text 
           component, the text part should include the graphic as a separate 
           component, which must be handled by an appropriate part handler. 
       °   The architecture has to define a common interface related to the 
           document layout.  If the graphic component is dropped to the text 
           component, both components have to agree upon the space requests 
           the component dropped has. 

   3.  Storage System. 

       °   The Storage System must be standardized. When the compound 
           document is saved, different data types involved in a document 
           must be stored in a file. 

       °   A document stored in a file with different data types must 
           associate the appropriate part handler to the data, when the file 
           is opened. 

       °   If different people work on one document at the same time in a 
           network, there must be a mechanism to prevent changes made by one 
           person being destroyed if the document is saved by another person 
           at the same time. 

   4.  Data Transfer between components in OpenDoc. This is part of the 
       storage system. 

       °   Data transfer between components may be done with drag and drop, 
           or clipboard actions such as cut/paste. 

       °   The graphic component may be pasted as a link to the text 
           component  with a data source even on another machine.  Linking 
           must be standardized by an component architecture. 

   5.  Scripting. 

       °   Components have to be customizable and usable directly from other 
           components or applications. 

       °   There must be a uniform way to customize components with a script 
           language instead of the application-specific script dialects used 
           today. 

   6.  Object Model. 

       °   If a newer release of the graphic component becomes available, the 
           part has to be updated without any dependencies to other 
           components. 

       °   They need to have a standardized binary interface to access the 
           components and enable plug and play behavior. 


   The technologies addressed by OpenDoc are structured in the following four 
   areas as shown in Figure 6: 

   °   How to visualize components defined by the compound document services 
       and the component services of OpenDoc 

   °   How to store and share components defined by the storage system 

   °   How to use components defined by the scripting architecture 

   °   How to access components defined by the underlying object model 



 


                                             



 
   Figure 6. OpenDoc Technologies 


   These areas are structured by the OpenDoc architecture as shown in 
   Figure 7. 


 


                                             



 
   Figure 7. OpenDoc Architecture 

   The base of the architecture used by all other pieces is the object model 
   defined by the OpenDoc Object Management Services.  On top of the Object 
   Management Services there is the Opendoc Storage System, used by the 
   components to store their content. The services needed by the components 
   are defined in the OpenDoc Component Services.  Services needed by the 
   hole document are defined in the OpenDoc Compound Document Services. 

IBM BookManager® BookServer Copyright 1989, 1999 IBM Corporation. All rights reserved.