苍龙之血染传奇:SOA--ESB

ESB：

       在实践中，要使得SOA得以运转，你必须有调用服务的方法，这个基础设施就是SOA的技术支柱。注意，ESB也可以是异质的，即使是Web Service这样的标准，其多个实现之间也会有差异。

       ESB的职责是，使得消费者能够调用供应者相应的服务。它包括了如下任务：

n  提供可连续性

n  数据格式转换

n  （智能）路由

n  处理安全

n  处理可靠性

n  服务管理

n  监测和日志

ESB的主要角色是提供互操作性。因为ESB集成了不同平台和编程语言，所以该角色的基础职能就是数据格式转换，TB目前仅仅是对java来说的，因为需要引入jar包，后来开发了个Implement，据说可以直接调用，囧，其实本来就不该依赖jar包。数据转换并不是一项轻松地任务，尤其是把性能问题结合起来考虑的时候。通常做法是引入一个特定的格式，所有单平台和API都映射到该格式上。对Web Sservice来说，这种格式通常是SOAP，另外现在有了hessian。

       另一项基本任务就是路由。一定要有某种方法从消费者向供应者发起服务调用，然后从供应者向消费者把答复传递过来，TB有一个基于mina的超强网络框架，据说这个东西很好用。

       ESB的其他职责都是对“提供互操作性”这个核心任务的扩展。

ESB职责详述

数据映射

松耦合的ESB通常要求：只有少数基础的，稳定的数据类型被定义为公共数据类型。对所有其他信息类型来说，供应者都要定义自己的数据类型。另外，数据类型的版本划分会导致如下情形：在同样的供应者提供的服务中，对同样的数据使用不同数据类型。

智能路由

路由，可能也会包括负载均衡和实效备援等方面，下面会有讨论。另外，我们可能还需要路由信息的不同方法，例如，消息可以被赋予不同的优先级，或者，甚至根据西欧阿西内容的不同给予不同处理。后者被称为“基于内容的路由”（CBR）。

要处理基于内容的路由，要求ESB至少对部分服务有语义方面的理解。换句话说，不光供应者和消费者在依赖某个服务的确切接口。可以通过给ESB加上些能处理的公共属性。但是，为了伸缩性，这些属性必须是消息头的一部分。比如SOAP的请求头。

处理安全

处理可靠性

不同协议提供了不同形式的可靠性。协议并不能保证消息传递“有一次且只有一次”。实际上，Web Services 的HTTP协议内生就是无法保证消息的传递。

ESB应该自己定义处理可靠性问题。ESB本身也能添加一些机制来改变协议的行为。（参考《ESB的消息交换模式》）。

服务管理

当SOA范围扩展时候，迟早会碰到管理所有服务的问题。如果分析师和设计师在寻求找到既存服务并且在新的业务流程中重用它们的方法，该问题由业务驱动；或者，该问题由技术驱动，可能有一个技术需求，要求能够部署和运行一个服务基础设施。（UDDI），貌似和ESB关系不大，其实是服务的管理。

监测和日志

ESB是运转业务流程和技术心脏，实施、调试和维护本地过程的方法，现在都分布到了许多系统上。所以，为ESB开发日志和监测功能是必须的、至少应该建立诸如关联ID之类的概念，以及在分布式系统上支持监测和调试的工具。

监测和日志应该包括哪个消费者调用了哪个服务，以及一个具体的服务调用进行了多长时间，这些对于撤销服务和监控服务非常重要。

业务活动监测（BAM）

       ESB使得“业务活动监测“称为成为可能。ESB使你可以监测消息，即时了解业务的状态，从而非常迅速的作出反应。比如login的某些服务调用时间，调用次数等，这对于我们的环境更多的是监控的作用，不过有些监控可以转换为商业行为。

ESB之间的差异

       点对点与中介

       区分ESB技术的一个重要方法是看它们为物理连接提供的耦合度。消费者必须知道服务提供者的确切地址吗？或者,ESB提供了某种机制，使得消费者可以送达正确的供应者吗？

参考《松耦合》中的物理连接方式

       协议驱动对比API驱动的ESB

       使用前者，ESB定义一个协议，供应者消费者根据这个协议发送和接收消息。比如，Web Services的SOAP协议。

       使用后者，ESB定义平台相关的API，供应者消费者使用这些API来进行服务实现和服务调用。

这两者有很大的不同。

当采取协议时，ESB的责任只需要定义协议，而相应的转换工具（也许已经有标准工具，也有可能要消费者和供应者自己实现）需要自己选择。而且，协议变化了，需要重新映射。通常，协议驱动的方法带来分布式通信模型的第三个层次。在模型的底层，有一个相对稳定的协议；在顶层，有一个调用和实现服务的API；在中间，有一个层负责将API映射到协议。（在互联网上可以找到相同的层级结构。传输层包含了稳定的HTTP（S）。要通过这个协议发送数据，不同的供应商提供了消费客户端（浏览器）或实现工具，所有这些提供了针对诸如Java、HTML等平台相关接口的映射）。协议驱动的ESB可能导致这么一个情形：

每个消费者和供应者都将ESB规定的协议映射到平台特定的业务接口上，java中我们使用一些代码把java接口转换为web service协议，一般都已经有些成熟的开源框架，比如.NET就可能使用WCF，一般，没必要一个业务系统去完全实现，这相当于是一个协议到API的映射。

       当ESB负责API时，ESB团队需要将服务调用和服务实现映射成格式良好的参与者可以通过ESB发出的消息。供应者和消费者能集中精力在业务上。

。。。。。。。。。。。。。

       Web Services内生是协议驱动的，所有的协议都会随着时间而变化，所以协议更改会产生缺乏互操作性的问题（超过50个的不同规范）。所以，使用Web Services的公司迟早都要考虑采用作为ESB一部分的映射层。让一个中央团队提供在业务API和协议API之间进行映射的解决方案，不过这些API也可能会变得非常不同。

API驱动的典型例子就是tair。

总结

l  ESB是SOA的基础设施

l  ESB的目的是提供互操作性（连接性、数据映射和路由），以及其他一些附加服务，如安全、监测等。

l  ESB是异质的

l  ESB是协议驱动还是API驱动，这是个基本决策

l  协议驱动的ESB定义供应者和消费者必须遵守的协议，但是，如何遵守协议由供应者和消费者决定。ESB和被连接系统之间的解耦方式使得他们不共享任何代码，所以ESB不必为各个系统部署程序可。缺点是，协议的任何变化都迫使供应者和消费者作出相应更新

l  API驱动的ESB为供应者和消费者提供API，它被用来实现调用服务。这使得协议的细节透明，但要求ESB按某种方式向供应商和消费者部署代码

l  ESB可以提供各种增值服务，其中，最重要的是分布式调试能力

l  业务活动监测（BAM）使你能监测ESB，这样你就能实现了解自己的业务，相应作出反应。这样可以创造一些商业机会和市场优势。