应用集成实战系列：服务总线中同步交互服务接口的定义规范

在基于SOA的应用集成项目中，用户会定义很多服务接口用于系统之间的交互。作为SOA应用集成中的基本元素，服务总线中的服务接口的定义规范对应用集成项目的实施具有重要的指导意义。

根据我的经验，在应用集成项目中定义的服务接口大多数为同步交互接口，比如Web Service接口，基本会占接口总数的八、九成。即便是需要进行异步交互的业务，经常也是由多个同步交互服务接口组合实现的。在本文中，我将介绍服务总线中的同步交互服务接口的定义规范。

首先，总线中的一个同步交互服务的须根据如下模式进行设计：






在同步交互服务中，必须要包括如下三个基本的消息处理路径：

①  请求消息处理：接收调用端发送的请求消息数据并进行处理

②  响应消息处理：将服务处理结果生成响应消息并返回给调用端

③  异常消息处理：对请求路径和响应路径中产生异常进行捕捉，生成异常消息，并作为响应消息返回给调用端

其次，在整个的服务消息处理的过程中，还需要包含如下元素：

服务日志：用于记录运行情况，包括调用时间、消息关键内容、成功/失败、异常信息等。日志记录的操作放在响应消息处理路径和异常消息处理路径当中，采用异步方式记录，以免日志记录操作影响服务的运行。
超时时间：在调用目标服务时，必须要设置调用超时时间，以免目标服务处理时间过长，导致服务总线中线程挂起的情况。超时时间建议不超过120秒。
报文校验(可选)：针对需要对报文进行限制(报文大小、格式等)的服务，需要在请求消息处理路径的起始处进行报文校验，校验失败触发异常消息处理路径。
调试日志(可选)：如果需要在处理过程中记录调试日志，必须要设置日志级别，以免在服务正常运行时占用过多的日志空间，消耗服务性能。

最后，同步交互服务接口的报文定义规范可参考如下格式：

请求消息报文格式：

<Request>

<ReqMsgHeader>      --请求消息头，用于传送服务请求的关键信息

<SID/>               --序列号系统生成，调用的唯一标识序号

<Invoker/>            --请求系统名称，标识请求系统

<Key_1/>             --业务关键字保留字段，用于记录关键日志信息和集成逻辑中的判断条件，可定义多个保留字段

<Key_2/>

<Key_3/>

<Key_4/>

<Key_5/>

</ReqMsgHeader>

<ReqMsgBody>        --请求消息体，请求消息的内容，可以为XML或者格式化的字符串，一般情况下，不需要在服务总线中进行解析。用这种消息体字符串方式定义，目的是减少业务报文的变化对服务的影响，不需要对服务接口进行频繁的修改。

</ReqMsgBody>

</Request>

响应消息报文格式

<Response>

<RespMsgHeader>     --响应消息头

<Result/>            --响应结果 1成功 0失败

<RespMsg/>          --响应结果描述，简单总结返回结果

<ExceptionInfo/>      --异常信息，详细的异常信息

<Key_1/>            --业务关键字保留字段，用于记录关键日志信息和集成逻辑中的判断条件，可定义多个保留字段

<Key_2/>

<Key_3/>

<Key_4/>

<Key_5/>

</RespMsgHeader>

<RespMsgBody>       --响应消息体，如果服务返回复杂的结果，比如查询服务，将结果数据以XML或者格式化字符串的形式放在该字段中。通常，该字段不需要在服务总线中进行解析。用这种消息体字符串方式定义，目的是减少业务报文的变化对服务的影响，不需要对服务接口进行频繁的修改。

</RespMsgBody>

</Response>

以上是我根据之前的项目经验总结的服务总线中同步交互接口的定义规范，供参考，实际项目中，可根据具体情况进行调整。

欢迎关注我的微信公众号：