多报文解析方法与流程

本发明涉及计算机及通信技术领域，具体提供一种多报文解析方法。

背景技术：

服务提供方提供的接口可供服务消费方系统访问、具有一定业务功能的服务。其业务功能最终由对应服务提供方系统实现。

服务提供方提供的接口是由不同业务系统提供的、具有一定业务功能的、可集成的实体，另外，业务系统接口表现方式有多种，根据具体业务系统实现技术和具体业务内容而不同；例如：某系统提供ejb，某系统提供webservice，某系统提供jms等。

数据服务交换，以前以多种交换工具和多种交换技术并存的方式进行，比如etl工具、http请求，restful接口以及手动导出等，这种方式和技术存在很多问题，如不易维护管理、资源利用率低、自动化程度低等

技术实现要素：

本发明是针对上述现有技术的不足提供一种多报文解析方法。该方法能够降低提供方和消费方的耦合程度，屏蔽了同服务提供方技术实现的差异和细节。

本发明解决其技术问题所采用的技术方案是：多报文解析方法，其特点是使用xml和json格式报文进行系统间的消息传递，客户端发出消息处理请求后，服务前端适配器对请求进行标准化预处理及判断，并将消息发送到中端，中端接收到前端发送的请求消息后，对消息进行缓冲，并进行重新组织，基于后端消费能力发送消息到后端进行消息处理，后端根据请求消息进行逻辑处理，生产消息所需数据或结果；后端处理完消息后，将返回结果发送到中端，返回结果数据，唤醒前端程序，前端程序接收返回结果并返回到客户端。

作为优选，服务前端缓存数据或结果，标准化预处理及判断完成后，从数据或结果中查找是否有历史缓存数据，如果有则对数据进行返回，如果没有则把消息发送到中端。

作为优选，客户端发出消息处理请求后，服务前端根据不同的接口请求协议类型分配到不同的适配器进行服务请求处理，并根据请求报文类型选择不同的报文解析适配器进行内容解析，以完成请求的标准化预处理。

作为优选，服务前端根据解析的认证信息确认服务调用方的身份信息，判断该请求是否符合安全规范以及是否有相应的权限。

作为优选，所述报文分为技术报文和业务报文，技术报文包含服务集成的技术控制信息，同时提供扩展性机制；业务报文表达业务服务的业务语义，包含业务逻辑所需要的业务属性。

业务报文包括业务请求报文和业务响应报文，对应业务服务的输入参数和输出参数。

多报文解析系统，其特点是使用xml和json格式报文进行系统间的消息传递，系统前端用于以适配器对请求进行标准化预处理及判断，并将消息发送到中端；系统中端用于接收到前端发送的请求消息，对消息进行缓冲，并进行重新组织，基于后端消费能力发送消息到后端进行消息处理；系统后端用于根据请求消息进行逻辑处理，生产消息所需数据或结果；后端处理完消息后，将返回结果发送到中端，返回结果数据，唤醒前端程序，前端程序接收返回结果并返回到客户端。

和现有技术相比，本发明的多报文解析方法具有以下突出的有益效果：

1.请求消息和响应消息均使用xml和json进行传递，采用xml和json字符串更符合松耦合原则，不但架起了服务提供方和服务消费方消息传递的桥梁，降低了提供方和消费方的耦合程度，最重要的是屏蔽了不同服务提供方技术实现的差异和细节，使用人员不需要了解底层使用的技术和工具，即可进行数据服务交换。

1.1跨平台能力，xml和json字符串不依赖于具体的实现平台而普适任何平台，可以方便对用于不同技术实现的系统进行整合传输。

1.2安全性好，xml和json是基于纯文本的，可以方便的被人读懂，它可以不受防火墙的限制，方便在系统之间进行传输。而对象格式是二进制格式，对于安全性要求很高的会被限制住。

1.3透明性高，xml和json对于各种协议都可以使用，所以可以根据需求灵活选择协议而达到协议的自由切换。

1.4侵入性低，xml和json避免对各集成系统的侵入，系统可以利用各种技术手段把接收到的xml和json数据进行处理，比如log记录下来以便于系统之间进行对账使用。而对象格式强制要求各系统使用并部署该对象，要求各系统也必须是同构的，在进行对账处理时还需要转换成原生的xml和json格式。

2.将报文在组织形式上划分为技术报文和业务报文两个部分，能够将一些技术控制信息与业务信息分离开来，一方面可使逻辑上更加清晰，一方面可以提高系统处理的效率。

附图说明

附图1是本发明多报文解析方法技术流程图；

附图2是本发明多报文解析方法整体图；

附图3是扩展信息节点结构图；

附图4是报文结构图；

附图5是技术报文的定义结构。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明，但不作为对本发明的限定。

实施例：

1、系统中心定位

报文解析在大数据的体系架构中处于应用和底层组件的桥梁位置，起着承上启下的作用，通过对核心组件api的抽象和封装，实现了对上层应用提供统一的、可管理的接口，降低了组件的使用门槛和使用成本；通过报文解析服务，很好的对数据进行封闭和保护，实现了对数据的管控、隔离。

2、系统分层设计

如附图1所示，服务分为前端、中端以及后端三部分，前端用于适配各种请求，如http、webservice、ejb等，可接受不同协议发送过来的报文，中端用于缓存请求，充分利用了kafka的高吞吐量、高并发的特性，提高系统性能，后端用于处理请求报文并进行解析，处理业务逻辑并返回结果，完成从请求到处理到返回的闭环处理。

3、多种类型的接口类型适配

多报文解析服务不仅支持传统的http接口，还支持webservice和ejb接口，符合这三种接口方式的客户端请求均可接入到系统中进行请求服务的处理，请求进入系统后，系统根据不同的接口请求类型分配到不同的适配器进行服务请求处理。

当服务提供方需要使用多报文解析服务的时候，服务提供方需要准备请求数据，请求数据支持xml和json两种格式，根据xml或者json的语法以及多报文解析服务融合技术对报文内容的要求进行请求数据拼装，拼装完成后即可调用多报文解析服务融合技术进行服务接口的调用。

4、多种报文格式的解析适配

多报文解析服务接收到请求后，系统会根据请求报文类型选择不同的报文解析适配器，系统目前支持xml和json两种报文格式的解析。

多报文解析服务对传递到系统的请求消息进行内容解析，解析时系统会根据报文类型的不同使用不同的解析适配器，系统根据解析出来的认证信息、路由信息进行后续处理，系统根据解析的认证信息确认服务调用方的身份信息，认证信息通过后，系统再根据路由信息进行接口服务的路由，根据路由信息路由到相应的服务提供方，服务提供方解析请求消息里的请求参数，解析完成后服务提供方根据请求参数内容、服务业务逻辑进行请求处理，请求处理完成后将处理结果返回给请求方。

对于json格式的请求报文，则调用jsonobject.parse("")；即可完成对json字符串转化为java对象。

如附图2所示，客户端发出消息处理请求，前端适配器对请求进行标准化预处理(根据不同的接口请求协议类型分配到不同的适配器进行服务请求处理，并根据请求报文类型选择不同的报文解析适配器进行内容解析)，并判断该请求是否符合安全规范以及是否有相应的权限，通过后则从结果中查找是否有历史缓存数据，如果有则对数据进行返回，如果没有则把消息发送到中端，同时前端程序进行监控，等待返回结果。

消息到中端后，消息在中端进行缓冲，并对消息进行重新组织，基于后端消费能力，发送消息到后端进行消息处理，后端根据请求消息进行逻辑处理，生产消息所需数据或结果。

后端处理完消息后，再次把返回结果发送到中端，返回结果数据，唤醒前端程序，前端程序接收返回结果并返回到客户端。

5、报文结构

报文在组织形式上划分为技术报文和业务报文两个部分，目的是将一些技术控制信息与业务信息分离开来，一方面可使逻辑上更加清晰，一方面可以提高系统处理的效率。

5.1.技术报文

技术报文包含服务集成的一些技术控制信息，既需要考虑技术必须性的要求，比如交易服务、交易流水号、来源系统等，同时需要提供扩展性机制，比如人员、安全信息的可扩展。技术报文的组成结构内容定义如下表：

对于expand，可以增加任意个节点，具体结构如图3所示。

name表示具体类型key，value表示具体的对应值。在有需要时必须增加，有些特殊的name使用要求规范如下：

①目标id：英文字母destination_id。

②数据人员：英文字母sjry，在业务需要传入人员信息时填写。

③数据机关：英文字母sjjg，在业务需要传入机关信息时填写。

④压缩算法：英文字母ziptype，标识采用的压缩算法，用于报文压缩。

⑤加密算法：英文字母encrypttype，标识采用的加密算法，用于报文加密。

⑥身份信息：英文字母identitytype，标识渠道系统采用的身份信息，用于渠道系统的身份认证。

⑦签名信息：英文字母signatureinfo，标识渠道系统采用的签名信息，用于渠道系统对业务报文进行的签名。

⑧业务数据标识：英文字母ywsjbs，存在能标识此笔业务时需要，用于交易流水查找。

2.业务报文

业务报文表达了业务服务的业务语义，包含业务逻辑所需要的业务属性。

业务报文包括业务请求报文和业务响应报文，对应业务服务的输入参数和输出参数。应用集成平台需要能够根据要求配置这些服务参数是否进行业务语义上的校验，需要能够按照标准通用开放的形式定义业务报文格式及其效验格式。

3.报文规范

采用xml和json方式来传输接口数据，报文满足通用性和扩展性原则，能满足业务的各种需要，而且方便开发人员应对不断变化的业务需求，方便新交易的开发。

报文结构，从报文结构上体现技术报文和业务报文，如图4所示。

service为技术报文根节点；

head为技术报文头信息；

body节点为报文体，业务报文填写在此节点中。

技术报文的定义结构如图5所示。