EDA和SOA的融合以及实践

在 SOA 实践中，尤其强调业务为先的原则，因为我们必须先进行业务流程的整合重组，然后才是 IT 系统的服务化。业务流程本身的问题还是需要从业务本身去解决，再好的技术也解决不了业务的问题。试想一下，如果一个企业各个部门之间各自为战，缺乏协作和沟通，那么可能开发出一个好的面向服务的 IT 系统吗？

除了业务部门的努力外，IT 部门在做任何架构设计的决定前，必须确保理解清楚了业务部门的具体需求。所以说，项目前期 IT 部门和业务部门之间的协作和交流非常重要。

这里很容易有一个误区，尤其是对那些经验丰富的架构师。他们往往拥有丰富的 IT 经验和业务知识，自认为已经非常了解业务部门的需求，甚至有些时候都能够指导业务部门如何去改进。在这种自负的情绪中，他们觉得可以先把所谓先进的 IT 系统开发出来，然后再去推广，他们认为用户肯定会欣然接受这些系统，因为他们代表着先进的理念，但往往事与愿违。姑且不去深究究竟孰对孰错，退一万步讲，一个没有充分听取用户意见，没有用户参与的系统能够那么容易得到用户的认可吗？即便你是对的。

互联互通

在 Event-Driven SOA 的实施过程中，有几个关键指标：服务的分类和创建，事件的定义和管理，服务的互联互通，业务流程的理解和 IT 实现等。那我们应该更加关注哪个指标呢？因为我们往往很难一下子兼顾所有的指标。个人认为这其中最重要的就是服务的互通互联。当然这里所讲的互通互联并没有那么简单，并不是仅仅建立起通讯的通道就可以，它包括以下几个方面的内容：

无论通讯的方式如何，最好做到自动化

实现通讯的方式有很多种：同步调用，异步消息，Socket 甚至是文件，无论采用哪种，最好做到自动化的实现。任何人工的干预都容易引起错误和延迟。

通讯的双方之间需要定义清晰的接口，有共同的异常应对机制

特别是当通讯的双方是由不同的开发团队来完成，一定要在开始阶段就定义清楚接口，并在随后的开发过程中严格遵守，同时保持实时的沟通。这里面需要强调的一点就是异常的应对机制，要让双方都充分理解可能面对的异常情况及应对措施。

基础数据的共享

在金融系统中，会用到大量的基础数据（一般称之为 Reference Data），这些数据在各个系统都会用到。但事实上情况往往并不如此，经常是各个系统各自为战，不用或者是使用不同的数据源，导致在通讯过程中的识别歧义。

做到以上这些，技术上并不困难，更重要的是项目之间的协作和执行力强的领导团队。

结合到实际的例子，比如美国三军联合作战系统，其核心就是其“数据链”系统，它使得战场上的指挥中心、作战部队和武器平台能够实时交换数据，达到精确协作的目的。从下面这段描述我们就能感受到这种高效无缝协作的威力：

“在 7 年之后的海湾战争中，初级的“数据链”就已显威战场。以美军拦截导弹作战为例，就可以看到“数据链”的作用。伊军的“飞毛腿”导弹一发射，12 秒钟之后，位于太平洋上空的美国防支援计划（DSP）的导弹预警卫星就发现了“飞毛腿”，并迅速测出它的航行轨道及预定着陆地区，报警信息及有关数据迅速传递到位于澳大利亚的美国航天司令部的一个数据处理中心，数据中心的巨型计算机紧急处理这些数据之后，得到对“飞毛腿”导弹进行有效拦截的参数，然后航天司令部将这些参数通过卫星传给位于沙特阿拉伯的“爱国者”防空导弹指挥中心。防空导弹指挥中心立刻将数据装填到“爱国者”导弹上并发射，整个过程只需要 3 分钟左右的时间，而“飞毛腿”至少要飞行 4 ～ 5 分钟才能到达预定目标的上空，这就为拦截导弹创造了条件。…”

设计考虑

在明确了以上这些设计原则外， 我们需要一步步考虑整个架构的实现途径。首先面临的就是一些基础架构的选择。

基础架构的选择

在这里我们需要回答一系列的问题：自己开发还是购买？开源的还是商业的？选择什么 Web Service 的基础平台？选择什么样的消息中间件（Message Oriented_middleware， MOM）？是否采用企业服务总线（Enterprise Service Bus， ESB）？

这其中讨论的最多的就是是否以及如何使用 ESB。个人观点，ESB 是有价值的，仅当系统确实需要 ESB 的功能时。Accenture 首席技术官 Don Rippert 在他的一次早期访谈中提到发挥 SOA 的全部潜力大致需要以下 4 个步骤：

开始采用 SOA 架构，使用 XML 等标准的方式来使用应用程序接口

捕获一些业务过程，并将它们转化为 Web 服务

引入并全面使用企业服务总线

将业务过程执行语言（Business Process _execution Language， BPEL）集成进来，利用业务过程建模工具和 BPEL 可以创建不同的应用行为，而无需修改软件

为什么将 ESB 的使用放在第三个步骤呢，那我们需要从 ESB 的定义入手，来了解 ESB 究竟带给我们些什么。ESB 应该被理解为模式而不是产品，它应该至少具备以下这些功能：

服务的虚拟化，支持虚拟化通讯参与方之间的服务交互并对其进行管理。意思就是服务只需要关注完成自己的功能，不需要关心哪个服务调用它以及它需要调用哪个服务。

服务的转化、包装以及桥接

消息的传递、过滤以及路由

服务编制（Orchestration）

还记得前面将 EDA/SOA 和人体进行类比的例子吗？如果按照该思路，ESB 就可以看作是人体的中枢神经系统。其接受眼睛传入的“狮子来了”的信息，整体加工后成为协调的运动性传出，手脚也就开始动作了。