SOA 的基本概念及设计原则浅议

SOA是英文词语"Service Oriented Architecture"的缩写，中文有多种翻译，如"面向服务的体系结构"、"以服务为中心的体系结构"和"面向服务的架构"，其中"面向服务的架构"比较常见。SOA有很多定义，但基本上可以分...

  SOA是英文词语"Service Oriented Architecture"的缩写，中文有多种翻译，如"面向服务的体系结构"、"以服务为中心的体系结构"和"面向服务的架构"，其中"面向服务的架构"比较常见。SOA有很多定义，但基本上可以分为两类：一类认为SOA主要是一种架构风格;另一类认为SOA是包含运行环境、编程模型、架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境，涵盖服务的整个生命周期：建模-开发-整合-部署-运行-管理。后者概括的范围更大，着眼于未来的发展，我们更倾向于后者，认为SOA是分布式软件系统构造方法和环境的新发展阶段。

　　1、SOA 的基本概念

　　在SOA架构风格中，服务是最核心的抽象手段，业务被划分(组件化)为一系列粗粒度的业务服务和业务流程。业务服务相对独立、自包含、可重用，由一个或者多个分布的系统所实现，而业务流程由服务组装而来。一个"服务"定义了一个与业务功能或业务数据相关的接口，以及约束这个接口的契约，如服务质量要求、业务规则、安全性要求、法律法规的遵循、关键业绩指标(Key Performance Indicator，KPI)等。接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、相互理解。除了这种不依赖于特定技术的中立特性，通过服务注册库(Service ReGIStry)加上企业服务总线(EntERPrise Service Bus)来支持动态查询、定位、路由和中介(Mediation)的能力，使得服务之间的交互是动态的，位置是透明的。技术和位置的透明性，使得服务的请求者和提供者之间高度解耦。这种松耦合系统的好处有两点：一点是它适应变化的灵活性;另一点是当某个服务的内部结构和实现逐渐发生改变时，不影响其他服务。而紧耦合则是指应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当发生变化时，某一部分的调整会随着各种紧耦合的关系引起其他部分甚至整个应用程序的更改，这样的系统架构就很脆弱了。

　　SOA架构带来的另一个重要观点是业务驱动IT，即IT和业务更加紧密地对齐。以粗粒度的业务服务为基础来对业务建模，会产生更加简洁的业务和系统视图;以服务为基础来实现的IT系统更灵活、更易于重用、更好(也更快)地应对变化;以服务为基础，通过显式地定义、描述、实现和管理业务层次的粗粒度服务(包括业务流程)，提供了业务模型和相关IT实现之间更好的"可追溯性"，减小了它们之间的差距，使得业务的变化更容易传递到IT。

　　因此，可以将SOA的主要优点概括为：IT能够更好更快地提供业务价值(Business Centric)、快速应变能力(Flexibility)、重用(Reusability)。

　　从演变的历程来看，SOA在很多年前就被提出来了，现在SOA的再现和流行是若干因素的结合。一方面是多年的软件工程发展和实践所积累的经验、方法和各种设计/架构模式，包括OO/CBD/MDD/MDA、EAI和中间件;另一方面是互联网的多年发展带来前所未有的分布式系统的交互能力和标准化基础。与此同时，企业越来越重视业务模型本身的组件化，以支持高度灵活的业务战略。但是现有的企业软件架构不够灵活，难以适应日益复杂的企业整合，难以满足随需应变商务的需要，因此与业务对齐、以业务的敏捷应变能力为首要目标、松散耦合、支持重用的SOA架构方法得到青睐。更多的细节请参见"以服务为中心的企业整合"。

　　基于我们同客户打交道的经验，有必要在这里澄清大家经常混淆的几个基本问题。

　　第一，SOA是架构风格，是方法;而不是具体架构具体实现技术(如Web Service)、具体架构元素(如企业服务总线，Enterprise Service Bus，ESB)。

　　经常有人认为只要用了Web Service，就是SOA了。这是不对的，Web Service只是实现服务的一种具体技术表现形式。同样，认为搞SOA，就是买点软件，建个ESB，这也是不对的，ESB只是SOA架构风格中的一部分。首先，ESB是一种从实践中总结出来的架构风格元素，即BUS(总线模式);其次，ESB的主要功能是负责连通性和服务中介(Service Mediation)，解耦服务的请求者和服务的提供者。

　　第二，SOA的首要目标是IT与业务对齐，支持业务的快速变化;其次是IT架构的灵活性和IT资产的重用。

　　业务对敏捷性的需要，是SOA最大的驱动力。一方面是业务在这方面的要求越来越高;另一方面是今天的IT很不灵活，很难适应业务快速变化的需求，不仅仅是因为IT架构不灵活，更重要的是业务模型中的元素和IT系统的元素之间存在很大的差距。这种不对齐，导致业务人员和IT人员之间的沟通不够有效，业务的变化需要花费很大的代价传递到IT系统。很难想像，业务人员对一个Java对象，一个EJB或者一个JSP页面感兴趣，这离业务世界太远了。这种业务和IT的对齐，需要在IT系统中实现更高阶的抽象元素，就是业务模型中的元素(服务、流程、业绩管理)，并且满足业务需要的水平整合(将人、信息、应用和流程端到端地动态整合起来)。这样一个以服务为中心的、端到端整合的环境，首先使得业务变化可以在业务元素这个层面上沟通，更容易、更准确地从业务传递到IT。其次，这种变化被隔离在需要变化的局部，而不扩散到系统的其他部分。这就需要整个IT架构本身是松散耦合的，一个服务的变化(功能、数据、过程、技术环境等)不影响其他服务。最后，我们希望这些反映业务元素的服务，是相对稳定、可以重用的，这对快速适应变化、减少成本是非常重要的。

　　第三，在工程上，SOA的重点是服务建模和基于SOA的设计原则进行架构决策和设计。

　　经常碰到客户提出这样的问题：SOA挺好，为什么好?怎么做才是SOA的方法?跟过去的方法，比如OO/CBD有什么不同?有时候一个J2EE服务器就好了，为什么那么复杂?

　　从建模和设计的角度来说，SOA更多地侧重在业务层次上，也就是通过服务建模将业务组件化为服务模型，它是业务架构的底层，是技术架构的顶层，承上启下，是灵活的业务模型和IT之间的桥梁，保证二者之间的"可追溯性"。从这里往下，是基于已有的方法，比如OO/CBD来进行的。从架构的层次上，SOA更多地侧重于如何将企业范围内多个分布的系统(包括已有系统/遗留系统)连接起来(ESB，Adapter/Connector)，如何将它们的功能、数据转化为服务，如何通过服务中介机制(ESB，Service Registry)保证服务之间以松散耦合的方式交互，如何组装(集成)服务为流程，如何管理服务和流程等。从这往下，对于实现服务的一个具体应用，它的架构、设计和实现是可以基于已有的实践和方法的，比如J2EE或.net。

　　有些时候，由于业务需求比较简单，所有这些东西都在一个J2EE的应用服务器上，有些要素不是那么突出，不过随着系统规模的扩大，要解决的业务问题更复杂、范围更大的时候，SOA的各种架构要素就会变得越来越重要。

　　在下面的小节里就概括地讨论一下SOA的若干个重要方面，包括：面向服务的计算环境，编程模型，架构风格，工程方法，以及相关的技术。

　　2、计算环境的演变和面向服务的计算环境

　　2.1 计算环境

　　计算环境由一组计算机、软件平台和相互联通的网络组成，这个环境能够处理和交换数字信息，允许外界访问其内信息资源(1) 。不同的计算环境有不同的计算风格和编程模型，由一些特定于该计算环境的技术来支撑。如何在一个计算环境中分割和部署计算能力、数据资源，如何让各个部分相互通信和协作，如何在概念上对问题域进行建模，然后映射到该计算环境，都会受到计算环境的影响和制约。因此，了解一下计算环境的历史，会帮助我们理解面向服务的计算环境是如何演变而来的。

　　2.2 计算环境的演变历程

　　计算环境的演变经历了若干个阶段，在早期的主机时代，绝大多数的计算功能和系统的组成部分，都包括在一台机器里。在20世纪80年代，随着PC的繁荣，计算环境发生很大的变化。通过局域网相互连接的计算设备构成客户/服务器计算环境，计算资源和数据资源被适当地分割，客户和服务器通过网络协议、远程调用或消息等方式来相互协作，完成计算。

　　为了满足更高的可伸缩性需求，多层架构出现，计算资源和数据资源的分布多样化，与企业中原来已经存在的计算环境，尤其是主机及其遗留系统之间的集成也变得越来越重要。中间件迅速发展，开始出现分布式对象、组件和接口等概念，用于在计算环境中更好地分割运算逻辑和数据资源。计算环境中不同部分之间的交互，也从原有相对低层的网络协议、远程调用和消息机制的基础上，发展到支持分布式对象、组件和接口之间的交互，这种交互在名字服务(Naming Service)等的支持下，通常是位置透明的。但由于缺乏普遍的标准化支持，很难做到技术透明，系统是紧耦合的。

　　随着互联网(Internet)的发展，开放和标准的网络协议被普遍支持，所有底层计算平台都开始支持这些标准和协议，这导致一个计算环境内部和各个计算环境之间交互的藩篱被打破。数据和功能的表示与交互在XML、WEB服务(Web Service)技术与标准的基础上，保证了通用性和最大的交互能力，这使得计算环境发展到一个全新的阶段--基于标准、开放的互联网技术的计算环境。在这样的计算环境中，各个部分可以采用异构的底层技术，它们使用XML来描述和表示自己的数据和功能，采用开放的网络协议(如HTTP)来握手，在此之上，基于Web服务来互操作和交换数据。在这里，一个很重要的新概念是"服务"(2)，它是一个自包含的功能，使用者通过明确定义的接口(契约)来与一个服务交互，这个接口的描述基于WSDL(Web Service Description Language)这样的开放标准。对象和组件重在表示一个事物本身的组成部分和相互关联(也就是WHAT"THINGS"ARE的问题)，而服务则表示一个事物做什么(也就是WHAT"THINGS"DO的问题)。Web服务是实现服务的技术手段，就如同各种编程语言中的对象是实现对象的技术手段，J2EE中的EJB是实现组件的技术手段一样。这种基于标准、开放的互联网技术，以服务为中心的计算环境，我们称之为"面向服务的计算环境"。

　　2.3 面向服务的计算环境

　　在面向服务的计算环境中，系统可以是高度分布、异构的。它一般包括服务运行时环境(Service Runtime)、服务总线(Service Integration Infrastructure)、服务网关(Service Gateway)、服务注册库(Service Registry)和服务组装引擎(Service Choreography Engine)等，如图1-1所示。

　　服务运行时环境提供服务(和服务组件)的部署、运行和管理能力，支持服务编程模型，保证系统的安全和性能等质量要素;服务总线提供服务中介的能力，使得服务使用者能够以技术透明和位置透明的方式来访问服务;服务注册库支持存储和访问服务的描述信息，是实现服务中介、管理服务的重要基础;而服务组装引擎，则将服务组装为服务流程，完成一个业务过程;服务网关用于在不同服务计算环境的边界进行服务翻译，比如安全。

　　面向服务的计算环境是开放的、标准的，由如图1-2所示的技术标准协议栈所定义和支持。例如，Transport层的HTTP协议，Service Description层的WSDL，Business Process层的WS-CDL等，与Policy相关的WS-Policy。本书后面的章节将讨论所有统称为WS-*的标准和协议。

　　图1-1 SOA计算环境的组成要素

　　

　　图1-2 SOA计算环境的标准协议栈

　　

　　面向服务的计算环境，为IBM所定义的随需应变计算环境奠定了现实基础。随需应变计算环境应具备以下特点，如图1-3所示。

　　图1-3 随需应变的计算环境应该具备的特点

　　

　　(1)整合：将人、过程、应用和数据全面整合起来。

　　(2)虚拟化：将分布、异构的物理资源(服务器、存储设备等)整合起来，呈现为统一的逻辑对象，以安全和可管理的方式供使用。

　　(3)自主计算：如同生物体一样，系统具备一些高级生物系统的能力，包括自我诊断和修复问题，自动配置和调整以适应环境的变化，自动优化资源的使用效率、增强工作负荷的处理的能力，自我保护数据和信息的安全。

　　(4)开放标准：整个环境建立在开放的标准之上，保证系统的交互性。

　　2.4 面向服务计算环境的现状

　　不同的服务计算环境，采用不同的技术和产品，这里主要结合IBM的产品和技术来介绍在J2EE平台上实现的服务计算环境。

　　主机通过增加对互联网技术和标准的支持，来创建主机上的面向服务计算环境。比如IBM的CICS 3.1，提供了SOAP和Web服务的支持，可以将主机上的应用以Web服务的方式提供出来，供消费者使用。

　　多年来，IT界的主要技术提供者，一直携手努力定义和推动Web服务的相关标准，并且在主要的几个计算平台上实现了高度兼容，包括.NET，J2EE和开源平台(如LAMPLinux，Apache，MySQL，PHP/Perl/Python)。

　　IBM以J2EE为基础，提供了全面的、强大的服务计算环境，如图1-4所示。

　　图1-4 IBM提供的服务计算环境

　　

　　在这个计算环境中，它是服务的世界。其中，Access Services提供访问已有应用或遗留系统的能力，将已有系统中的功能和信息转化为服务，IBM提供了访问不同系统的适配器和相应的框架来帮助转化。Business App Services指那些通过新的计算平台J2EE(如IBM的WebSphere Application Server)来实现的新应用，它们所实现的功能和信息也都转化为服务提供出来。Partner Service指那些来自合作伙伴的服务，WebSphere Partner Gateway提供企业边界处不同安全等差异的转换。Information Service是那些跟信息(而不是活动)有关系的服务，比如将多个系统中异构的数据，聚合、转换为业务需要的统一整齐的业务数据对象来访问。Process Service是指把多个服务聚合成为一个服务流程对应业务过程的服务，这种复合服务通常是长时间运行的过程。Interaction Service是把人的活动，通过人机交互以服务的方式出现在整个业务过程中，作为Process Service中的一部分。

　　在面向服务计算环境中，企业服务总线处于非常重要的位置，它提供服务的中介，解耦服务请求者和服务提供者，是服务计算环境中的核心。 ESB是过去消息中间件的发展，采用了"总线"这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上的动态互联互通。

　　ESB的基本特征和能力包括：描述服务的元数据和服务注册管理;在服务请求者和提供者之间传递数据及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式，异步模式等;发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。

　　ESB所提供的基于标准的连接服务，将应用中实现的功能或者数据资源，转化为服务请求者能以标准的方式来访问的服务;当请求者来请求一个服务时，ESB中这种中介转化过程可能简单到什么也没有，也可能要很复杂的中介服务支持，包括动态地查找、选择一个服务，消息的传递、路由和转换、协议的转换。这种中介过程，是ESB借助于服务注册管理及问题域相关的知识(如业务方面的一些规则等)自动进行的，不需要服务请求者和提供者介入，从而实现了解耦服务请求者和提供者的技术基础。这使得服务请求者不需要关心服务提供者的位置和具体实现技术，双方在保持接口不变的情况下，各自可以独立地演变。

　　所以，ESB采用总线结构模式简化了应用之间的集成拓扑，通过源自实践的模式，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互，从而在不同层次上使得SOA解决方案是一个松散耦合、灵活的架构。

　　需要注意的是，ESB是一种架构模式，不能简单地等同于特定的技术或产品，但实现ESB确实需要各种产品在运行时和工具方面的支持。IBM有很好的产品支持，运行时支持包括WebSphere ESB和WebSphere Message Broker;工具支持有WebSphere Integration Developer，支持用户以图形界面的方式来完成相关的开发任务，如发布服务、使用各种模式、转换消息和定义路由等。

　　2.5 面向服务的编程模型：服务组件架构(SCA)和服务数据对象(SDO)

　　为了促进面向服务应用的开发，IT公司联合起来，在2005年11月发布了服务组件架构(Service Component Architecture)和服务数据对象(Service Data Object)规范，这些公司包括IBM，BEA，Oracle，SAP等。

　　SCA的目标是大大地简化服务开发，直接采用Web服务和XML开发服务，使得程序员工作在底层技术上，需要应付各种异构环境下的具体实现细节。其中，SCA定义和规范了技术中立和实现透明的服务组件、服务及服务调用和组装;而SDO定义和规范了服务世界里的数据，这些数据对象拥有清晰定义的信息模型，独立于数据源和具体数据访问技术，使得服务访问数据和在服务之间交换数据更方便、有效。

　　很多公司已经在J2EE平台上支持了SCA/SDO，还提供了C++的版本。IBM WebSphere Process Server 6实现了SCA/SDO规范，提供了最新的SOA编程模型的支持，已经在很多实践中被广泛使用。