SOA业务服务环境的若干模式.doc

SOA业务服务环境中的若干模式 读：本文介绍了ESB产品常常提供的丰富的适配层，使得业务服务和服务消费者之间的技术整合成为可能。只要ESB产品不根据某些业务面不可控的规则和策略完成一些所谓“智能”路由时，它就是SOA环境中最有价值的ESB特性。 关键词：企业服务总线 ESB SOA设计模式 松耦合 服务契约 SOA参考架构基础 伴随世纪变迁，我们愈发感觉到需要一些稳定的，恒定的甚至“不可触及”的东西，由他们去支配其他不断变化的事物。诸如宗教仪式、数学公理和地球形状等，都属这类恒定的事物之列。然而有时候，人们在不断进化的过程中所积累的知识又迫使人们去修正对那些恒定事物的认识，这类事情时有发生， 譬如，数学公理就是这样不断变化的事物之一，特别是欧几里德的几何理论和人们对地球形状的认识。赫拉克利特曾说过：“唯一不变的是变化本身”，我决定追随他的智慧。 　　有些人的态度是简单地相信那些恒定事物，这样做非常简单；而另一些人则常常勇于挑战那些不变的事物——寄以弄清它们是否真正地永恒……本文的形成受益于这里提及的两类人的长期争论，探讨的话题与一组设计模式有关，即当它们的应用环境改变时，其利与弊？ 　　这里就有一个这样的热点话题，大家都知道两个经常被提到的模式——门面模式（Fa??ade Pattern）和仲裁者模式（Mediator Pattern）；当其应用环境从最初假定的应用编程的范畴发展到企业技术层编程的范畴，并最终发展到贯穿于业务时，其作用会有如何变化呢？这个论题之所以如此有趣，我想是因为： 　　技术产品物化了这些模式 　　这些产品被厂商推向企业的IT部门，极大地影响了人们的日常工作。 　　在这类产品之中，企业服务总线（ESB）突然间变成了实施面向服务的架构（SOA）的“必备”要素，然而对于其中的缘由却缺乏说得过去的解释。现有的大部分“解释”谈论的是采用ESB产品我们能够做什么，但是这种解释的结果仍然没能解开谜团。 　　根据日常生活中得到的经验，在开始本文之前，必须要明确一些术语的定义，确定“相通”的语言。比如，当中文提到SOA时，它指的是OASIS的SOA标准，如参考模型（Reference Model）和SOA参考架构基础标准草案；而“业务服务（Business Service ）”则指的是在OASIS SOA的语境下，人工服务和自动服务的综合体。它们实现特定的业务功能或特性，提供访问业务能力的途径。业务服务的实现方式多种多样，比方说，业务流程就是一种实现方式。人们通常将业务流程理解成一组按特定顺序编排的人工活动或自动化活动的集合。 　　谈及模式时，我采用的是GoF著作中给出的定义。有时，模式与实现该模式的产品的名字相同，所以我们必须要交代清楚。 　　一千人眼中有一千个门面 　　让我们先从门面模式开始热身一下吧。自1681年开始，门面这个词语就指建筑物的正面。在技术领域中，我们从GoF著作中对门面的定义开始——门面是在面向对象（OO）的设计中屏蔽其他接口的前端接口。一般来说，门面模式的实现能够将发送方（根据粗粒度的前端接口）发送过来的消息拆分成细粒度的目标接口所能识别的一组消息。这一能力解放了发送者，它不再需要理解目标接口的详细信息。与此同时，位于门面接口之后的接收者扮演的是仲裁者的角色，因为它知道如何拆分请求消息，并将拆分后的消息分往目标接口。 　　Java中有个EJB门面模式。该组件门面与其OO祖先略有不同。EJB门面模式通过如下方式提供服务：1）接受粗粒度聚合请求，该聚合请求是由发往若干其他EBJ的请求组合而成的；2）拆分请求并调用合适的EJB组件。在此场景中，门面模式从面向对象到面向组件的环境改变中存活了下来，但这却是它最后一次幸存。 　　也许因为门面模式非常有吸引力，所以大家又在面向服务（SO）的环境中根据个人需要给出了新的定义。下面是对服务门面模式的三个不同的定义， 在SO环境中他们之间又相互有着“细微的差别”。 　　我们首先从IBM的定义开始： 　　“该模式致力于在服务请求者与应用程序提供的功能或不以服务的形式而存在的能力之间提供松耦合的连接。松耦合隐藏了服务提供者的复杂性，取而代之的是标准的Web服务接口……服务门面模式还引入了一个仲裁点，由它负责若干标准功能，如日志。” 　　后来IBM又对上述定义作了追述： 　　“遗留的应用系统本身不能天然地融入SOA环境，对这些系统作出改变即昂贵又需要稀缺的技能……当企业希望在SOA的环境中向服务客户端提供服务接口，同时服务提供者的应用程序又无法便利地升级到能够提供服务接口时，使用该模式再适合不过了。” 　　IBM的目标和方法非常清晰——如果资源不能便利地通过服务的形式被访问，那就交由门面来处理。 　　与此同时，《.NET模式：架构、设计和流程》一书中把服务门面描述成服务间