[SOA资料整理]4、SOA的主要技术和标准

 

SOA的演进是伴随着很多标准和规范而发展起来的，包括XML、Web服务以及大量的和Web服务相关的标准，本节主要对于SOA相关的主要技术和标准规范进行简要的介绍。

1 XML标准
1996年， W3C开始从事可扩展标记语言XML（eXtensibl Markup Language，可扩展标记语言）的工作，XML的出现无疑为SOA的兴起奠定了稳固的基石。1998年2月10日发布了XML1.0，它是一种开发简单而又可扩展的、结构化和半结构化信息文本表示机制。
XML的设计源于SGML和HTML。IBM从60年代就开始发展的 GML（Generalized Markup Language，通用标记语言），其目的是使文件中能够明确的将标示与内容区隔 ，并使所有文件的标签使用方法一致。1978年，ANSI将GML加以整理规范，发布成为SGML，SGML它在上世纪60年代后期就已存在，这种广泛使用的元语言，允许组织定义文档的元数据，实现企业内部和企业之间的电子数据交换。1986年起为 ISO 所采用（ISO 8879），并且被广泛地运用在各种大型的文件计划中，但是SGML是一种非常严谨的文件描述法，导致过于庞大复杂，难以理解和学习，进而影响其推广与应用。于是，人们对SGML进行了简化衍生出 HTML。HTML 简单，在初期没有任何定义文档外观的相关方法，仅用来在浏览器里显示网页文件。随着因特网的发展，人们为了控制其文件样式，扩充了描述如何显现数据的卷标，在 Netscape 与 Microsoft 之间的浏览器大战后，HTML 标准权威性遭受重大的考验，所幸，到了HTML 4.0时，W3C 又恢复了其地位。然而，HTML不能解决所有解释数据的问题，如影音文件或化学公式、音乐符号等其它型态的内容；HTML的存在效能问题，需要下载整份文件，才能开始对文件做搜寻的动作；HTML的扩充性、弹性、易读性均不佳。为了解决以上问题，专家们使用SGML精简制作，并依照HTML的发展经验，产生出一套使用上规则严谨，但是简单的描述数据语言—XML，XML目的即在于提供一个对信息能够做精准描述的机制，藉以弥补 HTML 太过于表现导向的特质。 
通过XML，开发人员摆脱了HTML语言的限制，可以将任何文档转换成XML格式，然后跨越互联网协议传输。借助XSLT接受方可以很容易地解析和抽取XML的数据。这使得企业既能够将数据能够以一种统一的格式描述和交换，同时又不必负担SGML那样高的成本。事实上，XML实施成本几乎和HTML一样。
第一代XML协议的可扩展性不强。在实现每一次变更之前，协议开发人员都要达成一致。并且必须修改协议版本，以便工具可以区分新版本的协议和旧版本协议，并恰当地处理XML。第二代协议使用XML名字空间解决了这一问题。
XML是SOA的基石，XML规定了服务之间以及服务内部数据交换的格式和结构。XSD Schemas 保障了消息数据的完整性和有效性，而XSLT使得不同的数据表达能沟通过Schema映射而互相通信。

2 Web服务及WS-*标准
目前，SOA的主流实现方式是基于Web Service和WS-*标准的。很多情况下，一提起SOA就会联想到Web service，接着继续联想到WS标准，SOA基本上成为了WS-*类型的Web service的别名了。这种方法是建立一个优秀的核心、定义WS-*的标准、以策略开始、引入注册，这也就是Gartner规定的SOA的方法。
其中，Web服务是实现SOA中服务的最主要手段，其基本的协议包括SOAP，WSDL和UDDI，本节主要对这三种协议进行概要的介绍，另外针对WS-*标准进行简概述。

2.1 SOAP
SOAP（Simple Object Access Protocal，简单对象访问协议）由微软和IBM共同制定，用于规范WEB服务标准，实现异构程序与平台间的数据交换，有助于实现大量异构程序和平台之间的互操作性，从而使存在的应用能够被广泛的用户所访问。
SOAP是基于XML的协议，包括三个部分： 封套(envelope)定义了消息内容和处理的框架、一套编码规则用来表达应用定义数据类型的实例以及表达远程过程调用和响应的协定。与已定义的中间件不同， SOAP只是定义了一种基于XML的文本格式 而没有定义什么ORB代理或是SOAP API 因此用户可以方便的开发自己的应用而不必担心兼容性。
SOAP的一个主要目标是使存在的应用能被更广泛的用户所使用。为了实现这个目的，没有任何SOAP API或SOAP 对象请求代理，SOAP是假设你将使用尽可能多的存在的技术。SOAP的指导理念是“它是第一个没有发明任何新技术的技术”。它采用了已经广泛使用的两个协议：HTTP和XML。HTTP用于实现SOAP的RPC风格的传输，而XML是它的编码模式。采用几行代码和一个XML解析器，HTTP服务器（如MS的IIS或Apache）立刻成为了SOAP的ORBs。因为目前超过一半的Web服务器采用IIS或Apache, SOAP将会从这两个产品的广泛而可靠的使用中获取利益。这并不意味着所有的SOAP请求必须通过Web服务器来路由，传统的Web 服务器只是分派SOAP请求的一种方式。因此Web服务如IIS或Apache对建立SOAP性能的应用是充分的，但决不是必要的。
几个主要的CORBA厂商已经承诺在他们的ORB产品中支持SOAP协议。微软也承诺在将来的 COM版本中支持SOAP。DevelopMentor已经开发了参考实现，它使得在任何平台上的任何Java或Perl程序员都可以使用SOAP。而且 IBM和Sun也陆续支持了SOAP协议，和MS合作共同开发SOAP规范和应用。目前SOAP已经成为了W3C和IETF的参考标准之一。
SOAP提供了如下功能：
1) 定义通信单元的机制。在SOAP中，所有信息在一个清晰的可确认的SOAP消息中。一个SOAP封套封装了所有其他的信息。一个消息可以有一个消息体，消息体中可以包含任何XML格式文档；
2) 错误处理机制，可以标识错误源和导致错误的原因，并允许错误诊断信息在共享者和交互者之间传递；
3) 可扩展件机制。使用XML模式和名字空间技术，灵活扩展元素；
4) 灵活的数据表示机制。允许交换已经以某种格式序列化的数据，同时也提供了以XML格式表示诸如编程语言数据类型这样的抽象数据结构的规则；
5) 表示远程过程调用(RPC)和作为响应的SOAP消息的约定，因为RPC是最常见的分布式计算交互类型，并且便于映射为过程式编程语言结构；
6) 支持以文档为中心的方法；
7) 将SOAP消息束定到HTTP的机制。

2.2 WSDL
WSDL（Web Services Description Language，Web服务描述语言）是Web Services技术重要组成部分，它将Web Services描述定义为一组服务访问端点，客户端可以通过这些服务访问端点对包含面向文档信息或面向过程调用的服务进行访问。
1999年HP公司是第一个引入Web服务概念，eSpeak实现了“电子服务”平台。的软件供应商。2000年6月Microsoft提出了“Web服务”术语，把Web服务作为.NET计划重要组件。在Microsoft的SDL（Service Description Language，服务描述语言）和SCL（SOAP Contract Language，SOAP契约语言）和IBM的NASSL（Network Accessible Service Specification Language，网络接入服务描述语言）这两项技术的结合，形成了WSDL的基础。SCL采用XML来描述应用程序所交换的消息，NASSL描述服务接口和实现细节。2000年9月25日IBM、Microsft和Ariba提出WSDL1.0。2001年3月15日，他们提交的WSDL1.1成为W3C的Note。2002年7月9日提出WSDL1.2，2003年11月10日提出WSDL2.0。
WSDL是XML描述的网络服务，基于消息机制、包含面向文本或面向过程信息的操作集合。操作及消息的抽象定义与它们具体的网络实现和数据格式绑定是分离的。这样就可以重用这些抽象定义。消息是需要交换的数据的抽象描述；端点类型是操作的抽象集合。针对一个特定端点类型的具体协议和数据格式规范构成一个可重用的绑定。一个端点定义成网络地址和可重用的绑定的联接，端点的集合定义为服务。WSDL首先对访问的操作和访问时使用的请求／响应消息进行抽象描述，然后将其绑定到具体的传输协议和消息格式上，以最终定义具体部署的服务访问端点。在WSDL的框架中，可以使用任意的消息格式和网络协议。在WSDL规范中，定义了如何使用SOAP消息格式、HTTP GET／POST消息格式以及MIME格式来完成Web Services交互的规范。
WSDL描述了分布在Internet环境中服务操作的抽象定义接口和服务的具体实现端口，实现远程计算资源共享。但是，WSDL通常是协议定义的，协议描述缺乏准确性和严格性，需要一种形式化的表示和描述方法。通过服务描述，服务提供者将所有调用 Web 服务的规范传送给服务请求者。实现 Web 服务体系结构的松散耦合，无论是请求者还是提供者可以各自独立地使用平台、编程语言或分布式对象模型。服务接口定义是一种抽象或可重用的服务定义，它可以被多个服务实现定义实例化和引用。服务接口定义和服务实现定义结合在一起，组成了服务完整的 WSDL 定义。这两个定义包含为服务请求者描述如何调用以及与 Web 服务交互的足够信息。服务请求者可以要求获得其它关于服务提供者端口的信息。此信息由服务完整的 Web 服务描述提供。
通俗的解释，WSDL描述了Web服务的三个基本属性：
服务做些什么：—服务所提供的操作(方法)；如何访问服务：—数据格式以及访问服务操作的必要协议；服务位于何处：—由特定协议决定的网络地址，如URL。

2.3 UDDI
UDDI（Universal Discovery Description and Integration，通用服务发现和集成协议）是一组基于Web的注册中心的名字，这些注册中心存储描述了商业或其他实体的信息及其提供的服务的相关技术调用界面。UDDI 提供了一组基于标准的规范用于描述和发现服务，还提供了一组基于因特网的实现。
UDDI最早由 IBM、Ariba 和 Microsoft 建立。2000年9月发布UDDI1.0，2001年6月发布UDDI1.0。UDDI 注册中心里的数据从概念上可以分为四类，每一类表示 UDDI 最上层的一种实体。每个这样的实体都指定有自己的 UUID，利用这个标识符总能在 UDDI 注册中心的上下文中找到它：技术模型(Technical model)、企业(Business)、企业服务(Business service)、服务绑定(Service binding)。
企业与服务的注册信息分成以下三组：白页、黄页和绿页。白页表示有关企业的基本信息，如企业名称、经营范围的描述、联系信息等等。它还包括该企业任何一种标识符；黄页信息通过支持使用多种具有分类功能的分类法系统产生的类别划分，在更大的范围内查找在注册中心注册的企业或服务；绿页是指与服务相关联的绑定信息，并提供了指向这些服务所实现的技术规范的引用和指向基于文件的 URL 的不同发现机制的指针。

2.4 WS-*标准
仅仅使用Web服务基本协议无法保证企业级SOA的需要，因此在SOA的发展过程中制定了许多Web服务的相关标准。如针对安全性和可靠性，有WS-Security，WS-Reliability和WS-ReliableMessaging等协议保障；针对于复杂的业务场景，WS-BPEL和WS-CDL这样的语言来将多个服务编排成为业务流程；也有管理服务的协议，如WS-Manageability，WSDM等。跟Web服务相关的标准，还在快速发展当中。目前在SOA产品和实践中，除了基本协议外，比较重要的还包括BPEL，WS-Security，WS-Policy和SCA/SDO，如表1所示给出了一个基本的总结，详细说明见附录二。
表1 部分Web服务相关协议

Business Domain Specific extensions	Various	Business Domain
Distributed Management	WSDM, WS-Manageability	Management
Provisioning	WS-Provisioning
Security	WS-Security	Security
Security Policy	WS-SecurityPolicy
Secure Conversation	WS-SecureConversation
Trusted Message	WS-Trust
Federated Identity	WS-Federation
Portal and Presentation	WSRP	Portal and Presentation
Asynchronous Services	ASAP	Transactions and Business Process

Transaction	WS-Transactions, WS-Coordination, WS-CAF
Orchestration	BPEL4WS, WS-CDL
Events and Notification	WS-Eventing, WS-Notification	Messaging
Multiple message Sessions	WS-Enumeration, WS-Transfer
Routing/Addressing	WS-Addressing, WS-MessageDefivery
Reliable Messaging	WS-ReliableMessaging, WS-Reliablity
Message Packaging	SOAP, MTOM
Publication and Discovery	UDDI, WSIL	Metadta
Policy	WS-Policy, WS-PolicyAssertions
Base Service and Message Description	WSDL
Metadata Retrieval	WS-MetadataExchange

3 SCA/SDO标准规范
2007年初，18家致力于联合推动创建SOA行业标准的领先技术厂商，宣布了SCA（Service Component Architecture，服务组件架构）和SDO（Service Data Objects，服务数据对象）规范中关键部分的完成，并将正式提交给OASIS（The Organization for the Advancement of Structured Information Standards，结构化信息标准促进组织），通过其开放式标准过程进行推动。
SCA规范旨在简化服务的创建和合成，对于运用基于SOA方式服务的应用构建十分关键。随着SCA规范的完成，联盟合作厂商希望将其标准化过程提交给OASIS。此外，联盟厂商也已完成了SDO规范，旨在实现对多个站点中多种格式数据的统一访问，并将把SDO基于Java的规范开发和管理提交给Java 社团过程（JCP）组织，而基于非Java的规范 (C++ ) 提交给OASIS。
SCA和SDO规范能帮助企业更便捷地创建新的以及改造现有的IT资产，使之可复用、易整合，以满足不断变化的业务需求。这些规范提供了统一服务的途径，大大降低了在应用开发过程中，因程序设计语言与部署平台的不同而产生的复杂性。SCA和SDO规范都是用于简化业务逻辑和业务数据呈现的新兴技术。早期用户已经开始实行这些规范并从中获得了价值。
 
图 SCA/SDO规范与用户和厂商的关系图

3.2 SCA
SCA的基本思想是将业务功能作为一系列服务来提供，这些服务组合到一起，以创建满足特定业务需要的解决方案。这些复合应用程序既可以包含专门为该应用程序创建的新服务，也可以包含来自现有系统和应用程序的业务功能（作为复合应用程序的一部分来重用）。SCA为服务组合和服务组件的创建（包括SCA复合应用程序内部现有应用程序功能的重用）提供了模型。
SCA旨在包含广泛的服务组件技术以及用于连接这些组件的访问方法。对于组件，它不仅包括各种编程语言，还包括通常与这些语言一起使用的框架和环境。对于访问方法，SCA复合应用程序允许使用各种常用的通信和服务访问技术，例如，Web服务、消息传递系统和远程过程调用（RPC）。
SCA包含以下规范：
1) SCA EJB组件模型
SCA Java EJB客户及实现（SCA Java EJB Client and Implementation）规范描述了如何在SCA复合应用程序中使用EJB和EJB模块。它在两个层次上定义了EJB的使用，一是可以将完整的EJB模块像SCA复合体一样使用，不需要做任何内部细节上的改动，借助SCA连接到EJB模块提供的服务上，并将EJB模块的服务需求连接到EJB模块的外部组件所提供的服务上；二是可以使用单个EJB，由SCA提供所有的连接。
2) SCA装配模型
SCA装配模型(SCA Assembly Model)定义了构成一个SCA系统的各种构件及其之间的关系。包括：SCA复合体，SCA构件，服务，服务实现，服务需要和连线等。
3) SCA策略框架(SCA Policy Framework)
非功能性需求（例如安全性）的捕获和表示是服务定义的一个重要方面，在组件和复合应用程序的整个生命周期中都会对SCA产生影响。SCA提供了策略框架以支持约束、能力和服务质量预期的规范，从组件设计直到具体部署。此规范描述了框架及其使用。
4) SCA Java注释、API和组件实现
SCA Java公共注释和API(SCA Java Common Annotations and API)规范定义了Java API和注释，以支持使用Java编程语言来构建服务组件和服务客户。有一些紧密相关的模型，它们描述了如何在SOA上下文中使用其他基于Java的框架和模型，例如Spring和EJB，这些模型也使用此规范定义的公共注释和API。此外，Java组件实现规范还定义了用于创建服务组件的简单Java POJO模型。
5) SCA客户及实现：C++
SCA C++客户及实现(C++ C&I)规范定义了API和注释，以支持使用C++来编写适合SCA组装模型的服务组件和服务客户。
6) SCA客户及实现：BPEL
SCA WS-BPEL客户及实现(BPEL C&I)模型指定了如何将WS-BPEL进程用作SCA组件。
7) SCA客户及实现：PHP
针对PHP的SCA客户及实现模型定义了如何在“SCA装配”中使用PHP脚本和对象。
8) SCA客户及实现：Spring
针对Spring的SCA Java客户及实现模型指定了Spring框架如何与SCA一起使用，以实现以下目的：
进行粗粒度的集成：与Spring的集成将在SCA复合体层次进行，其中Spring应用程序上下文提供了完整的SCA复合体，并通过SCA暴露的服务和服务需求。这意味着Spring应用程序上下文定义了SCA复合体的具体实现的内部结构。
从SCA组件类型开始：利用Spring，可以实现任何SCA复合应用程序，这些应用程序使用WSDL或Java接口来定义可能具有某些特定于SCA扩展的服务。
从Spring上下文开始：可以将任何有效的Spring应用程序上下文用作SOA中的组件实现。特别地，应该可以从任何Spring上下文生成SCA复合应用程序，并在“SCA装配”中使用这些复合应用程序。
9) SCA绑定规范
SCA绑定(SCA Binding)规范适用于服务和服务需求。绑定允许通过特定的访问方法或传输来提供服务并满足服务需求。
Web服务绑定允许利用Web服务技术来访问外部需求或公开SCA服务。SCA提供了服务组件之间的互连的复合视图，而Web服务提供了用于访问服务组件的互操作方式。Web服务绑定还提供了SCA系统与其他服务之间的互操作衔接，这里的其他服务是指SCA系统的外部服务，但它们供SCA复合体使用。
JMS绑定允许SCA组件使用JMS API来通信。它提供了连接到所需的JMS资源的JMS特有的连接细节。它支持使用Queue和Topic类型的目标。
EJB Session Bean绑定可以将先前部署的Session Bean集成到SCA装配中，并允许向使用EJB编程模型的客户公开SCA服务。EJB绑定既支持无状态的Session Bean模型也支持有状态的Session Bean模型。

3.3 SDO
SDO是BEA 和 IBM共同发布的一项规范，而且它正由JSR-235专家组进行标准化以通过JCP（Java 标准化组织）的审核。SDO是Java平台的一种数据编程架构和API，它统一了不同数据源类型的数据编程，提供了对通用应用程序模式的健壮支持，并使应用程序、工具和框架更容易查询、读取、更新和检查数据。利用SDO，应用程序编程人员可以一致地访问和操纵来自异构数据源的数据，包括关系数据库、XML数据源、Web服务和企业信息系统。
为支持各种可能的应用，标准中包括了对各种常用语言的支持，包括：SDO for Java and C++，SDO for PHP，SDO for C，SDO for COBOL。详细内容可以从相关的白皮书和规范正文中获得。

4 REST架构
这里有越来越多的趋势表明SOA和Web service并不是互相等同的，除了基于Web Service和WS-*标准的、被称为正统SOA方法之外，REST(Representational State Transfer)软件架构也逐渐成为SOA实施的一种方式。
REST软件架构是当今世界上最成功的互联网的超媒体分布式系统，它让人们真正理解网络协议HTTP本来面貌，同时也正在改变互联网的网络软件开发的全新思维方式。AJAX技术和Rails框架把REST软件架构思想真正地在实际中很好表现出来。目前微软也已经应用REST，并提出把现有的网络变成为一个语义网，这种网络将会使得搜索更加智能化。 
REST软件架构是由Roy Thomas Fielding博士在2000年博士论文中首次提出的，该论文描绘了开发基于互联网的网络软件的蓝图。如下图所示，REST软件架构是一个抽象的概念，是一种为了实现这一互联网的超媒体分布式系统的行动指南。利用任何的技术都可以实现这种理念。而实现这一软件架构最著名的就是HTTP协议。通常REST也写作为REST/HTTP，在实际中往往把REST理解为基于HTTP的REST软件架构，或者更进一步把REST和HTTP看作为等同的概念。 HTTP不是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软件的协议。它不仅仅能够对于互联网资源进行唯一定位，而且还能说明对于该资源进行怎样运作。这也是REST软件架构当中最重要的两个理念。而REST软件架构理念是真正理解HTTP协议而形成的。
REST软件架构之所以是一个超媒体系统，是因为它可以把网络上所有资源进行唯一的定位，不管你的文件是图片、文件Word还是视频文件，也不管你 的文件是txt文件格式、xml文件格式还是其它文本文件格式。它利用支持HTTP的TCP/IP协议来确定互联网上的资源。
REST软件架构遵循了CRUD原则，该原则对于资源（包括网络资源）只需要四种行为：创建(Create)、获取(Read)、更新(Update)和销毁(DELETE)就可以完成对其操作和处理了。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。
尽管网络服务目前是以SOAP技术为主，但是REST将是是网络服务的另一选择，并且是真正意义上的网络服务。基于REST思想的网络服务不久的将来也会成为是网络服务的主流技术。REST不仅仅把HTTP作为自己的数据运输协议，而且也作为直接进行数据处理的工具。而当前的网 络服务技术都需要使用其它手段来完成数据处理工作，它们完全独立于HTTP协议来进行的，这样增加了大量的复杂软件架构设计工作。REST的思想充分利用 了现有的HTTP技术的网络能力。
实际上目前很多大公司已经采用了REST技术作为网络服务，如Google、Amazon等。在Java语言中重要的两个以SOAP技术开始的网络服务框架XFire和Axis也把REST作为自己的另一种选择。
与WS-*技术标准相比，REST更加适合轻量级应用，REST架构风格的优势就在于其简洁性，越来越多的Web 2.0网站和软件开发供应商把他们的业务服务往REST架构风格上面靠，以努力使得Web资源可编程共享化、Web服务的API更URL化。