对水利应用支撑平台的建议

张永进 , 解建仓 , 蔡 阳 , 吴晶晶

（1.西安理工大学 水利水电学院, 陕西 西安 710048；2.水利部水利信息中心, 北京 100053）

0 引言

J2EE，SOA 等国际规范与标准，对水利信息化应用影响很大，构建应用支撑平台，快速为应用服务，成了讨论热点和实践的方向。近 10 年的研究与实践，让我们发现，在一般商业平台产品与水利应用之间，还要有 1 个中间件平台，有了这个平台才能够真正支撑起应用。本文就是要讨论这样的水利应用支撑平台（以下简称平台）。

1 平台构建的目标

构建平台是为了提高水利应用系统的开发效率、稳定性和系统之间进行信息交换的能力，为此，平台应支持：通过组件构建应用系统[1]；组件之间的信息交换；通过简洁的方式增加、删除、升级组件改变应用系统功能；适应工作负荷变化的灵活配置能力，使应用系统对规模的变化有较强的适应能力。

2 平台技术模型

水利应用系统应由通过平台服务定制功能描述的业务组件和外部应用服务访问逻辑来实现，并可由服务执行功能进行加载、运行。其中，业务逻辑服务层所包含的业务组件可根据水利应用系统的需要不断修改、补充或删除。平台技术模型如图 1 所示。

3 平台的系统结构

应支持 TCP/IP 网络环境下的客户机/服务器结构。客户端应在平台的服务执行功能支持下运行水利应用系统，并通过业务逻辑访问接口获得服务器端的提供业务组件功能。平台系统结构如图 2 所示。

4 平台具体规定建议

应通过 XML 文档的形式，描述业务逻辑与外部应用 2 服务层提供的业务组件与功能的时序和组合关系，并能在应用服务控制层中的服务执行功能控制下运行。

4.1 应用服务控制层

应对系统行为及其它资源进行关联和控制，包括对业务组件提供的服务及系统资源的配置和控制，并在服务运行中实现人机交互界面的关联和控制。主要应包括以下功能：

图1 平台技术模型

图2 平台系统结构图

1）服务定制。应提供直观、简捷的用户交互界面，使用户可建立业务组件与功能的时序和组合关系，实现水利应用，并能以 XML 文档的形式存储结果。

2）服务执行。应能读取服务定制存储结果，并按照其定义访问业务组件与外部应用服务，关联相应的人机交互界面，提供水利应用系统需要的信息内容。

3）流控制。在服务执行中，应能按照事先定义的时序和组合关系，对业务组件产生的信息流进行组合、剪裁，以保证信息流动的正常进行。

4）安全控制。应具备用户身份认证[2]，及以此为基础的业务组件访问权限管理，并具备安全事件监测和评估的工具或方法。

可通过多种安全机制来实现，如数字签名、加密、访问控制、数据完整性等机制，这些机制可以单个使用，也可组合使用。应遵循 GB/T 9387.2，GB/T16264.8，ISO/IEC 10164-7 及 ISO/IEC 10164-8等标准。

4.2 人机交互服务层

应在应用服务控制层中的服务执行功能控制下，为业务组件产生的输入、输出信息流提供人机交互界面。应提供的人机交互界面主要服务功能包括：统计图形、空间信息、数据表、报表、交互窗体等服务。

4.2.1 统计图形服务

应满足以下要求：

1）支持各种常用统计图形，例如条形图、折线图、直方图等；

2）支持统计图形保存和打印；

3）有简明扼要的图题，纵、横坐标，计量单位符号，纵横坐标应标明相应的刻度、图例及必要的文字说明等；

4）图形的基本要素要安排合理，颜色搭配恰当；

5）图例及文字说明要简明扼要，避免与正文重复。

建议支持多轴多线形的图形统计，坐标底色能够根据数据情况变换。

4.2.2 空间信息服务

应满足以下要求：

1）支持二维、三维 GIS 信息的表现方式；

2）二维 GIS 服务在数据访问、操作上，应符合 OGC（开放地理信息协会）和 ISO/TC211（国际标准化组织地理信息技术委员会）共同推出的基于 Web 服务（XML）的空间数据互操作实现规范WMS，WFS，WCS，WPS，以及用于空间数据传输与转换的地理信息标记语言 GML；

3）三维 GIS 服务应支持通过遥测、航测等手段获得的地表图片信息的相关操作。

4.2.3 数据表服务

应满足以下功能要求：

1）支持数据的筛选和排序；

2）数据表列项可以根据用户的需求重新排列；

3）支持数据表的标题、标题栏、表体内容等基本元素的装饰，例如字体、字号、颜色；

4）支持数据导出；

5）建议支持公式计算、数据校验、逻辑判断等功能。

4.2.4 报表服务

应满足以下功能要求：

1）支持报表的基本操作，例如报表的保存、打印、页面跳转、显示比例、放大缩小；

2）能通过报表设计工具，支持复杂的报表布局，产生所需要的各种系列和格式的报表；

3）支持报表的标题、制表日期、计量单位、表内分栏、表体内容、表尾、附注等基本元素的装饰，例如字体、字号、颜色等；

4）支持数据导出。

4.2.5 交互窗体服务

应满足以下功能要求：

1）能根据业务组件输入信息流的要求，提供美观窗体界面；

2）窗体描述是与操作系统无关的、独立性较高的界面描述方式，具有较强的移植性。

4.3 业务逻辑服务层

应通过业务组件，以服务的形式提供业务功能。其中，每个业务组件都应符合 IPO 模型，并采用 XML 描述输入、输出信息的内容，XML Schema描述输入、输出的信息格式。同时应提供符合 UDDI 3.0 标准的业务组件描述。

业务组件应采用 Web Service 实现[3]，方法接口要求如下：

1）execute 方法。应根据该方法调用参数，执行特定业务功能。具体参数如表1 描述。方法返回值为 xs:string 类型，应符合 XML Schema 规范要求的功能执行结果。

2）get Action Return Schema 方法。应根据参数action Code 返回对应的 XML Schema 描述。具体参数如表2 描述。方法返回值为 xs:string 类型，应符合XML Schema 规范要求。

3）get Action Input Schema 方法。应根据参数action Code 返回对应的 XML Schema 描述。具体参数如表3 描述。方法返回值为 xs:string 类型，应符合 XML Schema 规范要求。

4）get Actions Info 方法。应返回 Service 所包含的业务功能的功能编码和描述。无调用参数，返回值为 xs:string 类型，应以 XML 格式描述，get Actions Info 方法返回的 XML 格式要求如下：

表1 execute 方法的调用参数

表2 get Action Return Schema 方法的调用参数

表3 get Action Input Schema 方法的调用参数

5）get Action Name 方法。应根据参数 action Code返回对应的业务功能描述。具体参数如表4 描述，返回值为 xs:string 类型。

表4 getAction Input Schema 方法的调用参数

业务组件描述应通过符合 UDDI 3.0 标准[4]的目录服务系统提供。描述信息应符合如下要求：

1）节点描述，应通过 Business Entity 域的Names 属性描述提供业务组件服务的节点名称；

2）节点提供的业务组件服务，应通过Business Service 域的 Names 属性简要描述业务组件的功能，Descriptions 属性详细描述业务组件的功能；

3）业务组件服务访问路径，应通过Binding Template 域的 Access Points 属性以 URL 的形式描述业务组件服务所对应的 Web Service 的访问路径。

4.4 业务逻辑访问接口

对业务组件访问要求为：

1）访问协议应符合 Web Service 标准要求；

2）以XML，XML Schema 文档标准描述业务组件的输入、输出信息流；

3）输入、输出信息流应能被服务执行功能解析；

4）应通过符合 UDDI 标准的访问协议获取业务组件描述。

4.5 服务访问接口

应符合以下规定：

1）以 XML 文档标准描述业务组件与功能的时序和组合关系；

2）能被服务执行功能解析并执行。

5 结语

构建了水利应用支撑平台后，信息化的应用模式就会发生根本性变化。数据、信息、组件、主题、知识图成为应用服务中心的实际内容，在平台的支持下，由组件、主题、知识图快速组织应用；由丰富的多元信息可视化直观表现应用。个性化定制应用就是新的应用模式。这个模式不是传说，是实实在在的实践。

[1]解建仓，罗军刚. 水利信息化综合集成服务平台及应用模式[J]. 水利信息化，2010 (4): 18-22.

[2]刘俊琦，程虎. 基于 J2EE 的应用支撑平台的设计与实现[J]. 计算机工程与设计，2006, 27 (15): 2821-2845.

[3]罗军刚. 水利业务信息化及综合集成应用模式研究[D]. 西安：西安理工大学，2009: 22-45.

[4]芮雄健，王忠民. UDDI 的原理与实现[J]. 计算机工程与设计，2005, 26 (6): 1602-1605.