SOA和面向对象

　　有些专业人员将SOA视为OO的直接发展，并将服务视为对象或组件。这与事实差之甚远。它们之间的相似性并没有超出用于定义的系统分解和用于实现的封装。

　　诸如继承和多态性等其他对象特性并不适用于SOA。两者之间的真正区别在于用法和编程模型（类似于基于实例的协作和基于服务的协作之间的区别。

　　·在OO中，相同类型的多个对象实例（可能同时存在）基于表示特定执行上下文的内部状态来进行区分。因此，对象的生命周期由其使用者通过创建对象来显式控制。

　　每个对象都公开多个方法，这些方法与某个特定的实例（执行上下文）绑定，并允许操作给定实例上的变量。

　　·在SOA中，服务支持的不是特定使用者的执行上下文，而是支持与该特定服务关联的企业资源状态。典型的服务调用是无状态的；此规则的最明显例外是对话式组合服务，此类服务通常具有一个执行上下文，并支持某个特定的对话。

　　因此，服务生命周期并不与任何特定使用者的生命周期关联——无论某个特定的使用者是否调用它，它都始终存在。由此而来的编程模型是服务的直接调用，而无需显式创建服务。

　　这个区别对于对象和服务的接口定义具有深远的影响。在OO中，接口上定义的多个方法从物理意义上讲始终属于该对象的同一实例，因为它们与同一执行上下文绑定。相反，由于服务没有执行上下文，因此服务接口中的方法关联纯粹是逻辑性的。

　　服务（也包括服务接口）实际上表示一个命名空间，此命名空间提供服务方法的逻辑分组，否则这些服务方法就是独立的实体，分别具有自己的服务质量要求、安全性、版本控制策略、端点地址等。让我们以一种编程语言作类比：服务的每个方法类似于FORTRAN子程序/函数，可彼此独立存在和执行。

　　SOA与EAI

　　传统的EAI实现通常基于EAI供应商推出的专有解决方案，从而创建与该供应商平台的“锁定”关系。许多专业人员将SOA视为下一代EAI技术。例如，Gartner Group提出了术语“面向服务的集成”（Service-Oriented Integration，SOI），EbizQ后来在其应用程序集成路线图中包括了SOA。

　　随着作为提供传输解决方案的技术的Web服务的最新发展，它们通常被视为基于标准的集成解决方案。这使得它们成为EAI实现的极具吸引力（并且独立于供应商）的替代选择。企业服务总线（Enterprise Service Bus，ESB）产品的引入使得基于Web服务、基于标准的集成解决方案更加流行。

　　尽管EAI和SOA的目标通常是相似的——使用现有的应用程序组合来支持企业业务流程——但它们以根本不同的方法来实现该目标。EAI集中于通过集成服务来公开应用程序的功能，实际上是将现有的应用程序组合作为一个企业业务模型来公开。相反，SOA集中于隐藏现有的应用程序，并改为公开一组与应用程序无关的业务服务，从而将企业业务模型投影到现有的应用程序组合上。

　　服务

　　SOA引入的基本抽象之一是服务。SOA实现通常包含三种类型的服务：

　　·业务服务（表示与业务一致的IT构件）
　　·集成服务（带有通过SOA技术来完成的集成实现，通常是Web服务）
　　·基础设施服务（表示针对基础设施支持的公共IT构件）

　　请注意，本文讨论的“服务”指的是业务服务。

　　在最简单的情况下，服务可定义为独立地开发、部署、管理和维护的自包含软件实现，旨在支持与企业整体相关的特定功能，并且在设计上是“可集成的”。服务功能由服务接口定义，接口可由多种实现来支持。这意味着服务不是某种编程构造或一组API，而是用于企业解决方案实现的体系结构构件（设计、实现和维护单元）。

　　服务实现关注事项

　　服务实现关注事项跨越从服务设计人员关注事项（如业务一致性和现有IT功能的重用）到公开给服务使用者的关注事项（服务契约、服务接口和访问策略）的范围。图4大致描绘了这些元素以及它们之间的关系。

　　图4. 服务实现关注事项

　　服务的业务功能

　　由企业业务模型定义，该模型又基于企业的业务目标。

　　服务契约

　　定义服务的业务功能、接口和一个或多个端点地址。

　　服务接口

　　以技术术语描述提供给潜在使用者的服务功能。接口被定义为一个服务名称和该服务支持的一组操作（方法）。每个操作的描述包括该操作调用（请求）所需的参数集定义，并在适用的情况下包括操作返回的结果（应答）。该描述还介绍操作的功能和前置及后置条件。

　　服务方法

　　可通过端点地址来访问，通常被定义为某个地址的网络位置。每个端点地址由一组访问策略控制。这些策略定义用于数据传输的通信协议、实际服务调用和服务质量（Quality of Service，QOS）（例如，某个给定端点地址所提供或要求的安全性和保密性）。

　　粒度和松散耦合

　　表示重要的服务设计特性。

　　服务实现

　　争取最大限度地重用现有的企业IT功能。

　　服务编排

　　表示将服务组合为更大的服务和在服务基础上构建企业解决方案的普遍机制。
以下各部分将进一步研究主要的服务实现关注事项。

　　业务一致性

　　SOA的主要承诺之一是业务-IT一致性。仅当服务与企业的业务模型保持一致时，才能实现此承诺。这意味着企业业务模型是成功的SOA实现的先决条件。必须准备一个高级模型来设定服务的方向、分区和分类。模型的细节可以随时间而与服务的开发并行发展变化。

　　根据聚合体系结构的规定，这种定义企业业务服务的方法可以实现更好的业务、组织和应用程序（服务）体系结构一致性。然后将软件实现（服务、流程）追溯到业务体系结构就更加容易了，并使得软件分析人员更容易理解软件应用程序，同时还可以简化业务功能变更的实现。

　　服务粒度

　　传统的分布式系统技术，如CORBA和DCOM，都提供了本地和远程透明性。无论目标位置如何，它们都提供相同的编程模型。这样的一致性不仅简化了编程模型，而且还可以使系统设计人员和开发人员不必花大量时间去考虑和定义边界。这种开发简单性与执行速度之间的权衡，是许多使用分布式对象构建的应用程序性能低下的主要幕后原因之一。这决不是分布式对象技术的问题，而是跨系统边界的细粒度对象交互的一个症状。

　　在SOA中，所有服务调用都是远程的。 这使得服务内（在服务内部）和服务间（跨服务边界）调用的不同特征变得非常明显。 这个区别强调了服务调用的开销非常大。结果，粒度就变成了服务设计的重要特征之一。

　　由于服务调用涉及到网络，因此将它们设计为粗粒度的。服务方法的执行所交付的价值必须能够弥补网络请求延迟的代价。因此，公开的服务接口必须是粗粒度的。与公开许多提供有限功能的接口不同，服务应该公开少量接口，这些接口允许各个请求执行完整业务功能。

　　恰当的服务粒度不仅允许创建性能更好的系统，而且还可以减少耦合。粗粒度的服务往往是自包含的，从而对其他服务的依赖性更少。

　　耦合

　　如果您希望使用服务来构建、维护和修改灵活的企业解决方案，以及支持整个企业中的联合开发方法，则那些服务的松散耦合是先决条件。下面的列表包括了一些耦合的后果。

　　·更紧密的耦合往往随时间推移而增加开销：

　　同步多个组织的变更
　　调整和重新部署已更新的组件而不影响其他组件
　　难于做出更改，并且开销非常高或无法实现
　　难于单独管理解决方案的不同部分
　　难以移动、难以扩展、难以分发、难以替换
　　更多的耦合意味着更高的测试开销

　　·更松散的耦合需要更大的前期投资：

　　更多的设计工作
　　更多的实现工作

　　SOA实现中的耦合的最重要方面包括：

　　功能耦合

　　尽管基于接口的设计并不新鲜，但是SOA则更进一步，它使（服务）接口基于企业范围的语义。早期的SOA采用者低估了使用企业范围的语义来实现服务互操作性的重要性。Web服务社区希望，定义良好的SOAP消息内容和结构与有效负载的XML表示形式以及传输的标准化相结合，将确保Web服务通信的互操作性。在现实中，这仅提供了技术上的互操作性，并确保来自一个系统的SOA消息可由另一个系统接收和成功处理。然而，它并没有以任何方式帮助实现语义互操作性——两个系统相互“理解”的能力。

　　此类区别的例子随处可见。例如，仅仅是因为许多语言都使用罗马字母，并不意味着使用这些语言（它们使用相同的字母）的人就能够相互了解。纯粹的字母知识不足以理解语言。

　　使用企业语义数据模型来定义服务接口能够创建可互操作的语义接口定义。这些语义SOA显著增强了服务之间的互操作性：它们全都在接口级别使用同一模型。

　　语义消息的引入要求服务实现支持两个完全不同但同等重要的数据模型。

　　·内部数据模型：由服务实现所使用。该模型与服务的内部实现相关，从而特定于基础的服务和组件。该内部模型不对服务使用者公开。
　　·外部数据模型：用于服务间交换，并且是企业语义数据模型。

　　每个服务负责企业和内部数据模型之间的语义代理和转换。

　　时间耦合

　　服务（尤其是Web服务发布）往往集中于同步服务调用。当前实现的缺点有时被视为SOA本身的缺点。因此，有若干出版物主张将事件驱动的体系结构（Events-Driven Architecture，EDA）和SOA-2作为修复SOA的方法。依我看，需要修复的不是SOA，而是其当前的用法。

　　使用同步通信来实现服务调用创建了服务使用者和提供者之间的时间耦合。

　　·服务提供者必须正常运行，服务使用者才能访问它。
　　·由于同步调用是阻塞调用，其中一个服务执行或请求/响应传递中的性能变化都会对服务使用者的执行产生重要影响。

　　使用单独的应答调用来实现异步服务调用允许使用者在提供者等待响应时继续执行。这导致了时间上分离的系统。在这种情况下，暂时的服务提供者中断和网络延迟只具有很小的影响。只要服务提供者返回响应，总体系统就能正常工作。

　　服务代表总体系统中的粗粒度独立实体，它们使得服务的可伸缩性和高可用性成为极其重要的问题。异步调用可以提供更好的可伸缩性和可用性特征，更适合用于SOA实现。

　　事务耦合

　　事务性，尤其是原子性、一致性、隔离性和持久性(ACID)，是解决分布式计算中可靠性问题的流行方法的代表。金融应用程序采用它来进行资金转帐，电子商务系统使用它开进行支付处理，制造应用程序使用它来进行库存控制，电信记帐系统使用它来进行呼叫计费，等等。

　　ACID事务通常是使用事务监视器（例如，Tuxedo、CICS、Encina）或组件平台（例如，J2EE应用程序服务器或MTS）来实现的。对ACID事务的支持需要整个事务环境的耦合，从而限制了互操作性和灵活性。

　　ACID事务实现的另一个要求是事务持续过程期间的资源锁定，这需要有保证的较短服务执行时间。较长的事务时间通常导致总体事务资源吞吐量的恶化。

　　ACID事务虽然非常适合于对象和组件，但是对服务来说则通常太受限制了。SOA通过传统的两阶段提交协议来支持业务事务。

　　业务流程

　　业务服务本身很少构成完整的业务解决方案，它们通常充当构件。完整解决方案的创建通常是通过组合或编排各个参与服务来实现的。此类组合通常使用业务流程来完成。

　　业务流程和以流程为中心的计算并不新鲜。从办公自动化和工作流系统开始，它们已在IT中成功使用了20多年。希望提高效力和竞争力的公司必须作出转变，使流程成为基于计算机的自动化和支持的基本单元。它们必须将重点从记录系统转向流程系统。“流程处理”需要取代“数据处理”。

　　BPM的核心是编排概念，其中某个流程引擎在操作输入/输出数据时对若干个手动和自动流程步骤进行编排。SOA使得BPM的实现变得更切实可行。SOA中的业务流程促进了业务流程从纯粹的自动化到受到管理的灵活性 的下一个发展阶段。

　　SOA的目标是将组织的计算资产公开为可重用的业务服务，并实现基本的业务功能，这些功能更容易通过业务流程来使用（重用）和集成。这种使用现有服务来快速组装和重新组装解决方案的能力是SOA的主要优势之一。如图5所示，业务服务和业务流程之间的关系为实现真正灵活的企业铺平了道路。

　　·业务服务支持稳定的业务构件，并整合了其接口很少更改的处理和规则。（然而，服务实现可以并且通常随时间而更改。）
　　·业务流程支持相当易变的业务过程和规则，这些过程和规则可能每隔几个月甚至每隔几周就会更改。
　　·业务流程和业务服务之间的交互基于企业语义，从而最小化了服务更改对业务流程的影响，并简化了从业务服务构建流程的过程。

　　图5. SOA中的服务和流程之间的关系
 
　　这种职责分离允许业务分析人员和IT架构师重用IT功能，这些IT功能通过编排服务的业务流程封装在业务服务中。这简化了新流程的创建和现有流程的优化。更重要的是，这些流程一经设计，即可快速对其进行修改以响应市场条件。所有这一切都转换为业务灵活性和竞争力的提高，而不会显著增加进行频繁流程更改所导致的边际成本。

　　SOA和模式

　　通过模式来解释和实现某种体系结构风格是已得到证实的方法之一。

　　“模式和模式语言是描述最佳实践、经证实的设计和获取过去经验的方法，以便其他人能够学习这些经验。模式是一种已得到证实的方法，用于快速理解设计指导和可在其中应用这些指导的各种上下文”。——John Evdemon

　　最近有许多关于SOA模式和模式语言的出版物。然而，每种出版物仅集中于SOA实现的某个特定方面，包括：

　　·服务访问和基础设施
　　·服务组合
　　·服务定义和实现
　　·服务版本控制
　　·服务安全性
　　·企业数据访问

　　真正的SOA模式语言应该定义全面的服务设计、创建、利用和执行——完整的SOA生命周期——方法。图6显示了此类语言的一个示例。

　　图6. SOA的模式语言
 
　　该模式语言包括三个主要方面（有些模式可能属于多个方面）：

　　服务设计

　　这一组模式包括一些最重要的服务设计活动。面向服务的分解模式提供起点，描述如何基于手边的问题来定义服务，包括企业业务模型和所需的长期体系结构质量。

　　服务契约模式定义正式的服务定义的创建，并允许系统设计人员为他们的实现选择最适当的服务，允许架构师和开发人员正确地调用那些服务。

　　服务存储库模式定义用于组织企业中的服务相关构件的解决方案，从而简化服务定义、创建和使用中涉及到的涉众之间的协作。

　　服务版本控制模式提供指导方针，用于处理服务契约和实现中不可避免的更改，从而使您可以减轻这些更改对服务使用者的影响。

　　服务实现

　　这些模式包括一些与服务实现活动相关的问题。服务实现层显示了如何利用现有企业应用程序组合来实现与企业业务模型保持一致的服务服务实现组件模式通过定义典型服务实现中涉及的组件以及它们的关系，从而对前述模型形成补充。

　　组合服务模式探索了一种方法，用于对多个现有服务的功能进行组合以支持服务使用者所需的功能。

　　服务基础设施

　　这组模式涵盖服务运行时基础设施的一些重要问题。服务注册中心模式集中于晚期绑定的实现，以便通过集中的注册中心实现服务调用，从而允许在单个企业范围的点控制服务的部署和运行时功能。

　　服务安全性是一种专门的模式语言，它定义一组模式并控制服务安全性的设计和实现。

　　服务日志记录和服务异常管理模式定义用于在高度分布式环境中进行集中日志记录和异常管理的方法。

　　服务监视和管理模式集中于对服务执行进行监视和管理的方法。最后，企业服务总线模式提供对服务通信虚拟化的认识，从而简化前面提到的基础设施模式的实现。

　　总结

　　在本文中，您了解了SOA体系结构风格的构成。您探索了此风格的主要元素以及它们的交互。您研究了此风格背后的基本原理，以及它与其他用于构建企业体系结构的方法的区别。我们还简单谈到了一种模式语言，您可以使用它来理解和简化此风格的实现。

　　敬请关注即将推出的文章，它们将更详细地讨论模式。

　　关于作者

　　Boris Lublinsky在软件工程和技术体系结构方面拥有超过25年的经验。过去若干年来，他一直致力于企业体系结构、SOA和流程管理。Lublinsky博士是一位技术演讲者和作家，在不同的杂志上发表了40多项技术著作，这些杂志包括Avtomatika i telemechanica、IEEE Transactions on Automatic Control、Distributed Computing、Nuclear Instruments and Methods、Java Developer’s Journal、XML Journal、Web Services Journal、JavaPro Journal、Enterprise Architect Journal和EAI Journal。Lublinsky博士目前在一家大型保险公司工作，他在那里负责开发和维护SOA战略和框架。您可以通过blublinsky@hotmail.com与Boris 联系。