from:http://bonny.javaeye.com/blog/778444
…
一千人眼中有一千个门面
让我们先从门面模式开始热身一下吧。自1681年开始，门面这个词语就指建筑物的正面。在技术领域中，我们从GoF著作中对门面的定义开始——门面是在面向对象（OO）的设计中屏蔽其他接口的前端接口。一般来说，门面模式的实现能够将发送方（根据粗粒度的前端接口）发送过来的消息拆分成细粒度的目标接口所能识别的一组消息。这一能力解放了发送者，它不再需要理解目标接口的详细信息。与此同时，位于门面接口之后的接收者扮演的是仲裁者的角色，因为它知道如何拆分请求消息，并将拆分后的消息分往目标接口。
Java中有个EJB门面模式。该组件门面与其OO祖先略有不同。EJB门面模式通过如下方式提供服务：1）接受粗粒度聚合请求，该聚合请求是由发往若干其他EBJ的请求组合而成的；2）拆分请求并调用合适的EJB组件。在此场景中，门面模式从面向对象到面向组件的环境改变中存活了下来，但这却是它最后一次幸存。
也许因为门面模式非常有吸引力，所以大家又在面向服务（SO）的环境中根据个人需要给出了新的定义。下面是对服务门面模式的三个不同的定义， 在SO环境中他们之间又相互有着“细微的差别”。
我们首先从IBM的定义开始：
“该模式致力于在服务请求者与应用程序提供的功能或不以服务的形式而存在的能力之间提供松耦合的连接。松耦合隐藏了服务提供者的复杂性，取而代之的是标准的Web服务接口……服务门面模式还引入了一个仲裁点，由它负责若干标准功能，如日志。”
后来IBM又对上述定义作了追述：
“遗留的应用系统本身不能天然地融入SOA环境，对这些系统作出改变即昂贵又需要稀缺的技能……当企业希望在SOA的环境中向服务客户端提供服务接口，同时服务提供者的应用程序又无法便利地升级到能够提供服务接口时，使用该模式再适合不过了。”
IBM的目标和方法非常清晰——如果资源不能便利地通过服务的形式被访问，那就交由门面来处理。
与此同时，《.NET模式：架构、设计和流程》一书中把服务门面描述成服务间的分界线，并将它提升到“控制器”的层面，而且是个具体的服务（再一次印证了“Web服务”这个名字是多么地晦涩）：
“提供一个Web服务的控制类，它是业务逻辑门面对象的接入点。业务逻辑门面对象又能在除了Web服务之外的其他环境里（比如基于CORBA 的应用程序）得到重用。”
另一定义引自Thomas Erl所著的《SOA设计模式》一书：
“一个服务如何能既适应其服务契约（Service Contract）或实现，又能支持核心服务逻辑独立发展呢？核心服务逻辑与其契约及实现资源之间的耦合性会阻碍其发展，并对服务消费者带来负面影响。”
所以，此处担心的是服务接口不适宜地暴露了服务实现。即，
“服务门面组件用于封装服务架构中有着负面的耦合可能性的那一部分。门面逻辑位于契约和核心服务逻辑之间，在核心服务逻辑与契约之间起着解耦合的作用。”
可以看出，上述引用的.NET服务门面只不过是外部访问的Web服务接口与实际实现服务功能的类/对象的接口之间的一个仲裁者而已。根据我的理解，Web服务接口一定是服务门面，但是，.NET服务门面却退居Web服务之后，建立了一个门面的门面。这表明，不是Web服务接口有问题，就是服务实现 （即具有真正功能的类或对象）的设计未能按照Web服务接口而正确地设计。
对于IBM而言，服务门面屏蔽了“不以服务的形式存在的资源”的原始接口。这很好，如果该门面是一个服务，那我就没有任何疑问。不然，我就会对IBM的定义充满怀疑。因为，如果服务门面只是一个接口，这听起来好像IBM仅仅为非服务的资源加上一层“神奇的”门面接口就使之变成了服务。对我来说，大家好像是在应对一个经典的语义问题：在谈论什么是现实世界所需的东西时玩文字游戏。尤其，当我们增加一门面或连接器时，增加的只能是新的连接性，但不论增加何种接口，都不可能改变本质，即事物的精髓（如可服务性）。用透明的玻璃盖代替金属盖放在煎鸡蛋的平底锅上，鸡蛋就能变成比萨？你认为呢 ？
《SOA设计模式》一书中描述的服务门面模式是一种与MS .NET和IBM的解释完全不同的事物。该解释，也就是上面的引文，引出了一个提问：服务门面模式是（如Thomas Erl所称的）架构模式，还是SOA架构中所看不到的一种实现模式？
在Erl的解释中，首先跃入我的眼帘的是“服务契约（Service Contract）”这个词，而它与OASIS SOA标准不符。基于上述引文我们只能推测“服务契约（Service Contract）”就是“服务接口（Service Interface）”（而“契约” 这个词汇的语义比“接口”更丰富，所以这种说法可能会误导开发者）。有了这层推测，引文中的最初的问题似乎是：“一个服务如何既能适应其服务接口（Service Interface）或实现，又能支持核心业务逻辑独立发展呢”？一个直观的结论是，接口在某处发生变化，而核心业务逻辑在另一处独立地发展，而服务体/实现也在自己的轨道上改变……这种做法，如果不能称之为荒谬的话，至少可以说是一团糟或在语义上是乱七八糟的。难道“位于契约和核心服务逻辑之间”的服务门面只求掩盖这种一团糟的局面，而不求解决问题吗？如果回答是“是”，那么至少这不是GoF定义的模式。
Erl的解释很显然牵扯到的问题之二是，服务接口实现细节与服务接口之间的耦合，比如，服务接口由服务的实现细节驱动吗？但是，服务接口必须由服务功能的访问方式决定。如果有人违反这一规矩，通过特定的服务内部实现生成服务接口（如某些不负责任的厂商在Web服务采纳的初期所建议的那样），那么他最好请求消费者的原谅，完全摈弃这种服务接口，重新建立/发布新设计的接口。比起将错误隐藏在门面之后并将错误的接口留给用户，这种做法来的更加安全及公平。为了避免将来出现这样的错误，出错就应付出代价，而不是遮盖起来。
不论如何，通过门面分离服务接口与服务实现体的想法对我而言仍然非常做作、易错并且政治化。这种分离催生了一种想法，那就是即便接口没有业务价值（注：业务价值属于服务本身），也可能独立存在。对于那些曾经试图构建一层接口层而找不到地方放置该层的人们，这种接口让他们迷惑。在业务世界中，这类接口的存在非常扭曲，就像某些建筑物的前门一样，虽然门后的建筑物已经损毁，但仍然称之为公司的总部。职能部门无法理解一个无接口的服务或者独立存在的接口/门面。在业务服务领域里，接口和服务是统一的整体。
因此，我们看到在面向服务的环境中门面模式的含义已经发生了变化。许多主导厂商出于“服务”概念上的Web服务技术的目的或利益，重新阐述了它的含义。在以上看到的情形中，门面模式（比如，服务门面模式）有着不同的语义，它们只会把我们带向巴比伦式的建筑（译注：巴比伦城的空中花园是古代建筑史上的一个奇迹，在其贯穿南北的圣道尽头是没有完工的通天塔，作者用此比喻厂商们意在营造种种美妙的构想，但是却永远无法实现），而非IT建设。
ESB现象
当David Chappell（当时他在Progress Software公司）发明这个词并发布第一款企业服务总线产品时，我住在马萨诸塞州的波士顿，我的一些朋友也在Progress公司工作。对我来说，该ESB产品的发布不外乎是老套的消息系统与Web服务联姻之后的另一市场噱头。从模式的角度看，ESB看起来像是仲裁者模式、发布订阅模式以及适配器模式等的结合体。当时我没怎么看好它，从目前看来我当初是错了。如果ESB占据所有业务消费者与业务服务间的交互范围，那么其仲裁特性就是为你的IT安置的一个定时炸-弹。ESB产品一点一点地蚕食所有业务的交互逻辑，成为了SO开发中不可或缺的一部分；它将所有服务绑在一起并紧抓不放。这真是我们的企业所需的吗？若是这样，ESB产品的重要性不因为其业务需求或业务价值，而是因为我们的SO环境中的任何东西都依赖于它，厂商产品还能奢求什么？
ESB产品的现象可以被一句经典的现实主义谚语一语中的：“通往地域之路由善意铺成”。简化了一双手之间整合的解决方案成了两双手之间沟通的障碍。尽管如此，我们还需沿着它发展的过程看看这些是怎么发生的。
仲裁者模式与门面模式的发展历史十分相似。在GoF的书中，仲裁者模式用于帮助开发者组织对象间的逻辑交互，解决设计的像意大利面式的交互或互相依赖等方面的问题。我非常喜爱此模式，也经常使用它。我也曾提到过，当门面模式需要决定如何分发消息时，其实现常常依赖于仲裁者模式的使用。当仲裁者模式的使用环境（译者注：从管理对象间交互）转向管理组件间交互时，我们并未看到太多的改变。
Web服务的引入也没有极大地改变仲裁者模式的使用。标准的Web服务接口，其本身就是一个门面，它需要一个真正的“工人”去决定如何处理接收到的消息。从该角度看，服务本身就可以内在地实现仲裁者模式。同一个开发人员（一双手）就可以控制交互的双方——消费者和服务——而不会出现任何问题。
我认为，这种开发经验促成了将ESB模式建立成至少是门面、仲裁者、适配器和发布订阅等模式的结合体。相应的ESB产品没过多久就占领了技术服务的市场。然而，在业务（如SOA业务服务）范畴中的功能性仲裁应有许多新的职责，这些职责对与技术领域、面向对象或面向组件的编程世界是未知的。
根据OASIS SOA参考架构基础的草案中，SOA被置于业务和技术中间，同时出现在此分界线的两边。这意味着在SOA环境中与业务逻辑相关的所有元素都会自动地提升到“业务”的地位并与某些业务职能相联系。然而，这不能代表它们已经从其技术职能中解放出来了；它们成了双重体，这也是现代IT的全新形象，即立志于提升业务敏捷性。
从以上推理来看，我们可以得到如下结论：如果ESB产品实现了业务服务消费者与业务服务本身之间交互的业务逻辑，那么ESB就成了一个业务面的事物（如同ERP系统）。考虑到此时，你一定瞪大了眼睛，所以我不得不后退一步温习一下我们所讨论的主题，一方面是SOA业务服务，它通过人工活动和自动过程的组合封装了业务和技术两方面；另一方面是服务契约（Service Contract），它是使服务提供者与服务消费者间达成一致，规定服务与消费者间的关系与交互的文档。
单凭ESB产品带来的迷惑，以及它没能在日常工作中起到真正作用，我就可责难此模糊的ESB模式，稍后我们会谈到这点。为了阐述我对ESB产品的疑虑，先让我对其若干个通用特性提出简要的质疑，看看它们掩饰了那些风险。（该视角是必要的，因为我们手头没有定义ESB是什么或应该怎样的标准。我们看到的每个ESB产品都是独特的……并且很难与另一个ESB兼容。）
因此，ESB产品通常包含若干个引擎，它们可供请求者和接收者通过Web接口进行访问（不排除有些ESB产品还可能支持其他交互接口）。我所参考的是Microsoft的面向Biztalk的ESB开发工具箱中介绍ESB产品的特性，如表1所示。
序号
ESB特性
挑战
1
智能消息路由
“动态路由，基于内容的和基于路线的运行时路由，或者基于内容的消息路由。”
ESB产品不仅能提供基于内容和消息的上下文（该信息一般不能事先预计）的路由，还能以消息发送方和接受方所不知的任何其他手段以及规则进行路由。人们坚信分发消息相干的职责是专属于ESB产品的。该特性源自发布/订阅和MOM系统，在这些系统中，发送方不知道接受方是谁，接受方也不知道谁请求了它的服务。
我想知道它们是怎样的业务用户和业务服务，它们不知道对方是谁，也根本不想知道。的确在某些场景中存在“中间人”这种角色，但是交互的双方相互之间非常了解（如“邮政服务”），或者中间人成了业务的一部分（如，专递服务）。
反对我的人可能会说ESB产品的工作是整合技术组件，不需要了解“业务规则”。我同意这种说法，只不过需要补充一点：基于此，ESB产品就不应该支持业务服务（也包含其技术部分）的交互，因为业务消费者与服务之间需要相互了解。
2
动态数据转换
“动态数据转换和翻译，不同消息格式或消息语义间的映射的定义是在运行时被解析的。”
为实现动态数据转换，ESB产品需要知道输入数据和输出数据的格式。然而有时候，尤其在实际工作中，输入数据是不完整的。这不成问题——因为ESB产品能够校验数据并从别处获得缺失的数据。很好！但是校验规则可能很快就跟不上交互策略的变化（因为ESB是IT基础架构层面的设施），特别当ESB由另一团队“掌管”时。
同样，如果ESB产品是服务消费者与业务服务间交互的“优等公民”的话，那么它必须承担业务职能。如果ESB产品只翻译交换双方的数据格式的话，那么ESB必须成为对服务消费者及（服务契约中所描述的）提供者双方负责的可信赖的翻译器。如果ESB产品足够高级，能够丰富消息，那么它就成了业务交易的一部分，而且必须符合所有业务规则/制度和安全认证和授权控制等。
例如，如果请求数据不完整，并且ESB产品所使用的其他数据源，在服务契约（Service Contract）中没有提及，那么消费者也许不能使用该数据源，若是这样，那么ESB支持团队就碰到问题了。相反，如果该数据源在服务契约（Service Contract）中明确地说明了，那么消费者为何选择ESB产品作为数据收集者，而不是事先通过另一服务来获得这部分数据呢？让人费解！
3
安全切入点和安全控制
人们认为ESB产品处于执行安全控制的有利位置。安全控制可包括消费者和服务认证，特定交互的授权/许可以及信息加密等 。
我不太清楚这是为什么，但是对我来说，在ESB中加入该特性应该是某些市场人员的主意；这不可能是安全专家的想法，因为这种“做法”违反了“安全101规定”。
多数研究者发现75%到80%的安全违例都发生在公司内部，而非企业周边。如果ESB是核心的交互协调者，那么恶意请求怎么可能没有通过检查而破坏核心系统呢？在ESB产品中处理请求者/响应者认证和授权控制已经为时已晚了……但是它的确方便了开发者，譬如，缩短了交付代码所需的时间。
以下安全违例在IT中非常普遍。许多开发者或架构师认为，即便他们所代替的用户并没有权限访问这些数据，他们也可以代替用户从存储库中获取数据。之后在内存中对获取到的数据进行过滤，所以该用户不会看到受限的数据，但是系统内存中的数据却失去了保护，也就可能被恶意程序轻易地截获。
4
运行时动态发现端点和端点虚拟化
“服务消费者不需要感知服务提供者的位置和端点的细节；人们可以轻易地向ESB添加新服务提供者，或更新服务提供者，而不会影响到服务消费者。”
该特性不同于“动态路由”特性，在这里，服务发送者和发送者也许知道对方是谁，但却不知道它们的实际端点。
端点虚拟化只有用于分离业务服务和服务消费者时才算是不错的实施方式。在Web技术中，向所有的网站客户暴露一个端口，并且在此门面的背后却配置了许多内部端口，该方法就是虚拟化的一个很好的证明。
就运行时发现而言，我认为，如果我们谈论的动态发现所发现的是上述提到的内部端口，那这的确是没有问题的。倘若“发现”指的是发现消费者并不知情的服务或服务提供者的话，那么我不建议这么做，除非你忽视“业务的约定”。
5
松耦合服务组合
“服务提供者和服务消费者无需感知服务的交互形式”
实际上，这段解释已经违背了微软的实施：ESB产品能够执行多种执行路线，而且，为了制定特定的处理路线，核心处理引擎要求每个消息包含处理指示（process instruction），或者定义处理路线的元数据以及应用于消息内容的任务。因此，服务消费者必须对交互形式非常清楚，相反却无需了解前文所提到的服务（译者注：这里的服务指得是ESB产品所调用的后台服务）。
6
集中异常管理
“有了异常管理框架，服务和基础设施元素，服务消费者或BizTalk组件就能够创建、修复、再提交异常消息以及执行补偿。”
对于高度集中的系统这是一个非常有益的想法，但它却无法在分布式环境下工作。
这类集中式系统要求ESB产品独占地负责异常管理框架。此外，它的构建基于如下前提假设，一切（包括服务和服务消费者）必须通过ESB来交互。我称它为“分布式计算下的桌面思维模式”。
为了“创建、修复、再提交异常信息并执行补偿”，ESB产品必须知晓所有服务提供者和消费者的消息细节。另外，它还必须了解规定消息修复规则和再提交机制的服务消费者的服务契约（Service Contract）。你曾见过这样的ESB产品吗？
7
协议转换
“为服务提供者与服务消费者提供跨各种不同协议的交互能力，其中包括Web服务的各种WS-*标准。
例如，某服务消费者可能递交一份基于HTTP的Web服务请求，由此而产生一条发往消息队列的消息。”
该陈述听起来更像是“整合”而非面向服务。
众所周知，消费者在与SOA业务服务交互时可能使用到的所有服务接口及协议都应列在服务契约（Service Contract）之中。如果服务消费者不能使用某个特定服务，它为何还要签订服务契约（Service Contract）呢？不过，我们倒是可以假定消费者希望通过某个中介，即ESB产品，来使用协定的交互协议。这种约定完全由服务消费者掌握，服务提供者一无所知，也不需要关心ESB。所以，所使用的ESB产品成了服务的消费者，所以也必须符合服务契约（Service Contract）。因此，服务与消费者之间永远要使用服务契约（Service Contract）中协定的协议。
我尤其难以理解左边给出的示例，服务消费者发送HTTP请求时希望得到服务的即时响应。而与此同时，服务通过消息机制却无法保证即时给出回应，它是一个异步接口，响应时间也无法得到保障。
8
服务质量
“异步的发布/订阅引擎实现了多种级别的服务可用性，提供了ESB实现的高可用性、伸缩性、以及消息可跟踪性。”
这里的服务质量由ESB产品提供的，但它与SOA中的业务服务的质量不一定相关。
9
扩展性
“为运行时以及设计时进行端点发现、消息路由和更多BizTalk服务适配提供多处功能扩展点。”
ESB产品若失去了增加更多端口和服务发现能力的话，它就是一个能力非常局限的“总线”。然而，单就“端口发现功能”的扩展而言，虽然使用增加新端点的方式增加业务功能是人们推荐的方法，但这只是新增业务功能的可选方法之一。不论如何，上述“扩展点”不足以宣称ESB模式和相关产品提供了SOA的扩展性。在SOA中，扩展性可能通过其他方式得到，譬如，编排或对交换的消息的格式扩展等。
表1.
ESB产品的某些特性用在面向服务的环境中更为准确，另外一些则有不那么合适，这些都是次要的。但是，在我看来，真正让ESB产品称为“定时炸-弹”的特性是：介于业务服务和业务消费者之间的仲裁特性。我总结了以业务为中心的SO环境不适合使用OO的仲裁模式的三个主要原因。
首先是分布式授权，在OO设计中使用仲裁模式时，从来不需要考虑这种分布式的情况，仲裁模式的使用总是基于这样的假设，开发人员可以完全控制所有对象，他所要做的事情是简化对象与对象之间的关系。可是，在SOA中，即便在同一个企业中，有时也不能保证单点授权。譬如，我们有两个业务服务A和B，它们分别包含业务服务α和β，这两个服务必须以“消费者服务”的形式进行交互。由于A和B隶属于不同的部门，所以其所有者及使用权限也不同。这意味着要编制A-B/α-β交互的开发者可能受到不同业务策略的限制和制约。打个比方，A和B的业务所有者都知道ESB产品由IT部门全权掌控。虽然A服务的所有者对此没有问题，但是B服务的所有者可能不同意让B/β服务依赖于“不受业务控制的”IT基础设施。基于这种业务情形，开发人员就（有可能）不能修改β以将它作为ESB的端点（end-point），所以也就不能访问它。
第二个原因是SOA服务的提供者与消费者之间的强制性服务契约（Service Contract）。除了其他方面之外，服务契约（Service Contract）还定了服务接口（包括协议）和SOA服务交互过程中需访问并应用的策略等。我们列举一下ESB产品对于服务契约（Service Contract）的可选做法：1）ESB独立管理并授权；2）ESB作为消费者域的一部分；3）ESB作为服务域的一部分。
第一种情况，ESB产品不应该这样使用，因为它违反了服务契约（Service Contract）：服务契约中不会提到任何ESB端点、交互协议以及ESB策略。第二种情况，ESB产品可能由服务消费者使用，但是ESB产品必须代替服务消费者而存在（拿这消费者的身份，遵守服务契约（Service Contract）中指定的接口和协议），有这样的ESB产品吗？最后，在第三种情况下，服务提供者可以将ESB的服务接口和策略称作WSDL文档中的SOA服务的接口与策略，并在服务契约（Service Contract）文档中引用它们。因此，消费者不会知道他是与ESB产品进行交互的。
看起来第三种情况明确了ESB产品在以服务为中心的SO环境中的定位。但是，别着急。你可曾见过服务提供者同意将ESB整合到其服务域中（包括相关SLA和其他业务职能）的先例吗？此外，在ESB上开发的与不同（ESB或SOA服务）业务所有者相关的执行路线由谁负责呢？这不是个小问题。
第三种情况是业务交互中的中间人的角色。如果中间人介于业务服务与消费者之间，它必须承载业务交互中特定的业务职能。如果它失败了，就应接受业务惩罚。因此，对于此在业务交易占据中间人的位置的技术性基础设施，它该担当那些业务职能，拥有何种业务权利？如果不能为它找到合适的定位，迟早它会开始驱动业务。
下面我们来分析一个假想的案例。有一工厂A和一供应商X。工厂A雇佣了一个司机，要求他从供应商X处运送零件到工厂，不过如何运输则由司机自行决定。这个司机非常聪明——他/她找到了运输这些零件最佳路径。后来，工厂A又联系了另一供应商Y，同样要求司机有自己决定从X或者Y运送零件。一直以来，这都没有任何问题。现在，工厂A开了一家分工厂B，还是雇佣该司机为A和B送货——司机需要找到获取和运送零件的最佳方案。最后，工厂A似乎拿不到零件，因为司机大多数时间更喜欢把零件运往B工厂，因为……B离家更近。这种情况的发生是有可能的，因为司机并没有参与到业务流程中，也就没有业务职责。
不幸的是，上述例子并非空穴来风——微软的咨询顾问建议将ESB当作企业中SOA服务的唯一交互基础设施。那么，上述三种ESB产品/模式与企业SOA业务服务不匹配的情况他们都将碰到。
SOA的主要业务价值之一是组合——通过再聚合/编排现有业务服务的方式灵活地应对业务变化。这要求业务服务必须最大程度地“活动”才能穿插到不同的编排之中。如果IT使用ESB产品连接业务服务和服务消费者，那么，起初看起来还没有问题，但是，由于所有交互都经过ESB，服务间的交互越复杂（即服务参与的编排越来越多），它成为运行瓶颈和单点故障的可能性就越大。再者，好几个厂商因频繁地强制升级产品或做出不能向后兼容的产品更新而著称，ESB产品当然也不例外。如果ESB产品是业务服务系统的核心，此类更新就会变得非常昂贵和耗时。而且你猜，谁会为造成的错误负责？没错，是你的IT，而不是厂商。
何去何从
如今，一些IT领袖意识到，如金融业（主要是银行业）、电信业、媒体、医疗保健和其他非制造业，拥有大量的消费者与客户，若要取得进步和成功，就得依靠企业与其IT团队和和谐共处。众所周知的企业需要实现IT与业务的敏捷的事实见证了二者间的问题，“因为IT组织与业务对其技术的期望越来越远了。”
在我看来，ESB模式的内部就存在矛盾，当这些模式通过ESB产品实现时，这些矛盾越发显得明显。最明显的疑惑应当是SOAPatterns.org上给出的企业服务总线模式的定义；从《SOA设计模式》一书来看，该模式的定义的确不仅限于“企业服务总线代表了一个能促进服务间复杂的互联的环境，它建立了中间处理层，有助于解决可靠性、延伸性和交互差异性等相关问题”。该模式只不过是一组技术，而不是关于如何使用这些技术或哪些情况下该（或不该）使用它们的手册。Thomas Rischbeck说到，“ESB模式关心的是整合任务，在SOA中，它为对参与者完全透明的客户-服务的交互带来了价值”。如果这种透明性不依赖于智能路由和数据丰富，而是一组与参与者交互相关的自有规则，那我还是很乐意接受的。在SOA中，我们有一种约束交互的机制——服务契约（Service Contract）——可是ESB似乎根本不把它放在眼里。
与此同时，正如前文提到的，ESB模式是一组模式的组合。有这样一个模式可以展现多种视图固然很好，但是这些视图应该是一致的——可是，我们有一个仲裁者模式，它有助于相互了解的双方之间的交互逻辑；另一个则是发布订阅模式，而该模式却建议交互双方互不了解。
恐怕ESB模式唯一的好处是隔离了业务服务和消费者。尽管没有发布订阅模式，在业务控制之外的ESB产品的存在（因为它作为基础设施而存在）也分离了业务服务和业务消费者。因此，在认识了所有上述言论之后，ESB产品还有积极的业务价值吗？
事实上是有的。而且，不论你信还是不信，该价值源自ESB模式包括的另一模式，即适配器模式。其价值是一组面向多平台和多交互协议的适配器。为了实现这一点，消息系统必须实现与各种异构系统之间的物理连接。ESB产品继承了这一适配层，因此能在技术整合层将业务消费者连接到业务服务。没错 ，我说的是“连接”，而不是“取代”交互的业务逻辑；ESB产品也许会严格地依据服务契约（Service Contract）进行“连接”。
所以，ESB模式和产品的业务价值与SOA并不相干，但是却与过去在IT基础设施方面的投资以及适配器的投资有关。在SOA中，在业务服务领域，只有当ESB产品产品成为业务服务或业务消费者的一部分时，比如管控并操作ESB的业务实体承担业务职能时，才能实现其透明性。
总结——带走这些思考
我们谈论了门面模式和ESB模式随着应用环境的变化而产生的不太明显的用法上的改变。对于门面模式，我们发现当该模式应用与对象、组件及服务时，其模式语义一直在改变。更准确地说，在SO环境中，门面与服务接口融合于一体，门面模式融入了聚集服务。
ESB模式更艰难、更危险的处境根源于仲裁模式与发布订阅模式的合并。因为ESB模式实现在ESB产品之中，所以当产品应用于业务服务时也继承了两个基础模式的矛盾之处。尤其是当ESB中的仲裁开始扮演独立角色，占据了除基本的路由功能之外的业务交互逻辑时，它就可能会破坏（服务提供者与消费者间的）服务契约（Service Contract）中的基本业务概念。直接地说，机械地将裁者-发布订阅模式的组合提升到业务提供者-消费者关系的层面是不可能的，除非作为中间人的ESB能像业务实体一样承担业务职能。由于ESB产品并不接受业务职能，这样的产品就不应该为业务服务所见，比如，他们必须成为服务的一部分或服务消费者的一部分 。只有这样，ESB产品才能融入业务服务间的交互之中。
另外，若在服务契约（Service Contract）中没有明确地记录服务与服务消费者之间的相互了解，则ESB产品就不应该承担交互中数据转换的任务。出于安全控制的原因，ESB产品本身被看作是安全的，但是当其用作某个服务交互的切入点，用作对交互参与者进行认证和授权，这是违背基本的安全规则的做法（非授权请求不可能穿透到核心系统的路由环境之中，在此之前就应已被拦截了）。
最后，文章总结到，ESB产品常常提供的丰富的适配层，使得业务服务和服务消费者之间的技术整合成为可能。只要ESB产品不根据某些业务面不可控的规则和策略完成一些所谓“智能”路由时，它就是SO环境中最有价值的ESB特性。
最后，我将通过对一个著名谚语的重新解释来总结本文，该谚语如是说：业务服务的世界何时才能实现与业务一致。不论IT部门为业务服务带来何种技术解决方案，它都不应该改变业务的“规则约定”。如果某个技术方案的确改变了这些规则，那么它将不可避免地造成业务和IT之间真正的裂缝；若不是现在，则是不久的将来