关于SOA,ESB&EAI的痴话

 

献给每天把这三个词放在嘴边的二姐。

一些个人见解及看法，为了可以让零基础的二姐看懂，以下会有大段对技术人员不适的文字描述出现，请未婚人士移步。

 

名词定义

 

SOA

Service-Oriented Architecture，面向服务架构。

EAI

EAI(Enterprise Application Integration)，企业应用集成

ESB

Enterprise Service Bus，即企业服务总线

 

这些是什么

孤岛一个又一个

应用程序的数量就和孩子的年龄一样，在比较小的时候，让人喜爱。但是一旦变大，厌烦的不得了。

举个例子，如使用者是一家银行汇款部门，那么维持正常工作的最小系统起码有，本币汇款系统，外币汇款系统，行内的会计系统，员工人事系统。

假设按照传统的思路做法，肯定是一个挨着一个做。拿本外币而言。但是可以说在最早的时代由于网络编程根本没有现在这么简单，这些系统往往是像太平洋里的一个个小岛，互相孤立。（信息孤岛的概念）。

就只拿会计流程来说，如果没有系统级别的连接，那么就会需要在Ａ系统做点什么，然后靠人工再去Ｂ系统继续完成工作。说到这里似乎应该可以明白为什么９０年代的电子打印凭证都会有２－４联，就是因为贷记可能是在一个系统能做，借记是在另外一个系统做。同理也可以解释ＣＣＥＸ是用来干嘛的。通俗点，为了连接两个小岛，居民们只好游过去。

刚开始岛不多，游泳可以强身健体。但是岛多了就不好玩了。业务量的增长和运营人员的增长不应该是线性的。如果这样科技就毫无价值了。

所以人民觉得需要造桥。

 

造桥的时代

慢慢让系统之间沟通即让两座小岛连接在一起的造桥技术开始有了，人们开始开始尝试不要游泳用使用桥梁来连接各个孤岛。慢慢的这个汇款系统可以直接通过一个按钮先做借记再做贷记，还保证比人做的更有效率更准确更安全。

体验到快感之后，人们就开始不断的给给各个系统搭桥，然后大家惊奇的发现，由桥梁在小岛间编织出了一张蜘蛛网。并且更加恐怖的是，有效桥２米宽，有些桥４米宽。当你开着卡车时你根本不知道走哪座桥才安全到达目的地，这样造成的结果就是又造了一座卡车开的过去的桥……

 

统一的造桥标准

后来民间组织了一个叫“桥路协会”的组织，他们制定了一套桥梁的标准（系统之间沟通的标准）。好比星巴克天天喊“我们卖的不是咖啡，是文化”一样，这个协会打着“我们卖的不是桥，是回家的服务”的旗号，把这个标准成为ＳＯＡ。即无论你怎么使用材料造桥，只要你符合在统一的宽度，高度＂就可以。

ＳＯＡ就是一种设计的模型想法，它的最终目的就是减少在系统间重复沟通（同时存在Ａ－＞Ｃ，Ａ－＞Ｂ，Ｂ－＞Ｃ这样的链路），减少维护和在这体系中安插新组建的想法。可以说有点淡化各个子系统，强化整体母系统的趋势。认为子系统只是向母系统提供一种特定的“服务”。同时如果按照系统新的服务进来，也不会对现的体系造成太大的影响。

ＳＯＡ只是一个又被包装的老感念，诚然现在主流的ＳＯＡ的实现都是ＪＡＶＡ和Ｃ＃通过ＷＥＢ实现的，但是ＳＯＡ肯定不只是ＷＥＢ实现，因为在没有Ｊａｖａ的年代，Cobra也是一种SOA思想的体现即与实现平台、语言无关。有统计的接口规范。

 

立交桥

古代的桥在同一个平面内最多存在一座桥。但是科技发达后，立交桥就被发明出来了。EAI/ESB的概念就在这个时代被提了出来。

这里要提一下EAI，我一直认为EAI的核心是消息转换、消息派发。

经典的EAI的拓扑有两种

一种是HUB模式，即所有的消息都集中到HUB在转发至目的地。

另一种是总线模式，所有应用平等的接入在骨干上进行点对点的通讯。

 

似乎这几年的趋势是在往总线拓扑发展。但是与SOA的核心价值相同的，其目的也是想找出一套统一的沟通模型让不同的结构、平台、语言的应用系统可以更好的利用现有资源，而不是重新再造一套出来。节约开发和维护成本。重点就在“集成”上。

 

再说说ESB，这个真是一个新名词。

ESB好似被新一代SOA概念一起提出来的。但是其核心价值不外乎“更容易、便宜地进行系统集成”。我不正确的解读ESB是一种为了SOA方案产生的平台产品。

 

那些又是什么

松耦合，紧耦合

举个例子，为了达到一个目的总有许多种解决方案，比如穿裤子和袜子。

有一个方案A是穿连裤袜，另一个方案B是穿袜子和裤子。

相对方案B来说，A就是紧耦合，因为你想换袜子必须把裤子一起换了。

但是A的优点也很明显，价格便宜，一次实施。

因为方案B你还要考虑是不是黑色的裤子是不是不能穿白色袜子的问题……