从EAI到SOA

2005年至今任职北京长城计算机软件与系统有限公司，任公司技术总监，负责公司技术团队的日常管理、公司技术核心能力建设、信用行业市场开拓方面的工作。

说到SOA，不能不说到EAI。我们不妨把专业的概念抛到一边，从常识的角度来认识一下问题的本质。事实上，我们实施EAI项目，它的目标无外乎包含下面几个:

各个分离的信息系统的实现互联互通，消除信息孤岛，实现信息的共享;

在EAI平台上，把各个信息系统的对外提供的应用处理程序接口统一地封装起来，这样的好处是以后有其他的客户端再需要接入时，可以统一地从EAI接口接入，接入的协议也是标准的;

把各个系统的接口进行组合，这样可以得到新的应用功能。

然而，在实施EAI平台的项目里，最困难的恐怕就是处理与各种各样后台系统的接口了，而众多的EAI项目的失败几乎都是因为后台系统的复杂性而导致的。现在，似乎还没有一个EAI产品理想地解决了对后台系统统一接入的问题。

其实，在这里我们可以分析一下问题的本质性因素。在系统整合方面的项目里，我们发现一个有趣的现象，就是服务提供方的甲方优势现象。通常，你要和一个系统去连接，如果我们是这项工作的发起者，那么往往意味着在技术实现上，我们是这个体系的请求者，也就是客户端，我们要把我们的请求发送到对方系统，在那里被对方接受、处理，再返回给我们。在实施时，我们面临的最大问题就是甲方，也就是服务的提供方是否会和我们和谐地配合工作。这里的工作既包含双方协议标准的约定、客户端的连接方式，同时还包含对方是否会在你需要的时候开启网络的端口、启动服务程序，和我们一起做联调测试等等方面的问题。这种情况下，EAI项目组实际是处于一个乙方地位，服务方掌控着自己的资源，他们会把这些资源看成是昂贵的财产，政治的因素在这里起着很强的作用，我们一厢情愿地呼叫着芝麻开门，但是我们面对的那扇大门可不会那么轻易地打开。

这时SOA的概念就出现了，在开放的互联网世界里，我们对这些后台系统的封装需要一种标准，大家都按照统一的标准来封装自己的接口，使得任何一个客户端可以和后台系统方便地实施连接。而这种接口，现在通常的做法是包装成为一个个服务程序，并且以一个标准协议对外，例如Web Service等等。这种情况导致的直接后果，就是EAI项目的实施被大大简化了，至少技术的问题已经不能成为某些政治因素的借口。这时，EAI项目的前面两个目标几乎已经被迎刃而解，而突出的问题将会集中在最后一个目标的实现上。

基于第三个目标，EAI平台的实施在应用目标上已经从一个技术接口的组装平台、信息交换平台转变为一个企业核心业务之外的增值业务平台，而企业在基础的核心业务上的创新业务往往可以在这个平台上方便地实现。在SOA时代，我们的目光应该逐步地把技术层面的系统联通、信息共享，转变为业务开发和产品创新上来，对这些理念的支持则成为SOA时代的EAI平台的核心内容。