围绕SOA的宣传热潮似乎是一浪高过一浪。软件提供商和分析师乐于向媒体提供信息，借此大肆吹捧自己的产品和技术特点。一些提供商声称他们的产品为实现SOA不断努力，另一些人尽管可能正在或多或少的使用着这些产品，但他们更愿意认为SOA在更大的程度上只是一种架构模式。

　　不论市场上有什么样的说法，重要的是要认识到任何一个SOA基础架构产品都是实现SOA的方法之一，是人们在实现SOA这一路走到现在的一个里程碑，但同时，这并不意味SOA的完结，SOA本身还要继续发展。平台软件能够为整个企业的服务架构，提供必要的主干网络，但是选择怎样的方案只能依据企业的具体需要来定。

　　目前普遍使用的企业服务总线(enterprise service bus，ESB)就是这样一类软件。最近的一些创新产生了一些搔动和困扰。所有的ESB提供商都说使用他们的ESB产品为面向服务的技术架构提供核心组件。然而，大多数提供商仍然是努力组成一个ESB，他们的产品仅仅具有普通ESB应该具备的功能。

　　设身处地想象一下，作为IT架构师，负责对应用程序实施SOA架构。你应该作些什么?这真的非常简单，你只需回到业务需求一块，只要服务调节指挥和架构模型能够满足业务需求即可。

　　服务调节

　　调节(Mediation)并不是一个新概念。在传统的面向对象的文献中,众所周知, 调节者(mediator)是推动“松耦合”(loose coupling)的一种模式, Mediator可以用来控制和协调这些对象间的相互调用,避免他们之间的复杂调用造成混乱甚至死循环,同时使逻辑更加清晰,需要改变某些逻辑时也很容易实现。

　　用服务替代上一句中的对象,这样你就可以很好地理解什么是服务调节。然而, 在SOA中服务调节不仅可以用来控制和协调这些服务间的相互调用(尽管这种相互间的调用是一个好的开始)。在强调技术中立性的服务世界里, 基于XML的信息交互作用更可以使多事情都变成可能,只要你在服务生产者和服务消费者之间放置一合格的调节者。

　　传输协议转化

　　通常,服务提供商基于某种传输协议(例如HTTP)提供服务,而服务消费者只能通过另一种不同的协议(比如MQ)通信。 因此,也许需要在服务提供商与消费者之间建立一座异步起动同步运行的连接桥梁,超越HTTP和Java Messaging Service消息服务(JMS)等协议.从技术角度讲, Java Messaging Service消息服务(JMS)并不是一种传输协议,而是一组供应商中立(vendor-neutral)的通信APIs。正如图1所示,异步Web服务实施通常表现为 “简单对象访问协议(SOAP)服务在JMS之上,”而在使用传输协议的背后是供应商特定(vendor-specific)的,如MQ或Tibco RV。

　　这种现象在有很多遗留软件的环境中非常普遍,这些遗留软件的服务已被开启,而其它应用程序却因为传输协议不配不能使用这些服务。与其建立一个新的协议适配器或在执行服务提供商的基础上实施异步起动同步运行桥梁,还不如让调节者来解决这些差异不同,做必要的转换。这样服务开发人员只需要集中精力解决服务逻辑问题,可以让基础结构软件负责调节责任。

　　数据格式转化

　　即使在同一机构中,不同部门对于业务实体的定义也会不一样。财务部可能有特别的客户结构,它区别于从开发帐单角度定义的客户。这种情况下,一个开发帐单中与客户相关的服务就不能在没有弄清数据模型区别的情况下采用财务部的服务。

　　你可以努力使每个人都接受一个公共的定义(如使用被提议的标准数据模型),不过这种方法在大型机构中可能并不十分有效。最好的方法就是让斡旋组件来解决不同格式的转化问题.甚至可以让服务接口只处理标准数据模式,不过服务消费者则将需要配置斡旋组件来转化其数据格式,使之成为服务提供商要求的数据格式。

　　执行服务政策

　　让调节者来解决服务提供商与服务消费者之间的交互问题,这使得在两者之间阻止XML传输变得十分简单,需要采取必要的步骤来保证政策的执行—例如以适当审查,日志监测和安全检测的方式。

　　其次,以调节组件代替这些横切关注点(cross-cutting concerns)使服务开发人员不需要一定在服务层满足调节需求.当然,如果这是你面临的唯一调节需求,那么实施像面向方面编程(Aspect-oriented programming,AOP)这样的基于技术的横切解决方案是最划算的。

　　服务处理器传输途径

　　传输途径和过滤器架构模式介绍了多用途消息预处理程序和后置处理程序如何提高消息处理循环速度。一个调节平台能够以宣告的形式为服务呼叫构成这样的过滤器，允许我们通过改变过滤器配置，改变这些呼叫预处理和后置处理组件的顺序。

　　这些预处理程序包括消息内容基础上的服务路径，背景或业务规则，消息富集，消息加密/解密，消息复制等等(如图1)。在这里，调节的核心价值不是在于能够提供一些开发者无论如何都要创建的处理程序，而是在于它能在宣告的形式下使任意处理程序的组合变得简单易行。

　　服务呼叫与调度

　　还记得关于服务提供商与服务消费者之间“松耦合”(loose coupling)的部分吗?如果服务消费者直接与服务提供商相互作用，那么在不影响服务消费者的情况下改变服务提供商的接口(不是实施，无论如何实施独立于接口)会是个难题。换句话说，服务消费者永远都与服务提供商紧紧地联系在一起。

　　然而，如果服务消费者只与中间人调节相互作用，同时调节服务保证不改变它与服务消费者接口，那么很显然调节者可以为不同版本的服务派发服务呼叫，甚至是对不同服务接口。很明显，这种情况下仍然需要调解诶(就是必要的转化)，但是重要的是，它使服务消费者与服务提供商相对独立。

　　图1:本图说明了一普通调节平台(mediation layer)如何处理之前提出的需要。

　　ESB可以看作是这样的调节平台，具备我们描述的部分或所有的性能。事实上，你会在一些更好的ESB产品中发现更多的性能。

　　服务编制

　　与服务调节不同，服务调节本质上就是配置一个中间组件作为实时中间件的一部分，而编制具备与服务内容和服务实施相关的功能。编制技术也是基于中间件，它能建立一个高度集中的架构，来管理设计业务流程的定义以及业务流程逻辑的操作执行。

　　服务层

　　在详细介绍编制之前，我们需要理解服务层的概念。注意，这里讨论的服务只是为了介绍服务层和域的抽象概念。

　　服务层是根据域操作的问题将服务划分为不同的种类(成为服务模型)。例如，业务服务仅仅集中于业务逻辑而应用或效用服务是更面向技术的。举个例子，使解决系统级问题变得简单的服务如安全和审查。如图2(是Thomas Erl “面向服务的架构:概念、技术、和设计”的再版)说明了各个服务层之间的关系。

　　图2:三个服务层通过使用服务模型实施。

　　业务服务实施可以利用效用服务，也可以利用有可能的其它业务服务――这就是所谓的服务组合。服务设计的基本原则之一就是在必要的情况下，构建服务时应允许服务参与组合。

　　服务编制是服务组合模型的扩展。通过控制工作流逻辑和呼叫顺序，一对服务层起到了许多业务服务和效用服务编制的作用。

　　例如，一抵押解决方案可能需要使用由外部信用代理提供的信用积分服务。对信用代理的呼叫可以并行发生，但是呼叫的结果需要经过总计和分析，之后才能发过来。这样复杂的工作流逻辑通常涉及到超市设定和例外，同时被设为典型的业务流程定义。

　　服务指挥与业务流程执行语言BPEL

　　决定你是否需要一个真正的服务指挥平台的关键因素是看你的服务和业务流程的交互是否需要一个如上文所说的复杂呼叫模式。如果他们的交互需要,那么你就可以在业务流程执行语言BPEL引擎这样的服务指挥平台上进行两者之间的交互。

　　业务流程执行语言BPEL是Web服务编制中最有前途的标准,虽然BPEL常常在构建可执行的业务流程模型的过程中提到,但是不能过分强调BPEL引擎的服务编制方面.要牢记BPEL在构建真实复杂工作流模型方面能力有限,这一点很重要,因此最好将BPEL看作是一种服务编制工具,而不是成熟的工作流建模工具。

　　BPEL与ESBs

　　一些ESB产品中可以实现业务流程执行语言BPEL,而一些不可以.不可以实现流程执行语言BPEL的那些产品可提供基于服务调节流的图形化向导(graphical wizard),该向导为简单快速运行服务流构建模型。如果你试图通过服务调节为所有快速运行、同步服务流和交互建模,那么你一定要认真、长远地考虑好你的调节需求是什么。如果你不能为所有快速运行、同步服务流和交互建模，那么就采用基于代码的实施，而不是投资一些昂贵的中间件，这也许是更谨慎的选择。

　　其它编制性能

　　商业编制产品提供的其它特性和性能如下所示:

　　有复杂交互模式的同步(synchronous)、状态无关(stateless)(快速运行，short-running)的工作流管理，例如并行呼叫和可能取消的时限性(Time-bound)操作。
　　长期运行(long running)、 状态相关(stateful)、异步(asynchronous)的工作流管理，这种状态下进程可能需要等待事件的触动。对于异步呼叫，也要支持有相关请求-响应(Request-Response)模式的回拨(callback)功能。
　　并行服务呼叫支持AND-join 和OR-join节点处理类型。

　　自从出现企业应用集成EAI之后，编制技术便不断发展。所以，目前，编制技术已经逐渐成熟而且变得相当普遍。不过，当在面向服务的技术架构中评定一款编制产品的使用效果时，你需要认真调查该产品所提供的网络服务技术和面向服务的公共法则的范围。

　　未来的发展趋势

　　即使就像商业化的ESB获得更多的完善一样，一些开源调停框架结构正在得到牵引，而且正在变成你希望考虑的解决方案，特别是你正在使用JEE平台。这些最为流行的框架结构提供诸如协议转化、数据转换和服务路由之类的调停功能。尽管如此，一定要紧记这些可能不会提供商业化产品中所提供的富用户界面。

　　另外一个令人感兴趣的趋势是最近才出现的，即什么可以成为硬件级ESB设备的特征。起初，这些特征被定位为企业界限XML安全设备，但是它们也提供非常强大的调解能力。此外，由于它们实际上是由专用硬件实现的，这些设备可以提供出众的处理性能。然而，它们能否得到广泛的采用或者甚至取代软件ESB解决方案，一切都尚待分晓。