1. OpenOffice.org技术架构

上一篇简单介绍了OpenOffice.org的发展轨迹、许可证问题、应用范围等情况。实际上，OpenOffice.org之所以获得如此广泛的应用，是与它本身优秀的技术架构，开放、可扩展、标准化的XML文件格式规范，以及社区成员的广泛参与密不可分的。

本篇将主要介绍OpenOffice.org的技术体系结构，它的分层架构、UNO组件模型、基于IDL的API和SDK，以及UNO与其它组件模型的互操作。

1. 分层架构

OpenOffice.org所基于的技术架构能够提供在UNIX和类UNIX系统上丰富的办公软件功能，并且这种架构能够被移植到其他很多的平台上。这是因为整个架构就是在平台无关性的思路下实现的。

整个OpenOffice.org中实际上只有不到10%的代码是与平台相关的，这些代码为上层的组件模块提供一个系统抽象层。由于C++编译器存在于每一个主要平台上，所以OpenOffice.org采用了C++作为主要的编程语言（最底层的部分代码由于效率等原因是C语言编写的）。这种实现方式允许OpenOffice.org移植到非常广泛的不同的平台上，采用面向对象语言也使得OpenOffice.org具有面向对象的技术架构。

图1是OpenOffice.org的分层架构图，总体上分为四层，每层由若干不同的子层/库组成，在图中用小方框表示。每层和每个子层/库都完成不同的功能。需要注意的是每个子层/库很可能不是对应于具体的某个源代码模块，而是相关的若干个模块。因为OpenOffice.org的源码模块众多，刚发布的时候还不到100个代码模块，而最近发布的OpenOffice.org 1.1.2已经到了150左右。模块之间的相互依赖关系可能是很复杂的，而且随着版本发布的更新不断有变化。所以从总体上把握OpenOffice.org分层模型的功能结构和依赖关系对于掌握整个OpenOffice.org的技术架构是很有帮助，也是至关重要的。

表1是OpenOffice.org 1.1.2源代码模块的功能描述表。在约150个模块当中，有将近30个模块是从其它开放源码社区获得的源代码。这些模块依照字母顺序排列，它们的功能描述尽管比较粗略，也会对理解整个OpenOffice.org的体系结构很有帮助。需要注意的是不同版本的OpenOffice.org包含的模块数目可能有不同，或有增删，而且有些模块也正在变更当中。

大致上讲，

• 系统抽象层（System Abstraction Layer）封装了所有系统相关的API并提供了共同的面向对象的API以平台无关的方式访问系统资源；

• 基础设施层（Infrastructure Layer）构建应用程序同平台无关的环境，为了向上提供组件和服务，这一层完整地包含了面向对象平台所需面向对象API的很多方面，包括组件模型、脚本解释、复合对象等等；

• 构架层（Framework Layer）为在不同应用间能够实现复用，提供每个应用和所有共享功能（例如公共对话框、文件访问或者配置管理等）所需的架构和环境；

• 应用层（Application Layer）提供所有的OpenOffice.org应用，这些应用的交互方式是基于若干底层的。

图2是OpenOffice.org 1.1.2源代码模块依赖关系树状图。这张图所描述的是OpenOffice.org中各个模块的编译依赖关系，实际的模块编译顺序也是根据这个依赖关系产生的。从图中我们大致可以看出OpenOffice.org的分层结构。最底部比较密集的区域是系统抽象层，在此之上非常密集的区域内的模块组成基础设施层，上部比较稀疏的区域是构架层，最顶部的若干模块组成应用层。

下面逐层描述它们的功能。

1. 系统抽象层

分层的系统架构是OpenOffice.org能够轻松移植到广泛而不同的系统平台上的重要因素之一。为此目的，OpenOffice.org架构中特别定义了一个称作“系统抽象层”的虚拟层。所有平台相关的实现都在这一层下发生，或者作为可选模块存在。所以理想状况下只要实现了系统抽象层提供的功能再把上面诸层所属的模块重新编译，OpenOffice.org就能够在新的平台上运行了。但如果想要实现所有功能，可选的平台相关模块也要进行移植。为了减少移植工作量，系统抽象层所提供的功能被缩减到每个平台上可用的最小集合。当然在某些平台上系统抽象层必须模拟某些不存在的功能，比如在没有本地多线程的环境下支持“用户境”线程。¹

系统抽象层包括如下四个子层/库：

• 操作系统层（Operating System Layer，OSL）封装了用来访问和使用系统资源（例如文件、内存、套接字、管道等）的操作系统功能。OSL是具有面向对象API的很薄的一层，和上层不同的是这里的面向对象API是C语言实现的API。C语言API的优势在于允许将该层用不同的实现语言移植到不同的平台上去，比如对于嵌入式系统或者互联网应用设备来说，汇编语言就可以用来实现这一层。

• 运行时库（Runtime Library，RTL）提供所有的准平台无关的功能。这里提供字符串类的实现，也能够把字符串转换到不同的字符集，内存管理的功能也是在这里实现的。

• 标准模板库（Standard Template Library，STL）²在这里作为泛型容器类来使用。STL提供了列表、队列、栈、映射等模板/类的实现。

• 可视类库（Visual Class Library，VCL）³是OpenOffice.org的核心库之一。VCL的实现分为两个部分，一部分封装了对不同的底层GUI系统的所有访问方式，另一部分是完全平台无关的，包括面向对象的2-D图形API和OpenOffice.org使用的整个窗口部件集。这种纵向划分的方法保证了所有的窗口部件具有独立于不同平台上所用GUI系统的相同的行为方式，并且在所有平台上的外观感受和功能都是相同的。对打印功能的访问、剪贴板和拖放功能都是在VCL内实现的。

1. 基础设施层

• 虚拟操作系统层（Virtual Operating System Layer，VOS）为了更方便地使用文件、线程、套接字等系统资源，把操作系统层（OSL）的所有功能封装成了C++类。这些C++类提供了一个以面向对象方式访问所有系统资源的便捷途径。

• 工具库（Tools Libraries）⁴由提供辅助功能的很多小库组成，包括处理日期时间相关数据的公共实现，也包括结构化存储方式的实现，另外还包括通用注册表、类型安全管理、以及持久属性数据的实现。

• 通用网络对象（Universal Network Objects，UNO）⁵是OpenOffice.org所使用的组件技术。这种组件技术不依赖于任何图形子系统，而是很大程度上基于多线程和网络通讯的环境所提供的功能。
  UNO中的IDL编译器能够根据特定的接口定义产生二进制表示形式和相关的C头文件或者Java文件。这个二进制表示形式是平台和语言无关的，并在运行时编组远程函数调用的参数、或者为特定语言访问接口所提供的实现产生即时代码。这种技术的优点是减少了同时为不同语言绑定所产生的代码量，缺点是不仅对每种语言绑定所产生的代码都需要特定的后端支持，而且对每种编译器都需要一个运行时的桥接模块。
  很多UNO的部件都是作为UNO组件实现的，这有助于创建非常灵活的系统以及运行时的系统扩展。以提供新的桥接/通讯协议为例，UNO提供了本地和在网络上的访问组件的透明方式，其中在网络上的通讯是通过IIOP实现的。如果组件是做为共享库实现的，那么该组件就可以被UNO加载入程序的进程内存中。从而对组件的每一个访问都好像是函数调用一样，不需要任何远程函数调用所需的参数编组。

• 通用内容代理（Universal Content Broker。UCB）⁶允许所有的高层代码透明地访问不同类型的结构内容。UCB由一个核心和若干通用内容提供者（Universal Content Provider，UCP）组成，后者用来集成不同的访问协议。现有OpenOfficr.org UCP实现了对HTTP、FTP、WebDAV和本地文件系统上内容的访问。

• 复合对象（Compound Objects）提供了复合文档（比如电子表格被镶嵌进文字处理文件中）的功能。现在的OpenOffice.org支持复合文档和镶嵌多媒体播放器这样的可视控件，并且这个实现是平台无关的。复合文档的所有内容都以同OLE结构存储格式兼容的方式保存，这样以来，只要支持OpenOffice.org的平台就可以访问OLE复合文档。复合对象在Windows平台上的实现可以和OLE服务交互，所以可以和所有支持OLE的应用程序更紧密地结合。

• 脚本与Basic库（Scripting and Basic Libraries）⁷提供一个解释器，用以解释源代码并产生元指令。这些指令可以通过附带的元指令处理器直接执行，或者在模块/库里持久保存已备后用。UNO实现的所有上层应用组件所提供的功能都可以通过组件的脚本接口访问到，这就保证了采用OpenOffice.org UNO技术的新组件不需很大的成本就可以被完全脚本化。脚本接口也实现为组件，这就允许其他脚本语言轻松地集成进来。在OpenOffice.org 2.0中会集成BeanShell⁸（一种轻量级的Java解释器）和JavaScript。实际上随OpenOffice.org所附带的Basic是一个Basic方言。

1. 构架层

• 应用架构库（Application Framework Library，SFX）⁹为所有的应用提供环境，每个应用所共享的而没有被其他层提供的功能都在这里实现。就程序结构来讲，每个应用都要实现一个壳（shell）和若干视图（view），SFX提供了所有的基础功能，所以应用只需补充特有的功能即可。
  这个架构库对于内容检测和集成来说也是结构合理的，模板管理和配置管理就在这里提供。SFX也和复合文档的一些方面相关，比如菜单和工具条的合并和设置。对所有应用的定制化功能也是由SFX提供的。

• 共享功能库（SVX Library）¹⁰为所有应用提供架构无关的共享功能。SVX的一部分实现了一个被若干应用用来做图形编辑和输出的完整的面向对象“画布”，这个“画布”还包含一个完整的3-D 引擎。另一部分实现了字体选择、颜色选择等公共对话框¹¹，而数据库连接¹²也是完全在这里实现的。

4. 应用层

所有的应用：文字处理应用¹³、电子表格应用¹⁴、演示文稿应用、图表应用等等，都是在这一层实现的。而这些实现实际上都是共享库，在运行时由应用架构进行加载。架构提供了所有这些应用的环境以及它们交互的功能。

2. UNO组件模型

现在开放系统世界里并没有每个人都接受的组件技术。桌面领域有KDE和GNOME，他们都把CORBA作为底层通讯方式的基础，但是高层的组件模型彼此完全不同。所以现在不可能写出在两种桌面环境都可用的组件。而且现在的CORBA规范中并没有包括组合文档和其他桌面软件相关的功能。

另一个问题是现大多数CORBA的设计实现都是用来通过远程服务运行分布式网络应用的。所以在桌面组件模型中采用这样支持完全网络通讯负荷的CORBA实现在大多数情况下都是错误的选择。Mozilla开源项目开始的时候就根据需要建立了一个可以轻松移植到不同平台上的轻量级组件模型，这就是XPCOM。

OpenOffice.org之所以采用自己的组件模型正是基于以上这些原因，以及为了提供一套与Microsoft Office相似的办公套件功能。OpenOffice.org套件提供的UNO组件技术满足了现代桌面应用对组件的所有需求。UNO也是在对象技术层面上形成的，该组件技术是OpenOffice.org API建立的基础。

UNO技术包含如下的特点：

• 开放：UNO支持所有流行的组件标准通讯协议，例如CORBA、JavaBeans、OLE（Windows Scripting Host、Visual Basic、Delphi等）、JavaScript、Python¹⁵、Perl¹⁶等脚本语言，以及C++和C语言的本地集成。其中C、C++、Java和Python都已经实现了完整的UNO绑定，而OpenOffice.org Basic、OLE和共同语言架构（Common Language Infrastructure，CLI）现在只支持访问UNO组件，还不能用来创建新的组件。

• 面向对象：UNO是面向对象的，支持聚集、集成、异常处理和多态这样的概念。

• 基于接口：UNO的功能被集成进接口里，具有相似功能区域的组件对同样的接口有访问权限，开发者将具有组件世界的真实感觉。

• 平台无关：UNO特意被设计成平台无关的，有OpenOffice.org的平台就有UNO。

• 支持异常：UNO提供对异常机制的支持，这意味着它可以被映射成嵌入的开发系统的出错处理机制，比如C++异常和Java异常。

• 开发系统无关：UNO可以用现在所有的流行开发环境和编程语言实现，包括C++、C、Visual Basic、Windows Scripting Host和所有支持COM的系统、CORBA、JavaBeans组件、以及OLE。

• 支持网络：基于UNO技术的组件可以在网络上通讯，也可以在远程服务器上实现功能，比如在互联网设备上提供完整的文字处理功能。

3. API，SDK，与UDK

OpenOffice.org 应用程序接口（Application Programming Interface，API）基于OpenOffice.org的UNO组件技术，由许多类CORBA的IDL定义¹⁷的接口所组成。UNO组件技术决定组件和应用如何相互通讯、某种编程语言如何访问API，而API定义了独立于特定编程语言的访问OpenOffice.org功能的接口。这种接口结构对于决定开发中需要重新实现应用到何程度非常重要。

OpenOffice.org API定义的接口具有如下特征：

• 完全是定义好的组件与环境的接口，可以轻松地组合起来满足特定对象的需求。

• 版本无关性，通用功能和特定版本所需要的功能被区分开来；

• 可扩展性，开发者可以从接口的一个最小集合开始逐步地增加应用的特性；

• 可重用性，总是尽可能地采用通用的接口定义。

与其他办公套件的API不同，OpenOffice.org并不是已有实现的简单反映，它是从应用和组件开发者的角度来设计的，所以提供了几乎所有的OpenOffice.org组件程序接口，并且可以集成新的组件。

1. 应用领域

OpenOffice.org API有很多应用领域。首先，为了自动运行某些任务可以编写典型的宏程序；其次，部分OpenOffice.org可以作为其他程序的组件运行，比如将OpenOffice.org当作JavaBeans组件来访问。另外，有一个非常有趣的应用是将OpenOffice.org的用户界面替换掉，并搭建一个完全不同的应用环境。

2. 结构规范

OpenOffice.org API的结构规范采用的是“接口与支持类”方式，而不是“实现－继承”方式。

“接口与支持类”方式意味者对象只通过接口进行通讯，支持类被用来提供实现。这样的设计思路是因为组件是高度地环境、语言、和版本无关的。“实现－继承”方式意味着部分实现的基类，而子类从中衍生接口并继承下来。不选择这种规范的原因是在较大的系统中会导致膨胀的接口和深度继承层次。而且，主要通过基类依赖于环境的组件，也是编程语言相关和高度版本相关的。

3. 对象模型

OpenOffice.org API是为UNO组件技术设计的，也是用它实现的。因此OpenOffice.org API是程序语言无关的，可以在C/C++、Java和好几种脚本语言中使用。对于其它语言来讲，只需要一个语言绑定就能够提供对整个OpenOffice.org API的访问。该API是基于以下的原型构造的：

• 实现类：类其实不是在OpenOffice.org API中实现的，在这里提及只是为了更好的理解。实现类实际上是使用真实的程序语言来实现服务。一般来讲，使用服务的开发者不需要处理API层次上的实现。而对象不是为应用而是为实现类翻译成实际语言概念，这点类似于Java现实类的实现。

• 服务：对象规范称为服务。你可以把服务想象为对支持服务的实现类和使用组件所提供服务的应用都有利的“合同”。服务通常描述实现的的接口和一套参数。虽然服务通常不翻译成实际语言概念，你也可以把它看作类似于Java的抽象类。

• 接口：API层次上某一方面的规范称之为接口。接口可被看作是“合同”内通过合法验证的文字模块，接口可以组合成整个“合同”。OpenOffice.org API中的接口非常类似于Java中的接口。

• 结构：普通的数据块可以被定义为结构，因此结构是不含方法的。结构的优势在于它们可以传送到不同的进程甚至不同的机器，这会大大提高了进程间通讯和远程调用的效率。使用Java实现时，结构可以表示为只有数据成员和get/set方法的类。

• 异常：异常是方法调用的非常规结果。正如在Java中一样，异常被用来处理出错。

• 常量/常量组/枚举：常量被分成两类，可以分组和赋值为数值和字符串值的常量，和包含数值固定集的枚举。在Java实现中，这两者都表示为具有常量数据成员的类。

4. 模块化分层

OpenOffice.org API是按照与Java及CORBA类似的层次模块概念来组织的，从上到下一共分为四层：

• 办公软件接口，比如对文字处理、电子表格、绘图和演示文稿的接口；

• 集成架构接口，使得能够集成进OpenOffice.org新的组件，比如配置管理和通用内容代理；

• 应用域无关接口，这类非常重要的接口包括属性访问、集合、流操作、附加脚本引擎和其他很多接口；

• 组件系统接口，这部分基础接口包括必要的处理对象模型的接口，比如生命期控制、查询、建立桥接、和实例化远程对象等接口。

5. SDK和UDK

OpenOffice.org软件开发工具包（Software Development Kit，SDK）¹⁸是OpenOffice.org的一个补充部件。它提供使用现有UNO组件与开发新组件编写应用所需要的工具、例程和文档。SDK的主要部分就是《OpenOffice.org开发者指南》¹⁹，这本超过1000页的内容全面的指南提供了OpenOffice.org API概念、UNO组件模型、和在不同应用上下文中如何使用API的详细介绍。这本《指南》对于利用SDK进行OpenOffice.org的二次开发具有非常重要的参考价值。利用OpenOffice.org API和SDK提供的其他资源，开发者可以在不修改OpenOffice.org源代码的情况下使用自己熟悉的编程语言，基于UNO组件构建新的应用。

开发者在OpenOffice.org中有时也会看到UDK和ODK这样的名称，它们与SDK有联系也有区别。UDK是UNO和SDK的合称，而ODK实际上是指SDK中的一个模块，也用来指SDK中OpenOffice.org架构和应用相关的高层部分。

4. 融合与发展

   1. 组件桥接

现在桌面环境下所流行的组件技术有KDE/KParts²⁰、GNOME/Bonobo²¹、CORBA、Mozilla/XPCOM²²、OLE/ActiveX和OpenOffice.org/UNO等，各种组件技术之间的交互并不方便。为了在不同的环境中提供办公软件的功能，就有必要支持不同的组件技术。由于OpenOffice.org的组件技术能够使用桥接方式访问其他组件，有可能将办公组件集成进不同的环境中，比如GNOME、KDE和Mozilla。在组件基本概念非常相似的环境中实现桥接是相当容易的，而其他环境下想要隐藏所有的概念差异并提供桥接功能可能会非常困难。但是在很多情况下开发者和用户必须要处理不同的概念和哲学。而且如果桥接需要处理复杂的参数和调用转换，效率问题可能会凸现出来。

由于OpenOffice.org UNO支持对OLE的桥接，所以OpenOffice.org已经能够作为一个ActiveX控件在IE等支持ActiveX的程序内运行。可惜的是UNO同GNOME/Bonobo桥接的项目开始后又中止了。而OpenOffice.org为Mozilla提供的插件也已经开发完成，将会集成在2.0版本中。OpenOffice.org为KDE中的Konqueror 制作的插件²³也已经实现了一些基本功能。

2. 本地部件架构

在VCL最初的设计中并不封装底层GUI系统的本地窗口部件或控件。平台相关部分实现了2-D图形“画布”以供VCL上层的平台无关部分使用，该“画布”将每个功能调用都重定向到了底层的GUI系统上。

后来为了使OpenOffice.org在各个平台上的观感更接近于本地系统，开始了一个称作本地部件架构（Native Widget Framework，NWF）²⁴的项目。NWF的基本方法是使用本地桌面环境/窗口管理器提供的可视部件替换当前的基于窗口系统API实现的可视类库。现在把OpenOffice.org集成进KDE²⁵的项目正在进行，其中就包括实现KDE本地部件架构²⁶、和基于Qt实现VCL插件²⁷的两个子项目。其他的针对GTK+、Win32、和Apple Aqua ²⁸的NWF实现也在进行当中。

本篇主要介绍了OpenOffice.org的技术体系结构。在这一体系结构中有很多闪光之处，比如跨平台的分层结构、虚拟操作系统概念、UNO组件模型、基于IDL的API和SDK等等，都对OpenOffice.org移植到众多平台上、并获得广泛的应用和赞誉贡献良多。实际上OpenOffice.org架构中还有一些优秀的特性，因为篇幅所限在这里没有详细介绍，比如基于UNO的数据库连接（SDBC）和通用内容代理/提供者（UCB/UCP）。这些技术架构的详细内容需要读者实际进行研究与开发才会有更深入的理解。

下一篇将会介绍OpenOffice.org的另一个优秀的技术特点：开放、可扩展和标准化的XML文件格式规范。

本文依据《创作共用约定》之“署名-禁止派生-非商业用途”方式发布，即你可以免费拷贝、分发、呈现和表演当前作品，但是必须基于以下条款：

• 署名：你必须明确标明作者的名字。

• 非商业用途：你不可将当前作品用于商业目的。

• 禁止派生：你不可更改、转变或者基于此作品重新构造为新作品。

对于任何二次使用或分发，你必须让其他人明确当前作品的授权条款。

在得到作者的明确允许下，这里的某些条款可以放弃。

此约定是法律文本（完整的协议）²⁹的简单易读概要。

表 1 OpenOffice.org 1.1.2源代码模块的功能描述表

图 2 OpenOffice.org 1.1.2源代码模块依赖关系树状图