SOA基本架构模式详解概要.doc

五种SOA基本架构模式 目前，面向服务的架构（SOA）已成为连接复杂服务系统的主要解决方案。虽然SOA的理论很容易理解，但要部署一个设计良好、真正实用的SOA系统却非常困难。本文试图通过解析SOA的模式，提供与架构相关的技术指导，进而对以上问题提供详尽的的解答。 在本文中，一共提到了五种模式。表1列出了这五种模式以及各自相关的问题。 模式名称 相关问题 服务托管 如何使服务能够适应不同的配置，避免设置监听器、组件连接等重复性常规工作。 主动式服务 如何提高服务的独立性以及如何处理暂时性的问题？ 事务处理服务 如何可靠地处理消息？ 工作流化 如何提高服务对不断变化的业务流程的适应性？ 边缘组件 如何将服务的业务功能从无关的交叉问题（比如安全、登录等）中分离出来。 表1：模式列表 其中服务托管（ServiceHost）与主动式服务（Active Service）是两种最常见的模式——即使服务的使用范围很小，通常也会使用这两种模式。这两种模式的主要内容都与解决服务相关问题有关，即与具体的服务部署有关（见图1）。 模式一：服务托管 服务托管是我们要讨论的第一个模式。它是最基本的模式，或者至少是最基本的模式之一。服务托管模式主要负责运行着服务实例的环境，以及与此相关的路由任务。 问题 随便选一个服务，任何服务都可以，别告诉我具体是哪个：）。你可以找到一些处理传入的消息或请求的监听代码；你可以找到一些连接组件的代码，还有一些初始化并激活这个服务的代码；或许你还能找到一些能适当地配置服务的代码。有没有觉得我很厉害？实际上，你可以在服务里找到上面的所有代码，至少是大部分。 有许多工作都是重复性的、常见的。我们可以好好利用这一点。 如何使服务能够适应不同的配置，避免设置监听器、组件连接等重复性常规工作？ 第一个办法（实际上也不是什么办法），就是为每一个服务重写所有的连接代码。很显然，这不是个好方法，因为重写的次数越多，就越可能产生一些缺陷。并且，对于维护来说，许多重复的代码产生的问题更为严重。在维护的时候，你不仅要确保每一个服务中的缺陷都已经得到修正，还要保证没有任何疏漏、所有的服务都已经同步更新。 另一个相对较合理的办法，就是创建一个共同任务库，所有的服务都通过API与库相连接。这样确实会有所帮助，但是为了充分利用库的功能，你仍然需要编写连接代码。 还有一个办法是利用继承创建一个超类，用超类实现共同的功能，然后让各个服务继承这个类。然而利用继承也有问题，因为服务的功能通常无法通过一个单独的类获得很好的实现。此外，不同的服务所处理的业务也完全不同——否则它们就是一样的服务了。因此，也无法让把这些服务归于同一类结构。 继承几乎已经可以解决我们面临的问题——因为我们只需要写一次代码，只有不同的服务才需要定制。如果想不用继承得到相同的结果，我们就得使用框架。 解决方案 创建一个通用的服务托管组件，把它当作服务的容器或者框架。容器是可以配置的，并执行服务连接、安装等工作（见图2）。 服务托管就像是一个肩负着许多职责的迷你框架。它的第一个职责就是正确地示例服务所包含的组件或类。服务托管还负责读取配置信息，比如，它可以读取服务消费者用来连接服务的端口。其它职责包括创建服务环境，比如在终端创建监听器。最后，服务托管可以负责连接组件——终端监听器上的协议绑定或者创建一个与数据库的连接。所有这些职责的共同特征是它们都与服务的实例化和初始化有关，并且正如我们在问题部分所描述的一样，你很可能会在多个服务中遇到同样的情况。前面已经提到，服务托管是一个框架，与第二种方法中描述的库的概念有所不同。库是一个实用类或方法集，你可以调用它们来获取特定的功能。而框架则包含了一些功能或流程，并通过调用代码来扩展流程或将其转变为具体的流程。这就是“控制反转（Inversion of Control）”原理。这种原理已经在面向对象的框架中获得广泛的应用，比如Spring或Spring.NET、Picocontainers等。 服务托管模式与其它方法相比有许多优势。其中一个优势前面已经提到——即服务托管是一种框架，它可以调用代码来改善性能，而无需你亲自进行编排。另一个优势是它能更好地实现开放/封闭原则（OCP）。OCP原则认为类应该是可以扩展的，但是不能修改；而框架的概念正是这个原则的具体表现。 一个服务托管可以托管多个服务——虽然这种情况可能并不常见。我们曾经构建了一个系统，使用的方案规模小到一台计算机即可应付。这真的很方便。如果换另一种方案，那么服务可能就要扩展到多台计算机上，这样你就得应用多个服务托管实例，各个主机托管服务的一部分，而不是整个服务。 服务托管模式已得到了技术供应商的广泛应用，这一点我们可以在下面的技术相关部分看到。 技术相关 这一部分我们将简