2. 需要解决的问题
如上节所述经过分析,我们理解了传统方式开发应用集成项目的问题所在。透彻的分析问题,归纳出本质的需求相当于解决了一半的问题。以逻辑的视角来抽象问题,其实很多复杂系统平台的基本原理都是简单的。当开发应用集成项目时,为了避免多种多样的接口和数据带来的不便,一个很自然的解决方法就是统一接口和数据。我们需要有一个EAI平台来做以下几件事情。
(1) 提供松耦合的统一的跨平台跨计算机语言的接口技术方式, 接口发现和调用规范。
(2) 提供一个统一的数据类型定义,结构数据的数据格式,行业内的数据语义。
(3) 非计算机编程的流程快速实现方式。
怎么样实现这些功能,提供一个EAI的设计开发运行平台呢?我们使用现有的技术来打造一个先进的解决方案。
第一个任务,提供松耦合的统一的接口技术方式,接口发现和调用规范。表2列出了几种互联接口方式。从现在的眼光来看, 基于消息中间件方式的服务调用接口自然是最佳选择,其好处在于:
(1) 提供高复用性的功能接口调用。
(2) 提供远程接口调用方式。
(3) 消息中间件的调用请求及结果传输方式, 在传输层解耦服务提供者和服务调用者。
(4) 统一的服务接口描述协议,服务注册和发现协议,服务调用协议等。其中所有数据使用XML表示,跨平台跨计算机语言。
(5) 灵活的服务发现调用规范,服务路由规范解耦服务提供者和服务调用者的端对端绑定关系。
说点题外话,概括一下消息中间件的功能。
表4 消息中间件的功能
功能 |
消息异步传输,消息发送接收方应用解耦 |
消息持久化机制,支持断点续传 |
消息可靠性保障,不丢失,不重复 |
|
第二个任务,提供统一的数据类型定义,结构数据的数据格式,行业内的数据语义。XML技术就可以解决前两个需求,XML有自己的数据基本类型定义,使用 作为分隔符号,用字符来表述树形结构化的数据。现在越来越多的行业数据协议解决了第三个需求,这些行业内部的数据语义定义规范一般都支持XML数据格式,如ebXML, FIXML。XML加行业数据模型是第二个任务最佳的解决方案。 如果已有系统数目为n, 现在需要做的数据转换的次数只是n次,比之前少了一个数量级。系统间不再需要做两两之间的数据转化,只需把数据转换为统一的格式和语义定义模型,在另一个地方把这些数据转化为另一个系统的数据格式和数据语义即可。
一二加起来,就是现在常用的一种遗留系统接入手段,即将已有系统封装为服务,对外提供标准的服务接口,数据使用XML格式的行业数据模型来定义。在服务内部完成系统私有的数据格式和语义到标准的数据格式和语义之间的双向转换。
第三个任务,有了封装好的服务之后,剩下的事情就是根据业务流程需求,利用服务作为业务活动最小粒度单元来编排实现流程。我们选用BPEL来实现服务的编排,完成业务流程。BPEL工具的通常工作方式是使用图形化设计时工具编排流程,BPEL流程配置保存为XML文件,运行时由BPEL引擎来执行流程。
图2 使用最新技术的EAI解决方案
https://p-blog.csdn.net/images/p_blog_csdn_net/zlushangnwpu/EntryImages/20080729/EAI1.jpg
使用新的EAI解决方案完成以前相同的开发任务,复杂性大大降低。先将系统1,2,3的接口封装为标准服务接口,在服务内部完成系统1,2,3到标准的双向数据转换。流程开发者非常方便的基于服务编排实现流程。
概括一下我们的EAI解决方案包括标准服务接口Web Service , XML+行业数据模型规范,BPEL。 底层是封装已有系统的服务,再基于服务编排实现新的业务流程。这个使用最新技术构建的EAI应用架构同时也是一种SOA的企业应用架构。 事实上,SOA作为企业分布式应用的一种开发思想,强调企业应用由分散的高复用性的服务构建而成,新的业务需求不需要重头开发,只需要使用现有服务进行编排实现即可。而服务构建时对遗留系统的接入就是EAI。 可以说EAI是SOA企业应用范畴内的一个重要构成部分。
图3 SOA企业应用系统架构
https://p-blog.csdn.net/images/p_blog_csdn_net/zlushangnwpu/EntryImages/20080729/EAI2.jpg
Apps |
业务流程管理 |
企业服务总线
|
Service |
Service |
Service |
Service |
Service |
Apps |
Apps |
Apps |
Apps |
Apps |
|
|
Process |
Process |
Process |
Service |
上层是业务流程 中间是各种服务 底层为已有系统 |