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

目 录
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

本文来自think58 [资料来源：http://www.THINK58.com]

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 copyright think58

 Wiki模式与数据竞争力
1.2.1 Wiki模式的基本特征
作为开放式知识库中最重要的形式之一，Wiki是这样一种以“知识库文档”为中心，“共同创作”为手段，依靠“众人不断地更新修改”，借助互联网创建、积累、完善和分享知识的全新模式。后来Ward Cunningham 为Wiki 总结了开放、增长、有组织、通俗、全民、公开、统一、精确、宽容、透明和汇聚等设计原则，凡是基本符合这些设计原则的内容编辑系统都可称之为Wiki[1]。
需要强调说明的是，上述原则应用到一个内容编辑系统中去才可称为Wiki，如果不能在一个编辑系统中对内容进行开放式编辑修改，内容就不会增长，如果不公开透明和不能汇聚全民的参与，就无所谓宽容和统一。
Wiki 的原理在于开放编辑和自由协作，用户可以修改系统中所有开放的信息文本，Wiki 系统则记录下所有用户修订的版本历史。与Blog 强调个人的自主性相比，Wiki 更强调用户群体的集体协作，特别适合协同创作，如共同构建知识库、形成共同规范或标准化的文档说明等。比如在Wikipedia中，各个词条最终形成的中性客观定义就是在这样的机制中产生的。原本没有什么客观的知识，有的只是主观林立的意见分歧，在开放编辑的条件下，不同用户的反复修订相当于进行一场广泛参与的协商讨论，协商讨论得越充分，得到的结果越容易获得更多人的接受，越接近符合共同规范意义上的“客观的知识”。通过这种开放修改权限的方式，那些比较容易为他人所接受的观点能够保持较久的时间，从而获得更大的影响力和更广泛的传播范围，那些恶意的、低质量的修改则难以久留，最终沉淀下来的是得到大多数参与者广泛讨论和协商后的、观念之间博弈与平衡的结果[2]。 think58好，好think58 [资料来源：http://THINK58.com]
总之，Wiki 设计思想可以提炼为：相信用户、相信群体的智慧，只有借助于群体智慧创造的作品才能更好的满足群体的需求、才能获得群体的满意和认可。这种思想，作为web 2.0最重要的设计模式之一[3],已经被很多网络应用所采纳。除文本编辑之外，Google Map电子地图的开放编辑功能便是这种模式的典型应用。
1.2.2 数据竞争力
可以说，现在每一个重要的互联网应用都有一个专门的数据库驱动，无论是Wikipedia的词条库、Google的网络爬虫资源、Napster的分布式歌曲库还是MapQuest的地图数据库。离开了强大的数据支持，网络应用都难以发展。不过，Wiki模式的变革也为我们提出了一个问题：谁应拥有数据？
在传统的互联网模式下，由网站或互联网应用提供数据，用户只是简单的查询使用这些数据。一般情况下，数据的所有权和管理权完全在网站服务的提供者手中，而对有价值数据的掌控往往是公司竞争优势的来源，这里把这种竞争力称为数据竞争力。
1.2.2 对抗还是共生
那么Wiki模式对传统的数据竞争力会产生什么样的影响呢？
当前很多公司非常注重对数据竞争力的保持，但数据的来源和所有权已经不像从前那样单一。由于越来越多的数据来源自网络用户本身，而公司及其仅仅是提供产生数据的服务平台，数据的开发与使用也就越来越难以被少数企业控制。正如专有软件的增长而导致自由软件运动一样，在接下来的时间汇总中我们可能会看到专有数据库的增长导致的自由数据运动。在维基百科全书(wikipedia)这样的开放数据项目中，我们看到的就是这种对抗势头的前兆。

本文来自think58

然而并不是说Wiki模式就一定会减弱企业的数据竞争力。Amazon.com便是一个很好的例子。Amazon是美国最大的网上出版物销售网站，它销售与当当网等竞争者相同的产品。公司并不直接拥有书籍，它是从卖方获得产品的描述、封面图片、目录等信息。但是，Amazon缔造出了一套激发用户参与的机制，他们利用用户的搜索购买等活动产生的附加信息，来提供准确更个性化的查询结果。他们还将数据服务开发为第三方接口，可供其他应用集成。Amazon通过它原有的数据服务为用户发挥“群众智慧”提供了平台，又利用这种 “群众智慧”所获得的数据信息使他们的服务更具竞争力。
这让我们看到，二者其实是可以通过技术手段进行结合，互相促进的。
服务组件架构和服务数据对象规范
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编程模型的实现提供了切实可行的标准。目前两项规范仍处在发展完善阶段，还没有非常成熟的应用。

think58好，好think58 [资料来源：http://THINK58.com]

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 还支持各种编程样式，除了同步调用-返回样式外，还包括异步样式和面向消息的样式。 think58好，好think58

[资料来源：http://THINK58.com]

此外，该架构也支持各种用于调用服务的访问机制的绑定方式。这包括 Web 服务、消息传递系统和 CORBA IIOP。绑定是以声明方式处理的，独立于实现代码。基础设施功能（如安全、事务和可靠消息传递的使用）都是采用声明方式处理的，已从实现代码分离。SCA 通过策略使用基础设施功能，而策略旨在简化控制功能如何应用到业务系统的机制。
值得一提的是，SCA还促进了使用服务数据对象(SDO)来表示形成参数和服务返回值的业务数据，从而提供了对业务数据的统一访问方式，对 SCA 本身提供的业务服务统一访问方式形成了补充[8]。本文正是基于这个特点，将SDO作为业务数据的载体来实现数据服务的改进。
think58