面向资源架构的知识组织应用研究，本文主要内容关键词为：架构论文,组织论文,知识论文,资源论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
1 引言 目前，人类社会已进入了数据大爆炸时代，据IDC统计，全球数据产生量仅2011年就达到了1.8ZB(约1.8万亿GB)，比2010年增长47%[1]。这一现状下，知识服务已不局限在文献服务，而是以一种包含问答式检索、倾向性分析、情感计算等功能的新的网络应用理念服务于人们日益变化的信息需求，方便于人们从互联网上按需获取知识[2]，而知识组织是实现上述理念最重要的基础。 目前，对知识服务和知识组织的研究主要集中在理论和方法上。姜永常[3]探讨了知识服务与信息服务的区别。王曰芬等[4]利用共现分析构建概念空间和本体实现语义检索，用于改进知识组织中文本分类的效果。夏立新等[5]结合知识服务提供方与最终用户，构建了基于知识供应链的知识服务模型，实现了按用户行为过程来组织服务活动。蒋勋等[6]从协同合作的视角研究了知识服务中社群成员的选择问题。苏新宁[7]探讨了知识服务的类型，并从知识服务的角度研究了知识组织的理论、技术与方法。杨锐等[8]研究了知识组织中语义化开放接口的主要功能实现方式。沈思等[9]对知识组织中的分类表进行了研究，分析了分类表的知识组织结构，并给出了分类表的机器组织方式。李冬冬等[10]在用户信息行为的基础上界定了个性化知识服务的概念，构建了用户信息行为与个性化知识服务的关联性。 现有研究丰富了知识服务与知识组织的内容，但很少涉及技术实现。知识组织本质是对海量数据的采集、过滤、分类和萃取等数据集成和挖掘的过程。这一过程中数据的请求和响应方式直接决定了知识服务的效率，而针对海量数据，一个轻量级的软件集成技术显然是至关重要的。 在众多集成技术中，基于简单对象访问协议(Simple Object Access Protocol，SOAP)的Web服务是目前应用最广的一种[11]。通过该技术，信息系统可将相关功能和数据以软件服务的方式对外公开，在此基础上构建中间件，即可实现系统集成[12-13]。SOAP Web服务真正体现了以服务为中心的思想，其具有的高可重用性、松耦合性、统一接口及开放性等优势，使得Web服务成为面向服务架构(Service-Oriented Architecture，SOA)事实上的实现标准[14-15]。然而，随着学术界对Web本身及HTTP协议的进一步认识，相关学者发现SOAP Web服务的发布和调用均要通过HTTP的POST方法进行。事实上，HTTP协议还存在GET、DELETE及PUT等固有方法。这些方法本身即为常规的Web应用而设计，几乎可以满足所有的应用场合，通过SOAP协议来处理Web应用无疑是舍近求远的做法。针对这个问题，基于REST理论的面向资源架构(Resource-Oriented Architecture，SOA)被逐渐提出。 面向资源架构(SOA)不仅完全遵守Web标准，而且其具有轻量级数据管理的特点，正可作为知识组织实现的技术手段之一。本文将从分析HTTP协议入手，对面向资源架构的起源、理论、开发框架进行概述，并给出基于面向资源架构的知识服务总体框架，探讨面向资源架构在知识组织实现中的应用。 2 面向资源架构理论分析 面向资源架构以REST为基础理论，而REST则起源于学术界对Web及HTTP协议的进一步认识，因此，要对面向资源架构有清晰的认识，首先需要对HTTP协议进行分析。 2.1 HTTP协议分析 HTTP是基于文档的协议，文档是对请求和响应内容的封装。客户端使用HTTP协议向服务器发送请求时，先将请求内容封装成文档，放在信封里发送给服务器；服务器收到信封后，先取出文档并对其解析，得到请求的内容，再根据请求内容将响应封装成文档，放在信封里返回给客户端[16-17]。 HTTP协议是互联网通信协议之一，由于其简单灵活而被广泛接受和应用，任何基于HTTP协议的Web应用均按照以上方法进行请求和响应。总体来讲，有两个因素决定了HTTP请求能否正确执行：作用域信息和方法信息。 作用域信息是客户端指定要操作的数据对象。在Web中，作用域信息一般置于网址或HTTP文档主体中。前者是指在浏览器里直接输入指定信息的网址，如在浏览器中输入地址http://www.baidu.com/s?wd=rest，这一请求的作用域信息为/s?wd=rest，即客户端告诉百度其需要的是rest的信息。后者则是将作用域信息置于HTTP文档主体中，SOAP Web服务即采用这种方法。同样是查找wd=rest，SOAP Web服务则先把wd=rest信息封装成XML文档，再发送给服务器。服务器接受到该请求后，需要先对HTTP文档主体进行解析，得到wd=rest信息后，才能进行数据处理。相比第一种方法，该方法多出一个解析步骤。 方法信息即HTTP请求方法，规定了操作对象时采取的方法。常用的HTTP请求方法有GET、POST、PUT、DELETE四种[18]，分别规定了对服务器数据的获取、增加、更新、删除等操作。 上述两者的结合足以满足所有Web应用的场合。然而，一般的Web应用在提交请求时，仅使用POST和GET方法就实现了所有的CRUD(Create Retrieval Update Delete)。如删除操作通常以GET方式提交要删除数据的唯一标识，由服务器端来判断和定位数据，并执行删除操作。SOAP Web服务则是将作用域信息置于文档主体中，并且一律采用POST方法来提交请求。这两种请求方式均没有充分利用HTTP协议的特点，在面对复杂的数据请求时，显然会造成请求混乱或意义不明确等问题，违背了HTTP的设计初衷。为此，Roy Thomas Fielding博士提出了REST模式的Web架构。 2.2 REST研究 REST是Representational State Transfer的简写，中文名为表述性状态转移，是对良好Web应用进行定义的网络架构模式，这一概念由Roy Thomas Fielding[19]于2000年在其博士论文中首次提出。在一个REST模式的Web架构中，所有需要操作的事物均被抽象为资源。每个资源均被赋予一个资源标识符URI，URI既是资源的名称，也是其访问地址。用户通过URI可以获得资源的表示，即Web页面。不同的资源表示中又包含了其他资源的URI，通过这些URI又可以获得其他资源的表示。其中Web页面代表了资源的状态，而Web页面之间的切换，即状态转移。将一个Web应用设计成REST模式应满足以下6条约束。 (1)客户—服务器：该约束将用户接口与数据存储两个关注点分离成客户和服务器，以增加Web程序的跨平台性，简化服务器组件，并提高系统的可收缩性。 (2)无状态：该约束要求客户端向服务器发送的每个请求都必须包含此次请求所必需的所有信息，其请求状态全部保存在客户端，而不需要利用服务器上的任何信息，使得客户端和服务器端相对保持独立。 (3)缓存：该约束规定服务器响应的数据需要被隐式地或显示地标记为可缓存或不可缓存，以提高客户端对响应数据的使用效率。 (4)统一接口：该约束要求对每个Web组件的操作均通过统一接口进行，以简化Web系统架构，明确每次请求的目的。这是REST模式区别于其他Web模式的核心特征。 (5)分层系统：该约束将Web架构分解为若干等级的功能层，并要求各组件只能与紧邻层交互，以使Web应用内部结构更清晰，更具目的性。 (6)按需代码：该约束指客户端可以以下载并运行服务器代码(而非数据)的形式对自身功能进行扩展，以增加其灵活性。该约束为可选项。 这六条约束可视为从“零Web”推导至REST式Web所需经历的六个步骤，同时也体现了Web架构的发展过程，如早期静态网页式的Web架构即满足前三条约束的定义，而目前各类动态Web框架则关注于系统分层约束。但是，Roy Thomas Fielding仅仅给出了约束的定义，而并未给出具体的实现方案。在此基础上，Leonard Richardson等[20]在其专著RESTful Web Services中，对REST给出了更详细的解释，并提出了RESTful Web服务这一概念。 2.3 RESTful Web服务研究 RESTful Web服务是符合REST模式的Web服务。Leonard Richardson等认为符合REST模式即每次Web请求均采取HTTP方法，且所有作用域信息均包含在URI中。在该前提下，RESTful Web服务将一切与业务相关的事物抽象为资源，并为每个资源设计一个唯一标识。该标识即URI，其包含了请求的作用域信息。针对该URI，使用不同的HTTP方法发送请求，则实现对应资源的CRUD操作，从而完成各类业务操作。表1为使用不同HTTP方法向同一个URI提交请求时能够实现的功能。
RESTful Web服务对外公开URI即对外发布服务，用户只需按照标准的HTTP方法向URI发送请求即可实现对资源的相应操作。RESTful Web服务的请求和响应如图1所示。
图1 RESTful Web服务的请求和响应 客户端向服务器端发送请求时，先将相关信息进行封装，再使用相应的HTTP方法发送至对应的URI。当服务器接收到该请求后，首先判断请求的方法类型，根据不同的方法信息，执行相应的增加或更新操作。当操作执行完成后，服务器将响应信息以HTML、XML、TEXT或JSON等格式封装后置于HTTP文档主体中，返回至客户端。客户端获取服务器返回的信息后，先根据不同的信息格式采取相应的方法对其进行解析，最后再展示给用户浏览。 从上述过程可以看出，对于资源获取和删除操作，客户端只需知道URI即可。而对于增加和更新等操作，除了需要知道URI外，客户端还需要知道要提交哪些信息。尽管这些信息可以从现有资源的详细信息中推测得到，但这么做就违背了软件服务的宗旨。针对这个问题，Sun公司推出了Web应用描述语言(Web Application Description Language,WADL)[21]，用于描述客户端可以访问的URI、访问的方式、提交请求的格式以及返回的数据格式等请求和响应信息。 与SOAP Web服务相比，RESTful Web服务从以下三个方面进行了优化： (1)服务请求和响应。SOAP Web服务使用SOAP协议进行服务的请求与响应，这一方式不论是客户端还是服务器端，均需要进行XML的处理工作。从HTTP协议的定义来看，SOAP相当于创造了一种新的机制来完成HTTP本身可以完成的工作，而RESTful Web服务则完全遵守HTTP协议进行信息传输，在信息传输和解析的效率方面，RESTful Web服务明显要高于SOAP Web服务。 (2)服务描述和发布。SOAP Web服务使用WSDL对服务进行描述和发布。本质上，WSDL是一个结构复杂的XML文档。而与之功能类似的WADL，虽然也是XML，但对于同一个服务的描述，其远比WSDL简洁。如对方法public String SayHello(String name)的描述，WSDL总字符数为1309个，而WADL则只有360个。 (3)服务主体的发布。SOAP Web服务的主体通过UDDI来发布。UDDI由于结构复杂、不便使用，已逐渐被市场遗弃。而RESTful Web服务对外公开URI即发布服务主体，不需要借助任何额外的机制，并且，由于URI与普通网址类似，也易于被搜索引擎发现。 从以上三个方面可以看出，RESTful Web服务是一种轻量级的、灵活的Web服务，其充分利用了HTTP协议，体现了“网站就是Web服务”的思想[22]。 2.4 面向资源架构研究 2004年，IBM的软件工程师James Snell[23]提出面向资源一词，随后面向资源架构(Resource-Oriented Architecture，ROA)的概念由Alex Bunardzic[24]正式提出，但他们均没有给出系统的定义和解释，只是作为面向服务架构的对立面提出。真正系统地对ROA进行定义，并给出详细架构的依然是Leonard Richardson[20]，他将ROA定义成一种将实际问题转换成RESTful Web服务的方法，提出了资源、资源标识、资源表示和资源链接四个概念对ROA进行定义。 (1)资源 资源(Resource)是用户需要操作对象的核心抽象。一个资源是一组实体的概念化映射，任何可以被命名的事物都可以成为资源，比如一个苹果或一个文件等。 在数学领域，资源R是以时间t为自变量的成员函数，该函数将t映射到等价的实体或值的集合中。资源可以随着时间t的变化而变化，也可以在某个特定时间段映射到一个空集上。如“2011年世界500强企业排行榜”，在《财富》杂志2011年推出以前为一个空集，而“世界500强企业排行榜”则随着年度的不同而不断变化。资源也可以不随时间变化，是静态的，而且静态资源与动态资源在某些情况下会有交集，或完全相同，如“2011年××会议集中的所有论文”和“与Web服务相关的最新论文”。 在计算机领域里，资源是现实事物的计算机信息表示，通常表现为具有一定格式的文档或数据库表记录等信息实体。资源由标识和表示两部分组成。 (2)资源标识 资源标识(Resource Identifier)是对在Web组件交互中所涉及资源的唯一标记，也是访问和操作资源的通用接口，每个资源都必须具有一个资源标识。REST使用URI[25]作为资源标识。在Web中，URI既可作为资源的名称，也可作为资源的访问地址，是Web应用能够向前进行的基础。 一个URI只代表一个资源，任意两个资源都不能有同一个URI。但是两个不同的URI，在某个时期可能会指向同一个资源所代表的值，比如“软件最新版本”的URI为“http://xxx/latest”，“当前软件版本”的URI为“http://xxx/1.0”。当“软件最新版本”为1.0时，这两个URI指向同一个资源，但这是两个具有不同意义的资源。 由于采用了URI作为资源标识，使得ROA具备了可寻址性和无状态性两个特点。可寻址性是指用户只需在浏览器中输入URI，即可访问到资源，这一点是由URI在Web中的作用决定的。无状态性则是指每次HTTP请求是完全独立的，不依赖之前的请求，而这一点也是由URI可以包含调用服务的所有信息的特点决定的。 (3)资源表示 表示(Representation)是资源当前状态的数据显示，由资源的数据、表示数据的元数据和描述元数据的元数据组成。资源的数据是指资源的实质内容，表示数据的元数据则是对资源数据的信息描述，描述元数据的元数据则对表示本身的一些控制信息，这两类元数据通常以“名称/值”对的形式出现。表示的这一数据结构与HTTP协议的结构基本吻合，因此HTTP协议自然成为资源表示的最佳方法。而在HTTP协议的文档区，则可灵活选择HTML、XML、JSON或TEXT作为资源核心内容的表示格式。 资源的表示通常从服务器端传输至客户端，但也可以从客户端传输至服务器端，如新资源发布时，基本信息即由客户端提供。一个资源可以有多个表示，如同一篇文章的中文版和英文版，为了不违反一个URI只能对应一个资源的原则，通常将中文版和英文版视为两个不同的资源，通过不同的URI来访问。 (4)资源链接 在REST式服务中，资源表示通常为超媒体，其中不仅包括了核心的数据，还包括了通往其他资源的URI即链接。这些URI建立了资源之间的联系，实现了资源间的切换。资源链接的存在使得面向资源架构具备了连通性的特点。 这四个基本概念之间的关系如图2所示。
图2 ROA基本概念关系
图3 基于面向资源架构的知识组织框架 这四个概念中，资源和资源标识将实际问题转换成资源并赋予URI，而资源表示和资源连通性则确定了资源的状态及不同资源之间的调用关系，最终将实际问题转换成RESTful Web服务。 3 REST框架现状分析 REST框架是一套已经实现了资源、URI和统一接口等REST元素的API，这些API使得RESTful Web服务开发人员可以将注意力集中在业务资源设计和实现上，而不需要关注资源本身的结构、数据传输等底层问题，从而方便地构建具有面向资源架构的软件系统。比较有代表性的REST框架有Axis2、Ruby on Rails以及Restlet。 这三个框架各有优缺点，Axis2几乎可以在不了解REST概念的情况下，实现RESTful Web服务的开发和调用，是最简单的REST框架。正因为如此，Axis2不利于开发者对REST思想的理解，仅仅是一个快速开发的工具，并不适合作为学术探讨的对象。相比较Axis2，Ruby on Rails的开发过程更能体现出REST思想，但是该框架在发布之初并不支持REST，只是在后续版本中才加入对REST的支持，因此其中存在一些牵强的代码。而Restlet框架则完全遵守Roy Thomas Fielding在其博士论文中提出的REST目标，使用Restlet开发REST程序，将有助于研究人员加深对REST及RESTful Web服务的理解。 Restlet是Noelios Consulting于2005年发布的，基于Java的轻量级REST框架，该框架在实现Servlet、JSP、HttpURLConnection等Web技术功能的前提下，最大程度地遵守了Roy Thomas Fielding论文中所阐述的REST目标[26]。该框架中，Application、Router、Resource和Representation是构建完整的REST程序不可缺少的类。Router类负责接收用户请求，并根据HTTP方法调用相应的功能，起到路由的作用；Application则将Router类注册至项目中，起到管理Router类的作用；Resource类则用于构建资源；Representation则用于表示数据，几乎所有数据的返回均是通过返回Representation来实现。 使用Restlet构建RESTful Web服务的主要步骤为： (1)定义基本功能类，包括业务方法以及数据访问接口。 (2)设计URI。 (3)通过继承Resource类来构建资源类，实现资源的发布以及功能的调用。 (4)通过继承Application类构建应用程序类，其中使用Router类建立资源类和URI之间的映射关系，起到请求路由的作用。 (5)将创建好的项目发布至Web容器。 4 面向资源架构的知识组织应用 从上述分析可知，面向资源架构在系统的开放式改造和信息集成方面有着明显优势，而这两方面正是实现知识组织的技术内容之一，其应用框架如图3所示。 如图，应用面向资源架构对异构系统进行改造后，系统的各类信息分别以各自的URI对外开放，任何应用程序只要遵守HTTP协议，向对应的URI发送HTTP请求，即可实现相应的CRUD。在这种情况下，第三方应用系统可以方便地对异构系统进行访问，而在此基础上，可以方便地构建知识服务平台实现海量数据的集成。在此基础上，再进行过滤、分类、挖掘，最终为用户提供所需知识。在互联网普及的知识服务环境下，这种方式的集成与访问，无疑是最符合目前互联网现状的，可应用于网站、移动式应用、数据中心等多种数据源场合，而且其集成和访问成本也显然是比较低的。 5 结语 面向资源架构起源于REST理论，发展至今仅仅10年，但自REST提出开始即引起了学术界对Web及标准HTTP应用的重新认识。相比较面向服务架构，不论在信息的发布还是信息的获取上，面向资源架构均具有明显的优势，应用面向资源架构可以更方便地构建一个信息开放的环境。这一点恰是展开知识服务技术实现研究的基础，同时也满足目前网格计算、云计算等主流技术的信息管理需求。然而，本文的研究仅仅是应用面向资源架构实现知识组织的初步探讨，知识组织平台的构建、数据的挖掘、知识的萃取等问题将是下一阶段的工作。
标签：rest论文; restful论文; soap论文; uri论文; 面向服务架构论文; 架构论文; 用户研究论文; web技术论文; web容器论文; 应用架构论文; 客户端服务器论文; 信息架构论文; 服务器类型论文; web开发论文; soap协议论文; http协议论文; http请求论文; rest软件架构论文; web服务器论文;
