基于SOA的气象服务产品发布服务器控制系统及方法与流程

本发明属于气象信息处理技术领域，尤其涉及一种基于soa的气象服务产品发布服务器控制系统及方法。

背景技术：

目前，业内常用的现有技术是这样的：在全球气候变暖的大背景下，我国气象灾害明显呈上升趋势，将气象监测信息、预报预警信息及时地发布到政府及相关部门、公众等，最大限度地减轻气象灾害造成的损失，成为当前气象部门亟待解决的难题之一。早期的气象服务产品发布主要是通过广播的方式把预报信息发布出去，随着科技进步和技术的发展，信息传播的方式和手段发生了很大的变化，气象信息的传播和发布也不例外，出现了利用大屏大喇叭、手机短信、微博、微信、电话传真、网站等多种方式发布气象信息(灾害预警信息)，但是，这些新的先进的信息发布手段导致在实际应用中怎样快速有效的把特定气象服务产品发布到指定的用户(机构)手中，如当发生一次重要的天气过程(暴雨)，对这次过程，可以形成多个气象服务产品，需要发给多个用户，不同的用户其接收的设备是不一样的，如广大农村是大喇叭，而政府领导可能是传真或手机短信息，即使是同一发布方式，但由于其产品来源于不同厂家，其接口标准的不规范性也不能一次发布。其发布具有相当的复杂性和重复性，这样带来的后果是发布效率非常低，对于灾害发生迅速的，可能出现预警信息还没有发出而灾害已经发生的情况，就无法起到减灾防灾的作用。为了应对这些问题，近年来提出了一键式发布技术来解决，在一定程度上提高了发布效率。但是，近年来出现的一些新情况，使发布效率受到很大影响。如一个省有多部门在国突平台上发布预警信息，有多部门在同一短信平台上发布预警信息等，势必造成发布排队，从而影响发布效率的情况。这就提出了一个问题，在当前面临发布手段多样化，发布对象复杂化怎样提高发布效率？另一方面，很多气象业务系统都需要使用气象发布，使得气象发布问题成为一个共性问题，怎样在各个业务系统中使用气象发布成为亟待解决的问题。随着中国气象局业务系统建设走向集约化，特别是近年来国家突发事件预警信息平台的深入应用，使得气象服务发布面临的环境更加复杂化。当极端天气(气象灾害)大面积出现时，涉及很多部门很多岗位要发布气象(预警)服务信息，发布服务器就会承受较大压力，往往出现发布等待较长时间或发布崩溃等问题，发布效率显著下降。

综上所述，现有技术存在的问题是：现有的气象服务产品(气象灾害预警产品)的发布通用性较差，发布效率较低。

当前的气象服务发布在要求提高效率和集约化的背景下就产生了大规模的气象服务发布问题，主要表现为第一，气象服务产品发布延迟、耗时长问题，在灾害出现迅速的情况下，不能满足灾害预警的要求，因此面临当前预警发布形式多样化的前提下，必须解决气象服务产品发布延迟和发布时间长的问题，进而提高气象服务产品发布工作效率；第二，气象服务产品发布遗漏问题，当前发布对象较多并且复杂，气象服务对象随着气象服务业务开展而不断变化。在实际工作中如稍有不慎，在服务中容易遗漏某一个或多个服务对象，有时会造成重大责任事故和不可估量的损失，在以往的服务过程中已多次发生这种情况，因此，气象服务产品的发布必须从机制、流程、环节和技术上解决相关问题，避免对气象服务对象和气象服务重大事件的服务遗漏，提高气象服务的精准度；第三，气象服务产品重复分发问题，分析气象服务产品的发布流程、环节、发布对象、发布方式，出现气象服务产品重复分发大致有三种情况即不同发布方式之间分别分发，需要分发多次，造成重复分发，有很多的服务对象是相似的，但它们的发布方式可能不一样，要求分多次分发，发布对象相似、发布方式相同，要求分多次分发，因此，必须充分借助计算机技术解决气象服务产品重复分发问题，缩短气象服务产品发布时间，减少气象服务人员的重复劳动，提高工作效率；第四，气象服务产品发布不均衡问题，由于服务产品和服务对象的复杂性，出现服务不均衡的现象，因此，必须充分借助计算机技术，采用科学的发布策略和发布模型算法解决气象服务产品发布不均衡问题，缩短不同服务对象的信息送达时间，提高服务效率。

技术实现要素：

针对现有技术存在的问题，本发明提供了一种基于soa的气象服务产品发布服务器控制系统及方法。

本发明是这样实现的，一种基于soa的气象服务产品发布服务器控制系统，所述基于soa的气象服务产品发布服务器控制系统包括：

服务发布子系统，用于建立面向不同发布接口的插件标准库和插件驱动库，在气象服务发布智慧模型的支持下，运用气象服务产品发布任务调度引擎实现产品发布任务的高效精准分配，采用循环队列技术实现产品发布的高并发处理机制，通过气象服务产品发布引擎把气象服务产品发布到特定服务对象指定的气象信息接收终端上，实现气象服务产品的一键式发布；

发布监控子系统，用于对发布过程全程进行监控，实时监控每个发布作业、发布任务正在执行的情况；对一次发布情况的综合分析；

状态报告子系统，用于面向统一服务接口提供的信息查询接口；

系统授权子系统，用于实现系统的辅助功能或者前置功能。

进一步，所述状态报告子系统包括信息发送和状态报告接口，提供的查询接口包括接口地址、请求参数、返回结果；

信息发送接口的查询内容包括发送内容、发送结果，在状态报告接口中提供的查询内容包括报告内容、内容详情、其他事项。

进一步，所述基于soa的气象服务产品发布服务器控制系统的soa的架构包括业务层、控制层、服务层、应用层四个层次；业务层、控制层、服务层、应用层之间采用松耦合；

业务层，部署插件库、业务组件、模型方法；与业务有关的内容变成方法、技术、模型、组件等全部进行封装，实现业务处理；

控制层，包括插件映射、虚拟发布、任务调度，把系统的业务需求解析成系统可识别的技术和方法；实现系统的各种控制，包括模型控制实现、算法实现、面向大规模的调度实现度；

服务层，包括组件服务、队列服务、网络服务、系统服务；

应用层，包括api应用、api文档，提供使用发布服务器的应用编程接口

进一步，所述基于soa的气象服务产品发布服务器控制系统进一步包括：

作业池，用于存放用户提交的气象服务发布作业，存储实体；

任务池，用于存放系统产生的气象服务发布任务，往往由发布作业通过一定的方法生成，存储中间过程；

发布池，用于存放系统产生的气象服务虚拟发布机，存储中间过程；

虚拟发布机，用于发布任务与计算机资源综合生成的发布任务集合，存储中间过程；

管理器，用于管理大规模的气象服务发布作业、任务、发布虚拟机、调度；

发布引擎模块，用于按照规则、流程、方法把气象服务产品发布到具体的设备上。

气象一键式发布模块，用于在面对气象多种发布渠道、多种发布对象时一次性地把服务产品发布到所有需要发布的设备上。

其次，根据发布实现机制把发布过程的节点确定为：开始、作业池、任务池、发布池、发布实例化、结束，在每个节点内，都有标准化的处理过程，节点之间关系相对独立。

进一步，所述气象服务发布智慧模型包括：

接口采集单元，用于采集或收集各种发布渠道的相关信息，包括发布渠道的设备名称、型号、使用方法、接口，接口sdk包；

插件封装单元，用于将收集的所有发布方式按照规范和标准封装成各个.dll文件，形成插件库，并供应在全流程和环节上使用；包括应用方法封装、接口封装、插件标准库建设、插件应用库驱动，插件供应；

作业处理单元，包括队列管理、动态解析匹配、发布实例化，用于管理客户提交的发布作业队列、发布任务队列、虚拟发布机队列；

服务接口单元，气象服务发布统一服务接口，用于以api方式提供标准接口让用户使用发布服务器中间件；

本发明的另一目的在于提供一种实施所述基于soa的气象服务产品发布服务器控制系统的基于soa的气象服务产品发布服务器控制方法，所述基于soa的气象服务产品发布服务器控制方法包括：

(1)用户根据实际的发布需求，由发布的服务产品、发布渠道、发布对象等的集合构成在终端上把发布请求推送到发布服务器，并存储到系统的作业池中，多个终端的发布请求就会形成发布作业队列；

(2)管理发布作业，并将作业按照系统定义的规则进行分解，形成一个一个的发布任务并放入任务池中；

(3)管理发布任务，在充分考虑计算机资源和发布任务的情况下，对发布任务进行组合分配，形成动态的虚拟发布机；

(4)通过虚拟发布机的方式发发布任务送到发布引擎；

(5)发布引擎根据发布规则、流程、方法把发布虚拟机上的发布任务发布到具体的各种发布设备上，完成整个发布过程。

进一步，所述基于soa的气象服务产品发布服务器控制方法的气象服务产品的发布策略包括：

1)对同一类发布对象数量太大，设置多个分组，并把分组视为平台处理；

2)不同接口独立线程并发发布方式之间采用计算机多线程技术同时进行发布；

3)不同平台之间采用并行处理算法或者采用优先级策略；

4)同一平台内采用队列方式处理。

进一步，所述基于soa的气象服务产品发布服务器控制方法的气象服务发布服务是根据气象服务发布的各种业务需求进行高度抽象，具体使用的流程：

(1)气象发布服务器布署：将气象发布服务器中间件布署在一台指定的服务器上，供气象发布的各单位、部门各业务系统使用；

(2)用户注册：使用气象服务发布服务器中间件必须通过注册模块进行注册；

(3)查看api文档：利用系统提供的api帮助文档，查看气象服务统一发布接口提供的标准应用编程接口；

(4)发布引用

用户可以在自己的系统或程序中，以api的方式直接调用或引入气象服务发布服务器，完成各种复杂情况下的气象服务发布工作。

本发明的另一目的在于提供一种实现所述基于soa的气象服务产品发布服务器控制方法的计算机程序。

本发明的另一目的在于提供一种实现所述基于soa的气象服务产品发布服务器控制方法的信息数据处理终端。

综上所述，本发明的优点及积极效果为：本发明基于soa技术设计了气象发布服务器的总体架构、气象服务产品发布的标准化流程和气象服务发布统一服务接口，即标准化的气象服务发布应用编程接口(api)；提出基于插件封装的气象服务产品智慧发布模型，解决面向不同发布渠道以及同一发布渠道不同厂(商)家的发布接口不规范的发布问题；较好地解决了气象发布服务的通用性；提出气象服务产品发布动态调度模型，较好地解决了气象发布服务的高并发处理机制；建立的气象服务发布业务系统显著提高了气象服务产品的发布效率与发布可靠性，有效降低了气象服务系统的建设成本，明显增强了产品发布部门和服务对象的用户体验。本发明与现有发布产品(系统)的主要发布参数的比较如下表：

本发明与现有发布产品(系统)比较分析

以本发明为依托，开发了省市县一体化气象灾害预警服务系统产品，产品在全国400多个单位和部门(省、市、县三级)投入业务运行，以县气象局的一次预警发布来看，过去发布一次预警平均需要20-40分钟，现在都可以控制在8分钟以内，快的话一般3-5分钟就可以完成，显著提高了基层气象台站的气象灾害预警发布效率。该产品在xx省气象局(含省本级相关机构、市州级、县级)共115个部门全面投入业务化运行，该平台构建了该省市县三级气象灾害预警发布、管理和绩效评价体系，创新性地实现了该省气象灾害预警联防联动，有效提高了该省气象灾害预警全业务流程的水平和能力。

xx省气象局在开发气象业务一体化平台中引入了本发明。该一体化平台的操作系统涉及linux和windows操作系统，编程语言涉及java和c#语言等。开发人员统一以api调用方式在多个业务模块(山洪地质灾害监测预警、短临预警模块、专业气象服务产品发布模块等)中构建了各种气象服务产品的一键式发布功能，使系统开发成本显著下降，开发效率明显提高，在投入业务应用时，其性能明显高于以往的一键式发布模块，其稳定性和可靠性得到了有效保证。

与现有技术相比(一键式发布技术)，本发明具有如下优点：

(1)一键式发布服务：访问接口提供面向系统的不同发布对象、不同发布方式、同一发布对象的不同接口实现一键式发布服务，即一次性把系统的所有发布完成，显著提高发布效率；

(2)标准化的服务方式：针对各种气象业务(服务)系统，不管其操作系统环境、技术环境、开发语言环境都可以提供标准化的服务方式；

(3)跨平台跨语言的开发方式：以http方式提供服务，支持所有平台和语言的调用。其中支持主流的操作系统包括linux32/64bit、aix、hp-ux、windows32/64bit等，提供多种语言的调用，包括c#、java、c/c++、fortran、php、python等；

(4)全面适应不断变化的业务需求：在技术不断进步发展的今天，新增和变换发布方式是必然的，如在某地增加气象应急服务云平台、在服务的某部门增加了一台新型的传真服务器等，另一方面，气象服务(如气象灾害预警发布)具有时间和空间不确定性，即在实际业务工作中要求提供7x24小时的不间断服务和提供第三方发布渠道接口的热更新服务。为了达到目的，系统通过监控插件变化，守护进程实现系统和第三方接口的热更新服务。即只要通过插件提供接口服务就可以保障在系统不停机的情况下继续使用发布服务，极大地保证用户的投资和软件具有较强的生命周期。

(5)发布管理精细化程度高：可以应对非常复杂的发布需求，包括发布数量大、发布方式的不确定性和可配置性、高并发的发布需求、发布调度的复杂性等，可以针对发布对象、气象灾害种类、预警等级等制定发布策略，解决了长期以来存在的气象服务产品发布延迟耗时长、发布遗漏、多发重发、发布不均衡性等问题，有效提高了气象服务产品发布的效率和质量。

附图说明

图1是本发明实施例提供的基于soa的气象服务产品发布服务器控制系统结构示意图；

图中：1、服务发布子系统；2、发布监控子系统；3、状态报告子系统；4、系统授权子系统。

图2是本发明实施例提供的基于soa的气象服务产品发布服务器控制方法流程图。

图3是本发明实施例提供的气象服务产品发布服务器总体架构图。

图4是本发明实施例提供的气象服务发布的标准化流程图。

图5是本发明实施例提供的气象服务产品智慧发布模型的组成结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

针对现有的气象服务产品(气象灾害预警产品)的发布通用性较差，发布效率较低的问题。本发明基于soa技术设计了气象发布服务器的总体架构、气象服务产品发布的标准化流程和气象服务发布统一服务接口，即标准化的气象服务发布应用编程接口(api)；提出基于插件封装的气象服务产品智慧发布模型，解决面向不同发布渠道以及同一发布渠道不同厂(商)家的发布接口不规范的发布问题。

下面结合附图对本发明的应用原理作详细的描述。

如图1所示，本发明实施例提供的基于soa的气象服务产品发布服务器控制系统包括：服务发布子系统1、发布监控子系统2、状态报告子系统3、系统授权子系统4。

服务发布子系统1是核心，发布监控子系统2、状态报告子系统3、系统授权子系统4是为服务发布子系统1服务。

服务发布子系统1，在计算机信息技术、网络技术、通信技术的支持下，建立面向不同发布接口(微信、微博、短信息、大屏大喇叭、业务平台等)的插件标准库和插件驱动库，在气象服务发布智慧模型的支持下，运用气象服务产品发布任务调度引擎实现产品发布任务的高效精准分配，并采用循环队列技术实现产品发布的高并发处理机制，最终通过气象服务产品发布引擎把气象服务产品发布到特定服务对象(人或机构)指定的气象信息接收终端上，真正实现气象服务产品的一键式发布；

发布监控子系统2，对发布过程全程进行监控，包括实时监控和发布统计，实时监控就是监控每个发布作业、发布任务正在执行的情况，便于随时掌握发布的进程，特别是了解没有发布成功的情况，便于系统执行重发，发布统计就是对一次发布情况的综合分析；

状态报告子系统3，面向统一服务接口提供的信息查询接口，包括信息发送和状态报告接口，提供的查询接口包括接口地址(如http://发布服务器ip/send)、支持格式(json)、http请求方式(post)、请求参数、返回结果等，在请求参数和返回结果中包含有具体的参数和对象；在信息发送接口中提供的查询内容包括发送内容(类型、驱动、信息、对象)、发送结果，在状态报告接口中提供的查询内容包括报告内容、内容详情、其他事项；

系统授权子系统4，是该系统的辅助功能或者前置功能，是注册管理系统用户、发布渠道(设备)、发布对象等。

如图2所示，本发明实施例提供的基于soa的气象服务产品发布服务器控制方法包括以下步骤：

s201：用户根据实际的发布需求(由发布的服务产品、发布渠道、发布对象等的集合构成)在终端上(计算机)把发布请求(作业)推送到发布服务器，并将其存储到系统的作业池中，多个终端(如不同县或者地区)的发布请求就会形成发布作业队列；

s202：管理发布作业，并将作业按照系统定义的规则进行分解，形成一个一个的发布任务并放入任务池中；

s203：管理发布任务，在充分考虑计算机资源(计算能力、网络情况、负载情况、资源利用和使用情况等)和发布任务的情况下，对发布任务进行组合分配，形成动态的虚拟发布机；

s204：通过虚拟发布机的方式发发布任务送到发布引擎；

s205：发布引擎根据发布规则、流程、方法把发布虚拟机上的发布任务发布到具体的各种发布设备上，完成整个发布过程。

下面结合附图对本发明的应用原理作进一步的描述。

为了使发布服务器能够高效工作，在总体设计上采用基于soa的架构设计(如图3)，分成四个不同的层次，包括业务层、控制层、服务层、应用层，系统以业务层为基础、以控制层为核心、以服务层为支撑、以应用层为目的组成发布服务器；其业务层部署插件库、业务组件、模型方法，即从系统需求出发，把与业务有关的内容变成方法、技术、模型、组件等全部进行封装，实现业务处理，使得其他层不再涉及业务内容，充分实现了业务与技术分离，方便实现不断变化的业务需求；控制层包括插件映射、虚拟发布、任务调度，这层是系统的核心功能，一方面作为桥梁作用，把系统的业务需求解析成系统可识别的技术和方法，另一方面，要求实现系统的各种控制，包括模型控制实现、算法实现、面向大规模的调度实现度体现在这层，本发明的核心也在这层体现；服务层包括组件服务、队列服务、网络服务、系统服务，前面两层可以说能够实现系统的功能了，但是要在服务器模式下实现该项功能，必须考虑在服务器模式下的各种服务，只有这样才能够解决其效率和面向大规模的队列处理等问题，充分考虑服务器资源和服务模式，才能够是效率发挥到最大，正是这层的主要任务，这种设计使得发布服务器设计概念更加清楚，更加易于使用和维护；应用层包括api应用、api文档，这层是直接面向用户的，api文档将告诉用户这样使用气象发布服务七，也是常常说的帮助文档，api应用就是提供了一套怎样使用发布服务器的应用编程接口；该系统采用基于soa的架构设计，设计思路清晰、层次分明，各层之间采用松耦合，充分实现面向大规模的并发的气象服务发布任务的快速发布，提高气象服务发布效率。

发布流程设计：对当前气象服务的流程、环节、产品、发布对象、渠道等情况进行分析并将其总结如表1所示：

表1气象服务情况分析汇总表

从表1看，气象服务发布的复杂性主要表现在：气象服务部门复杂性、气象服务产品复杂性、气象服务对象的复杂性、气象服务渠道的复杂性、气象服务发布实现的复杂性，并且这些复杂性相互影响、相互作用，对气象服务产品的发布造成的影响不可忽视。另一方面，由于发布需求的复杂性和多样性，使得各个单位、各个部门的发布流程就千差万别，都给气象服务产品发布的标准化发布带来困难。本发明为了解决这一难题，另劈蹊径，从技术实现的角度出发，定义全新的流程节点和标准化流程，实现气象服务产品发布流程的标准化。其具体的标准化流程如图4所示。

首先，系统在标准化流程实现过程中引入了如下一些概念：

作业池：发布数据中心载体之一，用于存放用户提交的气象服务发布作业，存储实体；

任务池：发布数据中心载体之一，用于存放系统产生的气象服务发布任务，往往由发布作业通过一定的方法生成，存储中间过程；

发布池：发布数据中心载体之一，用于存放系统产生的气象服务虚拟发布机，存储中间过程；

虚拟发布机：发布数据中心载体之一，系统考虑发布任务与计算机资源综合生成的发布任务集合，存储中间过程；

管理器：管理大规模的气象服务发布作业、任务、发布虚拟机、调度等，因此，存在作业管理器、任务管理器、发布(虚拟机)管理器、调度管理器等概念，他们分别管理各个发布环节的作业、任务、发布等，实现的功能主要包括增加、修改、删除等，但各个管理器的功能不完全一样；

发布引擎：按照一定的规则、流程、方法把气象服务产品发布到具体的设备上。

气象一键式发布机制：顾名思义，一键式发布就是在面对气象多种发布渠道、多种发布对象时一次性地把服务产品发布到所有需要发布的设备上，其目的就是为了减轻发布工作强度，提高发布工作效率。

其次，根据发布实现机制把发布过程的节点确定为：开始、作业池、任务池、发布池、发布实例化、结束，在每个节点内，都有标准化的处理过程，节点之间关系相对独立。

具体的发布流程如下：

第一，用户根据实际的发布需求(由发布的服务产品、发布渠道、发布对象等的集合构成)在终端上(计算机)把发布请求(作业)推送到发布服务器，并将其存储到系统的作业池中，多个终端(如不同县或者地区)的发布请求就会形成发布作业队列；

第二，管理发布作业，并将作业按照系统定义的规则进行分解，形成一个一个的发布任务并放入任务池中；

第三，管理发布任务，在充分考虑计算机资源(计算能力、网络情况、负载情况、资源利用和使用情况等)和发布任务的情况下，对发布任务进行组合分配，形成动态的虚拟发布机；

第四，通过虚拟发布机的方式发发布任务送到发布引擎；

第五，发布引擎根据发布规则、流程、方法把发布虚拟机上的发布任务发布到具体的各种发布设备上，完成整个发布过程。

气象服务智慧发布模型：下面来看一个实际的例子：2016年6月xx日xx省气象局和下属的市县共100多个部门几乎在同时都需要发布暴雨橙色预警。在发布过程中，都需要向国突平台发布预警，因而，在发布过程中造成很多市县用户在发布中等待时间过长(近20分钟未发完)，分析原因，不难发现，大家都需要使用国突平台发布，当然就需要排队了。因此，在构建一键式发布时，不仅要考虑不同发布渠道之间的并发问题，还需要考虑同一发布方式发布数据量过大的处理技术，即要考虑负载均衡问题，要从发布的全局考虑问题，充分考虑发布渠道、发布对象、发布量、发布资源、系统资源等之间的平衡问题，即需要考虑气象服务的智慧发布问题，才能从根本上解决气象服务发布效率问题。气象服务产品智慧发布模型从技术实现方法上是从低层各发布模块开始，逐渐进行封装、抽象、组织成一个统一发布模型(顶层)，实现其标准化应用的方法，其组成结构如图5所示：

从图5看，气象服务智慧发布模型的主要内容包括：

(1)接口采集。即采集或收集各种发布渠道的相关信息，包括发布渠道的设备名称、型号、使用方法、接口，接口sdk包等，只有知道接口信息才能在发布服务器中使用。系统已对当前在气象行业中常使用的一些主要设备(渠道)进行了采集，发布渠道多种多样，既使同一发布渠道也有不同厂(商)家的产品，这些产品的发布驱动应用环境和使用参数也不同，因此，气象发布渠道很难有统一的标准，要提高气象服务发布的效率，必须对发布渠道的接口进行标准化处理。

(2)插件封装。插件封装就是将收集的所有发布方式(渠道)按照一定的规范和标准统一封装成各个.dll文件，形成插件库，并供应在全流程和环节上使用。从实现来看，包括应用方法封装、接口封装、插件标准库建设、插件应用库驱动，插件供应等。其中，应用方法封装就是针对每一种发布方式(渠道)的使用方法进行标准化封装；接口封装就是针对每一种发布方式的发布接口进行封装，并将这两种封装联结到一起形成一个dll文件，成为一个插件文件(*.dll)。如果针对所有接口都进行封装并组织在一起就形成了一个插件标准库。然而一个用户不可能使用所有发布渠道，系统从机制上采用注册制方式形成用户插件件，即插件驱动库，确保用户使用的接口是轻量级和私有化的，从而提高系统设备级发布性能，最后将插件驱动库供应给全流程使用，实现标准化应用。

(3)作业处理。主要包括队列管理、动态解析匹配、发布实例化等内容。在发布的全过程，需要管理客户提交的发布作业队列、发布任务队列、虚拟发布机队列。因此，系统设计了管理器来管理三种不同的队列；从发布流程来看，第一步就是作业解析，一个作业中包括有服务产品、发布渠道(多个)、发布对象(多个)，要实现发布，需要将作业进行解析分解成一个个的发布任务(服务产品、发布渠道、发布对象)；第二步就是在任务调度服务(模型)支持下，充分考虑各种条件(在任务调度模型中详述)将全部任务分配到多个虚拟发布机；第三步，多个虚拟发布机采用并发的方式发布相应的任务；第四步，分解虚拟发布机发布任务再利用发布引擎把具体的服务发布到具体的发布渠道和发布对象，在这一过程中，充分考虑发布参数和发布渠道的匹配问题，实现自适应，从而完成整个发布过程。

(4)服务接口。就是气象服务发布统一服务接口，就是以api方式提供一套标准接口让用户使用发布服务器中间件。提供的接口不依赖于任务操作系统和编程语言，提供的接口内容包括信息发送接口(格式)、状态报告接口(格式)，具体包括接口地址(如http：//发布服务器ip/send)、支持格式(json)、http请求方式(post)、请求参数、返回结果等。在请求参数和返回结果中既包含有具体的参数和对象，通过这些参数和对象自动与插件匹配，再通过插件的属性和方法把信息发送出去。从而实现发布服务器的全流程智慧服务。

气象服务发布策略与发布动态调度引擎：气象业务系统的建设要求实现集约化，气象服务也不例外，国突系统就是一个典型例子。以一个县为例，平均而言发布渠道有6-8种、每种发布渠道的用户数为100左右(如短信用户远不止)、每个省平均50个县(多数远不止)，这样全省发布作业就是30000～40000(个)。如果这样大规模作业在较短时间内并发，带来的用户体验必然是等待时间较长，甚至有超过30分钟的，这样就会出现灾害已发生而预警未发出的情况。

在气象服务产品发布体系中，每个服务部门会发布多个产品，每个产品根据类型和用途会形成多种格式，每种载体可有多种发布方式，每种发布方式根据优先级和任务规模可有多个发布池，因此，一次发布就建立了产品格式、发布方式、服务对象之间的关系；而发布需求有发布方式多样、服务对象规模较大的特征，发布方式多样体现在该产品的发布涉及多种不同的发布方式，并且手机短信息、大屏大喇叭还涉及多个平台；服务对象规模较大体现在气象服务对象数量较多，特别是短信息数量多，即使把其中一个平台的短信息作为一个队列来处理，数量还是很大，发布需要的时间很长，发布效率很低。鉴于上述特征，设计气象服务产品的发布策略如下：

1)对同一类发布对象(可视为同一队列)数量太大，可以设置多个分组(分组可以根据用户的需要而定)，并把分组视为平台处理；

2)不同接口独立线程并发发布方式之间采用计算机多线程技术同时进行发布；

3)不同平台(组)之间采用并行处理算法或者采用优先级策略；

4)同一平台(组)内采用队列方式处理。

上述发布策略充分利用计算机的高速计算功能为气象服务产品发布服务，确保气象方式、平台多样化，服务对象很多的情况下都能够保证气象服务产品很快及时地发出去，确保气象服务产品发布效率，更好地为防灾减灾服务。

另一方面，在计算机网络环境下，还需要考虑计算能力、网络情况、负载情况、资源利用和使用情况等，统称计算机资源。因此，设计气象服务发布服务器必须充分考虑作业(任务、虚拟发布机)与作业、资源与资源、作业与资源等相互关系，引入任务调度模型，实现高并发处理和任务动态调度机制，才能满足气象发布业务需要。

从气象服务产品发布智慧模型来看，会出现大量的发布作业，形成海量的发布任务队列。传统队列方法需要锁定队列，在队列较小的情况下影响不大，但对于发布任务很大的队列其性能会受到严重影响，因此，在技术实现上，引入环形队列，解决面临大规模发布任务的并发处理，提高发布性能。从发布服务器的标准化流程来看，客户机发布作业请求首先达到发布池，在对作业队列管理的基础上，将发布作业分解成海量发布任务并放入任务池。而构成发布任务的信息包括服务产品信息(名称、类别、格式、优先级，...)、发布渠道信息(名称、类型、方法、环境、参数、优先级，...)、发布对象(名称、联系方式、发布渠道，...)、发布方法、发布资源等，这些发布信息构成一个产品发布n维空间。为此，提出一个基于环形队列和基于超立方格子树sg-tree的区域匹配生成算法实现气象服务产品发布任务动态调度。其产品发布任务动态调度关键步骤如下：

(1)作业池的构建：基于服务产品、发布渠道、发布对象、系统用户，生成由产品内容实例、发布对象实例、发布渠道三要素构成的发布作业池，为气象服务产品发布构建基础的发布数据库；

(2)作业解析与任务预分配：因为每一项发布作业都包含有多项发布任务，并且每个用户提交的发布作业都不一样，即使是同一个用户每次提交的作业包含的任务也不相同，这是由气象业务具有较强的时间和空间性质决定的，因此必须对发布作业进行解析，形成标准化的发布任务，多个发布作业将形成海量的标准的发布任务；系统根据产品优先级、服务对象优先级、发布方式优先级，计算出任务的发布优先级，并根据发布池任务规模、计算资源负载将发布任务池中的任务预分配到相应的发布池中；

(3)虚拟发布机生成：从前面的作业解析看到，生成的发布任务是海量的。理论上可以进行并发发布了。但是，这样势必造成并发量相当大。因此，系统根据发布任务、计算机资源情况、任务优先级等情况对发布作业按照资源使用情况和相关规则生成组合发布任务，定义为虚拟发布机。使海量发布任务大大减小，可以更快地把发布任务快速发布出去。

(4)发布性能监控：发布引擎通过发布接口驱动库从各发布池获取发布任务，对发布任务进行标准化调用，并通过分布式、多线程并发处理机制、重发转发机制实现产品内容的发送，保证产品可靠送达服务对象，有效解决漏发现象，并向调度引擎反馈发布池接口池负载参数和发布日志信息；

(5)发布任务动态调度：监控发布日志，一个发布任务执行成功，会通过发布日志回馈机制，同步调整此任务的同根任务(一个产品通过多种方式发往一个服务对象时会生成同产品同服务对象但不同发布接口池的发布任务，称之为同根任务)在接口池中的顺序；若任务重发仍不成功，则会同步调整同根任务在接口池中的顺序。以保证每个服务对象都能尽快收到服务产品，有效解决发布延迟问题和发布均衡问题；

(6)发布全程调度：发布过程中有新的服务产品进入气象服务产品库时，实时调整各发布池任务列表，进行发布池的扩展、迁移、合并、撤销控制，动态维护产品发布的高效性和可靠性。

根据前面的发布动态调度算法和发布调度实现的步骤就可以开发出气象服务产品动态调度引擎来实现产品的调度策略和调度管理。

一键式发布引擎：任务调度引擎解决了大规模发布任务的动态分配调度问题，服务产品最终送达服务对象还需要对任务进行高效的执行(发布)，这是发布引擎要解决的问题。在任务调度引擎的支持下，发布引擎模拟了大量的“发布机器人”同时对发布池中的大规模的发布任务进行自动分发，发布引擎采用分布式的并发技术，发布日志回馈机制，通过调度引擎进行重发、转发、宿主迁移等控制，实现任务的快速、准确、可靠的发布，极大提高发布效率。

任务的发布主要是通过一键式发布方式实现的。一键式发布过程在插件驱动库的支持下，发布引擎监听各发布池的任务登记，从服务产品库取得产品内容，通过标准接口调用发布池的驱动模块将数据发送出去，通过发布日志回馈机制对发布任务进行重发、转发等处理(当任务失败时进行重发处理，当重发失败时优先执行同根任务，当任务发送成功后根据发布池负载适当调整同根任务优先级)。它包含发布作业入库(池)、作业解析、任务动态组合、虚拟发布机实时分配、发布池任务自动执行、发布任务跟踪与动态调度等核心环节，其中发布池在任务调度与任务执行之间起着承上启下、虚实转换的桥梁角色，发布池建立了发布服务器资源与发布驱动之间的关联，任务调度引擎和发布引擎作为守护进程，对任务池、发布池任务清单、发布日志进行监控，确保将任务及时发布出去。

发布引擎有效保证了产品发布的高可靠性、高并发性，解决了产品发布的漏发、延迟、不均衡性问题。同时，基于发布接口驱动库的标准接口调用机制使发布引擎具有标准化、规范化、高可扩展的突出特点，使一键式产品发布技术框架具有高可维护性和使用便捷性的优势。

使用流程与方法：气象服务发布服务器是一款中间件软件，是根据气象服务发布的各种业务需求进行高度抽象的共用软件系统，可以在不同技术环境(操作系统、开发语言)和不同业务平台下使用，具体使用的流程和方法如下：

(1)气象发布服务器布署：将气象发布服务器中间件布署在一台指定的服务器上，供气象发布的各单位、部门各业务系统使用；

(2)用户注册：需要使用气象服务发布服务器中间件必须通过注册模块进行注册，便于系统识别，方可使用；

(3)查看api文档：利用系统提供的api帮助文档，查看气象服务统一发布接口提供的标准应用编程接口(api)，了解相关方法、对象、参数等内容，了解系统提供的程序示例，基本了解怎样使用中间件系统。

(4)发布引用

用户可以在自己的系统(或程序中)，以api的方式直接调用或引入气象服务发布服务器，完成各种复杂情况下的气象服务发布工作。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用全部或部分地以计算机程序产品的形式实现，所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输)。所述计算机可读取存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。