1 Overview
Enterprise Service Bus (ESB for short) is the backbone of SOA service-oriented architecture. It provides security, reliability, and high-performance service capability guarantee on the basis of completing service access, inter-service communication and interaction. Adopting SOA architecture and integrating enterprise heterogeneous applications based on ESB bus can effectively reduce the coupling degree of application systems, various components and related technologies, eliminate the bottleneck of point-to-point integration of application systems, reduce the difficulty of integration development, improve reuse, and improve system development and operation. Efficiency facilitates flexible reconstruction of business systems and agile adaptation to business and process changes.
This paper expounds and clarifies the relevant specifications and standards of heterogeneous system integration based on AEAI ESB in the enterprise service bus ESB integration project, and provides technical reference and basis for project development and subsequent improvement and expansion.
2 Features
AEAI ESB, as an enterprise application integration product of Shutong Changlian, is mainly used to realize resource integration between heterogeneous systems (such as different databases, message middleware, ERP or CRM, etc.), to achieve interconnection, data sharing, Business process coordination and unification and other functions to build flexible and scalable distributed enterprise applications.
Compared with the traditional enterprise application integration software platform, AEAI ESB is a brand-new application service integration platform that conforms to SOA architecture. .
Figure 1. Enterprise application integration mode based on AEAI ESB bus
AEAI ESB provides tools for enterprise application integration design, development, deployment, operation, management, and monitoring of various life cycle stages. It provides a graphical and drag-and-drop development method, which can quickly create and expand different types of data (application) integration processes, and fully supports services and web services commonly used in services, which simplifies the creation and encapsulation of services, and enables users to Flexible orchestration of services to meet changing business needs and business processes.
AEAI ESB is built on the basis of JavaEE system and mainly includes three modules: server ESBServer, designer ESBDesigner, and management control center. ESBServer is the running environment of AEAI ESB, and the management control center is a Java Web application deployed on ESBServer, built on the development platform. ESBDesigner is a graphical, drag-and-drop design web service and message flow construction tool based on Eclipse Plugin. The main functions and features of AEAI ESB are as follows:
- Based on open standards, highly scalable
The technical architecture and implementation of AEAI ESB are based on open standards, support SOAP, WSDL and other specifications, based on open standards such as: SOAP, JDBC, JMS, JavaWS, JavaMail, Http, etc., which is convenient for system migration and future expansion.
- Support enterprise-level quality of service
Supported enterprise-level service quality, including message security, failure recovery, status diagnosis, service management, service auditing, reliable message transmission, transaction integrity, etc., provides data exchange process and data tracking capabilities.
- Provide data format conversion function
Provides a graphical visualization of heterogeneous data format conversion mapping tools, which can easily and quickly convert data from one format to another. Input data and output data can be converted between different formats, so that heterogeneous applications can be quickly integrated.
- Supports multiple service/component communication methods
Support a variety of service/component communication methods, such as synchronous and asynchronous, users can flexibly define communication methods according to their own needs.
- Provides full support for Web Services
It not only supports Web Service access and service proxy access provided by different external systems, but also encapsulates existing business applications into Web Services for reuse. Supports common standard protocols for Web Services, such as SOAP, WSDL, etc., and supports the orchestration of Web services and service encapsulation of different granularities, which is convenient for creating loosely coupled and reusable service-oriented architectures
- Monitoring and Management
A browser-based management console is provided, which enables status query and monitoring management of monitoring nodes, services, components and business processes. It has platform-level support for monitoring, tracing and logging, and also provides remote trace debugging capabilities.
- Support centralized management and distributed deployment
It supports distributed applications and deployment. The developed services, components and business processes can be distributed and deployed to multiple logical nodes on the network to realize distributed computing and applications, support horizontal and vertical expansion, and meet performance expansion needs. Support remote incremental deployment, greatly reducing deployment costs.
3 Data Standards
3.1 Information Collection Specifications
The construction and application of the data bus platform is not about the random flow of data without paying attention to business. Data exchange needs to standardize the attributes exchanged between business systems. Information collection specification refers to the specification of the method, frequency, processing strategy and other specifications of the data collection and exchange of the business system. For example: which data of which business systems need to be exchanged in real time and which are triggered exchange; whether the collected data is exchanged in full, incremental or according to certain conditions; whether it is collected through database, file collection or service acquisition, etc.
3.2 Data Content Specification
Data content specification refers to the standard of data cleaning and conversion in the process of data exchange. It is necessary to formulate benchmarks for duplicate data, benchmarks for data transformation, rules for cleaning, and ways to share. For example, the business systems of different units may have description information for a certain segment of the same semantics, but the format and content of the information storage will be different due to different business system developers. When other business systems need this data, this data Which business system should it be obtained from, or obtained for comparison, analysis, and processing, and then exchanged to other business systems.
3.3 Data Maintenance Specifications
The needs of data exchange may be varied, including temporary needs and long-term needs. The long-term requirement may be to establish a comprehensive database, data center, or to exchange the data in the business database of system A to the business database of system B for a long time. Therefore, it is necessary to formulate data maintenance standards and define the way of data maintenance for different business data of different systems. .
For example: the business data of the financial system should retain the exchanged historical data, and incrementally maintain it by means of timestamps; the business data of the OA system should only retain the data for 3 months, and it should be exchanged in the form of triggers; The way the data source captures business data maintains its own business data, etc.
4 Standard Specifications
4.1 Integrated Development Specification
- The creation project is divided according to the integration requirement business, the format is "company name" + "product" + "business name", for example: AeaiESBHr, AeaiESBCrm
- The directory under the project is divided according to the service provider (system). If there is only the same service provider, a directory needs to be created for division;
- The process name adopts Hungarian nomenclature (when several letters are combined, the first letter is capitalized, such as the HR system provides data to the portal: HRDataToPortal), and the code length cannot exceed 20 letters;
- Fill in Chinese aliases and descriptions for all message processes, and the descriptions must clearly state the specific meaning.
- ESB integration project main package name: com.agileai.esb;
- The public code is directly placed in the com.agileai.esb directory, and other codes use the package name and class name generated by ESB by default.
4.2 WEB service specification
The application/data interface is published in the form of WebService, and the Http communication protocol is used for synchronous communication. The AEAI ESB service agent supports SOAP 1.1 and SOAP 1.2 access protocols. The web service developed by AEAI ESB supports SOAP 1.1 by default. Requirements are as follows:
- Each field is a string type unless otherwise specified;
- The default format of the date field is "yyyy-MM-dd", such as: 2015-05-14;
- The default format of the time field is "HH:mm:ss", such as 16:25:16;
- The header information has a default structure, allowing custom headers.
Both the service agent registered in AEAI ESB and the service published in AEAI ESB support: user, password authentication and extended authentication mode, and provide service monitoring, service call statistics functions, and support business logs.
4.3 AEAI ESB Development Specification
The services developed in AEAI ESB in this project are mainly Web Service, Http, and Timer services. The existing Web services of the business systems of each unit and its subordinate units are registered in the AEAI ESB as a service proxy. AEAI ESB provides message forwarding, service monitoring, service statistics, service authentication and business log functions.
4.3.1 Service Agent Registration
First, log in to the ESB management console
Select the project to which you need to add a service proxy, and select the Service Proxy tab
Click Add to register proxy for WEB service
Add the service URL that needs to be proxyed to the corresponding location (1), click the resolve button to register the service proxy (2), add the authentication type (no authentication, user password, extension process) (3), add whether to enable the business log (4) )
In the provided ws service, the name of the service needs to be named by the business function and cannot be repeated
| <wsdl:service name="XXX"> <wsdl:port name="erp_ryzw_receivePort" binding="tns:ErpRyzwReceiveServiceSoapBinding"> <soap:address location="http://localhost:9090/AEAIESB/wsproxies/XXX"/> </wsdl:port> </wsdl:service> |
4.3.2 开发WEB服务
对于既有系统不能提供Web服务接口的应用系统，且需要Web服务方式来集成，或者需要对既有的Web服务实现服务编排重组，可以在AEAI ESB开发Web服务。
- 如果涉及到数据读取，需要对应系统管理员提供提供数据视图、字段说明、以及数据库连接方式；
- 如果涉及到数据写入，需要对应系统管理员提供中间表以及存储过程，ESB理论上不直接访问实际的业务表；
- 如果涉及到服务编排，需要对应系统管理员提供Web服务的SOAP调用样例，请求和响应参数说明。
4.3.3 开发HTTP服务
根据服务提供方提供的数据库交互方式（视图查询、存储过程）进行Http流程的开发
- 提供数据库连接信息，如账号密码及地址等（Oracle数据库还需要提供SID），登陆ESB管理控制台对数据库资源进行注册管理；
- 服务提供方需提供存储过程或相关的查询SQL语句；
- Http流程的返回值为JSON或者XML格式（需要就实际业务进行选择），调用方自行解析。
4.3.4 开发Timer服务
根据当前的轮询方式，在AEAI ESB上改造为Timer流程：
- 服务系统管理员提供当前的轮询策略（定时、间隔、自定义）；
- 提供数据库连接信息，如账号密码及地址等（Oracle数据库还需要提供SID），登陆ESB管理控制台对数据库资源进行注册管理；
- 提供查询全量数据还是增量数据，查询增量数据时的条件；
4.4 AEAI ESB测试规范
4.4.1 单元测试
单元测试由流程开发者自己来完成，单元测试是对完成一条流程后的最基本检查，主要是用来检测逻辑否正确，程序代码是否正确， 组件节点命名是否按照规则，实例正确生成、以及字段和变量的拼写错误，还包括所引用资源是否可以等细节。
单元测试的依据是测试规格说明书，单元测试的目的是对流程功能基本验证，该测试用来确定执行结果否符合预期，单元自测以持续执行3次均成功方验证为成功。
4.4.2 结对互测
当局者迷，旁观清。两个开发人员具有相同的缺点和盲可能性很小，当采用结对互测试的时候会获得一个强大解决方案 ，能更快的发现并解决问题 。结对互测准确来说是一个测试方法，而不是其中的具体环节。
结对互测是指两个流程开发人员相测试对方的流程，结对互测的基础已完成开发人员已完成单元测试。
4.4.3 集成测试
大多数流程之间不是独立的，而有关联。多个流程的执行才是真实的逻辑业务， 所以在有流程完成单元测试后，需要按照业务子系统对多个流程进行连贯的集成测试，用来发现执时是否可以满足实际业务的需要。
集成测试可以根据实际业务模块或者子系统，来各自独立进行。集成测试用来发现多个流程协作执行时产生的潜在问题，这其中包括流程数据业务一致性和稳定性等。
4.4.4 业务联测
业务模拟测试时在集成之后进行的，当各个子系统的对应流程进行了集成 测试并通过后，可以进行完整系统的业务模拟测试。通常业务联测需要业务人员的参与和协作，在系统试运行初期进行。
业务模拟测试是所有流程的完整，各个被集成子系统和数据库都以正常模 拟数据进行测试。此时AEAI ESB集成平台对用户来说是透明的，所有数据都通过业务人员在各自系统上进行模拟操作获取 。