ESB（企业服务总线）是SOA体系架构中必不可少的一个重要组成部分，甚至是最重要的组成部分，我想大多数人对这个说法不会有异议。然而要想非常浅显易懂地将ESB这个概念以及其实施的必要性讲给一个非技术人员或是一个单纯技术人员也并非一件易事。
首先非技术人员无法将这个抽象的东西与真实的业务关联起来。即不能把它归为财务系统、人事系统，也无法将其归入一个特定的流程。在他们心中，服务总线只是集成商需要关心的一个问题，离他们太远。
而技术人员则是走入另一个极端。因为在国内大多数应用都是以应用为目标，而且通常每个应用系统都是由一个集成商实现的封闭系统，技术人员如果想获得一个服务的接口或契约往往直接就可以找到服务的实施人员，这不是更加快捷吗？为什么需要服务总线？
在一次给合作伙伴的培训中，我想到了一个非常易懂的例子来说明这个问题。我们来做个假设，假如你是我们公司的客户，我是公司的技术人员，你想找到我获得技术资询。那么，在这个场景中，你就是服务调用方、我是服务提供方或服务实现者。试想你可以通过几种方式找到我？
方法一：拿出我的名片，直接拨打我的手机
分析：没有问题，在大多数情况下你可以一下找到我，但也有特例，比如：我手机没电了、手机不在服务区、或我正在与客户交流不方便接电话。那你怎么办呢？也许你会再发一封邮件给我；或许你真的很急，于地真接来我们公司找我。
那么我们把这个过程用技术语言翻译一遍：
你（服务调用方）通过手机（协议）以及电子邮件（协议）联系（调用）我（服务提供方）。
那么这种方式有什么问题吗？试想一下，你也许只记了我的手机号码，当无法接通电话时，你也许就放弃了。另外，由于你没有有记录你找我这个事件，过了一段时间你可能会想不起来何时、为何事试图联系过我。再有，也许我记了你的电话由于没有存你的号码而把你当做恶意电话而拒绝通话，等等。
方法二：拿出我的名片，拨电话到公司前台阿姨，将你想要联系我的需求讲给她，以求得她的帮助。
分析：这种方法好不好呢？显然，这是一个相对更好的办法，我们试着想象一下以下场景：
你打电话到我们公司前台，然后对前台阿姨说，我有急事找Gary，如果我在的话，阿姨会将电话转给我，如果我不在，阿姨也会问清楚你有何急事，或者告诉你，她将转告给我，让我尽快给你回电话。然后，你就可以耐心的等我电话了。
在这里，我们加入了一个第三方—阿姨，我们可以把阿姨想象成为服务总线。那么在这个场景中她起了什么作用呢？
你不必记得我的坐机、手机或是电子邮件等信息，你只要记得我们公司前台的电话就可以找到我们公司的任何一个人。
你不必担心你的请求是否会到达我，因为阿姨会尽心尽力的将你的请求转到我的分机上，就算我不在，她也会尝试多种方式联系我，确保客户的请求一定会到达被请求方。
你想找到我，这才是你真正关心的，你不会在意姨是如何找到我的，是打电话呢、还是喊了一声、还是发邮件、甚至是找其他同事去问的。
阿姨在接到电话时不会随便进行转接的，她一定会先确认请求的合法性，这就帮助我事先进行了请求安全验证。以保证我不受广告或无聊电话的骚扰。
如果阿姨是个有责任心的员工，往往会将每个客户电话做个记录，当我需要这种日志信息就可以找到阿姨。当然，阿姨可能也会无意中做着另一个工作，那就是我是否在公司（服务可用性）监控。
那么将以上的场景翻译成技术描述又是怎样的呢？
你（服务调用方）打电话（服务请求接入）到我们公司前台阿姨（服务总线），阿姨首先确认这不是广告电话或无聊电话（请求验证与安全验证），阿姨通过多种方式（多种协议）以不同的流程（服务协作）确认我是否在公司，如果我在公司将客户电话转过来（服务路由），如果我不在将通过电子邮件（请求的格式转换与内容加强）或其它方式（多种异步协议）将请求转到我。然后阿姨记录下（服务日志）这次客户请求。
这样，你是不是理解了什么是服务总线以及她在SOA体系架构中的意义呢？那么什么是服务总线呢？简单地说，她就是在服务调用方与服务提供方之间的一个中介。这个中间屏蔽了请求方与响应方的协议差异性，并为服务提供了服务协作、内容加强、服务路由功能。同时，作为一个平台，还提供了服务的监控、安全、以及日志功能。
发表于 @ 2007年09月06日 09:36:00|评论(loading...)|编辑