1  概述

　　企业服务总线（Enterprise Service Bus，缩写 ESB），是SOA面向服务架构的骨干，在完成服务的接入、服务间的通信和交互基础上，提供安全性、可靠性、 高性能的服务能力保障。采用 SOA 架构，基于ESB总线进行企业异构应用集成，可以有效降低应用系统、各个组件及相关技术的耦合度，消除应用系统点对点集成瓶颈，降低集成开发难度，提高复用，增进系统开发和运行效率，便于业务系统灵活重构、敏捷适应业务及流程变化。

　　本文对企业服务总线ESB集成项目中，基于AEAI ESB实现异构系统集成的相关规范、标准进行阐述、明确，为项目开展以及后续完善扩展提供技术参考和依据。

2  功能特点

　　AEAI ESB作为数通畅联公司的企业应用集成产品，主要用来实现异构系统（如：不同的数据库、消息中间件、ERP或CRM等）之间的资源整合，实现互连互通、数据共享、业务流程协调统一等功能，构建灵活可扩展的分布式企业应用。

　　相比传统的企业应用集成软件平台，AEAI ESB是一个全新的符合SOA架构的应用服务整合平台，是基于大量集成实践经验不断完善、用于构建可管理、可扩展及经济高效的EAI技术解决方案。

图1.基于AEAI ESB总线的企业应用集成模式

　　AEAI ESB提供了从企业应用集成的设计、开发、部署，到运行、管理、监控各个生命周期阶段的工具。它提供的图形化、拖拽式开发方式，可以快速创建可扩展不同类型的数据（应用）集成流程，并全面支持服务及服务常用形式Web Service，简化了服务的创建与封装，并能够使用户灵活地编排服务，以满足不断变化地业务需要和业务处理流程。

　　AEAI ESB基于JavaEE体系构建，主要包含三个模块：服务器ESBServer、设计器ESBDesigner、管理控制中心。ESBServer是AEAI ESB的运行环境，管理控制中心则是部署在ESBServer的Java Web应用，基于开发平台构建的。ESBDesigner是基于Eclipse Plugin开发的图形化、拖拽式的设计Web服务、消息流程的构建工具。AEAI ESB主要功能及特点如下：

• 基于开放标准，高度可扩展

　　AEAI ESB的技术架构及实现基于开放式标准，支持SOAP、WSDL等规范，基于开放式标准如：SOAP、JDBC、JMS、JavaWS、JavaMail、Http等，便于系统迁移以及将来扩展。

• 支持企业级服务质量

　　支持的企业级服务质量，包括消息安全、失败恢复、状态诊断、服务管理、服务审计及消息可靠传输、事务的完整性等，提供数据交换过程和数据的跟踪能力。

• 提供数据格式转换功能

　　提供图形可视化的异构数据格式转换映射工具，能够将数据从一种格式简便快速地转换成另一种格式。输入数据和输出数据可进行不同格式间的转换,从而可快速集成异构应用。

• 支持多种服务/组件通讯方式

　　支持多种服务/组件通讯方式，如同步和异步等，用户可以按照自己的需要，灵活定义通讯方式。

• 提供对Web Service的完整支持

　　既支持不同外系统提供的Web Service访问、服务代理接入，又能够将现有业务应用封装成Web Service供复用。支持Web Service常用标准协议，如SOAP、WSDL等，同时支持Web服务的编排及不同粒度的服务封装，便于创建松耦合及可复用的面向服务架构

• 监控与管理

　　提供了基于浏览器的管理控制台，能够对监控节点、服务、组件及业务流程进行状态查询和监控管理。对监控、跟踪和日志具有平台级的支持,还提供远程跟踪调试功能。

• 支持集中管理及分布部署

　　支持分布式应用及部署，开发的服务、组件及业务流程，可以分布式部署到网络上的多个逻辑节点，实现分布式运算和应用，支持水平以及垂直扩展，满足性能扩展需要。支持远程增量部署，大大降低部署成本。

3  数据标准

3.1  信息采集规范

　　数据总线平台的建设与应用并非是不关注业务，数据的随意流通。数据交换需要规范业务系统间交换的属性。信息采集规范就是指规范业务系统数据采集交换的方式、频率、加工策略等规范。例如：哪些业务系统的哪些数据要实现实时交换、哪些是触发交换；采集的数据是全量、增量还是根据某些条件进行交换；是通过数据库采集、文件采集还是服务获取等。

3.2  数据内容规范

　　数据内容规范指数据交换过程中数据清洗、转换的标准。要制定重复数据的基准、数据转换的基准、清洗的规则、共享的方式。例如:不同单位的业务系统可能存在对某段同样语义的描述信息，但是因业务系统开发商不同导致其信息存储的格式和内容会有区别，再其他业务系统需要这条数据的时候，此数据应该从哪个业务系统获取，或者是获取出来进行比对、分析、处理之后再交换到其他业务系统。

3.3  数据维护规范

　　数据交换的需求可能是多种多样，包括临时的需求和长期的需求。长期需求可能是建立综合数据库、数据中心或是把A系统业务库中的数据长期交换到B系统的业务库中，因此需要制定数据维护的标准，定义不同系统的不同业务数据采用数据维护的方式。

　　例如：财务系统业务数据要保留交换的历史数据，且采用时间戳的方式增量维护；OA系统业务数据仅保留3个月的数据，且采用触发器的方式交换；人力资源业务数据采用主动到数据源端抓取业务数据的方式维护自身业务数据等等。

4  标准规范

4.1  集成开发规范

1. 创建工程按照集成需求业务进行划分，格式为“公司名”+“产品”+”业务名”，例如：AeaiESBHr、AeaiESBCrm
2. 工程下的目录按照服务提供方（系统）进行划分，如果只有相同的服务提供方，也需要创建目录进行划分；
3. 流程名采用匈牙利命名法（在几个字母联合的时候，首字母大写，如HR系统提供数据到门户：HRDataToPortal），编码长度不能超过20个字母；
4. 所有的消息流程填写中文别名和描述，描述一定要写清楚具体含义。
5. ESB集成项目主包名：com.agileai.esb；
6. 公共代码直接放在com.agileai. esb目录下，其他代码采用ESB默认生成的包名以及类名。

4.2  WEB服务规范

　　应用/数据接口以WebService方式进行发布，采用Http通讯协议进行同步通讯，AEAI ESB服务代理支持SOAP 1.1、SOAP 1.2访问协议，AEAI ESB的开发Web服务默认支持SOAP1.1，对于Web服务报文信息字段要求如下：

1. 各字段若无特别说明均为字符串型；
2. 日期字段默认格式为“yyyy-MM-dd”，如：2015-05-14；
3. 时间字段默认格式为“HH:mm:ss”，如16:25:16；
4. 报文头信息具有默认结构，允许自定义报文头。

　　不论是在AEAI ESB中注册的服务代理还是AEAI ESB中发布的服务都支持：用户、密码认证以及扩展认证模式，同时提供服务监控、服务调用统计功能，同时支持业务日志。

4.3     AEAI ESB开发规范

　　本项目中在AEAI ESB中开发的服务主要为Web Service、Http、Timer三种方式的服务，各单位内部及下属各单位的业务系统既有的Web服务，在AEAI ESB中注册服务代理方式，AEAI ESB提供消息转发、服务监控、服务统计、以及服务认证和业务日志功能。

4.3.1  服务代理注册

首先，登陆ESB管理控制台

选择需要添加服务代理的工程，选择服务代理标签

点击新增，进行WEB服务注册代理

将需要进行代理的服务URL添加到对应位置（1），点击解析按钮进行服务代理注册（2），添加认证类型（无认证，用户密码，扩展流程）（3），添加是否启用业务日志（4）

在提供的ws服务中，service的name需要通过业务功能来命名，不能重复

4.3.2  开发WEB服务

　　对于既有系统不能提供Web服务接口的应用系统，且需要Web服务方式来集成，或者需要对既有的Web服务实现服务编排重组，可以在AEAI ESB开发Web服务。

1. 如果涉及到数据读取，需要对应系统管理员提供提供数据视图、字段说明、以及数据库连接方式；
2. 如果涉及到数据写入，需要对应系统管理员提供中间表以及存储过程，ESB理论上不直接访问实际的业务表；
3. 如果涉及到服务编排，需要对应系统管理员提供Web服务的SOAP调用样例，请求和响应参数说明。

4.3.3  开发HTTP服务

　　根据服务提供方提供的数据库交互方式（视图查询、存储过程）进行Http流程的开发

1. 提供数据库连接信息，如账号密码及地址等（Oracle数据库还需要提供SID），登陆ESB管理控制台对数据库资源进行注册管理；

1. 服务提供方需提供存储过程或相关的查询SQL语句；
2. Http流程的返回值为JSON或者XML格式（需要就实际业务进行选择），调用方自行解析。

4.3.4  开发Timer服务

　　根据当前的轮询方式，在AEAI ESB上改造为Timer流程：

1. 服务系统管理员提供当前的轮询策略（定时、间隔、自定义）；
2. 提供数据库连接信息，如账号密码及地址等（Oracle数据库还需要提供SID），登陆ESB管理控制台对数据库资源进行注册管理；
3. 提供查询全量数据还是增量数据，查询增量数据时的条件；

4.4  AEAI ESB测试规范

4.4.1  单元测试

　　单元测试由流程开发者自己来完成，单元测试是对完成一条流程后的最基本检查，主要是用来检测逻辑否正确，程序代码是否正确， 组件节点命名是否按照规则，实例正确生成、以及字段和变量的拼写错误，还包括所引用资源是否可以等细节。

　　单元测试的依据是测试规格说明书，单元测试的目的是对流程功能基本验证，该测试用来确定执行结果否符合预期，单元自测以持续执行3次均成功方验证为成功。

4.4.2  结对互测

　　当局者迷，旁观清。两个开发人员具有相同的缺点和盲可能性很小，当采用结对互测试的时候会获得一个强大解决方案 ，能更快的发现并解决问题 。结对互测准确来说是一个测试方法，而不是其中的具体环节。

　　结对互测是指两个流程开发人员相测试对方的流程，结对互测的基础已完成开发人员已完成单元测试。

4.4.3  集成测试

　　大多数流程之间不是独立的，而有关联。多个流程的执行才是真实的逻辑业务， 所以在有流程完成单元测试后，需要按照业务子系统对多个流程进行连贯的集成测试，用来发现执时是否可以满足实际业务的需要。

　　集成测试可以根据实际业务模块或者子系统，来各自独立进行。集成测试用来发现多个流程协作执行时产生的潜在问题，这其中包括流程数据业务一致性和稳定性等。

4.4.4  业务联测

　　业务模拟测试时在集成之后进行的，当各个子系统的对应流程进行了集成 测试并通过后，可以进行完整系统的业务模拟测试。通常业务联测需要业务人员的参与和协作，在系统试运行初期进行。

　　业务模拟测试是所有流程的完整，各个被集成子系统和数据库都以正常模 拟数据进行测试。此时AEAI ESB集成平台对用户来说是透明的，所有数据都通过业务人员在各自系统上进行模拟操作获取 。

企业服务总线项目集成标准（V1.5）