引言

城镇天气预报是公众认知度高、使用较为广泛的气象服务产品。各地城镇天气预报由地市气象局预报员制作完成后发送到各省气象局，随后在省气象局完成报文拼接后，经过省级预报员的检查或订正，通过气象业务通信网络转发至NWFD(National Weather Forecast Database：国家天气预报数据库)^[1]；NWFD负责全国31省近2350站168小时的城镇天气预报及其他指导预报的质控、处理、订正和合并，并向业务部门和公众发布。城镇天气预报数据传输流程如图 1所示。

城镇天气预报数据自地市向国家级传输过程使用的技术手段是多级的文件传输协议(FTP)，其优点是简单、易于使用。这种基于多级FTP实现的城镇天气预报数据传输流程中存在多个“文件落地——再传输”过程，这些中间过程中产生的落地文件通常借助定时作业来发起再传输，将造成数分钟的传输时延。虽然FTP是一个面向连接的、可靠的TCP应用协议，但在多级FTP传输情形下，数据传输环境复杂，传输发起端(地市级)无法与传输接收端(NWFD)建立直接的数据连接，中间过程如出现异常，控制信息也无法在两端有效传递。另外，跨区域协同预报、交互订正、预报质量控制等现代天气业务应用也对城镇预报数据实时交互能力提出要求。

目前各省气象局相继建立LWFD(Local Weather Forecast Database：省级天气预报数据库)试验系统，用以增强各省以城镇天气预报为中心的精细化预报业务数据的管理能力。本文研究应用JMS(Java Message Service：Java消息服务)在国家级NWFD与省级LWFD之间建立可靠、高效且具备一定交互能力的城镇天气预报消息传输机制。

1 JMS消息服务 1.1 JMS基本概念

消息(Message)是指在多个系统部件之间被传递的承载信息的数据对象，通常由消息头(Headers)，属性(Properties)和消息体(Payload)三部分组成^[2-4]。其中消息头由消息的唯一标识、目的地址、有效时间、优先级等信息组成，属性是应用程序自定义的信息，而消息体则是传递的数据信息正文。

JMS是一套基于JAVA技术，描述MOM(Message Oriented Middleware：消息中间件)的基本概念、语义接口、类抽象的基础服务框架，其核心是一组Java应用程序接口(Java API)，它提供创建、发送、接收、读取消息的服务，用以规范消息服务的实现和开发，并在此基础上提供可靠消息传输、事务和消息过滤等功能。

遵守JMS规范的MOM产品众多，其中商业产品包括Oracle WebLogic JMS，IBM的WebSphere MQ，SonicMQ等，开源实现包括JBoss Messaging，JORAM，Apache ActiveMQ，Sun Open Message Queue和Apache Qpid等。

1.2 JMS的两种消息模型

JMS支持两种消息模型：Pub/Sub模型(Publish/ Subscribe：发布者/订阅者)和P2P模型(Peer to Peer：点对点)^[2-3]。

Pub/Sub模型支持信息发布者建立主题和发布消息，信息订阅者则从主题订阅消息，表现为一种更松散耦合的通信机制，多用于一对多的群体对象的消息发布，如电子公告牌、新闻组等。

P2P模型采用消息队列技术实现。在P2P模式下，消息生产者向一个特定的队列发布消息，消息消费者从该队列中读取消息，每个消息只有一个消费者。消息队列提供消息的存储、路由和传输服务，并保证消息的传递；如果发送消息时接收者状态异常，消息队列会保留消息，直到消息被处理或消息到期。P2P模型的特点就是参与通信的只有生产者和消费者两个参与者，其机制就是满足点对点之间的可靠的消息传输，如远程事务操作等，适合用于不同应用系统或数据库之间远程的数据交换，本文使用此模型实现城镇天气预报的消息通信。

2 基于JMS的城镇天气预报数据传输技术 2.1 城镇天气预报中的数据传输

城镇天气预报是气象部门基础性的业务工作，其中，数据传输在全国城镇预报业务化流程中的关键环节。

城镇天气预报产品是由各地上传的城镇天气预报数据经过汇总、检查、质控及订正工作，由地市级预报员、省级预报员、国家级预报员依次参与、共同制作，最终形成的全国统一的预报产品。这就要求业务化流程中的数据传输环节必须实现以下功能：(1) 实现全国各省的预报数据向国家级的传输；(2) 解决由于天气预报的实时性和变化性，预报改变后需要及时更新补传的需求，以确保在服务中总能够使用最新的预报结果；(3) 支持国家级和省级之间开展预报业务时的实时信息交互需求，由地市预报员、省级预报员、国家级预报员参与协作、共同制作完成的城镇预报产品。

此外，全国城镇预报业务对数据传输还有高时效性、高可靠性、高安全性等性能方面的要求。

2.2 JMS在城镇天气预报数据传输的优势

我们从数据传输的类型、可靠性、传输模式等几个方面对比FTP和JMS两个通信技术(见表 1)。

可以看出，JMS传输具有可靠、安全、支持代理和集群、可配置项多等特点，可用于企业级大规模通信；而FTP在点对点数据传输有着简单易用优点，可用于普通的传输任务。

因此，选择JMS技术实现城镇天气预报数据传输具备以下优势：

(1) 增强城镇预报数据传输的可靠性。由于JMS的技术特点，具备内建数据重发、确认模式等多种机制，能保证JMS消息送达，即使在恶劣网络环境下，JMS也能减少因传输过程异常中断导致的空文件或文件损坏等现象，避免由此带来的报文重复传输和处理；

(2) 提高预报数据更新的及时性。虽然JMS是异步传输，但是基于事件的响应机制可以保障数据技术的传输处理，一旦省级LWFD城镇天气预报数据发生变化，增量更新的城镇天气预报数据送至消息中间件，立即可触发追加NWFD的事件；

(3) 促进预报业务的实时交互能力提高。基于双向的消息队列技术可支持城镇天气预报等精细化业务在多个不同业务部门之间交互，如国家级和省级之间的指导与订正、预报结果协调、实时预报质量控制等。

2.3 基于JMS的城镇天气预报传输框架

本文提出的城镇天气预报数据传输框架，是基于JMS的P2P模型设计，利用消息队列技术实现国家级NWFD、省级LWFD两层数据库之间的远程数据传输。

框架中，地市预报员直接使用网络化的客户端工具制作预报，预报数据直接写入省级LWFD，省级LWFD通过MOM向国家级NWFD进行远程传输，各省级LWFD作为消息队列的消息生产者，而国家级NWFD作为消息消费者，后者从统一的消息队列里，取得前者发送的预报数据及其增量更新，这是P2P模式的一种扩展，不同的是生产者变成多个。

框架由NWFD、LWFD、MOM、消息发送器、消息接收器等五个部分组成，如图 3所示。

其中，NWFD是全国城镇天气预报业务的中心节点，作为各省数据传输的目的地，它运行着一套ORACLE数据库及应用管理软件，担负全国城镇天气预报数据的实时接收、质量控制、数据处理、订正交互、统一发布等功能；LWFD是试验部署在部分省的城镇天气预报数据库，为地市预报员提供城镇天气预报数据的实时接收、数据处理、订正交互等功能的业务数据环境。

MOM是实现LWFD向NWFD数据传输过程中消息队列、消息路由、安全认证等系统级消息服务的关键设施。

消息发送器，运行于LWFD前端，负责实时探测LWFD的数据变更，实现城镇天气预报数据变更的消息装配，同时将其发送到指定的消息队列；消息接收器，运行于NWFD前端，负责连接消息队列，异步取得城镇天气预报数据消息，消息解析，并根据消息类型进行有关的处理操作。

2.4 关键技术

(1) 消息体的设计

城镇天气预报数据是复合数据类型，包含预报站点、预报时次、预报时效以及天气现象、温度、风力、风向等各类预报要素。JMS API定义了5种消息体接口，包括TextMessage、MapMessage、BytesMessage、StreamMessage、ObjectMessage，以便提供以多样的消息形式用于发送和接收数据。其中ObjectMessage不同于其他接口，它接口传递的是实现java.io.Serializable接口的可序列化对象消息。这种接口下，消息发送器、消息接收器无需将处理的数据对象再进行类似XML或字符流之类的编码处理。因此城镇天气预报数据的消息体接口采用ObjectMessage实现Forecast对象在消息发送器、消息接收器之间的传输。

(2) 事件驱动的消息应用架构

城镇天气预报数据传输业务要求在指定时间内处理完成。传统采用定时轮询方式来探测数据文件是否到达，这可能导致数据处理滞后，甚至丢失数据。JMS支持事件驱动的架构编码方式，简化了消息处理的程序代码，同时提高了处理的时效性。采用事件驱动方式，应用既不需要持续处于阻塞等待，也不需要设置定时轮询时间间隔，就可以及时处理每一个到达的消息。

位于NWFD前端的消息接收器采用注册监听器的方式，当有消息到达触发事件的时候，即回调监听器的onMessage()方法。

(3) 消息持久化

城镇天气预报是关键业务，对数据传输有完整性和安全性保障要求。JMS能够将传输的城镇天气预报数据作为持久性的消息写入磁盘，即使系统出现故障也可以恢复。消息持久化能有效提高城镇天气预报数据传输服务的可靠性。

ActiveMQ除支持内存对象方式保存消息外，还具备通过文件或数据库方式实现消息持久化的能力。城镇天气预报利用ActiveMQ原生支持的KahaDB文件库实现消息持久化，KahaDB的事务性日志可以提高MOM的可靠性，使用B树索引技术来改善持久化的消息访问性能。

(4) 消息服务的认证安全

城镇天气预报须在严格的安全环境下运行，这就相应地要求城镇天气预报数据传输消息服务应对接入JMS Agent有身份管理、授权访问能力。

城镇天气预报消息服务以插件方式集成JAVA认证授权服务(Java Authentication and Authorization Service:JAAS)。通过JAAS，ActiveMQ利用simpleAuthenticationPlugin插件实现用户身份认证，利用authorizationPlugin插件则可实现对制定的消息队列的进行角色读、写、管理授权。

此外，消息中间件还支持从通信层改进JMS服务的安全，例如使用经过身份验证的SSL连接等。

3 应用测试

为验证城镇天气预报数据传输框架的性能，我们搭建以下测试环境开展测试：消息服务器采用IBM X3755服务器(2颗2GHz AMD Opteron 8350 CPU，内存8G，操作系统为Redhat Enterprise Linux 5.3)，使用不同网段的两台Dell 965微机分别运行消息发送器和消息接收器，消息中间件采用Apache ActiveMQ 5.5.0。通过两个测试分别来验证JMS的传输性能以及JMS与多级FTP转发耗时对比。

3.1 性能测试

我们在消息发送器测试单线程依次发送一定数量的城镇天气预报消息至消息服务器的消息队列，消息接收器则从接收消息队列的城镇天气预报消息。实验取得消息数量在1000~100000之间的近20个测试样本，如图 4所示。

测试结果表明，伴随着城镇预报数据测试消息的数量增加，消息传输耗时基本上能够与消息数量之间保持较为稳定的线性关系。在传输0.1万、1.0万、10万个消息时，单位时间传输速度分别为0.83万/秒，1.43万/秒，1.83万/秒，平均消息传输速度能够达到1万/秒左右，并且消息接收端接受的所有消息均能保持原始发送顺序。

3.2 对比测试

选取2011年7月24日广东等9省台业务传输的64个数据文件作为测试样本，对比在多级FTP和JMS两种情况下的城镇天气预报传输性能。根据气预函〔2008〕140号“精细化预报产品文件格式说明”从接收到城镇天气预报文件名中抽取文件生成时间，并计算传输多级FTP情况下每一样本的传输耗时。测试中，消息发送器测试单线程批量向消息服务器发送样本数据，消息接收器负责实时接收数据，从发送时间和接收时间计算出样本传输耗时。逐一对于选取的文件样本进行两种方法的传输耗时对比，如图 5所示，其中横坐标为样本编号，纵坐标为传输耗时。

测试结果显示，多级FTP方式中样本文件平均传输的时间为418秒，与之相比JMS由于减少了中间环节，同样的文件传输只需要0.089秒左右，JMS传输能够明显改善城镇天气预报的传输性能，并将整体数据传输性能提高2~3个数量级。

4 结束语

本文讨论利用JMS在NWFD和LWFD之间建立城镇天气预报数据传输框架。这种基于消息队列方式的传输框架能够在提高城镇天气预报数据传输能力的同时，保证城镇天气预报安全、可靠的传输，优化了城镇天气预报数据的信息交换流程，为未来的精细化预报业务的应用交互提供技术基础。气象部门中存在很多可靠性和时效性要求较高的实时数据传输、交换业务应用场景，JMS在这些方面将有广泛的应用前景。