应用场景分析之事务
之前的文章反复论述过EAI平台适用的场景。已有的复杂业务系统已经实现,每个系统都有自己的数据接口定义。新的需求或者是在这些系统之间同步数据,或者是一个新业务流程需要调用多个已有系统的功能。简单的开发过程如下:
a) 统计新业务需要连接的技术,软件和系统的接口。对照EAI平台提供的Adapter(包括Business Works里的简单功能组件)是否都能够支持这些接口。如果EAI平台不支持,需要开发新的Adapter。
b) 适配器完成的只是对已有系统接口的封装,在已有系统和Business Works流程间做数据格式转换。在业务数据内容层,需要由EAI应用开发者分析各个系统上的数据语义模型,归纳概括出适用于整个应用系统范围内的数据语义模型,即业务数据的Schema。EAI应用开发者还可以直接使用一些行业标准,如FIXML。
c) 分析新的业务流程逻辑,进行流程层次模块划分,把具体模块对应于具体的Business Works的流程。决定各个流程的功能和粒度,流程互联方式,整个应用的部署方案。
见文章http://blog.csdn.net/zlushangnwpu/archive/2008/09/21/2957425.aspx
在企业应用范畴内,事务和集群是两个非常重要的主题。下面来看EAI应用和EAI平台中关于事务和集群的技术内容。
事务。EAI应用跨多个已有的软件或系统, 这些已有的软件和系统构成分布式的结构,EAI应用支持的事务自然是分布式事务,是支持两阶段提交的XA事务。TIBCO的EAI平台支持XA事务,有自己的TM(Transaction Manager)实现TIBCO Business Works XA Transaction Manager,也支持其他第三方的TM实现。Business Works中的组件和Adapter作为其他软件或者系统的接口数据适配器,本身没有功能处理逻辑,没有事务处理逻辑,只是在集成流程和其他软件或者系统之间透传数据和接口调用。如果这些被封装接口的软件或者系统支持XA规范,实现RM(Resource Manager)接口,那Business Works中的组件和Adapter一样可以实现RM接口。所以可以把Business Works中的组件和Adapter及其身后的软件或者系统看作一体,看作一个RM。
Business Works中的JDBC组件, JMS组件都支持XA RM接口。不过Adapter产品多数没有实现XA RM接口,这是一个欠缺。
使用TIBCO EAI平台实现XA事务示意图如下: