在企業(yè)級應用開發(fā)中涣达，系統(tǒng)間通信是一個很常見的需求。在企業(yè)的實踐中，不同的業(yè)務部門所使用的軟件并不一定是完全統(tǒng)一且相互可通信的帘睦。
在中國袍患，所有的增值稅開票全都要走政府統(tǒng)一規(guī)定的開票機器來開票，然后開票系統(tǒng)與企業(yè)所使用的ERP系統(tǒng)之間的數(shù)據(jù)通信則需要有專門的接口來做數(shù)據(jù)傳輸竣付；在泰國诡延，每個公司可以自己開具自己的發(fā)票，而且沒有統(tǒng)一的格式要求古胆，但是根據(jù)其稅務局的要求肆良，在未來，任何公司的每一筆需要繳納增值稅的開票業(yè)務在開票前都需要先交帶開票的業(yè)務數(shù)據(jù)以XML的格式交給政府逸绎，然后政府統(tǒng)一返回唯一的確認碼惹恃，只有拿到這個碼的發(fā)票才是有效的發(fā)票。當然棺牧，考慮到其中可能帶來的成本巫糙，泰國官方給出了幾種方案：
Host To Host
即企業(yè)直接通過自己的網(wǎng)關將簽名后的XML文件通過SOAP消息格式發(fā)送給政府網(wǎng)關，然后網(wǎng)關返回響應消息颊乘。
Service Provider
即企業(yè)將所有的消息發(fā)送給一個授權(quán)的第三方参淹，由第三方負責與政府網(wǎng)關做通信，然后第三方再將響應消息發(fā)送給企業(yè)的網(wǎng)關乏悄。
以上兩種方式都是直接通信浙值，雖然泰國官方還支持人工地將XML文件通過官方提供的網(wǎng)頁站點上傳到政府網(wǎng)關，然后該站點返回一個響應消息檩小，但是這種模式不再本文討論之列亥鸠，因為其不是自動化的。
乍一看需求很簡單识啦，系統(tǒng)和系統(tǒng)之間利用網(wǎng)絡消息發(fā)送請求和接收響應而已负蚊，但是實際的業(yè)務需求卻是很復雜的。
首先颓哮，對于一個企業(yè)來說其發(fā)票的數(shù)量規(guī)模是很龐大的家妆，特別是對于零售企業(yè)，因此為了效率和系統(tǒng)的吞吐量冕茅，并發(fā)地去做消息發(fā)送是必須的伤极。既然有多個消息同時發(fā)送出去，對于某些發(fā)送失敗的消息姨伤，應用層面是需要去做處理的哨坪。但是應用層面有自己的業(yè)務邏輯，比如準備數(shù)據(jù)乍楚，數(shù)據(jù)映射等当编，同時不同的發(fā)票類型對應著不同的原始數(shù)據(jù)和消息格式，此時如果把消息的生成徒溪，發(fā)送忿偷，處理異常金顿，解析響應等模塊也放在應用層面，勢必會給后期的維護帶來巨大的成本鲤桥，因為并發(fā)通信是一個很復雜的問題揍拆。
對于上述問題的一般解決方案是應用層面將原始數(shù)據(jù)和發(fā)票格式的主數(shù)據(jù)發(fā)送給一個消息中間件，由該消息中間件負責完成消息創(chuàng)建茶凳，發(fā)送嫂拴，異常處理，解析等功能贮喧，然后將響應消息再返回給應用顷牌。中間件和應用之間的連接是通過WSDL的規(guī)范來實現(xiàn)的，即WSDL定義好中間件需要的輸入數(shù)據(jù)塞淹，應用層面需要的返回數(shù)據(jù)，然后雙方基于這一協(xié)議來進行數(shù)據(jù)交換罪裹。（關于WSDL是什么及其原理可以參考這篇文章）饱普。
上述解決方案的好處是，對于應用來說状共，它只要把某條代開發(fā)票項目的原始數(shù)據(jù)傳給消息中間件套耕，然后等待接收返回的消息即可；如何消息中間件通信出現(xiàn)異常峡继，那么在應用層面會返回一個通信異常的錯誤冯袍，然后應用層面就可以根據(jù)自己的需求來決定是否需要重新給向中間件發(fā)送通信請求。而且碾牌，這個過程是完全可以自動化的康愤。消息中間件可以存在一個類似于輪巡的組件根據(jù)一定的策略去判斷某條消息是否處于失敗狀態(tài)，如果是舶吗，則可以進行重試征冷，然后返回正確的響應消息到應用層面；如果某條消息重試多次后仍然失敗誓琼，則可以通過人為干預的方式去監(jiān)控中間件的特定消息检激；同時，通過應用層面的每條代開發(fā)票項可以navigate到中間件相對應的消息項腹侣，因為代開發(fā)票項與中間件某條消息是一一對應的關系叔收。
在SAP系統(tǒng)中，此需求應用層面的產(chǎn)品叫eDocument Framework, 消息中間件產(chǎn)品叫Application Interface Framework(AIF)傲隶，但是AIF并不負責通信消息的生成饺律，真正與外部系統(tǒng)通信的中間件叫SAP PI。
因為SAP是靠傳統(tǒng)軟件服務起家跺株，其系統(tǒng)架構(gòu)自身的靈活性使得應用層面并不需要考慮到多線程和高并發(fā)的問題蓝晒，也幾乎不會涉及到分布式數(shù)據(jù)存儲和一個事務需要涉及到跨系統(tǒng)數(shù)據(jù)讀寫的場景腮出，所以SAP提供的消息中間件的解決方案并不會像阿里巴巴的RocketMQ那么全面，但是其產(chǎn)生的根源是一樣的芝薇。在上述介紹的解決方案中胚嘲，如果某個業(yè)務場景需要使用到跨系統(tǒng)的數(shù)據(jù)讀寫時，如何保證跨系統(tǒng)的一致性問題是很難解決的洛二，RocketMQ通過引進“事務型消息中間件”的概念來提供方案馋劈，其具體的原理可以參考這篇文章。
