在企业级应用开发中，系统间通信是一个很常见的需求。在企业的实践中，不同的业务部门所使用的软件并不一定是完全统一且相互可通信的。
在中国，所有的增值税开票全都要走政府统一规定的开票机器来开票，然后开票系统与企业所使用的ERP系统之间的数据通信则需要有专门的接口来做数据传输；在泰国，每个公司可以自己开具自己的发票，而且没有统一的格式要求，但是根据其税务局的要求，在未来，任何公司的每一笔需要缴纳增值税的开票业务在开票前都需要先交带开票的业务数据以XML的格式交给政府，然后政府统一返回唯一的确认码，只有拿到这个码的发票才是有效的发票。当然，考虑到其中可能带来的成本，泰国官方给出了几种方案：
Host To Host
Host To Host
即企业直接通过自己的网关将签名后的XML文件通过SOAP消息格式发送给政府网关，然后网关返回响应消息。
Service Provider
Service Provider
即企业将所有的消息发送给一个授权的第三方，由第三方负责与政府网关做通信，然后第三方再将响应消息发送给企业的网关。
以上两种方式都是直接通信，虽然泰国官方还支持人工地将XML文件通过官方提供的网页站点上传到政府网关，然后该站点返回一个响应消息，但是这种模式不再本文讨论之列，因为其不是自动化的。
乍一看需求很简单，系统和系统之间利用网络消息发送请求和接收响应而已，但是实际的业务需求却是很复杂的。
首先，对于一个企业来说其发票的数量规模是很庞大的，特别是对于零售企业，因此为了效率和系统的吞吐量，并发地去做消息发送是必须的。既然有多个消息同时发送出去，对于某些发送失败的消息，应用层面是需要去做处理的。但是应用层面有自己的业务逻辑，比如准备数据，数据映射等，同时不同的发票类型对应着不同的原始数据和消息格式，此时如果把消息的生成，发送，处理异常，解析响应等模块也放在应用层面，势必会给后期的维护带来巨大的成本，因为并发通信是一个很复杂的问题。
对于上述问题的一般解决方案是应用层面将原始数据和发票格式的主数据发送给一个消息中间件，由该消息中间件负责完成消息创建，发送，异常处理，解析等功能，然后将响应消息再返回给应用。中间件和应用之间的连接是通过WSDL的规范来实现的，即WSDL定义好中间件需要的输入数据，应用层面需要的返回数据，然后双方基于这一协议来进行数据交换。（关于WSDL是什么及其原理可以参考这篇文章）。
上述解决方案的好处是，对于应用来说，它只要把某条代开发票项目的原始数据传给消息中间件，然后等待接收返回的消息即可；如何消息中间件通信出现异常，那么在应用层面会返回一个通信异常的错误，然后应用层面就可以根据自己的需求来决定是否需要重新给向中间件发送通信请求。而且，这个过程是完全可以自动化的。消息中间件可以存在一个类似于轮巡的组件根据一定的策略去判断某条消息是否处于失败状态，如果是，则可以进行重试，然后返回正确的响应消息到应用层面；如果某条消息重试多次后仍然失败，则可以通过人为干预的方式去监控中间件的特定消息；同时，通过应用层面的每条代开发票项可以navigate到中间件相对应的消息项，因为代开发票项与中间件某条消息是一一对应的关系。
在SAP系统中，此需求应用层面的产品叫eDocument Framework, 消息中间件产品叫Application Interface Framework(AIF)，但是AIF并不负责通信消息的生成，真正与外部系统通信的中间件叫SAP PI。
因为SAP是靠传统软件服务起家，其系统架构自身的灵活性使得应用层面并不需要考虑到多线程和高并发的问题，也几乎不会涉及到分布式数据存储和一个事务需要涉及到跨系统数据读写的场景，所以SAP提供的消息中间件的解决方案并不会像阿里巴巴的RocketMQ那么全面，但是其产生的根源是一样的。在上述介绍的解决方案中，如果某个业务场景需要使用到跨系统的数据读写时，如何保证跨系统的一致性问题是很难解决的，RocketMQ通过引进“事务型消息中间件”的概念来提供方案，其具体的原理可以参考这篇文章。
网友评论