了解如何将SOA定义为一种体系结构风格，以促进将与业务保持一致的企业服务作为设计和构建解决方案的基本单元。了解为什么使服务与业务模型保持一致非常重要，并探索一种可用于实现该体系结构风格的模式语言。

　　引言

　　存在大量关于SOA的讨论，但是很少就这个流行的三字母缩写词的实际含义达成一致。面对很多竞争的定义，很难揭示其真正的本质。SearchWebServices.com宣布了一个关于其最佳定义的竞赛，并收到了大量的建议。很难选择单个“最佳”定义，因为SOA对不同的人具有不同的含义。

　　尽管所有这些观点都绝对是正确的，但是理解SOA的关键是体系结构(Architecture)的字母A。难题在于，还不存在一个得到普遍认可的软件体系结构定义；软件工程协会(Software Engineering Institute)维护的列表有50多种不同的软件体系结构定义。

　　对于本文，我使用IEEE标准1471-2000(IEEE Recommended Practice for Architectural Description of Software-Intensive Systems)提供的定义：

　　“体系结构是一个系统的基本组织形式，体现为其组件、组件之间的相互关系和与环境的关系以及指导其设计和发展的原理。”

　　特定体系结构的组件集和组件之间的关系被定义为一种体系结构风格：“组件和连接器类型的词汇表以及关于如何组合它们的约束集。”

　　Convergent architecture: Building model-driven J2EE systems with UML中提供的更全面体系结构风格定义认为“体系结构风格是通过共同的原理和属性相关的一系列体系结构”。IT体系结构风格既是IT体系结构的一种整体方法，又是一种特定方法。其整体性在于，它涵盖整个软件生命周期，包括项目和工具设计方面。其特定性在于，它合并和集成了许多在传统方法中作为单独实体来处理的结构化、过程化和描述性方面。“体系结构风格提供一个有用的合理替代选择集——并非所有替代选择——并协调它们以便良好地协同工作。”

　　SOA可定义为这样一种体系结构风格，它促进了将与业务保持一致的企业服务作为设计、构建和组合企业业务解决方案的基本单元的思想。多种模式、定义设计、实现和SOA部署完善了此风格。

　　为什么选择SOA？

　　业务和技术负责人等都对SOA感兴趣，并将其视为用于实现以下目的的万能解决方案：

　　·实现业务与IT的更好一致性
　　·创建更灵活和反应更灵敏的IT基础设施
　　·简化集成实现

　　人们坚信，SOA能够以双赢的方式，允许您将业务领域与信息技术(IT)领域保持一致。SOA就像是在两者之间创建共生和协作关系的桥梁，这种关系比以往所遇到过的任何关系都更为强大和有价值。而且，SOA还可通过业务和IT实现更好的一致性来获得理想的业务成果。

　　为了理解当前的SOA推动力，让我们首先更密切地查看一下当今的典型企业IT体系结构及其缺点。

　　以应用程序为中心的体系结构

　　当今的企业IT体系结构通常被视为应用程序的集合。软件系统的设计、开发、增强和维护都以应用程序为中心。此方法导致在企业体系结构中创建隔离的竖井，从而导致代价很高和不灵活的IT系统。每个应用程序都基于单一目的（例如贷款发放、索赔管理，等等），具有自己的数据存储区并针对一组单一用户。结果，它仅实现了企业功能的子集，仅使用和产生企业数据的子集，通常不关心企业中的其他处理。这些竖井将自身表示为数据岛(island of data)和自动化岛(island of automation)。

　　数据岛

　　每个数据岛分别具有自己的企业对象含义或定义。例如，在一个应用程序中，“价格”可能定义净价，而在另一个应用程序中，同一术语可能还包括营业税。即使诸如“地址”之类的对象在两个应用程序中具有相同的含义，其中一个应用程序也可能将其定义为一组地址行，而另一个应用程序则将其视为街道地址、城市、州、邮政编码和国家/地区。这两种情况都在应用程序之间造成了语义不一致。

　　它们分别都有与另一个岛重叠的内容。例如，处理健康和牙科索赔管理的应用程序还存储被保险人的人口统计信息。与此同时，客户关系管理（Customer Relationship Management，CRM）应用程序同时包含被保险人的地址和人口统计信息。这种重复导致了完整性问题。

　　没有哪个应用程序能够提供企业数据的完整视图。例如，抵押管理应用程序未包含关于借款人从其他部门贷款的信息。创建企业数据的统一视图要求集成来自多个来源的信息。

　　自动化岛

　　每个自动化岛集中于企业中有限的一组活动。例如，健康索赔管理应用程序仅负责健康索赔的处理，而不考虑这些活动在总体企业业务流程中的作用和地位。这要求用户“切换应用程序 (application hop)”以执行他们的工作，从而影响他们的工作效率。

　　不同岛中包含的业务流程之间存在重复。例如，由于合并和收购，保险公司可能有多个索赔处理系统。这要求在多个应用在程序之间同步变更，从而确保流程和支持这些流程的业务规则的一致性。

　　数据岛和自动化岛的影响在各个应用程序级别是不可见的。然而，它们在企业级别导致重大问题，最明显的是：

　　·信息保真度：数据岛之间的业务数据冗余导致企业数据的不准确表示形式——甚至是在执行定期同步的时候。这些表示形式本身通常是矛盾的，很难协调。由于各个应用程序独立发展，因此该问题的复杂性与日俱增。

　　·业务流程碎片：各个应用程序提供企业功能的有限部分。实现业务流程需要链接包含部分流程实现的应用程序。

　　解决这些问题已使得企业应用程序集成（Enterprise Application Integration，EAI）和企业信息集成（Enterprise Information Integration，EII）成为许多企业项目的焦点。这些活动目前（并将继续如此）消耗了企业IT预算的很大一部分。

　　这些集成计划代价昂贵、复杂和劳动力密集的一个主要原因在于，它们尝试将从未打算协同工作的不同应用程序中的数据和处理集合在一起。花在这个任务上的大部分时间都用于同时对现有应用程序中的数据和流程进行彼此参照以实现合理化。

　　从应用程序到流程和服务

　　Grady Booch在2004年接受InfoWorld杂志采访时表示，“诸如良好的抽象、良好的关注事项分离等工程基本因素从来不会从风格中消失……存在再次提高抽象级别的真正机会”。

　　SOA引入了两种高级抽象：企业业务服务和业务流程。企业业务服务表示现有的IT功能（与企业的业务功能保持一致）。对业务服务进行编排的业务流程定义业务的总体功能。

　　SOA的宗旨是消除当前存在的应用程序（具有刚才描述的所有缺点），并将软件系统创建为一组由业务流程进行协调的交互服务。每个服务实现总体企业上下文中定义的特定业务目标或功能，业务流程表示必须实现的业务解决方案。

　　基于与Jean-Jacques Dubray的通信联系，表1总结了以应用程序为中心的方法和SOA方法之间的关键区别。

　　表1. 以应用程序为中心的方法与SOA实现的比较

　　SOA和分解

　　企业业务服务通常被定义为企业IT系统的分解结果。分解(Decomposition)是由20世纪50年代晚期的经典系统理论形式化了的一种技术。系统理论认为，某个系统越复杂，其包含的内容就越不可知，因此要自动化它就越困难。该理论建议将复杂系统分解为较小、更加可管理、更容易控制的系统，然后将整体系统视为其各个部分的组合。同样的原理也适用于复杂的软件开发计划。

　　软件分解的发展

　　在20世纪60年代初引入的最初软件分解方法是将大型机应用程序划分为单独的作业，每个作业分别由一个单独的程序实现。后来，随着人们加深对程序内部原理的认识，每个程序本身又按照其功能被划分为模块或子程序。

　　Simula和Smalltalk在20世纪70年代引入的面向对象（Object-Oriented，OO）范例通过引入对象 或代码模块加强了分解方法的采用，其中每个对象实现某个实际事物的模型。其基本思想是在软件中表示“问题域的事物”，如客户、订单或交易。但是，对象所提供的抽象被证明太细粒度化，并与技术概念交织在一起来表示业务级别的含义。

　　由于种种原因，许多面向对象的开发人员最终将大多数时间花在处理诸如集合、图形Widget等技术构造上。在大多数情况下，问题域的对象消失在乱七八糟的模块中，这些模块不再表示问题域专家可识别的任何事物。OO的另一个问题在于，尽管在设计和实现期间，对象在分解方法中非常重要，但它们在部署或运行时不可见，从而并不直接支持部署或运行时分解。

　　在对更好范例的不懈求索中，20世纪90年代末引入了一种不同的分解方法。组件。其基本思想是通过提高抽象级别、增加粒度和创建与业务构件的更紧密联系来解决OO的问题。

　　软件组件的引入允许创建灵活、构造更好和更加可管理的软件应用程序。然而，它并没有解决主要的企业IT问题：其以应用程序为中心的性质。对象和组件都为各个应用程序提供了更好的设计和开发方法。SOA将分解方法推向一个更高的层次，如图1所示。与尝试分解各个应用程序不同，它分解整个企业IT功能。

　　图1. 分解方法的发展
 
　　SOA的元素

　　通过为其主要元素（业务服务和业务流程）提供业务含义，SOA体系结构风格促进了业务和技术的一致性。事实上，服务和流程都可追溯到企业业务体系结构。

　　企业SOA定义一组与业务一致的IT服务（对整个企业中跨多个业务部门甚至企业外部的参与者可用），这组服务集合起来满足组织的业务流程和目标。可以将这些服务编排到企业业务解决方案中，并通过标准协议来调用。图2显示了企业SOA的主要元素。

　　图2. 企业SOA概念
 
　　组织

　　拥有所有SOA相关的构件（模型、服务、流程、资源）并控制它们的创建、使用、访问和维护。这些构件的作用是支持组织及其业务目标。

　　业务模型

　　满足企业经营、战术和战略业务目标所需要的业务资源和流程的主要表示形式。

　　业务模型对于服务与业务目标和要求的成功一致性非常关键，从而对总体SOA实现的成功至关重要。

　　语义数据模型

　　定义给定企业的标准业务数据对象（例如，客户、协议，等等）。这些对象通过定义公共概念及其内容（它们描述企业的功能），从而实际创建企业数据的实体。

　　使用该数据模型来定义业务服务接口就导致创建了可互操作的语义服务接口定义——语义SOA。

　　服务

　　实现特定的企业业务功能并访问其数据和资源。定义良好并与业务保持一致的服务是灵活、可扩展的企业SOA实现的关键要素。

　　服务的结构允许独立地开发和部署它们。正确地定义服务并使其与业务和语义模型保持一致可以产生即插即用的实现，从而允许有效地将它们组合到不同的企业范围的业务流程和解决方案中。

　　业务流程

　　编排业务服务的执行以实现业务模型中指定的企业功能（例如，订单处理或索赔处理）。

　　业务流程通常以关键绩效指标（Key performance indicator，KPI）的形式与经营目标和业务目标关联，例如保险索赔处理或工程开发处理。作为流程实现的一部分来收集的KPI通常用于评估企业功能的有效性。

　　信息

　　表示组织的数据资源。数据以各种不同的格式驻留在各种各样的不同存储区、应用程序中。不同级别的数据由不同级别的SOA构造所使用。语义数据模型定义用于业务流程和服务的数据。SOA定义了用于将数据从其本来的操作格式转换为业务所需的语义数据的机制。

　　文档

　　表示法律实体，用于定义企业及其合作伙伴的义务（例如，财务文档、保险单和索赔，以及政府规章）。文档是现代企业至关重要的一部分，必须连同其他企业信息一起作为一级优先事项包括在SOA实现中。

　　什么使得SOA与众不同？

　　人们进行了若干尝试，以图将SOA表示为一种新形式的分布式系统体系结构，或表示为面向对象的扩展，或表示为下一代EAI。让我们进一步了解这些类比。

　　SOA与分布式系统

　　W3C Architecture任务组将SOA定义为某种形式的分布式系统体系结构，通常以属性为特征，如表2所示。

　　表2. 分布式系统体系结构属性

　　W3C开发的SOA模型（如图3所示）可以按照调用消息、实现、拥有组织和描述服务的元数据来定义。

　　图3. W3C的SOA模型
 
　　·面向消息的模型按照消息的内容（标题和正文）、传输方式和发起及执行代理来定义消息。
　　·资源模型按照URI、表示形式和拥有组织来定义资源或实现。
　　·策略模型按照策略的主体（资源和操作）和组织来定义策略。策略是对允许的操作或状态的约束，例如某个安全策略。

　　尽管SOA是面向消息和网络的分布式系统体系结构，但它不仅限于此。将SOA与分布式系统等同起来，这仅强调了服务通信的技术和实现方面，而忽略了它的关键价值主张：业务-IT一致性。