一种基于事项业务规则的智能分发调度系统的制作方法

本发明涉及业务支撑技术领域，具体提供一种基于事项业务规则的智能分发调度系统。

背景技术：

加快电子政务建设是提高党政机关工作效率、政府公共服务水平和社会城市管理水平的重要手段。“十二五”期间，各级政府高度重视电子政务工作全面进入了服务主导、应用深化、集约发展、整体推进的新时期。随着行政审批制度改革的深入，条与块之间相互衔接与协同的问题越来越突出。为了加强经济调节、市场监管、社会管理和公共服务职能必须加强条条的作用，然而过度的专业分工却给社会治理带来新的问题，特别是基层政府作为党委、政府工作的承受层、操作层和落实层，由于信息孤岛、业务壁垒导致工作压力越来越大，因此解决该类问题成为政府改革政务服务工作的重点。

通过整合现有各类基层公共服务平台的场所、设备、系统、人员、经费等资源，提供综合窗口受理服务，逐步实现“前台一口受理，后台分工协办”的工作模式。但是由于各个平台系统都有自己的数据标准，互相间的调用没有统筹处理，对接的接口不统一，导致出现对接困难，重复对接的问题，最后由于各种问题导致对接不了。各部门间的平台系统想打造成协同办公系统，实现与各部门审批业务系统的无缝对接，实现起来非常困难。

技术实现要素：

本发明的技术任务是针对上述存在的问题，提供一种能够有效的解决对接难、重复对接、高成本对接问题的基于事项业务规则的智能分发调度系统。

为实现上述目的，本发明提供了如下技术方案：

一种基于事项业务规则的智能分发调度系统，所述智能分发调度系统依据事项的业务规则，定义适配器，用于各个事项的个性接口，对外提供统一接口标准，标准接口定义完成后，发布到智能分发调度系统中，指定统一的事项业务标准，通过灵活的调度配置，接入各单位的事项业务，实现各单位事项业务间的相互调用，各个业务系统只需要调用调度系统的标准接口，由调度系统完成各个业务系统间的协作。

本发明所述的基于事项业务规则的智能分发调度系统能够打破各个业务系统信息壁垒，可以将申办、受理数据分发到各部门自建系统，各部门也可以直接通过智能分发调度系统提供的对接服务获取数据，实现单事项、垮部门(垮层级)协同审批事项分发汇集的传输。

所述智能分发调度系统自带路由功能，可以根据每个节点数据流大小控制对接数据的流向，解决大并发的场景业务系统排队调用接口的问题。系统自备服务监控、服务对账、服务二次提交功能。

市基层公共服务综合平台对统一受理应用系统、市(区)部门审批系统、基层公共服务系统进行整合，由调度管理系统进行协同调度。调度管理系统集中部署，实现市区街社四级垂直分拨调度。

作为优选，所述智能分发调度系统的功能包括事项服务集成、事项数据缓存管理、事项通信管理、服务监控、服务安全和接口设计，事项服务集成功能包括事项映射、协议转换、服务编排、事项管理和自定义适配器；事项数据缓存管理功能包括缓存超时管理、缓存策略定义、缓存持久化、缓存命中率和缓存索引；事项通信管理功能包括事项接口寻址、发布/订阅、接口标准管理、同步/异步消息和响应/请求；服务监控功能包括服务监控、调用统计、服务评估和服务测试；服务安全功能包括认证、授权、加密和日志；接口设计功能包括调用流程和接口类别。

作为优选，所述事项服务集成功能的事项映射为配置综合受理事项与对接业务系统事项间的关系，定义事项名称对应关系、事项编码对应关系，包括一对一映射、复杂元素映射、多对多元素映射、一到多映射、多到一映射。

一对一映射：直接将源字段赋给目标字段。

复杂元素映射：直接将同属性名的子元素映射到目标对象，属性名不同的被忽略，如果子元素为数组，则忽略。

多对多元素映射：在目标上创建相同个数的元素，如果子元素为数组，则忽略。

一到多映射：同一个源元素可以映射到多个目标元素。

多到一映射：映射规则中不支持多对一映射，如果希望将多个元素的某个值、和值、平均值映射到单一的目标元素，则需要使用公式规则。如果希望将多个元素筛选使用，则需要使用过滤规则。

作为优选，所述事项服务集成功能的协议转换为不同业务系统使用不同的协议传递消息，调度管理系统提供不同的接口类型以适应不同的入口或出口，协议的转换在调度管理系统内部封装完成，不需要在接入系统端做太多相关修改。

服务编排指的是以用户需求为目的，将各种服务或要素进行科学的安排和组织，使各个组成部分平衡协调，生成能够满足用户要求的服务。

通过服务分析和设计来定义一个完整的组合服务或流程服务，这个服务有完整的服务接口和服务契约文件，和传统方法的区别就在于这个组合服务是通过服务编排来实现出来的，而不需要通过程序开发代码的方式来实现服务的编排和组合。

编排的重点是服务可以接服务，因此往往上一个服务的输出将成为下一个服务的输入信息，在上一个服务进行服务调用和计算得到结果后将输出信息直接和下一个服务的输入信息进行映射，就达到基本的服务组装和编排的目的。

事务管理主要包括分布式事务、两阶段提交、一阶段提交、事务补偿机制等。

分布式事务：xa是由x/open组织提出的分布式事务的规范。xa规范主要定义了(全局)事务管理器(transactionmanager)和(局部)资源管理器(resourcemanager)之间的接口。xa接口是双向的系统接口，在事务管理器(transactionmanager)以及一个或多个资源管理器(resourcemanager)之间形成通信桥梁。xa之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲，两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源。

两阶段提交是指第一阶段：准备阶段，第二阶段：提交阶段。将提交分成两阶段进行尽可能晚地提交事务，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶段将是一个耗时极短的微小操作，这种操作在一个分布式系统中失败的概率是非常小的，也就是所谓的“网络通讯危险期”非常的短暂，这是两阶段提交确保分布式事务原子性的关键所在。从两阶段提交的工作方式来看，很显然，在提交事务的过程中需要在多个节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时，这样，比起一阶段提交，两阶段提交在执行同样的事务时会消耗更多时间。事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量达到一定数量的时候，就会出现大量事务积压甚至出现死锁，系统性能就会严重下滑。

一阶段提交：是从应用程序向数据库发出提交请求到数据库完成提交或回滚之后将结果返回给应用程序的过程。一阶段提交不需要“协调者”角色，各结点之间不存在协调操作，因此其事务执行时间比两阶段提交要短，但是提交的“危险期”是每一个事务的实际提交时间，相比于两阶段提交，一阶段提交出现在“不一致”的概率就变大了。

事务补偿机制：对于基于http/webservice/rpc/jms等构建的高度自治(autonomy)的分布式系统接口，一阶段提交模式是无能为力的，此类场景下，事务补偿机制可以实现“最终一致性”。

由于各个单位的业务系统千差万别，各种系统的数据格式完全不一样，这就涉及到数据识别的问题，比较通用的做法是为每一种数据格式开发一套适配器，比如有数据库适配器、文件适配器等，数据库适配器又分为oracle适配器、sqlserver适配器等。

系统支持对于适配器的自定义开发，可以根据实际的扩展需要进行自定义开发。

作为优选，事项数据缓存管理功能综合受理完成的事项数据全部进入调度中心的缓存池，由调度中心统一进行调度，通过对接中心转送到各业务系统。

缓存超时管理：综合受理完成的事项数据进入调度中心缓存池后，系统通过对事项数据的监控，实现对事项数据状态的监控。

系统设定每条事项数据被调度发送的超时时间，对于超过时间而未被业务系统取走的事项数据，根据设定的规则进行处理。

系统可以设定缓存数据的超时时间以及超时后如何进行处理。

缓存策略定义：系统为事项数据的调度设定优先级，可以按照先到先走的顺序进行调度，也可以根据实际的消息参数进行加急调度。

缓存持久化：对于在缓存池长时间未被成功调度的事项数据进行持久化处理，采用数据库表或存储硬盘的方式存储超时数据，并对持久化的数据进行分析，记录未被成功调度的原因，持久化的数据也可以通过调度中心的设定继续完成调度。

缓存命中率：系统通过记录各业务系统服务从缓存池中获取事项数据的成功率，评估服务的运行健康情况。

缓存索引：系统为存储在缓存池中的所有事项数据提供索引，管理人员可以查询事项数据，监控数据的调度情况，并可以对数据进行手工调度。

作为优选，所述事项通信管理功能的接口标准管理中，调度管理系统与业务系统之间消息交互通过标准接口进行，实现调度管理系统与业务系统之间的消息传送，主要包括发送接口、状态报告。

发送接口实现将事项数据由调度管理系统送到业务系统。

状态报告用于报告发送的事项数据的投递情况，显示数据是够正常被接收的信息。

事项接口寻址：为事项服务提供一个基于服务总线的服务寻址模式，以达到为服务的位置提供透明支持的目的。使用服务总线的寻址，外部服务运行环境所依赖的地址，对服务总线上的其他服务能够做到完全透明。

发布/订阅：使消息的分发可以突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发，用户或应用程序可以根据主题或内容接收到所需要的消息。发布/订阅功能使得发送者和接收者之间的耦合关系变得更为松散，发送者不必关心接收者的目的地址，而接收者也不必关心消息的发送地址，而只是根据消息的主题进行消息的收发。

同步/异步消息：调度管理系统的通信方式分为同步发送和异步发送。

同步发送保证了每条消息都被顺利收到并得到处理，若发送消息之后等待超时表示对方可能未妥善收到并处理消息，发送方可以对消息进行重发等操作。因此同步发送的方式一定程度上保证了消息的可靠性。

异步方式由于中间存在收发缓存，当接收端进程异常重启，缓存内消息可能丢失，因此发送方发出去的消息并不能保证被接收并得到处理。像线程级的异步来说，必须在收发双方的消息中增加消息序列号，并对发送的每条消息，消息发送的序列号，消息接收的序列号进行持久化，这样进程重启之后可以对双方的序列号进行同步，从持久化模块中取出丢失的部分消息。以这样的方式才能保证消息发送的可靠性。

响应/请求：在响应/请求消息发送模式中，一个应用程序发送一条消息(请求消息)到另一个响应应用程序(响应生成器)再到请求消息。生成响应的应用程序获取请求消息、处理请求，并向请求应用程序发出响应。响应发送到由请求消息的消息标题属性replytoqueuemanager指定的队列。请求应用程序在放置消息到队列上之前会在请求消息上设置这些消息标题属性。

作为优选，所述服务监控功能的服务监控包括调度异常监控、节点监控和调度监控，用于调度结果查询和调度历史记录。

调度结果查询：对于调度管理系统中调度的过程进行查询，并进行相关问题分析，会涉及所有跨系统业务的调度，业务量比较大，业务流转比较复杂，在这里要对这些调度过程要进行有效的管理，以方便对业务及数据的追踪。

调度历史记录：对于所有的调度操作进行记录，以方便后续的数据统计分析，历史记录追踪等。

调度管理系统中会涉及所有跨系统业务的调度，业务量比较大，业务流转比较复杂，在这里要对这些调度过程要进行有效的管理和监控，以方便对业务及数据的追踪。

调用统计：对调度管理系统中调度数据进行统计，参与服务交互的应用系统，每次发起或接受服务，调度管理系统都对其进行计数，并记录服务请求时间，服务完成时间，发起服务实体id，服务实体id，服务操作，服务状态等。主要包括：调度情况展示，调度问题分析，调度流量分析等。调度情况展示主要是指经过调度系统中调度过程展示。

服务评估：主要是对服务的调度效率，调度成功率，影响调度的原因及集中调度系统的健康状况等分析。分析出业务量的多少，帮助相关人员对于业务的受理等进行相应的调整。

服务测试：系统提供对已注册所有服务的状态测试，功能逻辑如下：

a)获取前端输入url或wsdl文档服务地址；

b)创建服务地址的资源连接对象；

c)应用资源连接对象与ws服务进行连接，若连接成功，则服务可用，反之则服务异常；

d)服务检测结果列表返回，检测结果包括：服务id、服务名称、服务url、方法名、状态。

作为优选，所述服务安全功能的认证保证接入调度管理系统的合法性，提供业务应用系统和调度管理系统之间的双向身份认真，采用基于证书的认证模式。

授权：对相应的调度服务进行权限管理，提供安全有效的调度机制，使相关系统间的调用在可按范围内进行。

作为优选，所述服务安全功能的加密为系统采用证书的方式加密服务调用数据，调度中心使用接收方的公匙对数据加密，接收方则使用自己的私匙解密。

日志：控制台流水日志记录前端控制台的所有操作，包括登录、认证、配置、修改、注销等操作。

路由关系配置日志记录路由关系配置的全过程留痕，记录配置过程的每一步操作。

作为优选，所述接口设计功能的接口类别中，应用对接管理系统中的标准接口分为通知类和业务类。

调用流程：

1.市、区统一受理系统接口发布到应用对接管理时，需配置接口服务与标准接口服务的关联关系。

2.委办局接收到新业务时，直接调用应用对接管理系统的标准接口服务，按标准发送请求参数。

3.应用对接管理系统接收请求参数后，根据“目标系统编号”，将请求参数流转到市/区统一受理系统接口服务。

4.市/区统一受理系统返回参数到应用对接管理系统。

5.应用对接管理系统将“返回参数”流转到委办局，完成信息交换。

与现有技术相比，本发明的基于事项业务规则的智能分发调度系统具有以下突出的有益效果：

(一)业务接口的标准化

通过调度管理系统的适配器，对外提供标准的接口，避免了接口重复开发，相同类型的接口标准不同的问题，为事项业务间的互联互通，提供统一标准。

(二)提高数据对接有效性

通过调度系统的实时服务监控以及服务数据缓存服务，在一定程度上提高了数据的有效性，完整性，解决数据对接中丢件的问题。

(三)数据对接的安全性

调度系统自带的服务安全机制，从认证、授权、加密、审计日志等几个方面加深了数据的安全维护，使对接双方的数据更安全。

附图说明

图1是本发明所述基于事项业务规则的智能分发调度系统的结构框图；

图2是本发明所述基于事项业务规则的智能分发调度系统的两阶段提交的示意图；

图3是本发明所述基于事项业务规则的智能分发调度系统的调用流程示意图。

具体实施方式

下面将结合附图和实施例，对本发明的基于事项业务规则的智能分发调度系统作进一步详细说明。

实施例

如图1所示，本发明的基于事项业务规则的智能分发调度系统，依据事项的业务规则，定义适配器，用于各个事项的个性接口，对外提供统一接口标准，标准接口定义完成后，发布到智能分发调度系统中，指定统一的事项业务标准，通过灵活的调度配置，接入各单位的事项业务，实现各单位事项业务间的相互调用，各个业务系统只需要调用调度系统的标准接口，由调度系统完成各个业务系统间的协作，该智能分发调度系统的功能包括事项服务集成、事项数据缓存管理、事项通信管理、服务监控、服务安全和接口设计。

一、事项服务集成功能包括事项映射、协议转换、服务编排、事项管理和自定义适配器。

事项映射为配置综合受理事项与对接业务系统事项间的关系，定义事项名称对应关系、事项编码对应关系，包括一对一映射、复杂元素映射、多对多元素映射、一到多映射、多到一映射。

一对一映射：直接将源字段赋给目标字段。

复杂元素映射：直接将同属性名的子元素映射到目标对象，属性名不同的被忽略，如果子元素为数组，则忽略。

多对多元素映射：在目标上创建相同个数的元素，如果子元素为数组，则忽略。

一到多映射：同一个源元素可以映射到多个目标元素。

多到一映射：映射规则中不支持多对一映射，如果希望将多个元素的某个值、和值、平均值映射到单一的目标元素，则需要使用公式规则。如果希望将多个元素筛选使用，则需要使用过滤规则。

协议转换：不同业务系统使用不同的协议传递消息，调度管理系统提供不同的接口类型以适应不同的入口或出口，协议的转换在调度管理系统内部封装完成，不需要在接入系统端做太多相关修改。

服务编排：以用户需求为目的，将各种服务或要素进行科学的安排和组织，使各个组成部分平衡协调，生成能够满足用户要求的服务。

通过服务分析和设计来定义一个完整的组合服务或流程服务，这个服务有完整的服务接口和服务契约文件，和传统方法的区别就在于这个组合服务是通过服务编排来实现出来的，而不需要通过程序开发代码的方式来实现服务的编排和组合。

编排的重点是服务可以接服务，因此往往上一个服务的输出将成为下一个服务的输入信息，在上一个服务进行服务调用和计算得到结果后将输出信息直接和下一个服务的输入信息进行映射，就达到基本的服务组装和编排的目的。

事务管理主要包括分布式事务、两阶段提交、一阶段提交、事务补偿机制等。

分布式事务：xa是由x/open组织提出的分布式事务的规范。xa规范主要定义了(全局)事务管理器(transactionmanager)和(局部)资源管理器(resourcemanager)之间的接口。xa接口是双向的系统接口，在事务管理器(transactionmanager)以及一个或多个资源管理器(resourcemanager)之间形成通信桥梁。xa之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲，两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源。

如图2所示，两阶段提交是指第一阶段：准备阶段和第二阶段：提交阶段。将提交分成两阶段进行尽可能晚地提交事务，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶段将是一个耗时极短的微小操作，这种操作在一个分布式系统中失败的概率是非常小的，也就是所谓的“网络通讯危险期”非常的短暂，这是两阶段提交确保分布式事务原子性的关键所在。从两阶段提交的工作方式来看，很显然，在提交事务的过程中需要在多个节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时，这样，比起一阶段提交，两阶段提交在执行同样的事务时会消耗更多时间。事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量达到一定数量的时候，就会出现大量事务积压甚至出现死锁，系统性能就会严重下滑。

一阶段提交：是从应用程序向数据库发出提交请求到数据库完成提交或回滚之后将结果返回给应用程序的过程。一阶段提交不需要“协调者”角色，各结点之间不存在协调操作，因此其事务执行时间比两阶段提交要短，但是提交的“危险期”是每一个事务的实际提交时间，相比于两阶段提交，一阶段提交出现在“不一致”的概率就变大了。

事务补偿机制：对于基于http/webservice/rpc/jms等构建的高度自治(autonomy)的分布式系统接口，一阶段提交模式是无能为力的，此类场景下，事务补偿机制可以实现“最终一致性”。

由于各个单位的业务系统千差万别，各种系统的数据格式完全不一样，这就涉及到数据识别的问题，比较通用的做法是为每一种数据格式开发一套适配器，比如有数据库适配器、文件适配器等，数据库适配器又分为oracle适配器、sqlserver适配器等。

系统支持对于适配器的自定义开发，可以根据实际的扩展需要进行自定义开发。

二、事项数据缓存管理功能包括缓存超时管理、缓存策略定义、缓存持久化、缓存命中率和缓存索引。

综合受理完成的事项数据全部进入调度中心的缓存池，由调度中心统一进行调度，通过对接中心转送到各业务系统。调度中心缓存池的存在，事项数据与业务系统之间统一调度，优化调用流程，提高调用速度。包括缓存超时管理、缓存策略定义、缓存持久化、缓存命中率和缓存索引。

缓存超时管理：综合受理完成的事项数据进入调度中心缓存池后，系统通过对事项数据的监控，实现对事项数据状态的监控。

系统设定每条事项数据被调度发送的超时时间，对于超过时间而未被业务系统取走的事项数据，根据设定的规则进行处理。

系统可以设定缓存数据的超时时间以及超时后如何进行处理。

缓存策略定义：系统为事项数据的调度设定优先级，可以按照先到先走的顺序进行调度，也可以根据实际的消息参数进行加急调度。

缓存持久化：对于在缓存池长时间未被成功调度的事项数据进行持久化处理，采用数据库表或存储硬盘的方式存储超时数据，并对持久化的数据进行分析，记录未被成功调度的原因，持久化的数据也可以通过调度中心的设定继续完成调度。

缓存命中率：系统通过记录各业务系统服务从缓存池中获取事项数据的成功率，评估服务的运行健康情况。

缓存索引：系统为存储在缓存池中的所有事项数据提供索引，管理人员可以查询事项数据，监控数据的调度情况，并可以对数据进行手工调度。

三、事项通信管理功能包括事项接口寻址、发布/订阅、接口标准管理、同步/异步消息和响应/请求。

事项接口寻址：为事项服务提供一个基于服务总线的服务寻址模式，以达到为服务的位置提供透明支持的目的。使用服务总线的寻址，外部服务运行环境所依赖的地址，对服务总线上的其他服务能够做到完全透明。

发布/订阅：使消息的分发可以突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发，用户或应用程序可以根据主题或内容接收到所需要的消息。发布/订阅功能使得发送者和接收者之间的耦合关系变得更为松散，发送者不必关心接收者的目的地址，而接收者也不必关心消息的发送地址，而只是根据消息的主题进行消息的收发。

接口标准管理中，调度管理系统与业务系统之间消息交互通过标准接口进行，实现调度管理系统与业务系统之间的消息传送，主要包括发送接口、状态报告。

发送接口实现将事项数据由调度管理系统送到业务系统。

状态报告用于报告发送的事项数据的投递情况，显示数据是够正常被接收的信息。

同步/异步消息：调度管理系统的通信方式分为同步发送和异步发送。

同步发送保证了每条消息都被顺利收到并得到处理，若发送消息之后等待超时表示对方可能未妥善收到并处理消息，发送方可以对消息进行重发等操作。因此同步发送的方式一定程度上保证了消息的可靠性。

异步方式由于中间存在收发缓存，当接收端进程异常重启，缓存内消息可能丢失，因此发送方发出去的消息并不能保证被接收并得到处理。像线程级的异步来说，必须在收发双方的消息中增加消息序列号，并对发送的每条消息，消息发送的序列号，消息接收的序列号进行持久化，这样进程重启之后可以对双方的序列号进行同步，从持久化模块中取出丢失的部分消息。以这样的方式才能保证消息发送的可靠性。

响应/请求：在响应/请求消息发送模式中，一个应用程序发送一条消息(请求消息)到另一个响应应用程序(响应生成器)再到请求消息。生成响应的应用程序获取请求消息、处理请求，并向请求应用程序发出响应。响应发送到由请求消息的消息标题属性replytoqueuemanager指定的队列。请求应用程序在放置消息到队列上之前会在请求消息上设置这些消息标题属性。

四、服务监控功能包括服务监控、调用统计、服务评估和服务测试。

服务监控包括调度异常监控、节点监控和调度监控，用于调度结果查询和调度历史记录。

调度结果查询：对于调度管理系统中调度的过程进行查询，并进行相关问题分析，会涉及所有跨系统业务的调度，业务量比较大，业务流转比较复杂，在这里要对这些调度过程要进行有效的管理，以方便对业务及数据的追踪。

调度历史记录：对于所有的调度操作进行记录，以方便后续的数据统计分析，历史记录追踪等。

调度管理系统中会涉及所有跨系统业务的调度，业务量比较大，业务流转比较复杂，在这里要对这些调度过程要进行有效的管理和监控，以方便对业务及数据的追踪。

调用统计：对调度管理系统中调度数据进行统计，参与服务交互的应用系统，每次发起或接受服务，调度管理系统都对其进行计数，并记录服务请求时间，服务完成时间，发起服务实体id，服务实体id，服务操作，服务状态等。主要包括：调度情况展示，调度问题分析，调度流量分析等。调度情况展示主要是指经过调度系统中调度过程展示。

服务评估：主要是对服务的调度效率，调度成功率，影响调度的原因及集中调度系统的健康状况等分析。分析出业务量的多少，帮助相关人员对于业务的受理等进行相应的调整。

服务测试：系统提供对已注册所有服务的状态测试，功能逻辑如下：

a)获取前端输入url或wsdl文档服务地址；

b)创建服务地址的资源连接对象；

c)应用资源连接对象与ws服务进行连接，若连接成功，则服务可用，反之则服务异常；

d)服务检测结果列表返回，检测结果包括：服务id、服务名称、服务url、方法名、状态。

五、服务安全功能包括认证、授权、加密和日志。

认证：保证接入调度管理系统的合法性，提供业务应用系统和调度管理系统之间的双向身份认真，采用基于证书的认证模式。

授权：对相应的调度服务进行权限管理，提供安全有效的调度机制，使相关系统间的调用在可按范围内进行。

加密为系统采用证书的方式加密服务调用数据，调度中心使用接收方的公匙对数据加密，而接收方则使用自己的私匙解密。

日志：控制台流水日志记录前端控制台的所有操作，包括登录、认证、配置、修改、注销等操作。

路由关系配置日志记录路由关系配置的全过程留痕，记录配置过程的每一步操作。

六、接口设计功能对调度系统的接口进行设计，包括调用流程和接口类别。

如图3所示，调用流程具体如下：

1.市、区统一受理系统接口发布到应用对接管理时，需配置接口服务与标准接口服务的关联关系。

2.委办局接收到新业务时，直接调用应用对接管理系统的标准接口服务，按标准发送请求参数。

3.应用对接管理系统接收请求参数后，根据“目标系统编号”，将请求参数流转到市/区统一受理系统接口服务。

4.市/区统一受理系统返回参数到应用对接管理系统。

5.应用对接管理系统将“返回参数”流转到委办局，完成信息交换。

接口类别分为通知类和业务类，如表1所示。

表1接口类别

以上所述的实施例，只是本发明较优选的具体实施方式，本领域的技术人员在本发明技术方案范围内进行的通常变化和替换都应包含在本发明的保护范围内。