开放式知识库中数据服务模型的改进和应用论文.doc

毕业论文 第32页
开放式知识库中数据服务模型的改进和应用

摘 要
开放式知识库与传统的知识库不同，是一种强调利用网络的“群体智慧”，通过用户对知识的不断修改达成“共识”的知识产生模式。随着互联网的发展，开放式知识库的内容飞速增加，逐渐成为最重要的网络信息来源之一。
本文基于当前最流行的开放式知识库之一—维基百科(Wikipedia)的开源项目MediaWiki，分析了其当前数据服务存在的一些问题，并利用服务组件架构和服务数据对象的编程规范和相应的PHP实现，设计了一种组件化数据服务策略(CDS)来改进其原有的数据服务模型。该方案将MediaWiki的部分数据服务封装为服务组件，通过标准的绑定方式来松散耦合为一个服务组合。其中数据以服务数据对象为载体，提供了统一的异构数据源访问方式。
本文还设计了一个Web应用系统(Wiki-Reader)来展示组件化数据服务的应用模式。该系统可以集成MediaWiki提供的数据服务，订阅和管理Wiki用户的关注列表，并建立个性化的个人知识库。经过改进，原开放式知识库提供的数据服务能够以通用方式供第三方集成，从而提高了知识库信息的复用性和个性化水平。

关键词：开放式知识库，MediaWiki, 服务组件架构，服务数据对象

Improvement and Application of Data Service
Model In Open Knowledge Repository

Abstract
Different with traditional knowledge repository, Open Knowledge Repository is a kind of knowledge producing model which emphasis on reaching a "consensus" through constantly revising, that is, using the internet's "collective wisdom".
With the development of the Internet, the content in open knowledge repository increase rapidly，and it gradually become one of the most important sources of information on internet.
Based on the most popular wiki-form open knowledge repository’s (Wikipedia) open source project--MediaWiki, this paper analyze some existing problems with its current data services model. In addition, by using Service Component Architecture and Service Data Object specification and their implementation for PHP, this paper designs a Component Data Service Schema (CDS) to improve the system's existing data services model. The improvement packs parts of MediaWiki's data services into service components, which are loosely coupled via standard binding manner. Data service object is used as a data carrier to provide a unified access through heterogeneous data sources.
To illustrate the CDS’s application mode, this paper also designs a system (Wiki-Reader) that integrates the data service provided by Mediawiki. Using this system, reader can subscribe and manage wiki users’ watch list, and establish a personalized knowledge base. After improvement, MediaWiki can provide general data services for third-party integration, thus enhancing the reusability and personalization of information in open knowledge repository.
Key words: Open Knowledge Repository, MediaWiki, Service Component Architecture, Service Data Object
目 录
1 绪论 1
1.1 课题研究的背景 1
1.2 Wiki模式与数据竞争力 1
1.2.1 Wiki模式的基本特征 1
1.2.2 数据竞争力 2
1.2.2 对抗还是共生 2
1.3 课题研究的现状和存在问题 3
1.3.1 Wiki模式的现存的问题 3
1.3.2 Wiki模式的数据服务改进 3
1.4 本文主要结构 4
2 服务组件架构和服务数据对象规范 5
2.1 概述 5
2.2 服务组件架构(Service Component Architecture) 5
2.3 服务数据对象(Service Data Object) 7
2.3.1 SDO模型框架 7
2.3.2 数据访问服务(Data Access Service) 8
2.3.3 SDO编程规范的目标和技术特点 10
3 开发环境和语言介绍 12
3.1 PHP语言 12
3.2 开发和运行环境 12
4 开放性数据库的数据服务改进方案 13
4.1 MediaWiki简介 13
4.2 MediaWiki数据服务改进概要设计 14
4.3 MediaWiki数据服务改进详细设计 15
4.3.1 数据建模 15
4.3.2 文章数据服务 16
4.3.3 关注列表数据服务 18
5 集成数据服务的应用方案 21
5.1 Wiki-Reader系统简介 21
5.2 Wiki-Reader概要设计 21
5.3 Wiki-Reader详细设计 22
5.3.1注册登陆模块 22
5.3.2词条数据管理模块 22
5.3.3个人词库管理模块 26
5.3.4用户列表管理模块 26
6 结论与展望 28
6.1设计总结 28
6.2 有待改进之处 29
致谢 30
参考文献 31

1 绪论
1.1 课题研究的背景
随着互联网的发展和普及，网络内容正在以爆炸性的速度增长。如何发掘到网络中用户所需要的内容成为一个非常重要的问题，很多技术和应用在这方面做出了杰出的成就，如搜索引擎技术、RSS订阅技术、P2P技术和语义网等等。
与互联网初期的内容提供方式不同，当前互联网的内容来源也越来越多样化。BBS、Blog和Wiki的出现，使得网络用户从单纯的信息消费者成为信息生产者。开放式知识库正是在这些信息资源和平台的支持下，逐渐成为网络信息的一个重要产生方式。
传统知识库的建立方式是，组织一批拥有这方面知识的专家，在特定的时间内编纂完成，并定期更新版本。其典型代表是百科全书、字典以及各种教材。与其不同，开放式知识库则强调利用网络的“群体智慧”，通过用户对知识的不断修改达成“共识”。近几年，这种开放式知识库所产生的信息不断增加。
1.2 Wiki模式与数据竞争力
1.2.1 Wiki模式的基本特征
作为开放式知识库中最重要的形式之一，Wiki是这样一种以“知识库文档”为中心，“共同创作”为手段，依靠“众人不断地更新修改”，借助互联网创建、积累、完善和分享知识的全新模式。后来Ward Cunningham 为Wiki 总结了开放、增长、有组织、通俗、全民、公开、统一、精确、宽容、透明和汇聚等设计原则，凡是基本符合这些设计原则的内容编辑系统都可称之为Wiki[1]。
需要强调说明的是，上述原则应用到一个内容编辑系统中去才可称为Wiki，如果不能在一个编辑系统中对内容进行开放式编辑修改，内容就不会增长，如果不公开透明和不能汇聚全民的参与，就无所谓宽容和统一。
Wiki 的原理在于开放编辑和自由协作，用户可以修改系统中所有开放的信息文本，Wiki 系统则记录下所有用户修订的版本历史。与Blog 强调个人的自主性相比，Wiki 更强调用户群体的集体协作，特别适合协同创作，如共同构建知识库、形成共同规范或标准化的文档说明等。比如在Wikipedia中，各个词条最终形成的中性客观定义就是在这样的机制中产生的。原本没有什么客观的知识，有的只是主观林立的意见分歧，在开放编辑的条件下，不同用户的反复修订相当于进行一场广泛参与的协商讨论，协商讨论得越充分，得到的结果越容易获得更多人的接受，越接近符合共同规范意义上的“客观的知识”。通过这种开放修改权限的方式，那些比较容易为他人所接受的观点能够保持较久的时间，从而获得更大的影响力和更广泛的传播范围，那些恶意的、低质量的修改则难以久留，最终沉淀下来的是得到大多数参与者广泛讨论和协商后的、观念之间博弈与平衡的结果[2]。
总之，Wiki 设计思想可以提炼为：相信用户、相信群体的智慧，只有借助于群体智慧创造的作品才能更好的满足群体的需求、才能获得群体的满意和认可。这种思想，作为web 2.0最重要的设计模式之一[3],已经被很多网络应用所采纳。除文本编辑之外，Google Map电子地图的开放编辑功能便是这种模式的典型应用。
1.2.2 数据竞争力
可以说，现在每一个重要的互联网应用都有一个专门的数据库驱动，无论是Wikipedia的词条库、Google的网络爬虫资源、Napster的分布式歌曲库还是MapQuest的地图数据库。离开了强大的数据支持，网络应用都难以发展。不过，Wiki模式的变革也为我们提出了一个问题：谁应拥有数据？
在传统的互联网模式下，由网站或互联网应用提供数据，用户只是简单的查询使用这些数据。一般情况下，数据的所有权和管理权完全在网站服务的提供者手中，而对有价值数据的掌控往往是公司竞争优势的来源，这里把这种竞争力称为数据竞争力。
1.2.2 对抗还是共生
那么Wiki模式对传统的数据竞争力会产生什么样的影响呢？
当前很多公司非常注重对数据竞争力的保持，但数据的来源和所有权已经不像从前那样单一。由于越来越多的数据来源自网络用户本身，而公司及其仅仅是提供产生数据的服务平台，数据的开发与使用也就越来越难以被少数企业控制。正如专有软件的增长而导致自由软件运动一样，在接下来的时间汇总中我们可能会看到专有数据库的增长导致的自由数据运动。在维基百科全书(wikipedia)这样的开放数据项目中，我们看到的就是这种对抗势头的前兆。
然而并不是说Wiki模式就一定会减弱企业的数据竞争力。A便是一个很好的例子。Amazon是美国最大的网上出版物销售网站，它销售与当当网等竞争者相同的产品。公司并不直接拥有书籍，它是从卖方获得产品的描述、封面图片、目录等信息。但是，Amazon缔造出了一套激发用户参与的机制，他们利用用户的搜索购买等活动产生的附加信息，来提供准确更个性化的查询结果。他们还将数据服务开发为第三方接口，可供其他应用集成。Amazon通过它原有的数据服务为用户发挥“群众智慧”提供了平台，又利用这种 “群众智慧”所获得的数据信息使他们的服务更具竞争力。
这让我们看到，二者其实是可以通过技术手段进行结合，互相促进的。
1.3 课题研究的现状和存在问题
1.3.1 Wiki模式的现存的问题
与上节所提到的重要应用一样，Wiki模式的应用也有一个独特的数据资源作为支持，那就是由大量网络用户不断添加修改所积累的词条知识资源，以及由此延展出的相关统计数据，如最受关注的词条、最富争议的词条等等。到2006年，wikipedia站点已经有超过210种语言版本，词条数超过350万则，英文版的词条数则突破一百七十万则,规模超越任何权威百科全书。随着数据量的激增，开放式知识库当前如此大规模的词条信息，也对它原有的数据管理和服务模式提出了挑战，如：
(1) 如何使用户在数量众多的词条中找到自己可能感兴趣的信息
(2) 如何保障词条的质量和客观性
(3) 如何使这个庞大的数据资源得到更广泛的利用
1.3.2 Wiki模式的数据服务改进
对于以上问题，研究和工程人员提出了很多方法改善信息的结构化水平。其中最重要的方式之一便是通过与语义网技术的结合，比如Krotzsch等人提出了通过语意化的“分类链接”的机制重新组织wikipedia中的知识结构，使得庞大的知识网络关系可以让机器所理解，从而提高数据网络的智能化程度，改进查询的效率[4]。
为了保证词条的质量，Besiki Stvilia等人引入了信息质量(Information Quality, IQ)的概念，并深入探讨了IQ的影响因子和评价机制[5]。通过扩展wikipedia所进行的实验表明，这种方式的确可以为信息质量提供一个较客观的参考指标。目前也有些开放式知识库通过用户评价来分级信息质量，如D。这两种评价方式都各自通过网络应用证明了其作用。
对于最后一个问题，搜索引擎技术对于此类数据资源的应用无疑起了很大的推动作用。但是这种较“传统”的数据发掘方式还未能发挥出开放式数据库资源的全部潜力，资源的搜索和再利用效率仍然有待提高。本课题正是在这样的背景下提出来的，希望用面向组件架构(Service Oriented Architecture)的框架，改善开放式知识库的数据服务模型，提高数据的可复用性。并开发了一个示例平台来集成数据服务，用以个性化地管理个人知识库。
为了使Wikipedia长时间积累下来的知识被充分的发掘利用，我们可以参考Amazon的方式，将数据作为服务提供出来供第三方集成。本文希望通过服务组件架构(Service Component Architecture)和服务数据对象(Service Data Object)规范，对wikipedia的开源项目MediaWiki做一些改进，使其在保持原有功能的同时，可以作为分布式组件提供数据服务。同时，本文也设计了一个集成该数据服务的客户端平台，用来个性化地搜索浏览词条资源并管理个人知识库。通过这个平台来体现wiki作为数据服务的一种潜在应用。
1.4 本文主要结构
本文绪论部分主要介绍了本课题的研究背景和现状，以及存在的问题。
第二章介绍了用于改造原有数据服务的SOA实现规范——服务组件架构和服务数据对象。
第三章介绍了本设计的开发环境和语言，以及运行的网络环境。
第四章论述了对常用的开放式数据库wikipedia的改进方案和实现方式。
第五章论述了用于集成数据服务的客户端的实现方案。
2 服务组件架构和服务数据对象规范
2.1 概述
为了进一步推动面向服务架构(Service Oriented Architecture, SOA)的发展，2005年12月，IBM联合BEA、Oracle、IONA、SAP、Siebel、Sybase、Xcalia以及Zend公司，共同发布了两项针对SOA的重要编程模型规范——SCA(Service Component Architecture 服务组件架构)和SDO(Service Data Object 服务数据对象)。
SDO与SCA可以看作是一对具有对应关系的规范。SCA规范用以帮助简化服务的构建与整合，而 SDO规范则关注对多个站点中多种格式数据的统一访问。二者结合，为SOA编程模型的实现提供了切实可行的标准。目前两项规范仍处在发展完善阶段，还没有非常成熟的应用。
2.2 服务组件架构(Service Component Architecture)
服务组件体系结构（Service Component Architecture，SCA）是一组规范，描述了用于使用面向服务的体系结构来构建应用程序和系统的模型。SCA 扩展了以前用于实现服务的方法，并对其形成补充，而且，SCA 构建于 Web 服务系列标准等开放标准之上，并扩展和补充了先前的服务实现方法[6]。
SCA 鼓励采用基于实现业务逻辑的 SOA 业务应用程序[7]代码组织方式，以便通过面向服务的接口公开其功能，以及通过面向服务的接口使用其他组件提供的功能（称为服务引用）。它将用于构建面向服务的应用程序的步骤分为两大部分：
(1) 组件的实现，提供服务和使用其他服务；
(2) 为了构建业务应用程序对组件集进行的组装，通过服务之间的引用完成。
SCA 强调将服务实现和服务组装分离开来，这种分离即体现在基础设施功能细节上，也体现在调用服务的访问方法细节上。服务组件在业务级别进行操作，只使用非常少的中间件 API 来工作。
服务组件可以使用众多编程语言中的任何一种语言编写的服务实现，这既包括常规的面向对象和过程的语言，例如 Java™、PHP、C++、COBOL，也包括 BPEL和 XSLT 等以 XML 为中心的语言，还包括 SQL 和 XQuery 等面向问题的语言。SCA 还支持各种编程样式，除了同步调用-返回样式外，还包括异步样式和面向消息的样式。
此外，该架构也支持各种用于调用服务的访问机制的绑定方式。这包括 Web 服务、消息传递系统和 CORBA IIOP。绑定是以声明方式处理的，独立于实现代码。基础设施功能（如安全、事务和可靠消息传递的使用）都是采用声明方式处理的，已从实现代码分离。SCA 通过策略使用基础设施功能，而策略旨在简化控制功能如何应用到业务系统的机制。
值得一提的是，SCA还促进了使用服务数据对象(SDO)来表示形成参数和服务返回值的业务数据，从而提供了对业务数据的统一访问方式，对 SCA 本身提供的业务服务统一访问方式形成了补充[8]。本文正是基于这个特点，将SDO作为业务数据的载体来实现数据服务的改进。
总之，SCA的基本思想就是将业务功能作为一系列服务来提供，这些服务组合到一起，以创建满足特定业务需要的解决方案。这些复合应用程序既可以包含专门为该应用程序创建的新服务，也可以包含来自现有系统和应用程序的业务功能（作为复合应用程序的一部分来重用）。SCA为服务组合和服务组件的创建（包括SCA复合应用程序内部现有应用程序功能的重用）提供了模型,如图2.1所示：

图2.1 服务组件架构模型
2.3 服务数据对象(Service Data Object)
SDO的设计是为了简化和统一应用程序处理数据的方式。利用SDO，应用程序编程人员可以一致地访问和操纵来自异构数据源的数据，包括关系数据库、XML数据源、Web服务和企业信息系统等[9]。
2.3.1 SDO模型框架
SDO 模型框架提供了一组核心组件，这些组件可以由支持 SDO 的实现和框架进行扩充。SDO 规范定义了数据持有者——数据对象 (Data Object) 和数据图 (Data Graph)，还引用了一种叫做数据访问服务(Data Access Service，DAS)的组件。DAS 负责访问数据源和处理数据图。
数据对象是SDO框架的核心。数据对象是一个业务对象的一般表达，并且没有和特殊的持久化存储机制绑定。数据对象是保存数据的组件，简单地说，它是由属性的键/值对组成的，每个值都可以是原始的数据类型，或者是另一个数据对象。数据对象是可序列化的。
数据图是一个相关数据对象的集合。在SDO1.0里，一个数据图总是被一个DataGraph信封对象所包装，而在SDO2.0里，数据对象图可以存在于数据图(DataGraph)之外。Data graph作为两个单词分开使用时，指任何一个数据对象集合；DataGraph作为一个单一单词使用时，特指一个DataGraph信封对象。
所有数据图都有一个单一的根数据对象，它直接或间接的包含图里的所有其它数据对象。当的数据图里的所有数据对象仅仅引用自身的数据对象时，我们称该数据图是封闭的。封闭是一个数据图的标准状态。
一个数据对象图由以下组成：
(1) 一个单一的根数据对象。
(2) 通过对根数据对象属性的递归检索到的所有可达的数据对象。
一个封闭的数据图形成了一个数据对象的树形结构。数据图能够记录跟踪描述数据对象的模式。数据图同样也可以维护一个变更概要(ChangeSummary)，变更概要表达了施加于该图数据对象之上的更改[10]，如图2.2所示：

图2.2 SDO数据对象图
元数据是一个描述对象内容的元模型，它可以让数据图实例完成自省 (introspection)。SDO的元数据模型如图2.3 所示，每个对象都与一些基本的元数据信息相关联，对象以一个类型加一个已排序的属性列表的形式表示。

图2.3 SDO元数据模型
2.3.2 数据访问服务(Data Access Service)
对于终端用户而言，访问数据图的标准方式是通过数据访问服务(Data Access Service)。DAS负责提供某些方法来组装数据图，也负责将数据更改保存回数据源。典型情况下，将会有多种不同的 DAS 类型，每种类型对应着一种特定的数据源和技术(XML、JMS、JCA、JDBC 等等)。DAS 总是以同一种格式(数据图)返回信息，它隐藏了实际的数据存储信息，在 SDO 应用程序和企业信息系统之间提供了一层数据提取的功能。DAS 不在 SDO 规范的范围内，但是它在实现中可能需要将多个数据源和数据类型的数据集成在一起，这样，唯一的 SDO 数据图就会包含了异构数据源的信息。
DAS提供了从库中加载数据图和将数据图保存回库中的方法，它能够理解我们定义好的Schema，让程序员能直接看到一个直观的对象图表(Object Graph)。它根据业务的语义定义一个完整的Schema，不仅能清晰地定义各种数据对象，而且还能有效地描述各种对象之间的联系，充分利用了XML强大的自描述能力。通过它，人们可以很方便的操纵数据对象[11]。例如，一个XML文件DAS将加载和保存一个数据图为XML文件，一个JDBC DAS将使用一个关系数据库加载和保存一个数据图。
经典的DAS使用了一个非连接的数据架构，客户端除了在读写数据图时，均和DAS保持一个非连接的状态。因而，一个使用数据图的典型场景涉及以下步骤：
(1) 终端用户发送一个加载数据图的请求给DAS。
(2) DAS启动一个持久库上的事务去接收数据，创建一个表达该数据的数据图，并且结束这个事务。
(3) DAS返回一个数据图给一个终端用户应用。
(4) 终端用户应用处理数据图。
(5) 终端用户应用使用修改后的数据图调用DAS。
(6) DAS基于终端用户对数据的修改，启动一个新的事务更新持久库中的数据。
SDO和DAS的交互关系参见图2.4：

图2.4 SDO通过DAS访问异构数据源
对于一种新的不被支持的数据源或数据格式，一般情况下，我们可以通过开发相应类型的DAS保证对这一数据源的通用支持，从而保持SDO的模型和接口不变。这就是说通过SDO作为数据载体的分布式组件可以具有对任何数据源的扩展性和通用性。
2.3.3 SDO编程规范的目标和技术特点
SDO编程规范的目标和技术特点主要体现于以下方面：
(1) 对异构数据源的统一数据访问。
当前的数据编程技术或多或少都是特定于数据源类型的。而在实际应用程序中，数据通常来自于各种异构数据源，包括关系数据库（通过JDBC、实体EJB或其他持久性框架访问）、定制的数据访问层（使用各种常见的设计模式来实现）、 Web服务（通过JAXRPC或其他方法访问）、XML数据存储区、JMS消息和企业信息系统（通过JCA Resource Adapter或通过一些定制的API访问）。这种数据异构性对应用程序开发人员提出了严重的挑战，因为他们需要学习和使用大量不同的编程模型。过多的数据访问API也对一些常见数据编程任务的自动化工具和框架提出了挑战，比如绑定UI组件到后端数据源等。因此，我们需要一个与数据源类型无关的、表示数据集合的通用工具，为开发人员提供统一的编程模型，并为工具和框架提供在不同的数据源中以一致的方式使用的机会。
(2) 对静态和动态数据API的统一支持
静态的强类型接口可以为应用程序员提供一种使用编程模型的简单方式。例如，实体EJB、JDO、Hibernate以及其他对象/关系持久性机制提供类型化的Java数据接口，这为开发人员提供了一种方便的编程模型。相比之下，JDBC的ResultSet 和RowSet 接口只提供了动态的非类型化数据API。类似地，JAXB为XML数据提供了代码生成的Java接口，这使XML数据编程比使用DOM或SAX API更简单。
只有静态数据API或只有动态数据API是不够的。静态数据API提供应用程序员所需的易用性。但是在某些情况下，静态Java数据接口既不可行也不适合。例如，对于事先不知道结果数据的类型的动态查询，静态Java数据接口就不可行。因此，统一的数据编程技术需要同时无缝地支持静态和动态数据API。
(3) 对离线编程模型的支持
许多应用程序自然地包含数据访问的离线使用模式：应用程序读取一组数据，将其在本地保留一段短的时间，操纵数据，然后再将更改应用到数据源。例如，这在基于Web的应用程序中是非常常见的模式：一个Web客户端请求查看一个表单，一个Servlet或JSP请求本地读事务中的数据，并将数据呈现在HTML表单中，Web客户端提交对表单的更新，Servlet或JSP使用新的事务更新数据。最佳实践通常要求对该场景使用乐观并发语义，从而提供具有适当的业务级语义的高级别并发。
目前没有哪一种数据访问技术能够同时提供这种离线的乐观模型以及前述的其他特性。JDBC扩展(通过JSR114中的CachedRowSet)提供了离线模型，但是如前所述，JDBC不能满足异构数据访问或易用性的要求。类似地，许多对象/关系持久性机制（例如，许多实体EJB实现、JDO、Hibernate等等）虽然支持乐观并发语义，但是它们不提供必需的统一数据访问特性。
(4) 应用代码与数据访问代码的去耦合性
为了获得可重用性和可维护性，应用代码应该与数据访问代码分离。数据访问技术应该服从这一关注点分离。通过SDO编程规范，我们可以将数据访问和业务逻辑代码较好的分离开来。
SDO编程模型与其他的数据模型的比较如表2.1所示：

表2.1 SDO与其他数据模型的比较

访问模型
API
数据源
元数据
查询语言
JDBC Rowset
连接
动态
关系数据库
关系型
SQL
JDBC cached Rowset
离线
动态
关系数据库
关系型
SQL
Entity EJB
连接
静态
关系数据库
Java 内省(Introspection)
EJBQL
JDO
连接
静态
关系数据库和对象
Java 内省
JDOQL
JCA
离线
动态
基于记录
未定义
未定义
DOM & SAX
/
静态
XML
XML 信息集
Xpath, XQuery
JAXB
/
静态
XML
Java 内省
/
JAX-RPC
/
静态
XML
Java 内省
/
SDO
离线
皆可
任意
SDO
任意
3 开发环境和语言介绍
3.1 PHP语言
PHP 是一种流行的开放源代码脚本语言。官方正式名称为“PHP: Hypertext Preprocessor”的递归缩写。它主要用于服务器端应用程序及动态网页上，但是也可以用在命令行上执行，或是开发独立的图形用户接口（GUI）。
2004年7月，以Zend引擎II为基础的PHP 5.0 发布，同时也加入了许多新特性：
(1) 更完整的面向对象支持: 使其成为了比较完整的面向对象语言。
(2) 透过新的Zend引擎，提升了PHP执行的速度。
(3) 对MySQL数据库有更完整的支持。
(4) 更佳的XML支持。
(5) 内建SQLite数据库（但在PHP 5.1取消了内建，改用扩展函数库的方式）。
(6) 整合了SOAP的支持。
(7) 提供例外处理。
(8) 新的数据库存取接口PDO（PHP Data Objects）。
最新的版本是2007年5月发布的5.2.2。
PHP主要应用在网页服务器，处理使用者的输入来产生网页。但是命令行脚本或是窗口程序接口（GUI）的开发也是PHP的主要应用范围[12]。
PHP最初就是设计成服务器端脚本语言，因此这也是PHP应用最广的部份。在此领域有许多其他的竞争者，例如ASP.NET、ColdFusion、JSP、Perl、Ruby on Rails等等。
在网络工业领域，PHP是LAMP架构的其中一部分，所谓的LAMP是指Linux、Apache、MySQL、以及PHP所组成的网络环境，提供了许多安全、可靠的网页应用程序。PHP目前已经是全世界最受欢迎的服务器端脚本语言，跨平台的特性更是让PHP广为流传，目前世界上有超过2000万台服务器安装有PHP。
3.2 开发和运行环境
本设计的开发环境采用Eclipse＋PHPEclipse插件的组合。Eclipse是著名的跨平台的可扩展的自由集成开发环境（IDE）[13]。尽管Eclipse是个IDE平台,但是它的思想和组织架构的核心是支持一个通用模型,该模型可为多个开发者建立组件级的应用。为了控制工具组协同工作以支持程序任务，它提供了一个核心服务。工具建立者可以把他们的符合Eclipse插件规范的可插入组件封装进Eclipse平台中。Eclipse的一个基本的可扩展机制是，新插件可以添加处理元素到已存在的插件中。Eclipse也提供一组核心插件来启动这一处理[14]。最初它主要用来做Java语言开发，但是目前已经可以通过这种插件机制使其作为其他计算机语言的开发工具，比如PHPEclipse就是使其支持PHP语言开发的插件。
本设计采用Windows、Apache Server、MySQL以及PHP的组合作为网络运行环境，即WAMP架构。这一架构也保留了原有LAMP架构基本特性，并可以利用Windows下较丰富的软件资源。此外，由于利用了SCA和SDO编程模型，还需要从PECL中下载安装SCA_SDO扩展组件包，当前最新的版本为2.0版。PECL是PHP Extension Community Library的缩写，目的是提供PHP社区各种扩展函数库。PECL在2003年从PEAR(PHP Extension and Application Repository)项目分离出来，现在已经是一个独立运作的项目。
4 开放性数据库的数据服务改进方案
4.1 MediaWiki简介
MediaWiki是基于LAMP架构的开放式知识库开源项目，它也是当前最成功的开放式知识库应用之一——wikipedia的系统基础。其系统架构见图4.1。
MediaWiki主要提供了如下功能模块：
(1) 登陆与权限控制模块
控制用户注册和登陆，以及用户所在组的权限控制。
(2) 用户管理模块
管理用户的资料与使用偏好，包括所关注词条等信息。
(3) 词条管理模块
负责词条的添加、编辑、变更历史查询等功能。
(4) 特殊数据模块
提供针对词条的特殊信息，如统计数据、词条分组信息等

图4.1 MediaWiki 系统架构
4.2 MediaWiki数据服务改进概要设计
MediaWiki中最富价值的首先是由众多系统用户经过不断的更新修改积累下来的词条信息，这也是开放式知识库的核心数据所在。此外，用户在使用中通过“无意识”产生的数据也有其价值所在，如词条被浏览的数量、词条被修改的频率、以及词条被关注的情况等等。
本设计对MediaWiki的改进主要分为以下几部分：
(1) 将词条内容的相关数据和用户关注列表的相关数据分别开发为SCA服务组件
(2) 通过SCA架构所支持的web服务[15]绑定方式将服务组件组成一个组合(Composite),该组合将为客户端提供数据服务。
改造的系统架构如图4.2所示：

图4.2 MediaWiki改进部分的SCA架构
如图所示，通过将原有的封闭式的数据服务改造为服务组件，使MediaWiki的数据服务模型具有了以下新的特点：
(1) 提供了可供第三方集成的数据服务，增强了数据资源的复用性。
(2) 采用SCA服务组件架构，服务组件之间可以通过多种接口和绑定方式来松散的耦合在一起，而且也不局限于用某一种语言实现，具有很强的复用性。
(3) 数据采用SDO数据对象作为载体，可以通过DAS跨越多种异构数据源进行访问，增强了数据资源的通用性。
4.3 MediaWiki数据服务改进详细设计
本设计主要针对两项数据服务做出改进，首先是词条解释本身，另外是用户关注其感兴趣的词条所产生的关注列表(watch list)。
4.3.1 数据建模
要将所需数据封装为SDO，首先要对数据结构建模。服务所需的数据对象(Data Object)有Watchlist和Article两种类型，它们组成了具有包含关系的树型数据结构，在SDO规范中，这个结构将作为数据图的一部分，其组成的数据图(Data Graph)如图4.3所示：

图4.3 Watchlist的数据图结构
需要提到的是，在有DAS返回的数据图中，其根结点都是一个单独的数据对象，作为其他所有数据对象的父节点或祖先节点，并无实际数据，所以在上图中并未显示。
4.3.2 文章数据服务
在MediaWiki中文章内容分为三种形式：原始形式、Wiki形式和最终显示形式(即XHTML)。在显示前要经过两次转换，如表4.1所示：
表4.1 MediaWiki中三种内容形式的转换
原始形式
{{Help}}
Wiki形式
[[Template:Help]]
显示形式
<P><a href=”http://localhost/Mediawiki/ Template:Help”>Template:Help</a></P>
文章数据服务提供了文章内容相关的信息，该服务组件通过@service标签声明一个服务组件，通过@binding标签说明绑定类型(这里采用http/soap绑定)。其中的getHTML ($namespace ,$title) 方法获取某词条内容的显示形式，并用@param和@return标签声明参数与返回值。通过命名空间和标题生成一个标题对象，再由标题对象初始化一个文章对象，在此过程中访问数据库加载并转换文章信息(即词条解释的数据)，并将