(技术报告)web服务和语义web技术简介_v1.01new

《(技术报告)web服务和语义web技术简介_v1.01new》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

[技术报告]Web服务和语义Web技术简介(V1.01)赵文峰2010.5.10摘要本文档对Web服务(WebService)和语义Web(SemanticWeb)技术的背景、截至2009年11月为止的主要标准提案做了一个较全面的笔记，并有一定的总结归纳和分析评论，适合于这两个领域的初学者快速了解领域概貌，其中有些表格对其他人员也具有一定的参考价值。其中前两节关于Web服务的和第3节关于语义Web内容相互独立，可以分开阅读。版本历史：1.02010.5.10,赵文峰,整理去年年末的笔记而成。1.012010.7.7,赵文峰,修正了少许排版错误。北京邮电大学网络与交换技术国家重点实验室网络服务基础研究中心 目录1Web服务的起源和背景........................................................................................................................11.1Web服务的起源.........................................................................................................................11.2Web服务与SOA的关系...........................................................................................................51.3Web服务的其它应用.................................................................................................................82Web服务技术概览..............................................................................................................................152.1核心标准及扩展机制...............................................................................................................182.1.1SOAP.............................................................................................................................182.1.2WSDL............................................................................................................................192.1.3增强WSDL的WS-Policy和WSPL...........................................................................212.1.4增强SOAP的WS-Addressing等...............................................................................222.2基本的扩展标准.......................................................................................................................232.2.1安全...............................................................................................................................232.2.2可靠消息传递...............................................................................................................242.2.3事务处理.......................................................................................................................252.3其它扩展标准...........................................................................................................................262.3.1元数据注册和交换.......................................................................................................262.3.2组合...............................................................................................................................262.3.3增强的MEP..................................................................................................................282.3.4资源及其状态...............................................................................................................282.3.5管理...............................................................................................................................292.4综合使用这些标准——部署和开发模型...............................................................................303语义Web..............................................................................................................................................323.1数据模型及其语义：RDF/RDFS............................................................................................333.2本体——RDFS，OWL和描述逻辑.......................................................................................363.3规则——DLP,SWRL和RIF...................................................................................................403.4RDF数据的查询和生成——SPARQL、GRDDL等.............................................................443.5更进一步——语义Web研究及应用现状..............................................................................463.6语义Web服务标准及提案......................................................................................................474参考文献...............................................................................................................................................50 技术报告《Web服务和语义Web技术简介》1WEB服务的起源和背景RPCREST,即ROAWeb(ONC/RPC,DCE/RPCRSS/Atom等)FlashWeb面向对象单机式组件HTTPHTMLAjax(COM)MashupIT设施的托管租用分布式对象技术Web2.0(CORBA1.0,RMI,ActiveX云计算SaaSDCOM)MOMTPMonitor(MQSeries,(Tuxedo等)B2B电子商务MSMQ等)(ACE)EDI(EDIFACT,XMLX12,HL7)分布式组件技术(CORBA3.0,J2EE,DCOM+MTS/.NET,ICE)办公自动化基于XML的EDIWorkflow技术(ebXML,RossetaNet)(WPDL/XPDL)SCM电信网业务层WebServicesCRMERP(Parlay/(SOAP,WSDL,WS-*;ESB)BusinessProcess企业计算...ParlayX)(WS-BPEL)Mgmt.(BPML,BPMN)(OpenGIS)EAISOA地理信息系统网格(OGSA数据仓库/WSRF)科学计算A(B)技术(标准或产品)演化出应用领域图例用到了架构图1Web服务、SOA的来历及与其它技术的关系基于SOAP和WSDL的Web服务技术的出现，是分布式计算技术在互联网时代自然发展的结果，它的出现正好满足了企业IT系统在转向面向服务的体系结构(Service-OrientedArchitecture,SOA)时的技术需求，因此近几年来受到了产业界的高度重视；另外，Web服务也已成为网格技术的主流实现技术，也已经被用于电信业务提供、地理信息系统、Web2.0等许多领域。这些技术或架构之间的关系可粗略表示为图1。1.1Web服务的起源分布式计算技术用于构建跨越不同机器的软件系统。这样的系统可以直接基于操作1 技术报告《Web服务和语义Web技术简介》系统层的Socket构建，其它分布式计算技术都是工作在Socket之上的，但它们屏蔽了底层细节，提供了一些常用的抽象，大大简化了较复杂系统的构建过程。最早的分布式计算技术是RPC(远程过程调用,RemoteProcedureCall)。Internet的前身ARPANET刚出现时，每种应用（如发送邮件、传递文件、传送语音）都由专门的协议来实现。后来，为了将这些协议中的共同部分抽取出来以便复用，在1970年代后期[1]产生了RPC的思想，它可用于实现网络范围的进程间通信，调用其它机器上的子程序。其开发、运行时的原理如图2所示，此后的CORBA、Web服务等分布式技术的基本原理都与此类似。基于IDL类语言的Client接口描述Server根据标源业务相关代码，运行在注码业务相关代码由自中的RPC产品提供的容器中工动生成具XOR生动自成调用动生调用成工具自Stub:编码/解码由Skeleton:编码/解码RPC产品模块(如:ORB)RPC产品模块(如:ORB)运行时接口消息网络图2RPC类分布式系统开发和运行原理RPC有多种实现，应用最广的是Sun公司提出的ONCRPC(OpenNetworkComputing[2][3]RPC,也称SunRPC)，它使用类似于C语言的接口描述语言RPCL(RPCLanguage)来描述过程接口，用RPCGEN工具可以根据RPCL文件生成对应的C语言头文件和客户端、服务器端的代理(Proxy,客户端代理也被称作存根(stub)，服务器端代理有时被称作框架(skeleton))，在运行期间代理负责在客户端和服务器之间传送客户端调用远程过程时的输入输出数据。ONCRPC使用UDP和TCP端口号111来传递基于二进制的过程调用请求和响应消息，其中请求消息中显式地指出程序名称和过程名称，数据编码使用基于二进[4]制的XDR(eXternalDataRepresentation)。RPC的其它实现有开放系统基金会的1DCE/RPC(DistributedComputingEnvironment/RemoteProcedureCalls)等多种，包括Windows平台上也有，但总的来说，主要用于Unix平台上的C语言编程。RPC中的通信是同步的，为了在分布式系统中实现异步调用，从1980年代中后期开始，出现了面向消息的中间件(MOM,MessageOrientedMiddleware)，如IBMMQSeries,1http://www.opengroup.org/dce/2 技术报告《Web服务和语义Web技术简介》MSMQ,TibcoRendezvous等，它们通常使用带有持久性机制的消息队列，在以异步方式通信的分布系统之间实现了可靠的消息传递，通常还支持subscribe/publish消息模式，适用于构建事件驱动的系统。为了满足在金融等行业对高可靠性、可扩展性的要求，从1980年代起还出现了面向事务的中间件（或称事务处理监视器,TPMonitor），除了实现分布式环境下的事务处理外，这种产品还实现了分布式应用的管理功能，包括服务的启动和关闭、服务间共享资源(如数据库连接)的管理、负载均衡和容错。产品有：如BEATuxedo和IBMCICS等。随着面向对象编程语言的流行，RPC系统也有了面向对象的对应物。主要有1991年OMG组织发布的CORBA(CommonObjectRequestBrokerArchetecture)1.0，1996年底微软推出的DCOM(DistributedComponentObjectModel)和1997年随着JDK1.1发布的RMI(RemoteMethodInterface)。比起本地的面向对象技术，分布式对象技术中需要解决如下新的问题：1）需要有一个超越本进程空间和本机的类的命名和对象定位机制；2）考虑到网络能出现阻塞甚至瘫痪，系统要具备分布式对象管理能力以自动跨越故障。如服务器端需要有能力自行销毁一个由客户创建、但客户未能及时销毁的对象，这需要服务器端有专门的对象管理系统接管对象引用，让客户端通过它间接地引用远端对象。另外，由于Internet上传输时延可能很大，往往要求系统具备传递异步消息的能力，还有一些功能如事务管理、安全、持久性、负载均衡与可扩展性等在构建较大系统时会经常遇到，为免于重复发明轮子，需要计算平台以基础服务的形式统一地提供，让开发者专注于与业务逻辑相关的开发工作。在计算平台中支持这些的结果，便形成了分布式组件技术。在这种结构下，系统由组件及其容器组成，容器以中间件的形式提供了对象定位、分布式对象管理、负载均衡及容错、异步消息传递、事务管理、安全、持久性等基础服务；组件专注于自己所要提供的功能，部署在容器中运行，一般通过简单的编码或配置即可利用容器提供的基础服务。Java世界中，该类型技术始于1997年底发布草案的EJB(EnterpriseJavaBean,最初以CORBA作为通信机制后来改用RMI)，它与其它基础设施一起构成了J2EE。受此影响，于1999年开始研究的CORBA3.0（2002年成为正式标准）中引入了CORBA组件模型(CORBAComponentModel,CCM)。而微软的COM(ComponentObjectModel)技术，在1990年代初期诞生时定位于同一机器上跨越多种编程语言的二进制复用技术，在加入DCOM具备了分布计算能力、2000年与MicrosoftTransactionServer(MTS)整合后成为具备了上述大部分功能的分布式组件系统。这三种技术的简要比较见表1。3 技术报告《Web服务和语义Web技术简介》表1三种主要的面向组件的架构的基本情况COM/DCOMCORBAJ2EEIBM,Sun,BEA等众多厂主要推动者微软Sun,IBM等商组成的OMG各种主流系统（通过Java支持的操作系统以Windows为主各种主流系统虚拟机）C/C++,Smalltalk,Java,C/C++,VB,Delphi,支持的开发语言Ruby,Python,Lisp,以Java为主VBScript,JavaScriptCOBOL,Ada,PL/IOMGIDL,CIDL(3.0中随接口描述语言MicrosoftIDLJava，或JavaIDLCCM引入)抽象协议GIOP及其主要JRMP，或RMIoverIIOP运行时接口协议基于DCE/RPC实现IIOP(以与CORBA互通)靠GUID(散列而得的NamingService，以及对象定位机制128bit随机数)标示COMTradingObjectService(按JNDI类能力描述查找)分布式对象管理POA(PortableObject机制（含负载均靠MTS提供Adapter)提供了一个基础靠EJB容器提供a衡机制）架构EventService和JMSAPIover各种具体的异步消息机制使用MSMQbNotificationServiceMOMJavaTransactionServiceObjectTransactionService事务管理机制靠MTS提供(JTS)和JavaTransaction(OTS)API(JTA)JavaAuthenticationandDCOM引入了DCERPCAuthorizationService的安全服务；MTS提供一安全机制SecurityService(JAAS),以及Java个可说明的安全框架和简GSS-API,JCE,JSSE,化的编程模式SASLentitybean;EJB3.0后被更CIDL的子集Persistent简单的JavaPersistence序列化机制无明确规定StateDefinitionLanguageAPI代替；支持对象到关做了规定系数据模型的映射COM作为控件(可视化的在一些关键的应用如电信本地组件)技术在网中使用较多；但2002年Windows中应用很广；V3.0.2之后标准再无更在企业计算中应用较多；应用状况2002年后基本被.NET继新；且因标准庞杂但有些2006年发布了EJB3.0承和代替，在基于规定却不明确导致各ORBcWindows平台的应用中使实现不易互通，受到了用较多。ICE,J2EE等的挑战注：a.但仍不够，实现中需要额外的设计，如BEA借鉴其具有分布式对象管理功能的事务管理中间件产[5]品TUXEDO推出的M3在POA之上工作。[5]b.但不够具体，各厂商实现时常与各自的消息处理产品结合如用TibcoRendezvous代替IIOP。c.文献[6]中列出了CORBA多项设计缺陷，并认为原因在于其采用委员会投票方式制定标准，但其成员接纳、标准提议、冲突协调等方面机制有重要缺陷，如在没有参考实现时就推出标准。分布式组件系统并不限于这几个。如前面提到的DCE/RPC中，也提供了目录和安全服务，也加入了对分布式对象的支持。再如ZeroC公司根据CORBA的经验教训也推出了4 技术报告《Web服务和语义Web技术简介》2一个分布式组件系统ICE，支持常见的多种操作系统和开发语言，并称其更优雅简单，性能更高，而功能要优于任何一个具体的CORBA实现。ACE(AdaptiveCommunication3Environment)则是另一个高性能的面向对象的用于分布式系统的中间件，它用C++封装了从进程间通信到消息路由的各种常见的通信机制，可看作一个支持更多通信方式的MOM，支持多种操作系统，基于ACE已开发了符合CORBA引用模型的ORB——TAO(TheAceORB)。20世纪末，Internet迅速发展，对J2EE/CORBA/DCOM等分布式组件技术提出了新的挑战。各企业、组织的网络防火墙大多设置成只对外网开放HTTP所用的80端口，而这几项技术都依赖于其它的访问协议，这使得它们难以构建跨越各组织边界的系统。另外，随着各行业信息化程度的加深和全球范围内市场竞争的更加激烈，需要IT系统能够在更广大的范围内、跨越不同的技术平台实现互联互通，这几项技术彼此之间也需要能够互联互通。为此目的，一些系统(如EJB和DCE/RPC)曾加入与CORBA的互通能力，但[6]4CORBA规范设计上的缺陷使得深度的互通仍然困难。由于现在几乎所有的技术平台中都支持ASCII编码，所以选择基于文本的而非二进制格式的消息来作为各种异构系统之间互通的接口就是很自然的了。事实上，Internet本身的成功也离不开HTTP/FTP/SMTP这些应用层协议基于文本的消息编码方式。在这样的背景下，UserLand公司与1998年提出了使用HTTP作为访问协议、用XML5编码消息内容的RPC机制XML-RPC协议后，微软等公司迅速跟进，将其功能增强后于2000年以SOAP1.1的名称提交给了W3C，并将其中的计算组件称作Web服务(WebService)。结合此后推出的接口描述语言WSDL和实现事务管理、安全、异步消息等的WS-*系列标准，最终形成了一个基于XML、以HTTP作为主要传送协议（也可以使用其它协议）、广泛使用URI作为各种实体的标示的分布式组件系统，统称为Web服务技术。目前，Web服务规范侧重于组件间的接口消息，而不涉及组件容器的行为，其定位主要是用分布式组件技术的模式来互通各种异构系统，而不是要取代前述已有的分布式组件系统。1.2Web服务与SOA的关系近年来在产业界受到热捧的SOA一词首先于1996年由研究和咨询公司Gartner提出，它不是一种技术，而是一种思想，是一套用于指导企业IT系统的建立和演化的指导原则。这些原则的核心是：技术要和业务一致，即一个服务对应于企业业务层的一个可复用单元而非底层实现技术的一个模块；可以说SOA是一种业务语言，它关注的不是技2http://www.zeroc.com3http://www.cse.wustl.edu/~schmidt/ACE.html4CORBA在这一点没有成功还有个商业上的原因：微软公司没有参与CORBA的制定，它力推Web服务。5http://www.xmlrpc.com/spec5 技术报告《Web服务和语义Web技术简介》[7]术细节。其它的原则包括：松耦合、具有良定契约、基于开放标准、可复用、能自治、[8][9]可发现、可组合、无状态(可选)等。目的是互通和整合企业内和企业间的各种IT系统，包括各种历史遗留系统和企业兼并过程中获得的异构系统，并通过业务层的复用提高IT系统的可复用性、使之在面对不断变化的业务需求时能够迅速地适应，如图3所示。对于企业间的B2B电子商务，SOA还可以使得其EDI（EletronicDataInterchange,电子数据交换）过程与企业内的业务流程实现无缝的集成。ServiceUIChannelsCompositeApp.PartnersConsumersPresentationServicesBusinessProcessServicesBusinessActivityServicesSharedServicesSOASecurityDataServicesSOAGovernanceSOAEventProcessingServiceMediation&MessagingConnectivityServicesOtherNone-ServiceEnabledAssetsSerivcesofPartnersResources图3SOA架构下应用的典型结构EDI方面的标准早期的有联合国EDIFACT、美国X12系列、医疗卫生业的HL7等，67基于XML的有联合国/OASIS的ebXML、一个IT制造业企业联盟发起的RosettaNet等。这些规范除了定义消息格式外，有的还定义了文档交换过程涉及的其它方面的内容，如ebXML和RosettaNet都定义了自己的业务流程模型、消息交换模型及其安全机制，其中ebXML的消息传递模型使用SOAP作为其底层协议无关的传输手段。另外，ebXML还定义了自己的注册机制(也实现为SOAP服务)，但其注册机制、安全机制、消息可靠传递机制使用的都是自己定义的SOAP扩展而非UDDI和WS-*协议，其原因部分地在于该标准制定得比较早(2002年)。在企业内IT系统整合方面，早期的工作有数据仓库、ERP(EnterpriseResource6http://www.ebxml.org/7http://www.rosettanet.org/6 技术报告《Web服务和语义Web技术简介》Planning,企业资源规划)和EAI(EnterpriseApplicationIntegration,企业应用集成)。数据仓库只涉及数据层面的整合，通过将企业各部门的数据通过提取、转换、加载(ETL)集中地复制到一个中心数据仓库中，对其中的数据进行OLAP(On-LineAnalyticalProcessing)分析（以便按照各种角度、各种聚集方式显示数据）、甚至挖掘（以发现数据间隐含的关系）可实现决策支持系统(DecisionSupportSystem)，但它不涉及业务层面的整合。1990年代初期形成的ERP的概念源于60年代出现的MRP(MaterialRequirementPlanning,物料需求规划)系统，后者用于在制造业企业内生产流程的各个阶段间调度原料的投放量以使得效益最大化；80年代MRP与企业的营销、财务、人力资源系统整合实现了在更大范围的调度，形成了MRPII；到90年代初，还是Gartner公司提出，将MRPII与80年代兴起的、以与上游供货商进行整合为目的的供应链管理系统(SCM,Supply[10][11]ChainManagement)结合，形成了ERP。目前，SAP、PeopleSoft、J.D.Edwards、金蝶等公司的ERP系统在制造业和其它行业拥有较广泛的应用。虽然ERP虽然整合了多种IT系统，但它整合的方式是革命性的，ERP产品在形式上是一个庞大的、包含了上述多种系统的、体现了行业内最佳业务流程的综合系统（针对小企业会有简化，但仍然是单一产品），厂商依赖度高，虽然一般都带有一些适配接口，但仍不利于重用企业原有的各种专门系统，也不便针对特定企业的特点进行调整。另外，ERP所整合的IT系统仍然有限，如直到较晚时才开始支持前端系统如CRM(客户关系管理,CustomerRelationManagement)；各种市场调查的结果表明ERP系统一般只能涉及企业在信息需求方面的[12]25%-40%。EAI技术则基于一种演进式的方式进行整合，通过标准接口对原有各系统包括ERP、CRM、办公自动化、决策支持等系统进行包装，然后通过总线或hub-spoke结构的中间[12][13]件来连接各个系统，从而可以有效地解决ERP式整合方式的问题。由于缺乏更广泛的标准，EAI一般通过各种MOM、J2EE等平台来各自实施。这种思想再往前一步，便形成了SOA。Web服务系列标准的提出，使得EAI和SOA有了更加互通性更强的标准接口，促进了SOA思想的落地、实现，推动了EAI的发展。虽然从理论上讲，SOA也可以通过其它[9]类型的分布式计算技术（包括SOA一词出现之前出现的技术）得以不同程度地实现，如MOM,事务处理监视器、CORBA、J2EE、REST服务(见下一节)以及像ebXML和RosettaNet那样的B2B平台，但Web服务技术对其实现最为全面。因此，SOA一词在提出后的最初几年并未引起重视，直到Web服务技术出现后才受到产业界的热捧。另一方面，Web服务技术的应用虽不限于SOA架构下的企业计算，但其关于事务、安全、可靠消息传输等方面的内容，在SOA中发挥了重要甚至关键的作用，这些标准制定过程中的最大7 技术报告《Web服务和语义Web技术简介》驱动力也来自于SOA的需要；而在其它一些应用领域，由于对安全性、事务完整性要求不高，只有基本的SOAP和WSDL被用到。SOA采取在业务层面看待IT系统的一个结果，是Web服务被赋予了新的意义，它被看作一个业务活动，从而既可以被实现为一个可以在几秒钟之内完成的函数调用，也可以是一项持续时间长达几小时、几天甚至几个月、可能需要人工参与的业务任务，如下订单、收货。相应地，组合服务不再只被看作底层实现技术中一个调用了其它函数的新函数，而是更多地被视为一个包含了多个业务活动的业务流程。事实上，Web服务组合标准WS-BPEL本身就是由两个业务流程建模语言IBMWSFL和微软XLANG合并后形成的。它们出自业务流程管理(BusinessProcessManagement,BPM)领域，后者用于识别、建模、开发、部署和监控企业内各种由软件或人实施的活动组成的行事流程。虽然所有的IT系统都是以某种形式来支持和实现业务流程的，但BPM系统的独特之处在于它显式地将业务流程逻辑从其它业务规则中分离了出来。BPM是强调人机交互、以文档流转和处理为中心的办公自动化系统(OA,OfficeAutomation)中的工作流(Workflow)与后来出现的EAI的互通异构系统的技术能力相结合的产物；经过2002-2005年间的标准大战，现在形成了两种类型的标准，一种主要用于流程执行，[14]有WS-BPEL和XPDL等，一种用于业务建模和分析，有BPMN等，也可以使用UML。另外，在B2B领域中ebXML和RosettaNet也定义了自己的业务流程模型。需要注意的是，企业实施SOA的过程不是一个单纯的技术活动，而往往需要整个企业对业务重新梳理，甚至还需要相应地调整企业的业务流程，以便识别出可重用的IT资产，然后进行接口包装后接入新部署的企业服务总线(ESB,EnterpriseServcieBus)，一般初始开销较大，之后才能获得SOA架构灵活应变的回报。1.3Web服务的其它应用凭借良好的互通异构系统的能力，Web服务在企业计算之外也被广泛应用于其它需要互通和集成的地方。网格(Grid)8 技术报告《Web服务和语义Web技术简介》图4网格OGSA体系结构Grid一词于1998年出现，是另一个高度依赖互通的技术领域，现在Web服务在其中起到了关键的作用。该技术产生的背景是：科学研究中有些计算任务的计算量很大，存在着将其分解后交由互联网上成千上万台计算机合作完成的需求；另外，科研中有的学科需要的数据也分布极广，如各种传感器获取的数据。可以说，网格是一种致力于在大范围内共享计算能力和数据等资源的技术。早期的网格项目（如Condor,Legion等）都8是各自独立地设计资源模型和访问接口，2002年以后，GGF组织制定了一个影响重大的标准OGSA(OpenGridServicesArchitecture)，提出了一个基于Web服务概念和技术的网格体系结构。但由于普通的Web服务一般都是永久性的、无状态的服务，而网格环境中大量的是临时性的短暂服务，如一个计算任务的执行等，所以OGSA中提出一个OGSI(OpenGridServiceInfrastructure)来对SOAP/WSDL等协议加以补充，以支持有状态的资源。后来IBM、HP等推动制定了WSRF(WebServiceResourceFramework)系列标准，[16]以结合Web服务的各种WS-*规范来实现OGSI的功能。OGSA的体系结构如图4所示。电信网业务层在电信网中，从上世纪末开始，业务层的增值业务提供技术在INAP协议的基础上9开始引入OSA/ParlayAPI，以便以API的形式开放电信网的资源，如呼叫控制、会议控制、短消息等业务能力，使得可以方便且能保证服务质量地将电信网和互联网的能力结合起来提供新的业务。OSA/ParlayAPI标准是用UML进行定义的，从2003年起该标准的制定者ParlayGroup、ETSI和3GPP开始对一些简单、常用的电信网能力另外制定了一个Web服务形式的接口标准ParlayX，以便能让更广泛的开发人员参与电信网相关业务8即GlobalGridForum,已在2006年与EnterpriseGridAlliance合并为OpenGridForum。9http://etsi.org/WebSite/Technologies/OSA.aspx9 技术报告《Web服务和语义Web技术简介》的开发。而OSA/Parlay标准本身，在后来版本中也包含了从UML到WSDL映射的非正式规定，但同时也包含了从UML到CORBAIDL映射的正式规定和到Java映射的非正式规定（即JAIN）。地理信息系统(GIS,GeographyInformationSystem)在地理信息系统中，让各组织所拥有的数据之间实现互通具有特别重要的意义，为10此目的，从2002年起，OGC(OpenGeospatialConsortium)制定了OpenGIS系列标准，涵盖了GIS系统的数据模型和交互机制等各个方面。其中交互机制方面包括多个地理空间服务(GeospatialService)标准：OpenGISWebMapService,OpenGISWebFeatureService,OpenGISWebCoverageService和CatalogueServicefortheWeb。这些标准使用UML定义一系列服务、接口和操作，并同时给出了直接使用HTTP和SOAP两种传送方式。[15]另外，还使用Web服务标准BPEL来实现工作流和服务链。Web2.0与Web应用集成在互联网上，近几年来也经历了一个互通、共享大幅度增强的过程，出现了许多新的应用大大方便了个人用户发布内容、在用户之间及网站之间共享内容，大大增强了用户之间的联系和协作，如：blog、wiki、新闻聚合(RSS/Atom)、视频共享网站、folksonomy(通过统计用户自由添加的标签对资源进行分类)、Mashup(集成现有的web应用来向用户提供新的应用，也被称作Remix)、社会网络(SNS)等，2004年前后，人们开始使用“Web2.0”一词统称这些应用。各种Web2.0应用背后的支撑技术是互联网技术自然发展的结果：由增强后的JavaScript结合DOM(文档对象模型)形成的Ajax技术使得浏览器不用刷新整个页面就可以从服务器获取新的数据、更新部分页面，大大提高了Web页面的灵活性，实现了许多原来只有本地软件才能实现的各种丰富的用户界面；AdobeFlash使得音视频内容无缝地集成到标准的HTML页面中，RSS/Atom/JSON等轻量级标准使得网站能将其提供的内容与展示这些内容的页面中分离出来，而REST(REpresentationalStateTransfer,表述性状态转移)、SOAP以及原始的XML-RPC，为Web2.0提供了几种在服务器端进行Web应用集11成的方式。在Web上进行应用集成早在Web2.0兴起之前就已存在，通过硬编码方式解析普通的、用于显示给人看的HTML页面而提取数据，早就有比较购物类网站能够在自己的页12面上显示一件商品在其它多个网上商店的售价。但显然这种方式笨拙而脆弱，在Web2.0兴起后，一些网站主动将HTML页面与页面中包含的数据分离，用XML/JSON等10http://www.opengeospatial.org/standards11http://en.wikipedia.org/wiki/Web_2.012如http://www.shopping.com和国内的酷讯网(http://www.kuxun.cn).这类网站有的也同时采用这种方法：制定标准的页面格式让其它网站凭自愿主动地提供符合其定义的商品信息页面10 技术报告《Web服务和语义Web技术简介》格式为这些数据同时提供一种供程序使用而非人浏览的表现形式，结合具体的传送方式(REST、SOAP或XML-RPC)，遂形成了供其它应用而非人访问的API。REST一词产生于2000年，是针对基于Web的应用的一种架构，曾被用于指导HTTP1.0/1.1的设计。它把Web看作一个分布式信息系统或分布式超媒体系统，其中每个资源有一个URI，一个Web应用就是不断获取或发送作为一个个资源的表述的字节码(即页面、文件等)、从而实现客户端应用状态不断转移的过程。为了尽可能地降低响应时间并保持一定的简单性、可扩展性等，该架构强调了若干原则：通信需要是无状态的，[17]所传送的内容要尽量可缓存，各组件间的接口形式要统一等等。对于HTTP，这些原则意味着：1）把Web上的各项应用都看作是对资源的操作；2）资源通过URI来标示，而不使用消息载荷；3）把对资源的操作分为四种：创建、删除、获取、修改，分别使用HTTP的PUT/DELETE/GET/POST四种请求方法来表示。也可将其称作面向资源的体[19]系结构(ROA,ResourceOrientedArchetecture)。不过Web上并不是所有的应用都符合REST架构的原则，如HTTPCookie机制就违反了REST。对于Web应用集成，REST意味着把需要通过API访问的应用模块看做也看作资源，应用的参数通过编码入资源的URI来指定；用XML、JSON等格式的结构化数据表示资源，直接通过HTTP来传送。由于REST、SOAP一样都能作为Web上的应用接口、用于服务器端的应用集成，有时候也被称作一种“Web服务”技术。与SOAP相比，可看作是一种轻量级的Web服务，虽然在Web上SOAP通常只使用最基本的形式，即不含header、不配合使用WS-*协议。REST式的Web服务原来缺乏像WSDL那样的接口描述语言标准，但2009年8月Sun公司将其四年前推出的WADL(WebApplicationDescriptionLanguage)提交给W3C以寻求广泛的应用。比起SOAP式Web服务，该类服务简单易用，在对安全性可靠性要求不高时较有优势，更受Web开发人员的喜欢，而SOAP式服务因具有明确的接口描述而更符合传统软件及企业应用的开发人员的使用习惯，现在提供公开Web服务的网站有很多都同时提供这两种接口。另外，与企业计算不同的是，在互联网上还广泛存在着客户端的集成。主要方法是：通过在页面中嵌入由其它网站提供的JavaScript脚本，从而在自己网站提供的页面中能包含来自其它网站的内容，Ajax的出现，使得这一方式更加流行。另外，Firefox浏览器还开创了通过浏览器插件(GreaseMonkey)加载的第三方JavaScript脚本对来自特定服务器13的页面进行处理后再显示的更纯粹的客户端集成模式。14ProgrammableWeb网站列出了互联网上大量的可供集成的API以及集成结果，在2009年11月，光该网站上列出的Web上基于REST和SOAP的API数量已达1300多个，13http://userscripts.org列出了大量这种脚本14http://www.programmableweb.com11 技术报告《Web服务和语义Web技术简介》如可浏览Amazon网站上商品的AmazonProductAdvertisingAPI(曾用名:AssociatesWebService(2009年3月31日之前)和AmazonE-CommerceService(ECS,2007年10月29日之前))，提供存储服务的AmazonS3(这两个均同时提供REST和SOAP接口)，Yahoo!的Flickr(仅提供REST接口)等。值得注意的是，现在有的网站提供的API虽然自称是“REST”，但没有合理使用HTTP方法表示操作类型，而是将后者编码入请求的URL中，因此严格来说是不完全符合REST架构的，几乎只是“使用HTTP直接传输XML数据”的代名词。另外，严格来说，SOAP作为一种封装协议，本身与作为架构的REST并不完全对立，虽然SOAP现在主要用于RPC类型的用途，但也可以按照符合REST架构的方式来[19]使用。最后，Web2.0也可以与SOA结合，作为一种表现技术用于经过SOA整合的企业IT[7]系统与消费者、员工间的接口，提供更丰富灵活的访问方式，促进人与人之间的协作。云计算[18]15云计算(CloudComputing)是近年来在产业界兴起的另一个与Web服务有关的新技术，它充分利用集群技术、宽带技术、虚拟机技术的新进展，将IT设施的托管运营模式提高到了新的水平。除了传统的服务器硬件和Web服务器软件平台这两个层面的托管、租用外，1999年开始兴起的SaaS(软件即服务,SoftwareasaService)寻求将一些普通的软件实现在Web服务器端，用户通过基于网页的页面访问，并根据实际使用时间进行计费。近年来，在Google、Amazon等大的网络公司在运营过程中建立了功能强大但耗费很大的计算机群和数据存储中心，借助虚拟机技术和Web技术的新进展，它们开始在不同层面上将这些能力以服务的形式出租给外界使用、从而形成了SaaS等托管运营模式的新形式：1）软件层：即SaaS，提供基于浏览器访问的现成的软件。如：Salesforce.com(主要提供CRM产品，已拥有日本邮政等众多用户),OracleCRMOnDemand,GoogleApps(如功能类似于MSWord的GoogleDocs)等；2）平台层：可称作PaaS，提供开发、运行平台，供开发人员开发Web应用，大体上相当于前述的Web2.0中的Web应用集成，但同时提供可扩展性较强的运行环境。如：Salesforce.com的Force.com(通过Web服务利用Saleforce的能力开发ERP等应用)等，YahooPipes(轻量级、可视化的简单消息处理类服务组合工具和运行平台)，GoogleAppEngine(目前可使用Python和JavaServlet，并以API或标准类库特定实现的方式允许应用使用Google自己使用的一些技术如BigTable,URLFetch,Memcache等)；15http://en.wikipedia.org/wiki/Cloud_computing12 技术报告《Web服务和语义Web技术简介》3）基础设施层：可称作IaaS，提供一个具有指定计算能力、存储容量和操作系统的虚拟机器。如：AmazonEC2(利用Xen虚拟机提供Linux,Windows等环境，硬件能力(即处理器性能、内存和硬盘的大小)和常用的服务器软件有多种配置可供选择，可通过网络传入和安装其它软件；并有存储、消息队列等Web服务可用；见图5，其中一个虚拟机称作一个AmazonMachineImage(AMI))，IBMBlueCloud(类似前者，2008年5月还在无锡开通了其大中华区云计算中心)，MicrosoftAzure(包含了一个操作系统和一组面向开发人员的服务)等。2007年出现的“云计算”一词指的就是这些应用。与以前的硬件托管、租用技术一样，它们能够平滑、甚至降低企业的IT投入，而借助于高水平的集群技术和虚拟机技术，它们通常具有更加强大的可扩展性，尤其适合小型的企业、组织、政府机构等采用。EC2APIVMinstancetoolsmanagementEC2rawclientSOAPclientsoverAmazon(SOAPetc)HTTPSMgmt.LisFirefoxEC2WebServicestedconsoleonbyplugInterminate,Webpagebundle,Launch,etc.AMIs(AmazonMachineImages)ch--onS3LaunSSH(forLinux)&VMSSHInstancesofdleselectedAMIsBunsterclientsegiRRemoteDesktopPRDConnection(forWindows)ifictecnespnterIion-atoverplicecApfainter图5AmazonEC2的逻辑结构Web服务技术在云计算中的作用是：SOAP协议可用来作为宿主环境中一些功能的调用接口。如AmazonEC2使用基于HTTPS的SOAP作为启动、配置、停止虚拟机运行的接口，它的几种客户端都是基于此构建的（如图5所示）。虽然在云计算的C/S接口上现在更多地使用基本HTTP/Ajax(如GoogleDocs)及私有协议(如GoogleAppEngine用专用客户端通过私有接口上传代码)，但当云计算中的应用需要与其它应用互通、集13 技术报告《Web服务和语义Web技术简介》成时(如Force.com)，使用SOAP这样的开放标准会更有优势。14 技术报告《Web服务和语义Web技术简介》2WEB服务技术概览如前所述，Web服务是一种分布式系统的接口技术，主要用于各种异构系统的互通，因此Web服务技术的主要内容是一系列的关于组件间接口格式的标准。这些标准遵循一个模块化的结构，具有很好的可扩展性。在最简单的情况下，只使用SOAP和WSDL就可以工作；当应用更复杂，要求服务具有安全、事务等方面的保障时，再引入相应的扩展协议即可。服务组合特定的应用语义标注其(WSBPEL等)(DPWS,WSRP)(SAWSDL)它扩元数据注册、交换“订阅/发布”MEP服务管理资源及其状态展(UDDI等)(WS-Notification等)(WSDM,WS-Mgmt.)(WSRF,WS-RT等)基本安全可靠消息传递事务扩(WS-Security等)(WS-RM(WS-TX系列等)WS-Reliability)展WS-AddressingWS-Policy等核心标MTOMwithAttachmentWSDL准SOAP传JMS输机TCPUDPMOMsSMTPIIOP...制HTTP(S)运行时接口消息格式服务接口契约的描述图1Web服务标准分类示意图我们把到2009年11月底为止W3C和OASIS等标准化组织已经通过的正式标准（及可能的传输机制）进行分类、并大致分类后显示在图1中。这些标准的详细列表见表2，其中还列出了WS-I组织为了促进标准的各个实现之间的互通而制定的一系列Profile文件，其中针对常用标准指出了为实现良好互通所应遵循的许多细节上的规定。从中还可16见在多个分类中存在着相互竞争的两个甚至三个标准，因此，在各种较复杂的情况下，16与许多其它标准一样，Web服务标准的制定过程也充满了企业之间的合作与竞争。除了核心的SOAP和WSDL得到了最广泛的认同外，Microsoft、IBM联合一些企业（往往有BEA）提交了大量标准，而在多个方面Oracle、Sun15 技术报告《Web服务和语义Web技术简介》Web服务互通异构系统的效果如何，还有待最终的实践来验证。另外，其中ebXML框架中的几个标准虽也基于SOAP、可用于Web服务的各种应用，但制定较早，没能利用其它WS-*标准，而是自成体系，其应用往往局限于ebXML体系中。最后需要注意的是：由于Web服务标准的制定过程通常是几个企业在小范围内设计、实现、发布后再提交给大型的标准化组织讨论，因此，有的规范虽然没有成为后者投票通过的正式标准，但也可能已经得到广泛采用。下面各小节对各个分类和主要标准的要点分别进行介绍，最后给出了综合应用这些标准实现企业计算时典型的系统部署模型(特别是基于ESB的)和一个开发模型SCA/SDO。标准SAWSDL与其它WS-*标准相比比较孤立，放在下一节中与其它语义Web服务标准一起介绍。表2Web服务标准列表说明：1.“备注”栏中符号※表示该标准与上一行的标准定位类似，存在竞争关系；2.未加说明的公司名表示这些公司发起了该标准。未列出的多由IBM,Microsoft等发起。3.标准状态：Standard(Std.)、Recommendation(Rec.)、Final分别是OASIS、W3C、WS-I的正式标准；draft是草案；在W3C中CandidateRec.较接近这一状态，Note则是draft之前的状态。4.本表包含了截止到2009年11月底W3C和OASIS通过的所有Web服务技术的正式标准、大部分较新的草案和重要的历史草案(用浅颜色表示)；未包括针对一般SOA的SOA-RM,SCA/SDO等。较近的版本及其分类规范名称备注发布时间、状态SOAPV1.2,2003,W3CRec.V1.1,2000,W3CNote虽是Note但广受支持WSDLV2.0,2007,W3CRec.V1.1,2001,W3CNote虽是Note但广受支持SOAPMessageswithAttachments2000,W3CNote搭配SOAP1.1SOAPMessageTransmission2005,W3CRec.搭配SOAP1.2OptimizationMechanism(MTOM)核心WS-Policy系列规范：V1.5,2007,W3CRec.规范WS-PolicyFrameworkWS-PolicyAttachmentWSPL,i.e.WS-XACML(WebServicesV1.0,2007,OASISdraft※；Sun等ProfileofXACML)WS-Addressing：V1.0,2006,W3CRec.WS-MessageDelivery2004提交给W3C后无※；Oracle,Sun等进展WS-SecurityV1.1,2006,OASISStd.用到XML-SignatureV1.0,2004,OASISStd.和XML-EncrptionWS-TrustV1.4,2009,OASISStd.安全WS-SecureConversationV1.3,2007,OASISStd.WS-SecurePolicyV1.3,2009,OASISStd.V1.2,2007,OASISStd.WS-FederationV1.2,2009,OASISStd.等企业都提交了定位相近的标准与之竞争；但在安全方面，这些大企业少有地达成了一致。其它比较活跃的企业还有：SAP,Tibco,Fujitsu,Iona等许多公司。16 技术报告《Web服务和语义Web技术简介》WS-ReliableMessaging(WS-RM)V1.2,2009,OASISStd.可靠WS-RMPolicyV1.1,2007,OASISStd.消息WS-ReliabilityV1.1,2004,OASISStd.※；Oracle,Sun等传递ebXMLMessageServiceV2.0,2002,OASISStd.※WS-MakeConnectionv1.1,2009,OASISStd.WS-Transaction(WS-TX)系列规范：V1.1,2007,OASISStd.WS-Coordination(WS-C)V1.2,2009,OASISStd.WS-AtomicTransaction(WS-AT)WS-BusinessActivity(WS-BA)事务WS-CompositeApplicationFramework只有WS-CTX1.0成为※；Oracle,Iona等；(WS-CAF)系列规范：OASISStd.,2007该工作组已关闭，该WS-Context(WS-CXT)规范料将不再有进展WS-CoordinationFramework(CF)WS-TransactionManagement(TXM)UDDIV3.0.2,2005,OASISStd.元数V2,2003,OASISStd.据的ebXMLRegistryInformationModelV3.0,2005,OASISStd.※(在某些情况下)发布ebXMLRegistryServicesV2.0,2002,OASISStd.和交WS-MetadataExchange2009,W3Cdraft部分地可代替UDDI换WS-Discovery(WebServicesDynamicV1.1,2009,OASISStd.IBM未参与Discovery)WS-BPELv2.0,2007,OASISStd.组合WS-CDLv1.0,2005,W3COracle等Cand.Rec.WS-Eventing2009,W3Cdraft2006年提交；IBM,Microsoft,Oracle等增强WS-Notification系列规范：OASISStd.-2006※；更复杂，欲用于的WS-BaseNotification网格；IBM,HP等MEPWS-BrokeredNotificationWS-TopicsWSRF系列：v1.2,2006,OASISStd.GlobusAlliance,IBM,WS-ResourcespecificationHP等；WS-ResourceProperties(WSRF-RP)用于网格架构OSGA；WS-ResourceLifetime(WSRF-RL)WS-ServiceGroup(WSRF-SG)资源/WS-BaseFaults(WSRF-BF)状态WS-Transfer2009,W3Cdraft※Microsoft,BEA,WS-ResourceTransferSonic,IBM等WS-EnumerationResourceRepresentationSOAPHeader2005,W3CRec.BlockWSDM(WebServicesDistributedv1.1,2006,OASISStd.IBM,HP等Management)v1.0,2005,OASISStd.管理WS-Managementv1.0.0,2008,DMTFStd.Microsoft,Intel,Sun,HP,AMD,Dell等语义SemanticAnnotationsforWSDLand2007,W3CRec.IBM和学术界标注XMLSchema(SAWSDL)DevicesProfileforWebServicesV1.1,2009,OASISStd.定义在资源受限设备(DPWS)上提供WS的最小需特定求应用WebServicesforRemotePortletsV2.0,2008,OASISStd.为Portal和其Web(WSRP)V1.0,2003,OASISStd.Services数据源定义标准的数据交互接口17 技术报告《Web服务和语义Web技术简介》SOAP-over-UDPV1.1,2009,OASISStd.传输SOAPoverJavaMessageServiceV1.0,2009,W3CCand.绑定Rec.BasicProfile2.0,2009,WS-Idraft1.2,2007,WS-IdraftWS-I1.1,2006,WS-IFinal标准1.0,2004,WS-IFinal互通AttachmentProfile1.0,2006,WS-IFinal轮廓SimpleSOAPBindingProfile1.0,2004,WS-IFinalBasicSecureProfile1.1,2009,WS-IdraftReliableSecureProfile1.0,2009,WS-Idraft2.1核心标准及扩展机制与传统的RPC类技术类似，Web服务技术的最核心，是一个运行时访问协议和一个接口描述语言，分别是SOAP和WSDL。而WS-Addressing和WS-Policy分别为它们提供了标准的扩展机制以支持各种高级功能。虽然按照其各自规定，SOAP并没有指定使用哪种接口描述语言、WSDL描述的服务可以使用其它协议来访问，但现在一般都将它们两个结合起来使用。2.1.1SOAPSOAP被设计为一种在分布式环境中传输结构化信息的轻量级的、可扩展的协议。它可以使用现有分布式系统中见到的各种传输机制（如HTTP,JMS,裸的TCP等）来传输；一条SOAP消息就是一个不含DTD和处理指示(PI)的XML文档，这使得它能互通异构系统；在最简单的方式下，它可以像XML-RPC那样简洁地传输RPC消息；而在需要时，通过引入各种Header，它又可以像其它分布式组件技术一样以统一的方式支持中安全、事务等属性，而与下面使用什么传输协议无关。具体而言，一个SOAP消息的根元素是Envelope，它有两种子元素：可选的若干Header元素和一个必选、但可以为空的Body元素。与业务相关的载荷一般放在Body内；与安全、事务等QoS属性有关的支撑数据一般放在Header内，通常由各种扩展协议规定。用于RPC时，Body的内容为：以调用的方法名为名称（响应消息中则通常使用“方法名+Response”）的元素及其以方法的输入参数为名的各个子元素（响应消息中若返回值类型不是void，则返回值作为第一个，元素名在SOAP1.1中不重要，按1.2须是“result”）。用于其它用途时，Body的内容通常是有预定义模式的XML元素，可以是多个，但若是一个则更便于根据XMLSchema验证有效性。SOAP的扩展机制主要是：定义标准的Header块，有时也需要定义专门的Body内容。此外，SOAP还通过“action”信息粗略地指出消息的用意。SOAP1.1中规定若使18 技术报告《Web服务和语义Web技术简介》用HTTP传输，使用一个必需的”SOAPAction”请求头域表示之，1.2中则改在传输协议中为指向SOAP消息的MIME类型添加一个”action”参数来表示。action的具体含义由应用决定。虽然SOAP经常被用于“请求-响应”MEP(消息交互模式)中，但SOAP本质上是单向的；SOAP1.2中通过给出收发双方一些相关性质的取值和状态转移图描述了两种MEP:request-response和response，其中后者指以SOAP消息来应答非SOAP的请求。SOAP消息在发送者到最终接收者之间可以经过0或多个SOAP中间节点，中间节点通过处理、修改Header（有时还有Body）的内容，以此帮助实现各种QoS属性。另外，当Body和Header内的数据不存在预定义XML数据模式时（如数据本身就是非XML的），需要使用约定好的编码方式进行编码，SOAP1.1和1.2各定义了一种编码方式供选用。关于承载协议，SOAP标准本身中给出了到HTTP的绑定方式，其中SOAP消息的MIME类型在1.1和1.2中分别使用”text/xml”和”application/soap+xml”。W3C和OASIS还分别定义了从SOAP到JMS和UDP的绑定的标准：SOAPoverJavaMessageService和SOAP-over-UDP。SOAPMessageswithAttachments和SOAPMessageTransmissionOptimizationMechanism(MTOM)都定义了如何将与SOAP消息有关的二进制数据跟在SOAP消息本身后面一起组成一个MIME类型为”Multipart/Related”的载荷放入传输协议中。这意味着一个SOAP节点需要能处理传输协议所传输的这种类型的载荷，而不仅是SOAPEnvelope载荷。两个标准分别用于SOAP1.1和1.2，区别是：前者将其它part（也可以是文本数据）看作与SOAP消息本身相关、但又不属于消息的信息，相应地定义了从SOAP消息中引用这些信息的方式；后者则将其它part看作是SOAP消息的一部分，单独拿出来用原始的二进制格式来表示以优化传输性能。2.1.2WSDLWSDL在两个层次上描述Web服务：1)抽象的功能接口；2)具体的到访问协议的绑定方式。两者相对独立，一个功能接口可以具有多个不同的绑定。服务的功能接口包括一系列操作(operation)，操作中含有输入消息和输出消息以及可能的异常消息（用于服务器端出现异常时代替正常的输出消息返回给请求者）。绑定(binding)中则定义了这些信息在运行时如何编码为访问协议（如SOAP、直接的HTTP、SMTP等）的消息，同一种绑定可以在多个地方实现，若干这样的实现的地址组成一个服务(service)。WSDL本身不能描述一个功能接口中各个操作之间的依赖关系，这意味着它所描述的Web服务都是无状态的，都是一组彼此间存在某种关系的操作的松散集合；要描述有状态的服19 技术报告《Web服务和语义Web技术简介》务，需要使用注释文字或者某种扩展机制。具体地，WSDL1.1中称上述“功能接口”为portType，而service中一个实现了某binding的地址称作一个port。操作的消息包括多个part，每个part有name属性，并用type属性指出其抽象类型（也可以具体如XMLSchema类型）或者用element属性引用一个XML元素而准确地指出其格式。一个操作的输入消息和输出消息都只能有最多1条，根据其具体数量和两者的顺序，定义了四种MEP：One-way(只有I),Request-response(IO),Solicit-response(OI),Notification(O)。前两种的实现比较自然，后两种虽然可以通过回调机制实现，但因为标准中定义不清被WS-I推荐不要使用。WSDL1.1中定义了到SOAP和HTTP的绑定方式。其中SOAP绑定在operation层用style和use属性决定了如何生成消息内容。style表示操作是“面向RPC的”还是“面向文档的”，其两种取值的含义是：ò”rpc”：按照SOAP规定的RPC用法，由operation元素和其以消息中各个part为子元素构成SOAPBody的内容，用part的name作为元素名；ò”document”(默认值)：各part直接出现在Body下，消息内容如何解释完全取决于应用，从而实现了服务器和客户端之间的松耦合。use属性的两种取值：ò”encoded”：仅用于各part是用type指出抽象类型的情况，消息中需要按照某种encodingStyle将其编码为具体的消息格式。典型地，需要在消息中用xsi:type属性为各元素指出具体的类型；ò”literal”(WS-I推荐的默认值)：part的element或type属性已给出了具体的消息格式，消息中不需要插入元素的类型信息，消息更简洁。这些取值的4种组合中，document/encoded在实践中不被使用，document/literal因其松耦合的优点而广为采用。但WSDL1.1对后者的规定不细，WS-I推荐：此模式下消息的part的定义中须使用element属性，且消息中只出现最多1个part。另外，在此模式下，由于消息中没有操作名，当一个服务内多个操作的请求消息使用了相同的顶层元素时，服务提供者无法识别收到的消息是属于哪个操作的，实践中常通过如下称作“document/literalwrapped”的模式来解决此问题：每个消息最多只有1个part，且part的顶层元素名与对应的操作名相同。WSDL1.1的扩展机制主要是：在与绑定有关的诸元素（包括service和port）中允许插入任何来自其它命名空间的子元素和属性，以表示到特定技术的绑定等信息。在插入的元素中可使用wsdl:required属性指出是否必需支持。在WSDL2.0中，除了将1.1中的portType和port分别改称interface和endpoint外，还去掉了独立的message元素，而由操作的input和output中的element属性直接引用一20 技术报告《Web服务和语义Web技术简介》个XML元素schema来规定消息的具体格式，而非XML的消息内容则通过扩展机制实现。相应地，绑定的定义得到简化，不再需要WSDL1.1中的use属性，因为相当于use一律取值为”literal”；style属性也移植接口定义下的operation中，但用法稍有变化：可以不出现，也可以指定多个取值，目的是在接口层就对操作的消息、尤其是第一条输入消息的模式加以限制，预定义的三种取值”RPC”,”Multipart”和”IRI”中最后一个表示操作的第一条消息须能被序列化为一个IRI。该值结合相应的HTTP绑定，使得WSDL2.0能够描述REST式的Web服务。另外，WSDL2.0中一个operation可以包含多于1条输入消息和/或多于1条输出消息，因此operation的子元素input/output/infault/outfault在必要时需要通过messageLabel属性指出其在operation对应的MEP中担当的角色，——在WSDL2.0中每个operation必须指定一个MEP（通过pattern属性）。规范预定义了8个基本的MEP以期满足大多数应用。其中有4种与WSDL1.1类似：In-Only,Out-Only,In-Out,Out-In，其中前两种不得出现fault消息，后两种的第二条消息可以被替换为fault；较新的四种中，RobustIn-Only和RobustOut-Only中唯一那条消息可以触发一个fault消息，In-Optional-Out和Out-Optional-In都允许可选的第二条消息，且两条消息都可以触发fault。WSDL2.0的扩展机制与1.1类似，另外还可以通过自定义新的MEP并将其标示URI作为pattern属性的取值的方式来实现小的扩展。2.1.3增强WSDL的WS-Policy和WSPLWSDL只描述了服务与其请求之间的契约中最基本的部分，若服务契约中还包括其它特性，如安全、事务、可靠性等QoS特性，就需要对WSDL进行扩展，这正是WS-Policy的目的。WS-Policy通过在wsdl:definition下插入策略的声明，并在wsdl:binding、wsdl:service内的从service到operation到input/output各个层次上加入对它们的引用来达到这一目的。声明中，一个策略表达式的结构是：顶层元素wsp:Policy包含若干Assertion，一个Assertion表示了为实现某种特性所需的一项特征，在安全、事务、可靠消息传递等标准中都预定义了若干个。一个wsp:Policy下有多个Assertion时，通过组合运用wsp:All和wsp:ExactlyOne两个策略算子元素来表示它们之间的关系。Assertion可以通过布尔类型的wsp:Optional属性表示是必需还是可选的；Assertion还可以递归地包含wsp:Policy。策略的引用，通过在所要引用该策略的元素（如binding,binding/operation,service/endpoint等WSDL元素，以及Policy声明中的适当位置）内插入来实现。请求者也可以通过适当方式提出自己期望的策略表达式，它与服务的策略表达式通21 技术报告《Web服务和语义Web技术简介》过直观的比较规则可计算出一个相匹配的交集，调用服务时请求消息中需要携带满足其中断言的信息。WSPL（即WS-XACML）是另一个关于策略表达式的定义、匹配的标准，它基于OASIS关于访问控制的标准XACML的框架，语法上更复杂，也能提供更细的控制。但目前的成熟度、与其它WS标准的结合程度、受支持的广泛性都要差于WS-Policy。2.1.4增强SOAP的WS-Addressing等要想以传输协议透明的方式实现各种复杂的MEP，仅靠SOAP提供的机制是不够的，甚至对于基本的request-responseSOAPMEP，若传输协议是单向异步的，服务都没有标准的方式可以获知响应消息应发往什么地址。针对此问题，WS-Addressing对SOAP做了扩展。WS-Addressing首先定义了一组SOAP头元素以携带端点地址信息：From,ReplyTo,FaultTo,To。其中ReplyTo和FaultTo用于实现这样的MEP：服务把响应消息或异常消息发往与请求的来源地址不同的另一个端点。若消息中ReplyTo被设为匿URIhttp://www.w3.org/2005/08/addressing/anonymous，则表示应使用传输协议自身的后向通道来传送响应消息。To元素将消息最终接收者的地址放入SOAP消息中，从而使得SOAP中介可以进行SOAP在其承载协议上的消息路由。上述前三个元素的内容是一个EndpointReference元素（常简称作EPR），其中除了端点地址外，还可以携带Metadata和ReferenceParameters两个子元素，前者用于包含或引用WSDLinterface定义以供在某一个地址上实现了多个interface的情况下识别特定的interface；进一步，若提供服务的端点还指定一组参数及其取值要求在请求中携带、以便端点进行消息分发等操作时，这写参数及其取值在ReferenceParameters中给出。其次，为了实现许多MEP所需的响应消息与相应请求消息的关联，规范定义了MessageID,RelatesTo,RelatesTo/@RelationshipType等元素和属性，其中RelationshipType属性的默认值”reply”表示当前消息是RelatesTo所指的消息的响应。还定义了头元素Action以用统一的方式携带SOAP规范中的action信息，以帮助接收者分发消息。最后，规范规定了当启用本协议时，WSDL2.0/1.1的每一个MEP下各消息中应使用上述哪些元素、属性。在各种情况下To和Action都是必需的。若服务提供者想启用WS-Addressing，需要在WSDL文件中：1.加入需要启用的声明。可以使用WS-Policy，为此WS-Addressing定义了三个断言表示启用本规范、是否使用匿名响应地址。另外也可以使用WSDL2.0的SOAP22 技术报告《Web服务和语义Web技术简介》绑定方式中的Module机制，加入。还可以使用，但该做法尚未成为正式标准，正处于draft状态。2.为interface内的input和output元素添加属性wsaw:Action.若不添加，则使用WS-Addressing规范给出的规则生成一个默认的Action值。另外WS-MessageDelivery是由其它公司提出的一个与WS-Addressing非常类似的提案，但其在2004年提交给W3C后在标准化的进程上不再有进展。2.2基本的扩展标准在企业计算等对可靠性要求较高的场合，SOAP需要在安全、可靠消息传递、事务等方面进行扩展后才能满足需要，尤其是安全标准WS-Security，几乎在所有其它涉及较重要任务的扩展标准中都建议使用它，因此一般把这三方面的扩展看作Web服务技术中基本的组成部分。2.2.1安全在Web上，安全方面的考虑通常包括如下几个方面：ò消息的完整性：通常通过对消息进行签名来实现。ò消息的机密性：通常通过对消息进行加密来实现。ò用户的认证与授权：通常通过用户向服务器出示令牌(token)来实现。令牌可以简单如用户预先在服务器上注册时产生的口令，复杂一点的也可以是由可信的第三方出具的某种担保凭证，如基于公钥体制的X.509证书，以及基于对称密钥体制的Kerberos票据等。ò（有时候需要）单点登录(Single-Sign-On)：即用户在一个地方登录而通行于多个地方。OASIS的SAML是一个这方面的标准。要在Web服务上提供安全保证，在简单的应用中可以直接利用传输层提供的安全机制，如经过HTTPS传输SOAP消息。这种方式存在的问题是：1）只能对整个消息全部加密，妨碍了SOAP中介节点的使用；2）依赖于特定的传输机制，不符合SOAP与传输协议无关的设计目标。WS-Security标准的解决方案是：利用XML-Encrption对指定的元素（可以是Header和Body内任意层次上的任意元素）分别进行加密，利用XML-Signature标准对SOAP消息中指定的元素集合进行签名，并通过引入一系列XML元素和属性形成一个框架以实现：1）在SOAP消息头中携带签名结果；2）将各经过加密的元素的明文替换为密文；3）在SOAP头中携带令牌信息。23 技术报告《Web服务和语义Web技术简介》其中按照各自规范，签名和加密的结果中含有指示使用的是哪个密钥的信息（可以指向同一个消息中携带的token），签名结果中还包含了对被签名元素的引用。签名过程是：先对各待签名XML元素按照指定规范（W3C有两个）进行正规化处理、再用某种哈希算法分别得到一个摘要，然后将这些摘要经过正规化得到一段文字后再用私钥加密得到签名结果。当一个消息中同时使用了加密和签名时，所产生的各个SOAP头信息采用“晚产生的靠前”的规则进行排列。令牌可以是多种形式，基本的如plaintext、编码后的二进制，规范预定义了几种常用的令牌的编码格式：UserName,X.509,Kerberos,SAML等。其中UserName即基本的用户名/口令，口令可以是散列后的摘要，散列中可以结合时间戳、随机数Nonce等以防止replay攻击。还可以用未在消息中传输的口令和一个指定的随机值Salt串接后散列若干次而导出一个临时密钥用于同一个消息中的加密、签名部分。其它几个安全相关的协议是在WS-Security的基础上分别提供了额外的安全设施，重要性不如WS-Security。WS-Trust针对各节点间所用的安全令牌种类可能不同的问题，提出一个框架以通过带内的方式在各节点间交换令牌、达成信任关系。该框架是：设立一个独立的节点提供由一对令牌请求、响应消息组成的安全令牌服务(STS)，这两条消息通过各种绑定机制可实现令牌的发行、续用、验证、撤销等。该标准的功能与Kerberos等现有机制有一定的重叠。WS-SecureConversation用于在一个由相关联的多条消息构成的会话中能够利用最初建立起的信任关系、免于每次都携带大数据量的完整的令牌信息。其方法是定义了一种新的令牌SecurityContextToken，在会话开始时通过WS-Trust或其它方式创建后，在后续消息中通过简单地引用它。结合WS-Trust还可对该令牌进行修改、续用和撤销。WS-Federation在WS-Security和WS-Trust的基础上提出了一个用户和其要访问的资源位于不同的安全域时的在线的信任建立机制。其方法是每个安全域中设立称作身份提供者的安全令牌服务（IP/STS）节点，各安全域之间的IP/STS预先建立信任关系，在运行时通过用户和各IP/STS之间交互在线获取可被欲访问资源服务器信任的安全令牌。除了用于Web服务之间的认证外，协议还定义了直接到HTTP的绑定机制从而可用于基于Web浏览器的单点登录，在这一点上它与SAML标准形成了重叠和竞争。两者相比，SAML更成熟，但WS-Federation的模块化程度更高，更能充分利用其它协议、各种令牌格式。2.2.2可靠消息传递为了使得SOAP能在无论什么传输协议上都能实现可靠的消息传递，支持消除重复消息、消息排序、消息状态通知等能力，WS-ReliableMessaging和WS-Reliability两个24 技术报告《Web服务和语义Web技术简介》标准定义了类似的SOAP扩展，来实现在网络数据链路层协议和TCP中常见的基于消息编号和滑动窗口的可靠消息传递机制。两个标准中都支持对消息进行分组，组内消息连续编号、并设有专门XML元素指示组的结束；都强烈建议使用WS-Security对可靠性报头进行签名；都允许发送方主动要求接收方发送Ack；像Ack这样的控制信息除了在SOAP头中以Piggy-backing的形式捎带发送外，也可以通过Body为空的消息专门发送。另外，WS-ReliableMessaging还定义了几个WS-Policy断言；其扩展SOAP的方式除了定义新的头元素外，还定义了两对在Body中传递的消息，即两个WSDL操作，用于创建和终止消息分组。WS-MakeConnection特别针对使用WS-Addressing的匿名ReplyTo地址时若在响应消息发送前传输通道出现异常（网络错误，或者响应消息需要很长时间才能生成）则响应消息无法发送的问题，提出这样的解决方法：使用一个特别的匿名URI来告诉服务提供者，若响应消息在后向通道中没有发送，则请求者将来会(每隔一定时间)发起连接来询问响应消息。2.2.3事务处理Web服务中的事务处理机制与其它分布式应用中的事务处理机制是类似的，都需要设立一个专门的协调器节点。事务开始时，发起事务的参与方向协调器发消息创建一个事务处理上下文；事务进行过程中，其它各参与方进入事务时都在协调器注册中注册，将自己与该上下文关联；等事务中的正常操作都顺利完成时，发起方通知协调器，协调器则向各参与方发消息提交（具体过程可以先发一遍“准备提交”消息，各方都准备就绪后再发“提交”），若过程中有错误发生，协调器通知各参与方取消先前操作。由于Web服务被设计为可以用于持续时间很长的业务活动中，除了使用数据库系统中常见的原子事务协议外，Web服务的事务标准中还引入了一个基于补偿的协议，以使系统能够对某个参与方中已经彻底完成的操作（而不是2PC协议中那种初步完成、等待提交的操作），通过实施另外的操作来撤销其效果。但须注意：补偿实际上是不可能完全实现的，因为若补偿操作再失败的话，就无法知道如何再做补偿，现实中，对这种情况都采用通知人去处理的办法。WS-TX系列标准把前述机制中的创建上下文和注册活动与后面的事务处理协议分离开来，前者作为一个统一的框架可以容纳各种协议。在WS-Coordination中定义了这个框架，引入新的SOAP头元素来表示上下文格式，定义了两个WSDL操作分别用于上下文创建和其它参与方的注册。　WS-AtomicTransactions和WS-BusinessActivity则分别定义了原子事务协议和基于补偿的协议，其中分别为协调器和参与方定义了状态25 技术报告《Web服务和语义Web技术简介》转移图及相应的各种节点应实现的WSDLinterface，包括诸如Prepare,Commit,Abort,Compensate这样的操作。WS-CAF系列规范中，WS-Context标准定义了一个通用的context表示、使用机制，除了事务外还可用于会话管理，与WS-SecureConversation有一些重叠；WS-CoordinationFramework草案定义了事务处理框架类似于WS-TX系列中的WS-Coordination；未能提交给标准化组织的WS-TransactionManagement则定义了原子事务协议和基于补偿的协议，以及一个业务流程管理协议。2.3其它扩展标准2.3.1元数据注册和交换Web服务的各种描述信息，如WSDL、WS-Policy所描述的，有时被称作“元数据”，Web服务的注册、发现主要就是元数据的注册、发现。服务注册可以简单地使用LDAP等通用的目录服务，也可以使用一些企业私有的解决方案如微软的DISCO和IBM的WS-Inspection(WSIL)。这方面的公共标准中，UDDI出17现较早曾被给予厚望，但目前仍未在Web上流行起来，更多地用在企业内部的注册库中，但这种场合也有企业使用ebXML的相应标准。UDDI使用SOAP提供服务描述的注册和查找，但其设计中过于追求所注册资源的通用性，使得在描述Web服务时缺乏标准的数据结构——UDDI预定义的少量数据结构中没有能够直接支持WSDL的，需要使用类似于指针的tModel(TechnicalModel)引用自定义的扩展结构才能支持。WS-MetadataExchange定义了专门的WSDL操作，用于服务请求者通过Web服务接口直接向提供者获取其提供的其它Web服务的元数据，如所关联的WS-Policy策略、完整的或部分的WSDL定义、XMLSchema。WebServicesDynamicDiscovery(WS-Discovery)也定义了一组WS服务(one-way的和request-response的)，用于在一定范围的网络内通过广播自己的能力、多播查询请求等方式来查找符合条件的服务。但协议中对于服务及请求的功能描述机制不加规定，目前可以利用LDAP等进行简单的描述。2.3.2组合为实现SOA提高企业IT系统灵活性的目标，一个非常重要的能力是：在接近业务逻辑的层次上组合现有服务来提供新服务。WS-BPEL提供了一个Web服务层次上的组合服务描述语言，受到了广泛的支持。其语法成份能映射到进程代数π-Calculus，因而17主要原因可能是由于目前企业界对于动态地发现原本没有业务关系的企业的Web服务的需求还不够。26 技术报告《Web服务和语义Web技术简介》具有严格的语义基础，可以使用相应工具对其进行形式化验证。WS-BPEL中组合服务称作process，一个process由invoke,receive,reply等基本activity通过常见的控制结构和一套异常处理机制组成。其中invoke是对成员服务的调用，receive和reply分别用于该process输入消息的接收和输出消息的发送，assign用于在XPath,XSLT等的精确控制下为变量（消息变量和本地变量）进行赋值。在控制结构所形成的各种复合activity中有两个较为特殊：pick用于从多个消息中任意接收一条消息，类似于UNIX的select()函数；flow表示各成员activity的并行，其中可通过link指定部分成员之间的同步关系。在BPEL引擎中，一个process由一个receive或pick中接收的消息激活后产生一个实例。由于BPELprocess通常是有状态的服务，实例的存活时间往往较长。在运行中引擎收到一条消息时，通过process中定义的correlationSet来提取消息中的一些标示信息来决定消息发给哪个实例（或者需要创建新的实例）。correlationSet由一组variableProperty组成，一个variableProperty就是一个指向消息内通过XPath表达式确定的特定信息的别名。各种activity可以按逻辑关系聚集成scope。scope中可以定义本范围内的各种局部变量、各种异常处理handlers和用于在本scope活动期间（即其内的普通activities已开始执行但未结束时）处理异步的输入消息的eventhandlers。scope可以嵌套，process本身可看作是一种特殊的scope，在其它适当的地方（如有的复合activity）内可认为具有一个默认的scope。process的异常处理机制由三种handler组成。当某次invoke收到一个fault消息或者process利用throwactivity主动抛出一个异常后，根据该异常的类型从当前scope的各faultHandlers中找出匹配的一个。但在执行其中用来处理异常的activities之前，先要终止当前scope的各个子activities，而这意味着要调用它们对应的scope的terminationHandlers。在faultHandler和terminationHandler中一个典型的动作就是调用compensationHandler，后者中包含一些用来撤销前面某些activity的效果的activity——与基于补偿的事务处理协议类似。process与其成员服务及客户之间的逻辑连接用partnerLink表示。一个partnerLink的两端中一端是process自己，另一端是一个成员服务或客户，两端中任何一端只要提供了Web服务——即实现了一个WSDL1.1的一个portType——就被认为扮演了一个role。invoke,receive等activity收发的消息都是在指定partnerLink的相应role所对应的portType内的operation中定义的。process脚本中的partnerLink只指定类型，并不指定实现对端portType的端点的地址，该地址或者通过运行环境进行静态的配置，或者根据运行中动态获得的信息来产生、然后通过assign动态地赋值给partnerLink，从而实现了27 技术报告《Web服务和语义Web技术简介》服务接口定义和实现地址的分离。WS-CDL则用于另一种形式的组合，它站在全局视角来描述一个业务活动中所有参与方之间的交互。通常用”choreography”（编排）称呼这种组合，而用”orcheography”（编18制）称呼BPEL那种基于某个节点的本地视角的组合。所以WS-CDL中的基本活动interaction与BPEL的invoke的一个不同是需要指出两个role。使用时，各参与方需要从一个WS-CDL流程中导出自己视角下的交互模型（即BPEL意义下的流程）。但现实中，WS-CDL很少被使用。主要原因应在于目前的电子商务应用中对于精确描述、并自动验证全局视角下的业务流程的需求还不够强。其它批评包括：WS-CDL只能描述两个节点参与的交互、不能描述多方交互；缺乏严格的语义基础，虽然标准制定后作者试图建立[20]起到π-Calculus的映射，但结果不明。2.3.3增强的MEP“发布/订阅”模式在面向对象设计、消息系统等场合都有广泛的应用。在该模式中，订户先向能产生消息的发布者发出订阅请求，此后发布者每当产生新的消息后，主动将其发往所有订户。WS-Eventing和WS-Notification各自定义了一个基于Web服务的实现。WS-Eventing较简单，定义了一组服务管理订阅状态的操作：Subscribe,Renew,GetStatus,Unsubscribe,SubscriptionEnd，并设置了一个SubscriptionManager节点，用于代表发布者受理除了第一个Subscribe之外的其它后续操作。关于递送模式，只预定义了一个基本的push模式，但可以扩展。WS-Notification被设计为可用在基于WSRF的网格系统中。比起WS-Eventing另外定义了：Filter；Topic（用以对订阅分类）；pull模式；Demand-basedpublishing（如果没有订阅者，就不发布消息）等。还允许将订阅表示为WS-Resources（见WSRF），对发布者的角色进行了细分：区分了Publisher和NotificationBroker（与SubscriptionManager不同）。2.3.4资源及其状态按照SOAP和WSDL本身的规定，Web服务是没有状态的。但有的Web服务应用中处理的是有状态的资源，如网格环境中所要使用和管理的计算、存储等类型的资源就是因节点的加入和离开而不断变化的，因此需要相应扩展规范以便可以用统一的机制操作这些资源，并能尽量动态地获得描述这些资源的元数据。WSRF系列标准最初由网格技术联盟GlobusAlliance和IBM联合HP等企业在200418原因是：choreography本意是集体舞的编舞、编排，orcheography指交响乐作曲，而交响乐演奏时会有站在舞台上的指挥来协调众乐手，而集体舞演出时舞台上不会有这样的控制角色。28 技术报告《Web服务和语义Web技术简介》年发布，以用于网格架构OGSA中。WSRF将资源及提供其访问接口的Web服务合称作WS-Resource，引入可被WSDL文档嵌入或引用的ResourcePropertiesDocument来描述资源的各种性质；定义了一组操作来访问、操作其中规定的资源性质，如：GetResourcePropertyDocument,GetResourceProperty,Set(/Insert/Update/Delete)ResourceProperties等；而在各种操作中，资源的ID作为WS-Addressing格式EPR的引用参数统一地放在SOAP报头内。WS-Notification被用来实现资源状态变化的主动报告。WSRF还定义了WS-Resource的生命周期模型和对WS-Resource进行分组的ServiceGroup。之后，由没有参与WSRF制定过程的Microsoft、BEA等发起制定了功能类似的规范WS-Transfer，其中的操作PUT,DELETE,GET,CREATE的对象是单个资源实例，但使用独立的WS-Enumeration规范来获取多个实例；主动的报告则使用WS-Eventing。而WS-MetadataExchange被用来动态地获取XMLSchema,WSDL,WS-Policy等元数据。后来IBM等加入，对WS-Transfer加以扩充，加入了对资源片段粒度上操作等的支持，使之能兼容WSRF，产生了WS-ResourceTransfer(WS-RT)。WS-Transfer中规定的操作与REST所用的HTTP诸请求方法的高度类似反映了这样一个现象：Web服务技术不仅可以用于构建SOA应用，而且可以像REST在Web上所做的一样，一样用来构建所谓的“ROA”应用(Resource-OrientedArchitecture)。2.3.5管理Web服务互通异构系统的能力使其也适合于构建分布式计算环境的网络管理系统，即在被管设备上设立专门的管理用Web服务端点作为与管理客户端的接口。由于网管系统中主要的任务是查看、设置被管资源的属性，现有的两个基于Web服务的管理标准就是分别基于WSRF和WS-Transfer系列标准制定的。WSDM基于WSRF，提出了一种新的资源性质：ManageabilityCapability(下文简称MC)。各种具体的资源在其资源模型中可以定义反映其特点的各个MC，规范中预定义了几个通用于各种资源的：Identity,ManageabilityCharacteristics(管理端点支持哪些Manageabilitycapabilities),CorrelatableProperties(在用于识别出两个管理端点对应的是否是同一个资源，当Identity不足以区分时),Description,States(具体资源特定的状态),OperationalStatus(资源的可用性状态),Metrics,Configuration。该标准还为对Web服务的管理做了更具体的规定：除了列出了前述States和Metrics的具体可用值外，还定义了一个特殊的MC用于让业务端点能够提供其管理端点的地址：ManageabilityReferences。在网管技术标准化组织DMTF(DistributedManagementTaskForce)制定的WS-Management则基于WS-Transfer系列标准。由于有众多硬件厂商的参与，该标准注重使其能适应从手持无线终端到大型数据中心的各种能力的IT设备。其产生背景是：在网29 技术报告《Web服务和语义Web技术简介》管技术中，由于原有的网管标准SNMP主要被用来监控而不是配置、且基于二进制的消19息格式也不便于基于脚本的配置，因此出现了WS-Management、NETCONF标准和WBEM架构。WS-Management针对几个在各种操作中通用的信息分别定义了SOAP头：OperationTimeout,MaxEnvelopeSize,Locale,OptionSet和RequestEPR；定义了一个简单的元数据发现用的操作Identify，以在传输协议已知的情况下动态地识别出一个支持WS-Management的服务；要求长度超过MaxEnvelopeSize(默认为32767字节)的SOAP消息使用MTOM传输；并定义了如何将DMTF提出的CommonInformationModel映射到WS-Management。2.4综合使用这些标准——部署和开发模型应用Web服务技术时系统的基本部署方式与传统的分布式组件技术类似，由容器处理安全、事务、可靠性等与具体业务无关的QoS类属性，各服务在开发时只需要关注自己的业务逻辑，在部署时通过简单的配置和/或开发过程中少量的标注即可利用运行环境所提供的QoS能力。具体地，WS-*扩展标准定义了许多SOAP头，一种标准通常在Web服务运行环境中有一个对应的处理模块，常称作handler。消息达到后，各handler先处理相应的SOAP头（有时也需读取和处理消息体），然后再交给具体的Web服务去处理消息体，发送时情况类似，例如图2所示的开源Web服务平台Axis2的消息处理流程。另外，类似于传统组件，一个具体的Web服务也可以启动多个实例。图2Web服务典型的运行时消息处理流程(来自Axis2的用户指南文档)在复杂些的企业计算环境中，可以引入企业服务总线(ESB,EnterpriseServiceBus)来实现更大程度的松耦合。ESB是传统的面向消息的中间件(MOM)与Web服务技术结合的产物，通常能以两种方式工作。一种是作为SOAP中介节点，客户端使用WS-Addressing的To元素在SOAP消息中指出最终接收者的地址，但在传输层发送消息19见http://en.wikipedia.org/wiki/Netconf30 技术报告《Web服务和语义Web技术简介》时，将消息发往ESB，ESB处理相应的SOAP头后把消息转发给最终接收者。另一种方式是完全的代理，ESB对每种Web服务实现一个代理服务，客户端看到的WSDL中的服务端点的地址就是ESB代理服务的地址，运行时，ESB代理服务收到请求消息后，根据系统配置确定真正的服务端点，并代表客户向其转发消息。让企业内各Web服务端点和其客户都接入一个ESB总线通常能获得如下能力：ò提供可靠的消息转发，支持同步、异步、多播等等多种消息模式；ò支持多种传输协议，使采用不同协议的客户和服务器可以互通；ò提供基于消息内容的消息路由，使得服务端点可以动态地加入、离开，实现更灵活的负载均衡和更大的可伸缩性；ò根据系统配置通过XSLT等方式转换消息格式、以匹配客户和服务器端消息格式的可能存在的差异。目前已有许多商用的和开源的ESB产品，而且其中也普遍提供了对WS-Security,WS-RM等基本扩展协议的支持。另外，在部署、分析基于Web服务的应用时有两个标准化组织提出的参考模型可供参考：OASIS标准《ReferenceModelforServiceOrientedArchitecture》从服务描述、交互、策略、现实效果、执行环境和可见性六个方面描述了SOA架构下的服务。W3C的一份非正式文档(WorkingGroupNotes)《WebServicesArchitecture》给出了一个元模型表达了面向服务的、面向资源的和面向消息的三种模型之间的关系。Web服务的开发方式也符合图2中所示的模式。具体地，除了使用Java、.NET等平台中开发环境提供的特定的开发、发布服务方式外，一个SOA软件企业合作组织OpenSOA还提出了一种SOA服务的标准开发模型：SCA/SDO。其中SCA(ServiceComponentArchitecture,服务组件体系结构)为基于Web服务或其它技术实现的SOA组件定义了一个统一的部署接口：向外提供一些服务（WSDLportType或JavaInterface）、向内引用了一些其它组件提供的服务，向下由特定的技术(Java,BPEL等)来实现，向上暴露一组性质供运行环境对组件行为进行配置；并定义了相应的组件间连接方式和组合方式。SDO(ServiceDataObjects)则用于统一和简化在应用中访问和操作来自异构数据源的多种类型的数据的方式，其中的数据源类型包括关系数据库、XML数据源、Web服务和企业信息系统等。虽然SCA/SDO规范在2009年才提交给OASIS，但多个相关企业已经在其开发环境中加入了对其的支持。31 技术报告《Web服务和语义Web技术简介》3语义WEB对Web服务的自动发现和组合问题来说，最关键的是如何准确描述Web服务的功能，并且是以服务提供者和潜在的请求者之间都能理解的方式。而前面介绍的Web服务标准绝大多数只涉及语法方面，开发者要想理解一个服务的功能，仅看WSDL文档及其引用的结构化描述是不够的，还需要结合大量的注释或文字说明。而近年兴起的语义Web技术致力于让机器理解Web上数据的含义，正好可以弥补现有Web服务标准的不足。语义Web技术大致产生于1999年W3C成立RDFInterestGroup时，其目标是改造现有的Web，使得机器可以理解其中的数据，进而可以由Agent软件按照其所有人的要求和偏好为其完成诸如预约医生、安排行程在内的诸多任务（参见TimBerners-Lee等描述的[21]一个场景）。对此宏伟目标，W3C专门成立的SemanticWebActivity制定了如图1所示20的路线图。图1语义Web技术分层(来自w3.org)20www.w3.org/2007/03/layerCake.png该图从2000年起几经变化，这里给出的版本是2007年3月、迄今最新的。32 技术报告《Web服务和语义Web技术简介》3.1数据模型及其语义：RDF/RDFSRDF(ResourceDescriptionFramework)是语义Web的基础，它用“资源-性质”分层模型来表示Web上的数据使得数据具有清晰的语义，使用URI引用来标示资源使得可以在整个Web范围内识别资源实例；从而使得不同节点上对同一个资源的描述可以整合起来。“资源-性质”模型类似于传统的“实体-关系”模型，是对数据建模的一种自然方式，但基本的XML语法所描述的数据模型是树状的，树中的一个节点代表的是资源还是性质并不明确，不利于各节点数据中资源信息的识别和合并。而另一方面，传统的关系数据库只工作于一个有限的范围，其中实体标示只具有本地意义，无法识别不同数据库中的同一个实体；另外，由于Web松散、自由的特点，一种资源的性质数量可以很多、但一个具体实例的许多性质（暂时）没有明确取值的情况非常普遍，这使得把一种资源当作一个关系来建模、存储的方式效率很低。具体地，RDF抽象语法中用三元组(triple)作为描述资源信息的基本结构。一个三元组包括主语、谓语、宾语各一个，表示一个资源(主语)的一个性质(谓语)有一个宾语所表示的取值；可以表示为一个以主语、宾语为节点、以谓语为有向边的有向图。一个这样的三元组集合称作一个RDF图(RDFGraph)。语法上，三元组中使用的词汇有取值互不相交的三种类型：URI引用(URIReference)、文字(literal)、空节点(blanknode)，且谓语只能是URI引用，主语不可以是文字。抽象语法的具体编码可使用XML或更简练的N3等格式。文字可以是有类型的或无类型的(plain)，无类型文字可有可选的语言标签，类型需要有URI标示，表示一个从词法空间到值空间的映射。预定义的rdf:XMLiteral类型用于在RDF中允许宾语是一个XML文档片段。空节点类似于一阶逻辑中的存在变量，其名称不重要；将一个RDF图E中的空节点替换为其它空节点或URI引用、文字得到的图称为E的实例。[22][23]RDF使用模型论为上述语法赋予了明确的语义。模型论用于将一种形式语言的语法空间中的词汇、句法等元素映射到语义世界即由资源个体组成的集合中，即将语法空间中的句子解释为对语义世界的结构的限制，从而能利用集合论严格的数学模型来判断该语言中一组句子中是否存在不一致之处，并识别出还有哪些未写出来的句子也成立。在一阶逻辑等处采用的经典模型论中，多元谓词直接映射为资源的元组集合，因此个体名集、概念名集、关系名集之间互不相交，但RDF模型论中为了使RDF能尽可能灵活而打破了这个限制，这使得其容易造成困惑，如：rdfs:Resouce类是rdfs:Class类的父类、却同时又是其一个实例，如图2左侧所示。33 技术报告《Web服务和语义Web技术简介》图2RDF/RDFS中预定义的几个主要类之间的关系其中的要点在于：RDF模型论对概念、性质区分了内涵和外延的不同。一个类、一个性质本身也是一个资源个体，但它们都另外有自己的外延，一个类的外延是一个资源个体的集合，一个性质的外延是一个资源个体二元组的集合。相应地，类A是类B的子类被定义为A的外延是B的外延的子集；而类A是类B的实例被定义为资源A本身属于类B的外延。类似地，性质的外延中也可以出现性质，这使得可以表达性质的性质和取值为性质的性质。实现这种区分的办法是：将词汇表中的所有词汇先映射为资源个体，然后再对后者中是类、性质的那些资源使用另外的映射定义其外延，如图2右侧所示。需要注意的是，对于RDF框架及其预定义词汇，RDF模型论并不是为其赋予语义的唯一方[24]式，也可以像UML那样采用分层模型，可以采用公理语义即将其映射为另一种已有[25]明确语义的形式语言等。具体地，RDF模型论中定义了三种解释：简单解释、rdf-解释、rdfs-解释，分别为不同范围内的语法元素指定语义条件和公理：RDF框架本身（即词法和句法，不包含任何预定义词汇）、在前者中加入RDF预定义词汇、进一步加入RDFS预定义词汇。从一个解释通常还能为语法空间得出一些推理规则（即蕴涵规则）：若某些句子为真即可断定另外某些句子也为真。在每种解释下，语法空间中“蕴涵”的含义都与经典模型论相同：一个RDF图的集合S蕴涵RDF图E，当且仅当任何能满足S中每个成员的解释I都满足E。其中I满足E指I(E)=true。RDF中，词汇表V上的一个简单解释(simpleinterpretation)I=被定义为：1)IR是一个非空的资源集合，是I的论域(domainoruniverse)；34 技术报告《Web服务和语义Web技术简介》2)IP是一个非空集合，称作I的性质集合；（注：IP未必是IR的子集）3)LV是IR的子集，包含了V中所有无类型的文字；4)IS是一个映射：V中URI引用的集合→IR∪IP；5)IL是一个映射：V中有类型的文字的集合→IR；IR×IR6)IEXT是一个映射：IP→2；（注：即为一个性质定义其外延）相应地，I满足E，即I(E)=true，当且仅当存在一个从V中的空节点集到IR的映射A，使得：对∀t=(s,p,o)∈E，有I(t)=true即：I(p)∈IP且(I(s),I(o))∈IEXT(I(p))；其中：1)对∀w∈V,且w是URI引用，有I(w)=IS(w)；2)对∀w∈V,且w是有类型的文字，有I(w)=IL(w)；3)对∀w∈V,且w是无类型的文字，有I(w)=w；4)对∀w∈V,且w是空节点，有I(w)=A(w)。相应的简单蕴涵可以通过简单的语法比较来识别，共有两种基本形式，可用逻辑形式示意为：P∧Q⇒P和foo(baz)⇒∃x.foo(x)。准确地说，是：RDF图S蕴涵E当且仅当存在S的一个子图是E的实例。可以证明，简单蕴涵满足单调性和紧致性。简单解释没有相应的公理，有4条蕴涵规则都跟空节点有关，如：gl规则:若RDF图E包含三元组(uuu,aaa,_:nnn)，其中空节点_:nnn已被指派给一个文字lll（使用类似于前述第二种基本形式的lg规则），则可为E添加(uuu,aaa,lll)。rdf-解释在简单解释中加入了解释RDF预定义词汇的语义条件，有下面一条用于解释rdf:Property的和另外两组解释rdf:XMLLiteral的：x∈IP当且仅当(x,I(rdf:Property))∈IEXT(I(rdf:type))即将rdf:Property与IP集合关联起来（结合后面的rdfs-解释后则可以说rdf:Property被解释为一个外延是IP的类）；另外也意味着IP∈IR，意味着对简单解释中IP和IR关系做了进一21步限制。相应的公理和2条蕴涵规则都比较直观，分别如：rdf:typerdf:typerdf:Property.rdf:subjectrdf:typerdf:Property.rdf:_1rdf:typerdf:Property.rdf:nilrdf:typerdf:List.和蕴涵规则：rdf1规则:若E包含(uuu,aaa,yyy)，则可添加(aaa,rdf:type,rdf:Property).rdfs-解释添加的10组语义条件主要用来解释rdfs:Class,rdfs:Resource,rdfs:Literal,rdfs:domain,rdfs:range,rdfs:subClassOf和subPropertyOf等。为此，先为IR引入了一个21其中规则rdf2涉及了RDF框架中一个有争议的、并不必需的限制：文字不能做主语。35 技术报告《Web服务和语义Web技术简介》表示类这种资源的集合的新的子集IC，以及一个表示类的外延的映射ICEXT：x∈ICEXT(y)当且仅当∈IEXT(I(rdf:type))；下面几条将几个重要类（确切地说，是下面这些词汇被解释成的类）之间的关系定义为图2所示的样子：IC=ICEXT(I(rdfs:Class))；IR=ICEXT(I(rdfs:Resource))；LV=ICEXT(I(rdfs:Literal))；若x∈ICEXT(I(rdfs:Datatype))，则∈IEXT(I(rdfs:subClassOf))；其它几组比较直观，如指定性质rdfs:subClassOf和rdfs:subPropertyOf具有自反性、可传递性，用性质rdfs:domain、rdfs:range表示性质的“定义域”、“值域”等等。若将其中定义这四个性质的条件从必要条件改为充分必要条件，则得到一组扩展的语义条件。相应的许多RDFS公理和13条RDFS蕴涵规则大多都与这几个类和性质有关，也比较直观，分别如：rdf:typerdfs:domainrdfs:Resource.rdfs:domainrdfs:domainrdf:Property.rdfs:subClassOfrdfs:rangerdfs:Class.rdf:_1rdf:typerdfs:ContainerMembershipProperty.......和蕴涵规则：rdfs2规则：若E包含(aaa,rdfs:domain,xxx)和(uuu,aaa,yyy)，则可添加(uuu,rdf:type,xxx)；rdfs9规则：若E中包含(uuu,rdfs:subClassOf,xxx)和(vvv,rdf:type,uuu)，则可添加(vvv,rdf:type,xxx)若使用前述扩展的语义条件，还可以增加9条蕴涵规则，如：ext1规则：若E中包含(uuu,rdfs:domain,vvv)和(vvv,rdfs:subClassOf,zzz)则可添加(uuu,rdfs:domain,zzz)ext8规则：若E中包含(rdfs:subClassOf,rdfs:subPropertyOf,www)和(www,rdfs:range,vvv)，则可添加(rdfs:Class,rdfs:subClassOf,vvv)（注：通常这一条几乎没有用处）3.2本体——RDFS，OWL和描述逻辑人和人之间的沟通需要双方能理解同一门语言，语言包括两个主要部分：语法和词汇表。无论语法规则是否曾被明确地逐条归纳出来、词汇表是否曾被整理成词典，交流中双方都在有意识或无意识地使用着这两者。类似地，要让机器理解Web上其它节点的数据，除了需要RDF提供的“语法”外，还需要共同的词汇表，这就是本体在语义Web中担当的角色。36 技术报告《Web服务和语义Web技术简介》计算机科学中“本体”的概念产生于语义Web出现之前，在知识工程（典型任务是知识表示与推理）中被用以捕获相关领域的共有知识，确定领域内共同认可的术语，通常还使用形式化模型对这些术语和术语间的关系给出严格明确的定义，实现对领域知识的推理。按照一个被广泛被接受的定义，本体是“共享概念模型的明确的形式化规范说[23]明”。使用时，当一个领域中建好本体后，各组织使用本体中的概念、性质等术语来标注本地数据中的资源个体信息，这样，机器就可以理解其它组织中的数据位于领域概念模型中的什么位置。不同的本体定义语言有不同的表达能力。在语义Web技术中，虽然RDF也能定义最简单的本体，即用rdf:Property定义的性质的列表，但RDFS和OWL是两个最主要的本体定义语言。用RDFS可以表示的概念模型特性主要有：类、性质、性质的定义域和值域、类和性质之间的继承关系，其语义和推理规则见前一小节。OWL的表达能力更强，如给出了多个构造新类、多个对性质进行约束的方式，将性质根据取值类型分为对象性质和数据类型性质两种等。它包含3个表达能力依次增强的子语言：OWLLite,OWLDL和OWLFull。其中OWLFull使用与RDFS类似的语义，其表达能力是RDFS的超集，适用于需要RDF框架下最大的表达能力但不需要可计算性保证的场合。OWLDL使用与OWLFull相同的词汇表，但改用传统的模型论语义，从而在保持计算完全性的前提下提供了尽可能强的表达能力。OWLLite与DL语义类似，但通过减少可以使用的词汇来降低了计算复杂性，适于构建一个有少量约束特性的分类体系。可以认为后两者是对一个受限的RDFS版本的扩展。具体而言，OWLDL和OWLLite的语义要求RDF模型论中类、性质、个体三种集合互不相交，在类和性质的外延中只能出现个体。为此为rdfs:Class新定义了一个子类owl:Class表示这样的类的集合，它的每一个成员即OWL类的外延都是个体集合，显然owl:Class不属于其本身的外延，它是用来定义其它OWL类的元类。另外预定义了一个OWL类owl:Thing，其外延是所有个体（不包括类和性质）组成的集合，它是所有的OWL类的超类，是rdfs:Resource的子类。但在OWLFull的语义下，owl:Class的外延与rdfs:Class相同，owl:Thing也与rdfs:Resource相同。与RDF类似，OWLDL语义也细分为两个层次，基本的解释与RDF简单解释类似，只解释了OWL描述本体的基本框架：即将词汇区分为类、性质、个体、数据等不同种类；经扩展后，才对用以表示类描述、性质描述、类/性质/个体公理的OWL预定义词汇分别进行了解释。OWL也使用一种抽象语法进行定义，可以很容易地转换为RDF图、并进一步编码为RDF/XML，规范中还另外给出了一种直接使用XML编码OWL的非正式标准。OWL还为不同本体间的映射提供了一些简单的描述功能，如用于类的owl:equivalentClass和用于个体的owl:sameAs、owl:differentFrom。37 技术报告《Web服务和语义Web技术简介》就理论基础而言，OWLDL和OWLLite分别相当于描述逻辑SHOIN(D)和SHIF(D)。描述逻辑(DescriptionLogic,DL)产生于1980年代，是知识工程领域中为了平衡表达能力和计算复杂性之间的矛盾对一阶逻辑进行剪裁取舍而获得的用于描述由概念体系组成的领域模型的一族逻辑。DL通常以概念（即OWL中的类）作为描述的核心，概念具有角色（role,即OWL中的性质），概念上可施加多种约束，从简单的概念和角色可以构造出更复杂的概念、角色；还可以指定如下形式的公理：两个概念（或角色）之间的包含、不相交，两个个体的相同或不同。通常约定用一些字母或符号表示不同的语言特性，组合这些不同的特性便得到不同的具体的描述逻辑。表3中列出了常见的特+[26]性。其中的ALC和R的结合ALCR+因与模态逻辑S4的紧密联系而被简称为S。与以前的DL不同的是，OWL使用URI引用代替了名称、使用XMLSchema数据类型，以符合Web环境的需要。表3描述逻辑常见语法特性及其语义(取自[26])利用与表3中的语义条件相应的蕴涵规则，可在以OWL描述的本体上进行比在RDFS本体上更多的推理、发现更多的隐含知识，如利用特性N，假设本体中使用RDF/XML语法定义了如下类Company：38 技术报告《Web服务和语义Web技术简介》1......则若在Web上不同的文档中分别用该本体标注了这样的数据：和则一个OWLDL推理机可以据此推出：http://example.org/persons/Bill_Gates和http://example.org/persons/William_H_Gates两个URI引用指的是同一个资源——注意OWL和其它DL一样，不使用唯一名称假设，不同的名称可能对应于同一个资源。大多数OWL推理工具都是将OWL本体转换为DL知识库进行推理的。在DL知识库中，将关于概念、性质的知识组成TBox子库(T:Terminology)，而将关于个体的知识组成ABox子库(A:Assertion)，大体上分别相当于本体定义文件和用本体标注的数据文件。一[30]般而言，给定知识库K，DL系统可以处理的典型查询有这么几种关于类的：1)类-实例成员关系查询：a)给定类描述C，问个体a是否是C的实例；或者b)给定类描述C，求给出K中所有C的实例；c)给定个体a，求给出K中所有a是其实例的类（或其中最具体的那个）；2)类包含查询：a)给定类描述C和D，求问C是否包含于D；b)给定类描述C，求给出K中所有（或最具体的）C的超类，或者求给出K中所有（或最宽泛的）C的子类；3)类的可满足性问题：给定类描述C，求问C是否关于K是可满足的（即一致的）。和它们各自相应的关于性质的查询。在多数描述逻辑中，又以关于类的这几种查询最为常见，而它们都可以归结为类的可满足性问题，如“C⊑D”等价于“C⊓¬D是不可满足[27]的”。因此，描述逻辑系统一般通过用Tableau算法判断一个类描述是否可满足的方法来处理各种查询。在各种逻辑和数据库系统中，对于系统中未给出的信息——如一个个体是否是某个类的实例——如何处理，有两种不同的方式：封闭世界假设(CloseWorldAssumption)中，认为未给出即意味着否定；而在开放世界假设(OpenWorldAssumption)中，未给出意味着信息缺乏，在进行公式集Σ是否蕴涵公式f的判断时，需要对未给出的信息分别按照肯39 技术报告《Web服务和语义Web技术简介》[27]定、否定两种情况考虑所有可能的模型。数据库中通常采用封闭世界假设；而描述逻辑通常采用开放世界假设，这更符合知识表示、语义Web的需要，但增加了推理上的复杂性。SHOIN(D)的推理复杂性是NEXPTIME-complete，SHIF(D)是EXPTIME-complete，[23]而OWLFull那种同时具有描述逻辑和RDF(S)表达能力的知识语言是不可判定的。但前两者的复杂度是基于最坏情况给出的、并不能说明在更多的平均情况下的性能，在以往实践中现实规模的知识库上，推理算法复杂度是指数级的描述逻辑也能在合理时间内[2-27]完成许多现实的处理任务。在2009年成为正式标准的OWL2中，在保持推理问题可判定和后向兼容的情况下又新增加了一些特性：特性Q(见表3)，Self约束，性质的自反性，不相交的性质，性质链包含，为概念指定键性质集，以及通过为XMLSchema基本类型指定一些facet的值来定义新的数据类型。OWL2的表达能力大致相当于文献[28]所称的SROIQ，由于性质的构造方式被大为增强，在相应的知识库中可将关于性质的公理和事实独立独立出来组成子库RBox。另外，OWL2基于对常见特性之间的交互对复杂性的影响的更精细的分[29]析，针对典型的应用场景制定了3种新的子语言（即轮廓(profile)）：OWLEL：用于类和性质数量庞大，但本体结构简单、主要用于概念分类的场合，如生命科学。基本推理任务相对于本体规模的复杂度是PTIME。理论基础是只包含存在量化的EL系列描述逻辑。OWLQL：适用场合：与传统的关系数据库互通，本体规模小，但实例数据规模庞大。虽然能力相当受限，但仍包含了UML、ER图等概念模型的大多数主要特征。其合取查询(conjunctivequery)可以映射为SQL，相对于数据大小的复杂度是LOGSPACE，与数据库相同。理论基础是DLLite系列描述逻辑。OWLRL：用于与基于规则的系统互通，通过基于规则的推理引擎来实现；并在不牺牲太多表达能力的情况下实现有效的推理。其主要推理任务相对于本体规模是PTIME。其设计受了DLP和pD*的启发。3.3规则——DLP,SWRL和RIF本体适合于表示概念模型，而对于其它类型的知识，在语义Web出现之前，知识工程领域中大量使用规则的形式来表示，因此语义Web中需要将本体和规则结合起来。1.各种规则系统。根据是否是基于逻辑的，可粗略地将基于规则的系统分为逻辑程序(LogicProgram)和产生式规则系统(Productionrulesystem)两种。前者与霍恩规则(Hornrule)密切相关，在一阶逻辑(FOL)公中，将一个合式公式对应的合取范式的每个分量称作一个子句40 技术报告《Web服务和语义Web技术简介》(clause)，从而一个公式对应于一个子句集；子句的分量称作文字(literal)，根据是否有否定连接词¬分为正文字和负文字两种。最多只含一个正文字的子句称为霍恩子句，恰有一个正文字的霍恩子句(A0∨¬A1∨¬A2∨...∨¬An)可等价地表示为(A1∧A2∧...∧An→A0)，也称为霍恩规则。本节提到的各种规则系统之间的关系如图3所示。DLProductionRuleSystemGenericLP/PrologDLPFOL(NAF)(actions)DatalogDefiniteLP/HornLP(functions)moreexpressiveLPs(∃,∨,NAFinhead;¬)图3各种规则系统的表达能力及其与DL、FOL之间的大致关系逻辑程序就是一个有限的规则集合。不同表达能力的规则对应于不同的逻辑程序。Prolog语言所实现的一般型规则(Generic/NormalRule)是一种重要的规则，其形式是：H:-B1,B2,...,Bm,notBm+1,...,notBn(2-1)其中符号":-"左侧称作头部或结论，右侧称作躯体或前提；H和Bi均是原子公式；逻辑连接词not称作缺省否定(DefaultNegation)或失败即否定(NegationAsFailure,NAF)。若22n=m，则(2-1)式可称作确定型规则(DefiniteRule)，对应于霍恩规则，若进一步地还不含函数，则称作Datalog规则（通常Datalog还要求满足一些安全性条件，如头部出现的变量都必须在躯体中出现）。若n=m=0，则称为事实(fact)。称不含变量的公式和规则为基态的(ground)。直观上，(2-1)式的含义是：若前提中的各公式均成立，则结论成立；缺省否定与FOL中的经典否定不同，大致可以理解为“不存在”，它使得一般型规则超出了FOL。一个逻辑程序Π支持的基本的查询是原子查询，包括两种形式：1.询问一个基原子能否2.原子公式A，求这些变量的所有能使A被Π蕴涵的绑定。形式地，一般型规则的语义可以通过稳定模型语义(StableModelSemantics)来指定[31]。若将含有变量的规则和公式看作将其中的变量分别替换为程序中所有常量而形成的所有基态规则和基态公式的缩写，则称程序Π中所有基态原子公式形成的集合为Π的Herbrand基库(Herbrandbase)，记作HB(Π)。22严格地说，霍恩规则就是FOL，而Definite-LP是与FOL不同的另一种形式逻辑，但因有可高度对应的语义，有[30]时对两者不加区别。41 技术报告《Web服务和语义Web技术简介》定义2-1(稳定模型).一个确定型逻辑程序Π的稳定模型是HB(Π)的符合如下条件的最小子集S：对于Π中的任何规则H:-B1,B2,...,Bm，若B1,...,Bm∈S，则H∈S。记作a(Π)。S对于一般型逻辑程序Π，对于任何原子集合S，设Π为从Π中删去：1)任何在躯体中含有公式notA的规则，其中A∈S；2)其它公式的躯体中形如notA的公式；S所得的程序，显然其中不含not，若其稳定模型与S相同，即S=a(Π)，则称S是Π的稳定模型。□稳定模型S满足基态原子p当且仅当p∈S.一般型逻辑程序Π蕴涵一个公式f(记作Π⊧f）当且仅当Π的每个稳定模型都满足f。确定型逻辑程序总有唯一的稳定模型，但一个一般型逻辑程序可能没有、有1个或者有多个稳定模型。特别地，可层化(Stratified)的一般型逻辑程序都有唯一的稳定模型。霍恩子句对FOL表达能力所做的限制换来了较好的可计算性。不含等词的Datalogv+1程序的稳定模型可以在O(n)的时间内求得，其中v是每条规则中逻辑变量的个数的最[30]大值。一般的Datalog的计算复杂度则属于ExpTime类；一般的霍恩逻辑程序是不可判定的，但当要求其不含递归时，属于NExpTime类；而一般型逻辑程序，若是可层化的，则属于ExpTime类(但[32]Theory5.2说是Pi(0,n+1)的,待弄清)，否则在稳定模型语义下是1[32]Π−complete(这个符号表示比NExpTime还复杂？待弄清)。若在一般型规则的基础1上，允许结论中出现析取、存在量词和/或缺省否定、在结论和前提中出现经典否定，[26][31]可得到一系列表达能力更强、但计算复杂性更高的规则。求解方法上，主要有从目标出发的后向搜索和从事实出发的前向搜索两种。前者如Prolog语言使用的SLD消解，后者如Jess等系统中采用的Rete算法（一种通过将规则集预编译成存储了当前事实的有向网络来换取性能的经典算法）。由于搜索过程中在有多个后继节点时有多种选择策略，具体的逻辑程序往往兼具声明式程序和命令式程序的特征，如Prolog语言中的规则除了在功能上能保证上述语义外，其性能则受到前提中各个文字出现顺序的影响。产生式规则相当于是把基于逻辑的规则中的结论部分替换为一组动作(Action)。基本的动作有增加事实（相当于基于逻辑的规则中的结论）、删除事实和修改事实。产生式规则系统广泛用于诸如“根据顾客的消费记录决定其可享受的折扣率”这样的商业场景、以及基于规则的专家系统中。动作的存在，使得其语义不能像一般的逻辑一样用模[22]型论来指定，但可由操作语义来指定：将规则解释为转移系统上的状态转移操作，其中每个状态由一个事实集合组成，运行过程是“匹配-冲突调解-行动”三个步骤的循环，直到达到某个终止状态、没有规则可匹配、或者遇到停机动作为止。求解方法大多(如OPS5)采用基于Rete算法的前向搜索。42 技术报告《Web服务和语义Web技术简介》2.规则与DL本体的结合。在语义Web中结合本体与规则时，一个基本的问题是描述逻辑(DL)与霍恩规则的结合。这两者都是FOL的子集，在实际中都有相对良好的计算性能，在传统的知识工程中都有着较多的应用（尤其是后者）。但描述逻辑和霍恩规则的性能优点是在分别对FOL做了不同的限定后获得的，因而所使用的推理机制不同（分别是Tableaux算法和SLD消解），对于两者表达能力的并集，除了使用通用但低效的FOL定理证明器外，尚无有效[30]的推理算法，因此结合过程的要点是在表达能力和推理难度之间进行取舍。具体地说，[30]描述逻辑中类描述的模型是“树形”的，即只能单独对类的各个性质单独进行限制，而不能限制不同性质之间的关系，另外还不包含函数，谓词中参数个数通常不大于2（但实质上这一点不构成限制，可通过具体化(reification)来模拟多元谓词）；而在霍恩规则中，用FOL完备连接词集合{¬,∧,∨,∀,∃}来衡量，前提中不能有否定，结论中不能有析取且变量必须是全称量化的。[26]具体的结合方法可以分为两种：异构法和同构法。异构法视本体和规则为独立的组件，均保持各自的知识表示与推理方式，良好的接口是其无缝结合的关键。代表系统有AL-log和CARIN，其中的Datalog异构知识库由两部分组成：DL知识库和Datalog异构规则组成的逻辑程序，异构规则在普通的Datalog规则的躯体中额外加入若干DL原子，其形式如C(a),或R(a,b)，其中C、R分别是DL概念和角色；推理过程中，由DL推理机负责检查DL原子的推导和可满足性检查，由规则推理机负责规则级的模式匹配及推导。[30]而同构法将本体和规则嵌入同一个逻辑语言，使用统一的知识表示与推理方式，DLP[34][35]和SWRL即是两个这样的语言。其中DLP识别出描述逻辑和霍恩规则的交集，将描述逻辑位于其中的成份转换为Datalog规则。这意味着按照前述霍恩规则对FOL的限定方式，表3中语义里包含了相应连接词的类描述或性质描述不能出现在规则的相应位置。而SWRL中允许OWLDL类描述和性质描述而不仅仅是类和性质作为Datalog规则的谓词，这意味着SWRL规则结论中会包含析取和存在量词、前提中会包含否定，因而超出了霍恩规则，可看作是本体和规则的并集，但[35]指出了其不可判定。现实中能支持SWRL的推理引擎都不能支持其全部特性。3.语义Web的相关规范。在规则及其与本体集成方面，W3C形成了RIF(RuleInterchangeFormat)系列规范（在2009年已进入候选标准阶段），主要目的是为Web上各规则系统之间的交互提供一个统一的语法接口和语义模型。其中子语言RIF-BLD(BasicLogicDialect)相当于霍恩规则，但使用具有面向对象特征的框架(frame)语法，其模型论语义类似于RDF模型论；子语言RIF-PRD(ProductionRuleDialog)是一种产生式规则；并识别出这两者的交集RIF-Core以便它们之间的交互。43 技术报告《Web服务和语义Web技术简介》[36]在其中的《RIFRDFandOWLCompatibility》规范中，指定了在一个RDF(S)/OWL本体与RIF-BLD规则同时存在的异构系统中（形式是：规则文档中引用了若干本体），如何以一致的语义去理解规则和本体两种知识。在本体方面，分别考虑了RDF的各种解释、OWL2DL、OWL2Full多种语义。其中OWL2DL情况下，对RIF-BLD的语义加以限制，将性质和类对应的资源集合与普通的资源个体集合相分离，从而得到一种符合DL模型论的语义，在此基础上进行合并。注意，这种统一语义对OWL只涉及其基本框架，而未解释用于构造各种类和性质描述和各种公理的OWL预定义词汇，即与这些相关的推理需要在本体引擎内进行，将结果用OWL基本框架的形式——即用具名的类、性质对资源个体的标注（以及表示具名的类、性质、个体之间的包含关系/异同性的公理）——呈现给规则引擎。另外，规范中非形式化地给出了一种用于同构系统中的语法，用于将OWL2DL的一个子集OWL2RL（大致相当于DLP）所定义的本体——包括其中的类和性质描述和各种公理——转换成规则形式后嵌入RIF-BLD文档。3.4RDF数据的查询和生成——SPARQL、GRDDL等图4SPARQL语言结构示意图与关系数据库使用SQL作为查询语言类似，W3C为RDF数据制定了查询语言SPARQL。各要素之间的关系如图4所示。语法形式上，SPARQL与SQL类似，用FROM子句指定要在其中查询的RDF数据集；用WHERE子句指定查询条件即图模式(GraphPattern)，基本的图模式就是主语、谓语、宾语可以是变量的三元组(即TriplePattern)的集合；一个SELECT查询的求解结果就是将图模式中的变量映射为常量（资源URI或44 技术报告《Web服务和语义Web技术简介》文字），使得WHERE图模式被实例化为FROM数据集的一个子图，但该条件可以通过引入特定的蕴涵体制(entailmentregime)而支持相应的推理（如RDFS/OWL）。考虑到Web上不同数据源之间的交互和集成，需要在同一个查询中查询来自不同RDF图的数据，SPARQL的FROM部分实际上将RDF的三元组模型扩展为包括一个图ID23在内的四元组（在Graph图模式中）。RDF图的ID也用URI标示，是一种特殊的资源，可像其它资源一样被变量引用。对于查询中的默认RDF图，其中的数据可以不出现图ID。另外：求解结果中的“RDF实例映射”用于映射RDF空节点；“Optional图模式”用于指定查询图模式中不要求必须匹配的部分，但若数据集中能够匹配，则在结果中也要给出其变量映射。其它几种查询都是基于SELECT查询定义的，CONSTRUCT用于使用求解结果中的变量映射创建新的RDF图，ASK查询相当于是询问相应的SELECT查询的求解结果是否非空；DESCRIBE用于给出求解结果的一些相关信息，但规范中未进行正式定义。对SPARQL查询求值的复杂度是PSPACE-complete，但若图模式表达式中只使用了AND和FILTER，则是O(|P|·|D|)的(其中P、D分别是查询图模式和数据集的大小)，在后[37]者中加入UNION后是NP-complete。另外，相应的SPARQLProtocolforRDF标准还用WSDL2.0定义了一个在Web上传递SPARQL查询请求和结果数据的消息格式。定义包括一个接口SparqlQuery及其唯一一个操作query，以及它们到传输协议HTTPGET、HTTPPOST和SOAP1.2的绑定。正在制定中的(2009年11月)SPARQL1.1规范还打算加入子查询、结果聚集、否定等特性，以及更新数据集的能力、用REST方式管理RDF图的能力。语义Web的成功，需要在Web上大量使用RDF模型表示各种数据，W3C制定了一些用于简化RDF数据生成过程的规范。其中GRDDL用于结合XSLT将各种XML/XHTML文档中的数据转换为RDF格式；RDFa则通过将性质、资源标示等信息以属性的形式直接插入到XHTML文档中，客户端工具可从中提取出RDF三元组，它与此前为一些应用指24定元标记的基于XML的微格式(Microformat)技术类似；POWDER用于为特定类型的多个资源批量生成指定的性质，如照片适用的版权协议、Web页面是否以可在手机上显示、资源的来源信息等，方法是用户在专门的Web描述资源（是一个XML文档）中列出自定义的性质信息（descriptionSet）及其适用的资源IRI（集合）的列表，运行时用户获取此文档后、访问这些IRI，得到各具体资源的标示后即可为其生成一些RDF三元组；正在制定中的RDB2RDF则旨在建立一个将关系数据库中的数据映射为RDF/OWL表示的标准语言。23确切地说是IRI，可看作允许Unicode字符直接出现于其中的URI，在RFC3987中定义。24http://microformats.org45 技术报告《Web服务和语义Web技术简介》3.5更进一步——语义Web研究及应用现状目前，图1的路线图上面三层——即统一逻辑、证明和信任——还没有规范出台，而语义Web的研究工作出现了两个方向，分别侧重“语义的一面”和“Web的一面”。前一方向着眼于使用强大的逻辑、获取更多的智能。途径是：将传统的知识表示、形式逻辑及其它人工智能(AI)领域中的成果针对Web环境的需要加以发展和应用，更精细地探索描述逻辑和规则系统的各种语法特征的组合的计算效率和有效推理算法，对基本的描述逻辑、规则系统加以扩展使之支持模糊推理、动态演化等。在近几年的国际语义Web会议(ISWC)上有许多这方面的文章，这些研究为上面三层技术的选择、规范的制定进行了有益的探索。但如文献[38]指出的：语义Web不能简单等同于AI，它还有“Web的一面”，即需要处理Web上大规模的数据集及不同数据集之间的连接、互通。但由于形式逻辑中表达能力与计算复杂性的矛盾，为了获得这种场合下所需的性能，需要使用放弃了OWL中许多高级能力的轻量级本体，即“少量的语义走得远”。循此方向，研究界探索了大规模RDF[39][40][41][42][43]数据集的有效存储和查询技术，并在一个W3C社区项目LinkingOpenData的协调下建立起一个包含了众多彼此相连的RDF数据集的庞大数据网络（见图5），到2009年11月，其中已拥有131亿条RDF三元组，1.42亿个连接不同数据集的RDF链接（如通过owll:sameAs指出分别位于两个数据集中两个URI表示的是同一个资源），包括百科知识（Wikipedia）、新闻媒体（纽约时报等）、政府数据（英国和美国）、地理数据、音乐娱乐、生物学研究、计算机科学文献（DBLP）等许多领域，主要由各站点将本地数2526据库、Web上原有的数据转换而成，广泛使用DublinCore,FOAF等通用本体和领域特定的本体，访问方式有直接下载、用专门工具直接浏览、提供SPARQL端点等。从而为语义Web技术的落地提供了一个强有力的平台。25http://dublincore.org/26http://rdfweb.org/foaf/46 技术报告《Web服务和语义Web技术简介》图5LinkingOpenData项目中的数据集及彼此间的链接关系(来自w3.org)另外，W3C还制定了一个轻量级的OWL本体SKOS用于表示图书馆分类那样的知识分类体系，SKOS将图书馆分类中的类别看作skos:Concept类的实例，实例之间通过skos:broader和skos:narrower等形成层次关系。但SKOS的概念层次系统只是现有词典式分类系统的直接的RDF表示，与具有严格逻辑基础的OWL不同，SKOS不是一种形式化建模语言。在研究界，还有如下问题受较多关注：同一领域不同本体之间的映射、与信息检索/机器学习/社会网络等技术的结合、用户接口的设计、对动作性知识的建模（即语义Web服务，见下文）等。3.6语义Web服务标准及提案到目前为止，W3C所制定的语义Web标准如同图1所显示的那样，都是针对Web上静态性内容，即数据性知识的，而对于描述像Web服务这样的动态性知识的语义是不够的。[21]但在TimBerners-Lee关于语义Web的设想中，是包括了诸如预约医生这样的动态性活动的。于是，很自然地产生了语义Web服务的想法，即把语义Web技术应用于Web服务的描述中，使得Web服务的功能可以形式化地进行刻画、被不同机器一致地理解，从而47 技术报告《Web服务和语义Web技术简介》可以实现Web服务的自动发现、自动调用、自动组合、自动监控和管理。自从McIlraith等开创性的论文[44]发表以来，学术界对语义Web服务已进行了大量的研究，并向W3C提交OWL-S,WSMO,SWSO,SAWSDL等数个标准。这些提案刻画Web服务功能的方式，源自于以往对形式语义学、人工智能规划、形式逻辑等的研究，关于这些背景知识，参见文献[51]。语义Web服务的标准化工作虽然多年前就已启动，但至今并未有实质性进展。多个提案中，只有最简单的SAWSDL在2007年8月被WebServiceActivity接受为正式标准外，其它在提交后数年内未有进展。而SAWSDL过于简单，离学术界的期望相差较远。[45]OWL-S由斯坦福大学、卡耐基-梅隆大学等主要位于北美的大学学者提出。它用OWL语言定义了一个用来描述Web服务的语义的概念体系，包括三个部分：Profile集中、简要地描述了服务的功能、QoS、发布者信息等，主要用于服务发现过程；Process描述了服务的内部流程，即由顺序、选择、循环、并行等控制结构所连接的对各原子服务的调用，用于服务组合过程；Grounding则用于在Process中调用到的原子服务的语义描述和它们语法描述即WSDL消息之间进行必要的映射，用于服务调用过程。前两者中对服务的功能描述基于输入参数、输出参数、前提条件和效果四个方面(合称IOPE)，其中前两方面均为参数类型的列表，该类型通常指的是OWL本体中定义的类，但也可以是XML数据类型；后两方面即PE基于逻辑表达式，其中前提条件是一个具有真值的逻辑语句，结果则包括多个<具体条件,具体效果>逻辑语句对。从而服务的功能被表示为：在现实世界的状态满足前提条件的情况下，服务执行后，若某个具体条件被满足则其对应的具体效果在执行后的世界状态中为真。这一模型来自于人工智能中规划(planning)问题的表[46]示语言如PDDL中对动作的表示方式。OWL-S是几个提案中提出较早、在学术界影响也较大的一个，它与现有语义Web标准结合较好，但该提案中没有定义Process所描述的组合服务如何作为一个新的服务映射到WSDL描述以便发布，这使得OWL-S在服务组合方面的定位限于最终用户视角，而不能像BPEL那样用于服务提供商。另外，对于PE中的逻辑表达式使用什么样的语言标准中未加限定，需要使用者自行选择。[47]WSMO由以DERI组织为主的多个欧洲机构提出，使用一种语法上具有面向对象特征的逻辑F-Logic对服务建模。它将服务的功能表示为Precondition,Postcondition,Assumption,Effect四部分，前两者分别表示服务执行前后信息空间的状态(即输入参数、输出参数及相关约束)，后两者表示服务执行前后现实世界的状态。条件描述语言采用定义WSMO自身所用的WSML，该语言相当于用面向对象语法表示的带有非单调否定的FOL,为方便具体环境下的实现，还定义了对应于描述逻辑和规则语言的子语言48 技术报告《Web服务和语义Web技术简介》WSML-DL和WSML-Flight(大致相当于Datalog)、WSML-Rule(进一步允许函数)，以及它们的交集WSML-Core。另外还在顶层本体中引入Goal表示服务请求。WSMO中描述信息状态空间的方式与世界状态空间一致，允许一般的逻辑表达式，这比OWL-S中只是类型列表的输入和输出参数更灵活、表达能力更强。但其与现有标准相去较远，虽然其大部分内容可以用OWL表示。WSMO在顶层引入Mediator元素用以处理不同服务、请求之间的数据、流程差异，这与一般通过引入新的适配服务、组合服务的处理方式相比，更加系统化，但却不必要。另外，其组合服务内部结构表示方式尚不完善，对choreography的定义与通常(如WS-CDL标准中)的含义不同，指的是在最终用户视角下如何调用各个服务实现自己的目标，类似于OWL-S的Process。[48][49]SAWSDL最初由IBM公司、美国UniversityofGeorgia以WSDL-S之名提出，后来获得DERI组织支持。它十分简单，引入少量几个元素，利用WSDL的扩展机制在interface、operation、fault、XML元素或类型定义几个层面进行标注，将它们关联到本体中的概念。并能像OWL-S一样，用XSLT准确地在语法层和语义层的实体之间进行映射。其中在inerface和operation层面的标注用于对服务进行分类，其它标注给出了IO参数的语义。虽然SAWSDL充分利用了现有的Web服务和语义Web标准，不存在规定不清的细节，便于在产业界推广，但其只基于IO和分类的方式(虽然在最初的WSDL-S提案中有PE的内容)，不能准确表示服务的功能，不能满足学术界对Web服务自动发现、自动调用等的需要。[50]SWSO由美、欧多家机构合作提出，旨在将OWL-S、学术界针对有状态服务提出的基于状态机的模型以及一定程度上的WSMO结合在一个框架中，用FOL给出一个全面的、具有严格逻辑基础的模型以便可以在同一个框架内描述各种不同的服务模型(其FLOWS本体)，同时另外定义了一个基于规则系统的子集ROWS以给出一个可实现的参照模型。它像OWL-S一样用PDDL的动作模型来描述服务对世界状态的改变，且引入特别的谓词Kref以克服PDDL中不区分输入参数和输出参数的不足，使用FOL来描述IOPE中的条件，比较灵活；它将消息通道的创建、销毁加以建模、表示成特别的动作，使得它像BPEL一样可以描述服务间消息通道的动态变化。但是，目前尚未出现基于SWSO的系统。SWSO自身的问题有：其描述服务功能所用的FOL是基于流程建模方面的ISO标准PSL的，而该标准被支持的程度不如规划系统、情景演算、规则系统那样广泛；整个标准过于驳杂、不够完善和一致，如在其所举的一27个例子中大量地直接使用了来自WSMO的模型。27http://www.w3.org.page-archive.org/Submission/SWSF-Applications/49 技术报告《Web服务和语义Web技术简介》4参考文献[1]WhiteJE.AHigh-LevelFrameworkforNetwork-BasedResourceSharing.RFC707,Jan.1976.[2]ThurlowR.RPC:RemoteProcedureCallProtocolSpecificationVersion2.RFC5531,May2009.[3]RPCLanguageSpecification,http://docs.sun.com/app/docs/doc/816-1435/6m7rrfn9k?a=view2002,RetrievedatOct.2009.[4]EislerM.XDR:ExternalDataRepresentationStandard.STD67,RFC4506,May2006.[5]PritchardJ.COMandCORBASidebySide-Architectures,Strategies,andImplementations[M].AddisonWesleyLongman,Inc.1999.（徐金梧,张晓彤,屈蓉等译,COM与CORBA本质与互用.清华大学出版社,2002.第6章重要服务）[6]HenningM.TheriseandfallofCORBA[J].ACMQueue,June2006,4(5):28-34.[7]CarterS.TheNewLanguageofBusiness-SOA&Web2.0[M].IBMPress,2007(袁月杨,麻丽莉译.SOA&Web2.0——新商业语言.清华大学出版社,2007年)[8]ErlT.SOAprinciplesofServiceDesign[M].PrenticeHall2008.（郭耀译.SOA服务设计原则.人民邮电出版社.2009）[9]NewcomerE,LomowG.UnderstandingSOAwithWebServices[M].PearsonEducation,2005(徐涵译.电子工业出版社,2006)[10]张鹏翥.MBA系列教材——信息技术[M].上海交通大学出版社,2006[11]王晨光.顾问ERP[M].电子工业出版社,2009[12]JuricMB,BashaSJ,LeanderR,etal.ProfessionalJ2EEEAI[M].WroxPress,2002(袁然,汤代禄,刘立君等译.J2EEEAI编程指南.电子工业出版社,2002)[13]Wikipedia.EnterpriseApplicationIntegration.http://en.wikipedia.org/wiki/Enterprise_application_integration.2009.11访问[14]莫映.白话工作流发展史[J].程序员,2008,5:112-115.[15]PercivallG,ReedC,LeinenweberL,etal.OGCReferenceModel(OGC08-062r4).OpenGeospatialConsortiumInc.,2008[16]LiM,BakerM,TheGridCoreTechnologies[M].JohnWiley&Son,2004(王相林,张善卿王景丽译,网格核心技术,清华大学出版社,2006)[17]FieldingT.ArchitecturalStylesandtheDesignofNetwork-basedSoftwareArchitectures[T].DissertationfortheDoctoralDegree.Irvine:UniversityOfCalifornia,2000[18]陈康,郑纬民.云计算:系统实例与研究现状[J].软件学报,2009,20(5):1337-134850 技术报告《Web服务和语义Web技术简介》[19]RichardsonL,RubyS.RESTfulWebServices[M].O’Reilly2007(徐涵,李红军,胡伟译,电子工业出版社2008)[20]BarrosA,DumasM,OaksP.ACriticalOverviewoftheWebServicesChoreographyDescriptionLanguage[J].BPTrends,March2005[21]Berners-LeeT,HendlerJ,LassilaO.TheSemanticWeb[J].InScientificAmerican,May2001.[22]W3CRecommendation.RDFSemantics.http://www.w3.org/TR/2004/REC-rdf-mt-20040210/,2004[23]陆建江,张亚非,苗壮等.语义网原理与技术[M].北京:科学出版社,2007nd[24]PanJZ,HorrocksI.RDFS(FA)andRDFMT:TwoSemanticsforRDFS[C].InProc.ofthe2Int’lSemanticWebConf.(ISWC2003),LNCS2870.Berlin/Heidelberg:Springer,2003[25]GuhaRV,HayesP.Lbase:SemanticsforLanguagesoftheSemanticWeb.W3CNote,October2003[26]梅婧.语义Web本体与规则[T].博士学位论文,北京大学,2007[27]BaaderF,McGuinnessDL,NardiD,etal(ed).TheDescriptionLogicHandbook:Theory,Implementation,andApplications.Cambridge[M],UK:CambridgeUniverityPress,2003(pp.82-95;72-74;14-15,101)th[28]HorrocksI,KutzO,SattlerU.TheEvenMoreIrresistibleSROIQ[C].InProc.ofthe10Int’lConf.onPrinciplesofKnowledgeRepresentationandReasoning(KR2006).AAAIPress,2006[29]MotikB,GrauBC,HorrocksI,etal.OWL2WebOntologyLanguageProfiles.W3CRecommendation(http://www.w3.org/TR/2009/REC-owl2-profiles-20091027/),2009[30]GrosofBN,HorrocksI,VolzR,etal.DescriptionLogicPrograms:CombiningLogicProgramswiththDescriptionLogic[C].Proc.of12Int’lconf.onWorldWideWeb(WWW2003),2003.48-57[31]BaralC,GelfondM.Logicprogrammingandknowledgerepresentation[J].JournalofLogicProgramming,19/20:73–148,1994[32]DantsinE,EiterT,GottlobG,etal.ComplexityandExpressivePowerofLogicProgramming[J].ACMComputingServeys,33(3):374-425,2001[33]W3CRecommendation.RIFProductionRuleDialect.http://www.w3.org/TR/rif-prd/,2009[34]W3CMemberSubmission.SWRL:ASemanticWebRuleLanguageCombiningOWLandRuleML.http://www.w3.org/Submission/2004/SUBM-SWRL-20040521/,2004th[35]HorrocksI,Patel-SchneiderPF.AProposalforanOWLRulesLanguage[C].Proc.of13Int’lconf.onWorldWideWeb(WWW2004),pp.723-731.NewYork,2004[36]W3CCandidateRecommendation.RIFRDFandOWLCompatibility.http://www.w3.org/TR/rif-rdf-owl/,Oct.2009[37]PerezJ,ArenasM,GutierrezC.SemanticsandComplexityofSPARQL[C].InISWC2006,LNCS4273,pp.30–43,2006[38]HendlerJ.Thedarksideofthesemanticweb[J].IntelligentSystem.Jan/Feb,2007,22(1):2-4[39]AbarsDJ,MarcusA,MaddenSR,etal.ScalableSemanticWebDataManagementUsingVerticalPartitioning[C].InVLDB‘07,Vienna,Austria,pp.411-422,200751 技术报告《Web服务和语义Web技术简介》[40]WoodD,GearonP,AdamsT.Kowari:APlatformforSemanticWebStorageandAnalysis[C].InXTech2005Conference,2005[41]HarthA,UmbrichJ,HoganA,etal.YARS2:AFederatedRepositoryforQueryingGraphStructuredDatafromtheWeb[C].InISWC2007,LNCS4825,pp.211-224,2007[42]沈文南.一个RDF存储与查询系统的设计与实现[T].东南大学硕士学位论文,2006[43]W3CCommunityProject:LinkingOpenData.http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData/,from2007[44]McIlraithS,SonTC,ZengH.Semanticwebservices.IEEEIntelligentSystems,16(2):46–53,March/April2001[45]OWL-S标准提案.http://www.w3.org/Submission/OWL-S/[46]MartinD,PaolucciM,McIlraithS,etal.Bringingsemanticstowebservices:theOWL-Sapproach.In:Proc.oftheFirstInt’lWorkshoponSemanticWebServicesandWebProcessComposition(SWSWPC2004),LNCS3387.Berlin/Heidelberg:Springer,pp.26-42,2004[47]WSMO标准提案.http://www.w3.org/Submission/WSMO/[48]SAWSDL标准.http://www.w3.org/2002/ws/sawsdl/[49]WSDL-S标准提案.http://www.w3.org/Submission/WSDL-S/[50]SWSO标准提案.http://www.w3.org/Submission/SWSF/[51]赵文峰.信息提供类Web服务的自动发现和自动组合[D].博士学位论文,北京:北京邮电大学,2010(预计)52