水厂基于企业服务总线的应用集成研究

冼 峰，朱海峰

(上海市自来水市北有限公司，上海 200086)

1 引言

随着现代企业系统信息化应用水平的不断提高，信息化系统的应用规模已进入多系统、多业务、多层次、大规模的阶段。为了进一步提高各个系统的集成性、统一性和可维护性，保障业务开展和系统运维效率，需要对信息系统进行新的总体规划。通过业界先进成熟的IT技术，以实现内部众多业务系统之间的数据集成、应用集成、流程集成，实现信息共享与知识管理，使得业务更集约化、扁平化。

本次基于企业服务总线(ESB)的应用集成研究的总体目标是:通过ESB的应用研究，在技术、标准和管理方面，为建设基于SOA的企业架构及进一步推进企业信息化，奠定坚实的基础。

2 应用集成现状与问题

2．1 集成现状

首先分析供水企业管理工作中的地理综合展示系统与相关业务系统的集成方式。然后分别分析涉及产水［如数据采集与监视控制系统(Supervisory Control And Data Acquisition，SCADA)、水质监测］、供水(如新装业务、项目工程、GIS管网)、售水服务(如营收、现场维修)各个环节的核心业务流程、信息系统及其集成方式。

总体情况概括如图1所示。

2．2 存在的问题

经过分析整理，这些应用存在的问题主要有:

(1)各系统/部门之间的数据交换方式包括线上和线下，线下传递的图纸等资料由专人录入，项目工程的编号依赖人工约束。

(2)系统间是点对点的集成，一般直接通过数据库，或者XML RPC交换数据。

(3)各个系统有自己独立的用户管理体系，而且安全堪忧。

(4)各系统的主数据分散管理，有些系统还存在主数据无管理、错误的情况。

(5)包括供水热线提供的外部主数据没有得到管理和复用。

图1 应用集成现状Fig．1 Status Quo of Application Integration

(6)各种服务接口一般由提供数据的系统厂商作为服务提供者，与作为服务使用者的系统厂商根据两两约定后进行设计开发。这样的服务接口没有复用，且大多处于无管理的状态，也没有安全控制。

3 面向服务的集成架构

3．1 面向服务的体系结构与集成

面向服务的集成(Service Oriented Integration，SOI)是在面向服务的体系结构(Service Oriented Architecture，SOA)下，通过服务的交互来集成企业的各种数据资源，帮助企业将不灵活的旧系统集成起来，把业务数据或业务功能释放为可重用的服务。

面向服务的集成使得IT机构能够在已有的应用中提取可重用的服务功能，将传统的集成对象与开放的、高灵活性的Web服务整合在一起，提供抽象的接口来规定系统如何与其他系统进行通信。系统可以通过这些接口进行交互，而不是使用底层协议和自定义的编程接口。

SOI是对以往企业集成技术的继承与发展。它基于关注点分离、松散耦合等源自最佳实践的架构原则，继承了企业应用集成、消息总线、流程集成、数据集成等优秀技术。结合SOA先进思想的SOI正在成为企业集成的新方向。

SOA是能够使IT和业务紧密结合的手段和工具，为提升业务灵活性，其主要达成的目标包括五个方面:

(1)可重用:通过服务封装在应用之间实现可重用，这也是SOA的核心价值体现;

(2)分布式:远程访问、集中管理;

(3)开发性:在不同平台和操作环境下共享;

(4)灵活性:SOA的目标是实现业务的灵活性，应用可以被加入到新的模块;

(5)松散耦合:服务的实现与使用分离。

3．2 企业服务总线

企业服务总线(Enterprise Service Bus，ESB)的概念是从面向服务的体系结构发展而来的，与以服务为导向的应用架构体系紧密连接在一起，是SOA核心组成部分，是SOA架构中应用整合的骨干。

ESB是预装的SOA实现，包括了实现SOA目标所必需的基础功能组件。服务通过ESB进行交互。

ESB是传统中间件技术与Web Service、XML等技术结合的产物，用于消除众多平台及具体应用间的异构性，促进平台间的互操作，使不同格式数据间实现共享。

通过调查研究，我们选择Oracle完全基于J2EE技术构建 ESB产品——甲骨文服务总线(Oracle Service Bus，OSB)进行供水企业应用集成的实证研究。

4 基于OSB的应用集成研究

4．1 工厂总体规划

工厂总体规划及建议如图2所示。

图2 IT总体规划Fig．2 Blueprint of Enterprise IT

4．2 服务设计开发标准

通过研究实际情况，编写《XX供水企业基于企业服务总线的应用集成信息化标准》(以下简称《标准》)，对Web服务供应方和ESB建立包括互操作性、消息内容规范、消息协议、传输协议、服务描述、服务安全等在内的开发标准。

可以据此基于标准的接口定义和一致的实现手段，以面向服务的方式展开企业集成，逐步开发出一套强壮的集成解决方案。

4．3 既有WEB服务问题分析

参照《标准》，分析发现企业中既有服务的合规情况如表1所示。

表1 既有服务合规情况Tab．1 Compliance of Existing Services

具体而言，既有服务存在以下问题:

1)数据格式在服务接口中没有通过XML Schema(XSD)加以规范

业务数据作为消息交换主体，在服务接口里被模糊地定义为字符串类型，这使得服务接口无法做到自我描述，增加了调试维护及使用验证等方面的困难;另外，由于缺乏对业务数据的对象类描述，Web服务消息协议SOAP(简单对象访问协议)被事实上降格为一种传输通道，完全失去了使用SOAP的好处和意义。

2)个别服务实现有SQL注入的安全风险

空间查询和管网查询服务在请求消息的主体内直接注入SQL查询语句，这是上述问题所带来风险的一个极端化实例。

3)业务数据没有统一标准

这更多的不是服务设计问题，而是由于企业缺乏统一数据标准，无法对系统开发商提出相应的要求与约束;缺乏数据标准的结果就是同一数据类型在不同Web服务里表现为不同格式，从而造成服务开发与使用环节的浪费。

4)缺乏对命名空间的规范管理

所有既有服务的描述文件(WSDL)都使用临时的http://tempuri．org/作为目标命名空间;这在服务数量不多的情况下没什么问题，但随着服务数量不断增多，缺乏对命名空间的规范定义和使用会造成潜在的资源名字冲突和管理混乱。

5)缺乏对服务发布地址的规范管理

表2列出了既有服务的发布地址;随着服务数量的不断增多，缺乏对服务发布地址的规范定义会造成资源管理混乱。

表2 既有服务发布地址Tab．2 Addresses of Existing Services

4．4 典型集成实例的设计开发

4．4．1 以透传的方式发布既有服务

“透传”即透明传递，也就是把既有服务接入OSB，然后在不改变服务接口定义的情况下原样发布出去。

通过OSB透传发布既有服务非常简单，分两个步骤来做，如表3所示。

表3 既有服务发布步骤Tab．3 Steps for Publishing Existing Services

显然，将既有服务以透传方式发布在OSB上有以下好处:

1)便于对服务的发布地址进行规范管理

这从所有代理服务的新地址上就可一目了然(如表4)。

表4 规范服务发布地址Tab．4 Addresses of Normative Services

2)便于对服务的使用情况进行集中监控

一旦对既有服务的调用都割接到对透传代理服务的调用，我们就可以通过OSB管理界面对服务的使用情况进行有效的集中监控。

但是，简单的透传代理服务无法解决既有服务的《标准》合规问题，前面第4．3(既有WEB服务问题分析)中列出的1)～4)项问题依然存在。

为此我们继续研究如何基于OSB重构现有的服务。

4．4．2 为业务数据定义规范的XSD描述

在既有服务的WSDL里被定义为字符串类型的业务数据，其实有着自身的XML结构;所以，第一步要做的就是用XML Schema(XSD)语言对这些既有数据结构进行规范定义。

以远传水表服务的MeterHistoryInfo操作为例，给定水表ID和时间范围，它会返回水表在这个时间段内的读数信息(如图3、图4)。

＜MeterHistoryInfoResult＞元素在 WSDL里被定义为模糊的String类型，但它其实也是一个XML结构，我们用XSD对其的定义如图5所示。

图3 SOAP请求消息Fig．3 SOAP Request Message

图4 SOAP响应消息Fig．4 SOAP Response Message

图5 XSD定义Fig．5 XML Schema Definition

从上面的业务数据结构可以看出几个问题(其他既有服务都存在同样问题):

(1)元素和元素属性命名非常随意，在英文大小写和缩写的使用上完全没有规范可循;

(2)不少元素属性的命名采用了让人无法直观理解的缩写，不利于服务维护与使用。

为此，我们为每个服务定义了全新的采用一致命名规范的业务数据格式。还是以上面的XML结构为例，新的XSD描述如图6所示。

基于新XSD的XML结构与既有结构的格式对照如图7所示。

4．4．3 为代理服务定义新的WSDL描述

对既有服务的重构体现在代理服务拥有不同于(优于)既有服务的WSDL描述，这些不同包括:

1)新WSDL对消息格式的定义基于新的业务数据XSD

这样的WSDL在语义上实现了自我描述，容易理解和使用，也便于支持将来的业务数据标准化(如图8)。

2)新WSDL及其引用的新XSD都采用了规范的命名空间

(1)新代理服务的命名空间都以http://shanghaiwater．com/wsdl开头;

图6 规范的XSD定义Fig．6 Normative XML Schema Definition

图7 格式对比Fig．7 Schema Comparison

图8 WSDL定义Fig．8 WSDL Definition

(2)新业务数据的命名空间都以http://shanghaiwater．com/xsd 开头。

3)新WSDL对服务操作的命名进行了规范

操作名的修改使得语义上更准确直观，英文大小写和缩写也得到规范，例如:

MeterGISInfo→getMeterInfo;

MeterHistoryInfo → getMeterMeasurement。

4．5 设计并实现代理服务的消息流

对既有服务重构的核心在于设计并实现代理服务的消息流业务逻辑。该消息流把服务请求方发来的符合新WSDL定义的SOAP请求消息，转换成符合既有服务WSDL定义的SOAP请求消息发送给对应的业务服务，再把业务服务返回的符合既有服务WSDL定义的SOAP响应消息，转换成符合新WSDL定义的SOAP响应消息返回给服务请求方(如图9)。

由于响应消息的转换比请求消息的转换来得复杂，所以我们以前者为例做进一步的说明;响应消息的转换涉及多个步骤，其中最关键的有两个:

1)提取既有服务响应消息里的结果字符串并转换为XML对象

如前所述，既有服务的WSDL把响应消息里代表结果的XML结构都笼统地定义为字符串;我们要做的就是把这个字符串从响应消息里提取出来，然后转换成OSB所需要的XML对象以便后续处理。我们为此写了一个Java调用函数XmlObject StringResultParser．parse(String)(如图 10)。

图9 重构后的信息流Fig．9 Reconfigured Information Flows

图10 Java调用代码Fig．10 Java Callout

2)把上一步得到的XML对象转换为新的SOAP响应消息

为完成这个转换，我们须在代表既有服务响应结果的XSD类型(比如MeasurementResultType)和代表代理服务响应结果的 XML元素(比如MeasurementResponse)之间定义 XQuery变换(如图11)。

OSB开发工具会自动生成XQuery变换代码，涉及既有服务XSD命名空间的个别地方需要手工调整，最终代码看起来如图12所示。

4．6 为代理服务增加安全性配置

我们可以根据《标准》对服务安全性的要求，增加代理服务对请求方的身份认证。下以HTTP Basic Authentication(基本身份验证)为例，加以说明:

图11 定义XQuery变换Fig．11 Defining XQuery Transformation

图12 XQuery变换代码Fig．12 XQuery Transformation Code

(1)在OSB管理应用里创建用户账号和口令(如图13);

(2)在代理服务的传输配置里增加身份验证选项(如图14)。

增加上述配置后，调用代理服务必须提供正确的用户名和口令，否则就会因HTTP 401错误而无法访问服务(如图15、图16)。

4．7 结果对比分析

使用OSB实现对既有服务的透传发布非常容易，只需进行简单配置，无需定义新的XSD或WSDL等XML描述文件，更不需编程，但获得的好处有限。

如果严格依照《标准》在OSB上实现对既有服务的重构，就必须对既有服务的消息格式进行分析，重新定义代理服务的XSD和WSDL描述文件，设计不同XML格式之间的XQuery变换，甚至要通过Java编程处理更复杂的业务逻辑——这对OSB集成开发员的能力提出了一定要求，但服务重构产生的合规Web服务对企业今后推进面向服务的集成有巨大好处，对企业数据标准化也有明显促进作用。

图13 OSB创建用户界面Fig．13 Creating a User in OSB

图14 代理服务配置界面Fig．14 Configuring Proxy Service

图15 调用代理服务Fig．15 Invoking Proxy Service

图16 调用代理服务结果Fig．16 Response from Proxy Service

5 总结

本次研究充分借鉴国内外公共服务行业SOA建设经验、融合业界先进技术标准进行自主研发、建设，在一定程度上具有领先性，主要体现在架构先进、技术领先方面。

研究的目标是研究出适合企业适用的技术标准、管理规范，选用统一的架构体系和技术构建开放的、集成的、一体化的信息化应用环境，在此基础上构建以服务为导向的、一体化的、高效的企业业务应用，便于将来在既有应用信息资源的基础上分阶段实施新的信息系统规划。

为了在本次研究的成果之上继续深入推进基于服务总线的企业应用集成，企业考虑从以下几个方面着手布局:

(1)数据标准——成立专门的企业数据标准管理委员会，负责制定、维护和推广企业主数据与业务数据标准。该委员会要对企业数据标准的分类、描述语言、变更(版本)管理、保存与发布、使用合规管理等方面做出明确规定，并提供相应的文档与流程管理工具。基于上述规定，委员会要通过实施专项来定义和维护企业的数据标准;

(2)主数据服务——遵照《标准》(本研究项目的成果)和企业主数据标准，开发企业的主数据服务并在ESB上部署;

(3)业务服务——针对常用的业务功能或业务流程，设计开发可共享的企业级业务服务并在ESB上部署;

(4)人才培养——除非准备完全依靠外部供应商来实施上述任务，企业IT部门应该加强对内部人才的培养和锻炼，特别是与企业应用集成相关的分析、设计与开发能力。这包括(但不限于):常用的企业集成设计模式与技术、与XML相关的技术标准与 工 具 (XML，XML Namespace，XML Schema，XSLT)、ESB产品的配置与开发工具、常用的Java集成开发环境(Eclipse)等。在项目实施过程中，通过员工管理制度和项目管理安排使内部IT人才和外部供应商团队融为一体，是快速提高他们工作和学习能力的一个捷径。