存档三月 28, 2006

应用SOA和本体存在的不足和问题

SOA/Web服务的特点是灵活,平台和语言独立,服务可以通过简单的、设计良好的界面在Internet上发布和提供,服务效果和效率都有一定的保证。然而SOA/Web服务的架构目前还不成熟,仅仅依靠目前Web服务的一系列标准,对于语义互操作是不够的,困难至少有如下一些:

  • 缺乏对于“内容语义”信息(作为传输对象的语义)的描述机制(语义本体);
  • 缺乏对于“服务语义”(描述服务过程和行为的语义)的描述和共享机制(服务本体);
  • 缺乏发布和共享相同或相类似的服务,使同类服务尽可能得到重用而不重复的机制(注册体系及本体的建立、转换、映射、融合的机制);
  • 缺乏服务前提条件以及服务后果的描述;
  • 缺乏对自由组合的服务的质量控制和保证机制。

对上述困难的解决办法是进一步定义一些语义标准,使基于本体的语义互操作体系架构得以规范化。本项研究的努力也在于此。

本体的应用也存在问题:

本体目前被普遍用来对于领域知识或领域知识之间的联系进行形式化的表示,其理论和实践工具逐步成熟,成为建立系统内和跨系统互操作,特别是语义互操作不可缺少的工具。然而本体的应用有两个困难:

1. 本体建立的门槛过高。能够掌握本体建立方法、形式化方法和工具的不可能是普通用户,而且一般的专家都不行,需要“跨学科”专家,起码是建立本体的团队需要懂得领域知识和本体知识,可能还要有足够的计算机基础。这带来两方面的问题:本体普及的困难同时代价高昂,以及本体方法不可能广泛普及。

2. 获得对领域知识的共识是一件非常困难的事情。领域知识的丰富多彩,内部的不一致、不统一、相互矛盾的问题,多种“学说”、“学派”共存的问题,等等。

这些问题也带来本体的管理、版本控制、映射/翻译/合并拆分的困难。

对于上述问题,可以采取1、专家建立标准、大众使用的模式;2、允许容错,建立“半形式化”本体的方法来部分地解决,要知道a little semantics goes a long way,虽然不完美,但是根据20/80定律,仍然也能解决绝大多数应用中所需的语义互操作问题。

本体与SOA作为一种方法论和体系架构,现有的技术成果可能并不能完全解决语义互操作问题,还需要有所发展。但是已经是我们看到了解决数字图书馆语义互操作问题的曙光。

评论(1)

SOA与Web服务

面向服务的架构SOA最早是Gartner公司于1996年就提出了,但是它的广为传播却是由于近年来Web服务的兴起和普及。SOA从本质上说是一种理念和体系架构,而Web服务为其提供了可操作的实现手段。尽管Web服务不必以SOA方式实现,并且SOA也可以不基于Web服务,但是目前业界普遍承认Web服务是实现SOA的理想方式。Web服务提供了一整套相关技术(当然还不够),例如XML、简单对象存取协议(SOAP)、和Web服务描述语言(WSDL)、发现和集成(UDDI)等等,这些技术为Web服务自身的消息传送和接收,以及消息传输协议的绑定提供了灵活的、可扩展的语言支持,能够帮助人们针对具体的消息和应用找到编程的方法,从而实现SOA架构所提出的理念。因此,Web服务又可以看成是一系列的标准规范,而SOA是一系列的设计原则。这两种技术目前在应用中正互相促进,发展势头迅猛。

由于SOA和Web服务的上述特性,非常适合于用于实现数字图书馆的基于本体的语义互操作。

  1. 数字图书馆语义互操作是一种逐步进化的、分步实施的、分散维护的应用。
  2. 数字图书馆语义互操作需要支持时时更新的、多线程并发的、组合型的、实时的应用;
  3. 数字图书馆语义互操作在系统建立时需要支持“事件驱动架构”(EDA: Event-driven Architecture),而SOA与EDA具有很好的互补性;
  4. 灵活的业务流程管理需要同时支持SOA和EDA。

留言

关于SOA

SOA是一种软件架构,由一组独立的、自我描述的服务组成,并能够通过标准的方式进行访问。服务在其中作为粗粒度的,可被发现的,自解释的对象、实体或者构件,可以与其它服务或应用进行交互,并且常常是通过松散耦合的、异步的、基于消息通信的方式进行交互。各个单独的服务即可以独立提供服务,也可以组合成完整的服务过程[1]

SOA也可以看成是服务与用户之间的一种联系,每个服务模块都能够独立完成一定的功能,用户(通常是软件代理)通过服务界面(中的名字)进行调用(通常是通过请求-回复的消息机制)。一般说来,SOA非常适合解决Internet环境下的不同应用之间的业务集成问题,这个环境具有以下特点:

1 异构信息系统都是具有独立功能的实体,相互之间只具有松散联系。
在Internet这样松散的使用环境中,任何访问请求都有可能出错,因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。 SOA非常强调架构中提供服务的功能实体的完全独立自主的自我管理和恢复能力,比如事务处理(Transaction),消息队列(Message Queue),冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

2 基于文本的消息传递
传统的组件模型二进制编码在服务器和客户端之间传送对象,客户端通过对象调用实现某些功能。但是在Internet环境下,平台、语言和数据的异构给不同的服务之间传递对象带来的很大困难,由于基于文本的消息本身是不包含任何处理逻辑和数据类型的(或者说其包含的逻辑和数据定义对于传输过程是没有意义的,由接收方进行解析),因此服务间只传递基于文本的消息,具有最大的适应性和兼容性。
并且对于一个服务来说,Internet上各类服务和有关定义信息的版本管理几乎只能采取基于文本的消息传递方式,一方面服务使用方无法事先得知服务提供方的版本更新情况,但可以选择“兼容”的版本;另一方面可以只选择处理自己所需的,或者所能够解析的那部分数据,而忽略其它的数据。

3 海量数据的低频次访问
对于传统的分布式计算而言,通常都是通过函数调用的方式进行资源调用,一个功能的完成常常需要客户端和服务器来回多次。在Intranet环境下多次调用往往产生难以预计的后果,因此SOA系统推荐采用大数据量的方式一次性进行信息交换。

SOA具有以下六方面的优点:

  1. 定义界面和数据结构的标准简单;
  2. 语言和平台独立,基于标准,允许应用调用任何设备、基于任何软件和操作系统的服务;
  3. 服务界面与应用分离,允许许多服务自主升级而不影响用户使用;
  4. 面向消息的通信可以在广域网上提供分布式服务;
  5. 服务之间的松散耦合,使服务之间的相互依赖最小化,有利于服务的重用;
  6. 服务的发现机制,以及建立服务连接、组合服务的能力等。


[1] Brown, A., Johnston, S; & Kelly, K. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications. White Plains, NY: Rational Software Corporation, IBM, 2002.

评论(2)

关于实现“语义互操作”的技术路线

使机器能够处理“语义”是目前信息系统互操作所追求的最高目标。硬件平台能够“兼容”,通信协议取得一致,数据格式得到通用,软件系统也实现了“跨平台”,只剩下一个问题:信息内容的“语义”(即“意思”)经过传输之后,能否得到理解,怎样得到理解?得到理解的条件是什么?如何保证理解不走样?

对于具体的数字图书馆或者一个封闭的系统来说实现语义互操作可能并不难,即使是考虑到足够的灵活性和可扩展性,采用开放的软硬件平台,通过一系列严格定义的标准规范也能做到,例如传统的情报检索系统,或者用数据库系统实现的信息系统,都具有良好的语义一致性。但是在开放的网络环境中就不那么容易了,语义的规定不受同一控制,互操作要顾及各个层面,标准规范的制定和执行,永远是滞后的,标准规范使用的范围,永远只能在有限的领域范围内,其“效力”也不可能是强制的,其内容也不可能兼顾到方方面面,等等等等,这些因素,造成标准规范作用的局限性。

因而除了所需的各种标准规范之外,我们还需要一定的系统架构来保障语义功能的实现。这种架构就是面向服务的架构SOA,其主要实现形式为Web服务。

评论(1)