企业ESB平台部署及接口服务设计研究

2016-12-02 04:29龚伟
中国高新技术企业 2016年23期
关键词:制造企业

摘要:企业服务总线(Enterprise Service Bus,ESB)从面向服务体系架构(Service Oriented Architecture,SOA)发展而来,是传统中间件技术与XML、Web服务等技术结合的产物,可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。文章以某制造企业ESB平台部署及设计为例,介绍了ESB的实现方法。

关键词:企业服务总线;服务体系架构;ESB平台部署;接口服务设计;制造企业 文献标识码:A

中图分类号:TP393 文章编号:1009-2374(2016)23-0021-02 DOI:10.13535/j.cnki.11-4406/n.2016.23.009

1 概述

ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。

本文以某制造企业建设ESB的过程为例,简要介绍了企业部署ESB平台,并通过该平台进行接口服务设计的一些基本方法。

2 ESB平台部署

第一,系统软件的选择主要包括如下:

ESB平台软件:IBM Message Broker 8.0

系统管理服务器及日志服务器:Apache Tomcat 9.0

系统日志数据库:采用Oracle或者MySQL

第二,系统主要硬件设备如下:

负载均衡设备:基于F5构建,对外提供ESB平台的标准服务端口,由该设备接收所有的ESB服务请求,并将服务请求按照MB服务器集群中各服务器的负载情况分发给MB服务器集群中的MB服务器。

MB服务器集群:基于Linux服务器构建,安装了IBM MessageBroker软件,基于集群的Message Queue构建;服务器上运行了株机ESB平台系统,进行相关的数据处理及基于株机ESB规范的业务操作。

管理、日志服务器:MessageBroker的日志服务器,安装了Apache Tomcat,运行了日志软件以及系统配置软件,MB服务器将在启动时从该服务器读取相关配置信息,并在业务操作中将日志数据发送到该服务器。考虑到维护管理的复杂度,该服务器可以酌情建设APP服务器集群,但是基于关键性原则,不建议构建超过2台服务器的集群。

NAS:安装了NFS提供共享硬盘,通过iScsi对外提供数据库存储,主要保存在ESB运行过程中的各项日志信息,该数据库服务器可以使用主机现有的服务器实例来运行。

3 集成概念设计

3.1 业务场景到ESB集成的判断标准

3.1.1 业务服务满足度判断标准。业务服务满足度的判断标准是用来分析、判断该服务是否能够满足具体的业务,或者换言之是否存在具体的业务会使用到该服务。在业务分析时,该问题主要是用来衡量业务使用ESB来支持的价值,当该服务被越多的业务场景使用到,服务在该问题评判上的评分就越高。业务服务满足度的问题是“这个服务提供的业务功能能否满足业务流程和目标?这个服务能够直接(相对于继承于它的子服务)满足某个业务目标?”

3.1.2 服务实现复杂度判断标准。服务实现技术复杂度评判标准是用来分析、判断该服务的实现成本以及该成本是否能够被预算所实现。在实际业务实现时,存在一些老旧的不能支持Web service模式的系统,并且在过去集成这些系统时,使用了耦合度较高的集成模式,比如DLL方式;这样如果要将这些集成迁移到ESB上,需要较多的预算甚至需要重新改造软件系统本身;部分系统虽然支持Web service模式,但是因为原开发厂商的问题,要使用Web service的成本较高,服务实现复杂度判断标准的问题是“业务上是否可以提供资金支持本服务的整个生命周期(创建、管理、治理和维护)?”

3.1.3 服务实现安全性判断标准。服务实现安全性评判标准是用来分析、判断该服务在实现后是否会带来潜在的数据暴露风险。在实际业务中,任何数据都存在它的保密级别,比如某类数据可以被匿名访问获取或者某类数据的所有访问操作均需要记录访问者,也存在一些数据只能被少数人访问,而使用了ESB后,数据被发布到ESB上,客观上就可以被所有能访问ESB的外部用户访问到,因此需要考虑每一个服务对外公开的范围,甚至部分数据就不能使用ESB来对外提供集成。服务实现安全性判断标准的问题是“业务上是否允许将本服务提供给内部或外部的用户或业务合作伙伴?比如这样做可能会带来额外的成本、商业秘密、安全性等问题?”

3.2 集成概念设计的原则性要求

3.2.1 完整性。基于业务的需要,所有交互的数据、文档必须是完备的,数据交互本身必须包含所有本次需要交互的数据,并确保发送端发出的数据与接收端接收的数据完全一致。自校验可以被认为是保证数据完整性的主要手段,这是指:(1)在每一次数据交互过程中,通过技术手段来确保交互的数据的完整性;(2)在数据交互结束后,通过其他方法对于双方的数据进行检验,按照检验值判断双方数据一致。

3.2.2 及时性。该企业的信息系统均设计为支持内部生产业务运作,这就意味着大多数业务集成场景下,数据的实时性要求并不高,系统操作是要求当业务操作到需要被交互数据时,能够得到数据;在系统设计时就对应着可以通过在业务操作过程中补充拉取数据的方法来保证交互的及时性。

3.2.3 自纠错。作为数据完整自校验的后续手段,当发现两边数据出现不一致情况时,需要在系统集成时从集成方法上提供方法,来完成数据的重新交互。这意味着系统间的数据交互可以在任何状态下重新开始,无论是系统在数据传输过程中停机,还是业务问题需要重新初始化数据,均能够通过自纠错方法完成数据的重传,以达到数据在所有系统的最终一致。

3.3 集成场景

按照业务场景的特点,可以将业务场景分成如下种类来设计每一种场景的实现方法,来保证集成的完整性、及时性、自纠错。需要说明的是,这种方法仅是每一种场景集成设计的建议模板,在实际的设计过程中可以根据具体情况进行调整。集成场景的区分主要是基于每一个集成场景所交互的数据的特点进行分类,这些数据特点包括:

3.3.1 交互类型:交互类型是指在业务场景的使用过程中,服务的请求方对于服务返回的时间要求,这主要反映了及时性的要求,交互类型主要分为异步数据交互与同步数据交互。

3.3.2 数据变化频度:数据变化频度是指服务所提供的数据的变化频度,该类数据的增改的频次情况,基本上以每天都可能有更新描述为频度较高,否则为频度较低。

3.3.3 数据量大小:数据量大小是指服务交互的数据的单次交互数据量的大小,这包括两种情况:(1)单条数据的数据量较大;(2)单条数据的数据量不大,但是每次交互的数据条目较多。数据量大小一般以字节单位衡量;单次交互数据量在2K字节以上被认为数据量大,否则被认为数据量小,单次交互数据量在1M字节以上被认为数据量超大;在集成场景中,因为交互多条数据而造成的交互数据量大并不被认为数据量大。

3.3.4 数据实时性要求:数据实时性要求主要反映在异步数据交互中,数据使用系统对于数据的实时性要求,或者换言之系统间针对某服务提供的数据,多少时间内不一致不会造成业务问题。在分析时,系统间仅允许10分钟的数据差异称之为数据实时性要求高,否则称之为数据实时性要求低。

4 公共接口服务设计

公共服务是指在ESB规范中,要求所有业务系统均实现的交互服务,这些服务被用来支持最基础的集成业务,保证系统间集成的可靠性以及企业信息化系统数据的整体一致性。因此公共服务被设计为在所有接入ESB平台的系统中部署,作为规范要求所有接入系统实现。我们整理出了如下公共服务,作为企业ESB平台的公共服务,要求各业务系统实现。

表1

服务名 服务说明 业务系统角色

CHECKAVAIL 基础的心跳服务,ESB使用该服务确认业务系统的状态,并进行基础信息的交互。 作为服务提供端

NOTIFYINFOCHANGE 基础的通知消息服务,ESB通过该消息通知业务系统某种业务数据发生了变化。 作为服务提供端

RECINFODESC 基础的数据对照服务,业务系统通过该服务获取某业务数据的描述。 作为服务请求端

SYNCBASORG 获取组织机构信息服务,ESB通过该服务对业务系统提供组织机构的更新信息。 作为服务请求端

SYNCBASUSER 获取用户信息服务,ESB通过该服务对业务系统提供用户的更新信息。 作为服务请求端

SYNCBASDATA 系统预留的获取部分公共数据编码的方法,该数据编码形式为名称=值的形式,提供诸如性别编码、职位类型编码等编码的获取。 作为服务请求端

5 开发及应用流程

5.1 确定业务系统功能范围

该阶段的主要工作是确认当前需要部署到ESB的业务系统的功能范围,并讨论各功能集成场景。

5.2 确定该业务系统相关的服务接口

本阶段的主要工作是针对前一阶段得到的服务列表进行分析,确认能够完成本次系统集成。

5.3 基于ESB提供的wsdl生成代码

代码生成后即可开始Web服务的调用。

5.4 测试及上线

为了确保各自实现的正确性,为了以后的联调联测工作能够顺利进行,要求参与集成的各方对自己的开发结果进行测试。测试过程中使用的测试数据由各自虚构,但需使用有意义、符合规则、尽量真实的数据。集成相关方按照上线计划准备相关程序和基础数据,在指定时间进行上线。

作者简介:龚伟(1979-),男,四川荣县人,中车株洲电力机车有限公司信息管理部高级工程师,硕士,研究方向:装备制造业信息化。

(责任编辑:黄银芳)

猜你喜欢
制造企业
制造企业成本控制中运用价值流分析探究
基于SAP信息化系统下的制造企业成本管理控制趋势分析
从平衡记分卡看绩效评价
基于营改增背景下的制造企业纳税筹划方法分析