我的EAI解决方案

我的EAI解决方案

前面写了一系列的EAI解决方案的文章，写了EAI解决方案的思路。熟读唐诗三百首，不会作诗也会吟。基于自己看到的需求，看到的已有EAI解决方案的优缺点，也来构建一个自己的EAI解决方案，权当是山寨版，自娱自乐。

在文章http://blog.csdn.net/zlushangnwpu/archive/2008/11/04/3213850.aspx中列出了EAI平台需要提供的主要功能：

a)定义了中间层数据类型，数据格式，接口规范，接口通信方式和通信协议。

b)平台去做已有系统和中间层之间的数据格式转换。

c)对已有系统接口的封装，提供统一的接口。

d)使用图形工具进行流程编排，编写数据转换和映射规则。由EAI平台引擎来执行。

针对这些的功能， 和已有EAI解决方案相同的实现就不描述了。我的解决方案的不同之处在于：

1. 定义两套语义相同，格式不同的中间层数据接口协议。 一套采用基于XML的实现，即数据格式用XML, 数据定义用XSD，接口定义用WSDL，接口调用协议用SOAP；同时定义另一套基于二进制流或者字符流的数据接口协议，和第一套规范语义完全一样。对比基于XML的实现，节省时间空间消耗。

2. 在集成流程的程序实现中， 也有两套数据和调用对象的实现。一套是自解释形式的数据和调用对象的实现：数据实例的类（Data Instance）和接口调用的类（Operation）关联相应的数据接口定义类 (Class Description )；另一套是简单形式的数据和调用对象实现：普通的Java Object , Java method，利于节省集成流程程序的时间空间开销。但是需要代码生成工具来根据用户定义的数据和接口，生成大量的Java Object , Java method代码。

3. 封装已有系统接口， 实现已有系统和中间层之间的数据转换的适配器，对外提供程序API接口， 而不是通过图形化组件配置的方式来使用。可以提供Java , C++两种语言接口。 这样做的原因是图形化组件的使用方式限制太多， 不能灵活控制。

4. 不使用图形工具来实现流程编排，将集成流程的实现，流程中的数据映射完全交给集成应用开发者选用Java 或者C++语言来编程实现。 集成流程实现程序可以调用适配器的API来调用已有系统的接口。之前http://blog.csdn.net/zlushangnwpu/archive/2009/01/11/3754599.aspx中提到流程编排和驱动工具使用图形式语言描述流程的实现。这种流程描述语法比较简单，不如程序语言功能丰富，没有虚函数重载机制，不能更好地封装和复用公共的功能。没有成熟的第三方库，做任何工作都要从头自己开发。并且图形化的流程编排，处理逻辑分散在各个组件的配置页面中，对于应用开发者来说很难维护。

5. 已有的EAI解决方案里的适配器产品， 多是适配一些标准技术，国外比较通用的软件产品和系统， 但对国内的技术标准，行业标准和产品系统很少支持，例如国内银行常用的中国银行现代化支付系统CNAPS协议。其实如果目标系统提供了程序API， 再去适配价值不是很大， 适配器的主要目标应该是那些没有程序API的技术和系统，例如基于TCP Socket的各种行业通信和数据协议。

概括一下， 这个EAI解决方案是提供了一批有程序API的适配器组件，适配器的API遵循标准统一的数据和接口定义规范。这些组件不独立运行，由EAI应用开发者编程调用来实现集成流程。适配器主要针对一些没有程序接口，只有通信和数据协议的产品和系统。

 

总的来说， 这个方案取了现有方案的里，即有一套统一的数据接口定义规范和实现。而舍了现有方案的表，即图形化的适配器组件配置使用，和图形化的流程编排实现。之前和一家做银行代缴费业务的系统集成商接触，介绍几种EAI产品，没被采用。除了价格原因， 客户需要能连银联接口， 电信，电力缴费接口的适配器，而那些EAI产品没有。那些产品有的大量的连接通用技术和系统的适配器，人家不需要或者自己用代码实现也不复杂。客户需要很灵活地管理和多个已有系统的TCP连接， 而那些EAI产品里图形化方式使用的TCP组件，使用时限制很多， 不能满足客户需求。也参与过一些EAI项目的实施， 对于比较复杂的集成流程，使用图形化编排的实现方式很不灵活，经常实现很多个彼此差异很小的流程， 却不能把相同的逻辑抽取出来封装成可被调用的流程。

感觉图形化的EAI方案更适合需要连接大量比较标准的技术， 比较通用的软件和系统，且集成流程简单的场景。所以在投标时很有用，做POC是最佳选择，貌似功能强大，开发方便快捷。运行的时候，在界面上可以看到一条绿线在流程中流动，比较适合甲方领导。对于国内大部分的EAI产品提供商，与其拼着自己不多的实力去追赶国外厂商大而全，有漂亮图形工具的EAI产品， 不如做些国内集成商非常需要的行业协议适配器。

和SCA的思路类似， 我的方案只定义数据和接口，完成异构数据接口之间的转换，把实现留给开发者自己。个人观点，不知对错，仅供参考。有兴趣设计实现一个EAI方案的同仁，可以联系我，多交流讨论。：）