一種可靠的系統間消息通知方法和系統的製作方法
2023-05-11 14:20:21
專利名稱：一種可靠的系統間消息通知方法和系統的製作方法
技術領域：
本發明涉及一種數據傳輸領域，特別涉及一種可靠的系統間消息通知方法和系統。
背景技術：
隨著網際網路技術的快速發展，以消息通知作為交互模式的網際網路應用系統也越來越多。目前一種典型的消息通知應用是網上銀行與商戶之間的消息通知。它的應用場景是，用戶從商戶網站向網銀提交交易訂單，然後用戶在網銀完成實際支付，支付完成之後，網銀將用戶支付成功的結果以消息通知的形式返回給商戶，由商戶完成諸如發貨等後續交易操作。支付結果的消息通知能否可靠送達商戶，將直接影響用戶的交易流程，因此該消息通知送達的可靠性是非常關鍵的。
但是，網際網路是不可靠的，它的不可靠性既體現在網絡本身連通性與延時的不可預料性，也體現在連接在網際網路上的軟硬體設備可用性的不可預料性。因此，基於網際網路的消息通知有一定的丟失機率。但電子商務中的信息流對可靠性的要求非常高，丟失關鍵的消息通知輕則阻礙商業活動的順利開展，重則帶來商務活動參與方的資金財產損失。從目前的實際情況看，各種銀行與商戶系統間的消息通知都沒有做到可靠送達。據iResearch的2005年的統計數據顯示，目前國內的第三方網上支付平臺中絕大多數有較高的掉單率(即用戶在網銀支付成功的結果沒有及時通知到第三方支付平臺)，其中，掉單率最高的網上支付平臺達到20％。
WS-Reliable Messaging(Web SerVices Reliable MessagingProtocol，Web Service可靠消息協議)和WS-Reliability(Web ServiceReliability，Web Service可靠性)是兩種面向Web Service的可靠消息協議。其中，WS-Reliable Messaging是由IBM、BEA、Microsoft和TIBCO等公司提出的一種可以在分布式系統中進行可靠消息傳輸的協議。而WS-Reliability則是由OASIS組織的Web Service可靠消息(WSRM)技術委員會提出的一種使SOAP(Simple Object Access Protocol)簡單對象訪問協議消息可以確保送達的、無重複的基於SOAP的協議。本質上，這兩種協議都是基於對消息編序，並使用滑動窗口協議對消息進行確認來實現消息的可靠傳輸的。
HTTPLR協議是愛爾蘭的Propylon有限公司在2005年提出的，它是一種建立在HTTP協議之上的應用層協議，旨在為HTTP協議提供確保送達和單次送達的消息傳輸服務。HTTPLR針對消息上行(從客戶端到伺服器端)和下行(從伺服器端到客戶端)都提供了可靠消息的機制，但該機制不涉及消息發送端和消息接收端的可用性、組件的健壯性、消息的持久存儲、以及消息的重試和超時機制，而只是涉及消息交換的雙方如何就消息是否已送達達成一致的認識。
在現實情形中，無論是WS-ReliableMessaging、WS-Reliability還是HTTPLR協議，都未在網際網路環境下得到廣泛應用。究其原因，有以下幾點一是這些協議本身尚未完全成熟，有些尚處於草案階段；二是儘管在理論上描述了可靠消息傳輸的機制，但它們並未描述實現的具體機制；三是它們的應用環境有局限性，比如HTTPLR應用於HTTP協議之上，而WS-Reliable-Messaging和WS-Reliability協議是面向Web Service的；四是它們對客戶端和伺服器端的實現都有比較複雜的要求，而在當前的網際網路環境下，要求消息交換的雙方都實現同一種複雜協議往往是困難的。
發明內容
本發明要解決的技術問題是提供一種可靠的系統間消息通知方法和系統，適用於任何協作的系統之間，尤其解決了系統之間通過網際網路進行消息通知時，由於網絡、伺服器或者程序系統不穩定造成的通知消息丟失且不可恢復的問題。
為了解決上述問題，本發明提供了一種可靠的系統間消息通知方法，該方法包括以下步驟將通知消息存儲；發送存儲的通知消息；若通知消息發送不成功，則對該通知消息設置重試時間，並更新存儲；檢查等待重試的通知消息，如果存在重試時間到期的通知消息，則執行發送步驟。
所述可靠的系統間消息通知方法還可以包括，同時發送新通知消息以及重試的通知消息。優選的，所述檢查為定時檢查。所述新通知消息的發送是受到觸發後執行。
執行所述發送步驟前還可以包括判斷所述消息的事務處理是否完成，如果完成則觸發該消息的發送；否則註冊一個事務同步器，在消息的事務處理完成後再觸發該消息的發送。
所述可靠的系統間消息通知方法還包括根據所述通知消息選擇相應的協議適配器進行消息通知的發送；以及根據所述通知消息選擇相應的業務插件進行消息通知的預處理以及返回的通知結果的處理。優選的，所述的重試時間間隔隨著重試次數的增加而增大。所述的重試時間到期包括重試時間點小於或等於定時檢查的時間點。
本發明還提供了一種可靠的系統間消息通知系統，該系統包括資料庫，用於保存通知消息；通知客戶端，用於將通知消息存放到所述資料庫中，並觸發消息通知立即發送；通知執行器，用於發送通知消息，若通知消息發送不成功，則對應所述通知消息設置重試時間，並更新所述資料庫中的對應通知消息；通知恢復器，用於檢查等待重試的通知消息，如果存在重試時間到期的通知消息，則通知所述通知執行器。
所述的通知恢復器定時運行。
所述可靠的系統間消息通知系統還可以包括消息隊列，用於觸發所述通知執行器即時發送通知消息。
所述可靠的系統間消息通知系統還可以包括設置在所述通知客戶端的事務同步器，負責在消息的事務處理完成後再通過所述消息隊列觸發通知執行器。優選的，所述通知客戶端嵌入在消息的業務系統中。
所述可靠的系統間消息通知系統還可以包括至少一種協議適配器，每種協議適配器支持一種傳輸協議，用於系統間的實際數據傳輸；以及至少一種業務插件，用於通知消息發送前的預處理和返回的通知結果的處理。優選的，由所述業務插件判斷決定通知消息的發送是否成功。
本發明適用於任何協作的系統之間，與現有網際網路間可靠消息交換的技術相比，本發明具有的優點是1、系統之間通過網際網路進行消息通知時，由於本發明將通知消息持久存儲，如存儲到所述資料庫中，直到該消息發送成功，避免因為軟、硬體系統故障而丟失該通知任務，保證了消息通知的可靠到達。
2、所述方法和系統針對網際網路上的短期和中長期通信故障模式提出現實、高效的超時和消息重發解決方案。隨著重試次數的增加，其重試時間的間隔也越來越長。重試時間間隔的變化，兼顧了通知恢復的及時性和效率。對於短期的通信故障，系統能夠在故障恢復之後及時將消息通知送達接收方；對於中長期通信故障，系統能夠避免多次重試的開銷。
3、本發明通過擴展協議適配器，能夠適用於各種消息傳輸協議，而不是局限於一、兩種協議，適用於廣泛的互聯需求。由於這種多協議的支持，這種方法和系統在實現上是非對稱的，消息交互的一方(如消息的接收方)不需要實現複雜的交互協議，只需要根據業務的要求返回消息處理的結果，就能夠接收來自消息提供方的可靠消息。
4、本發明所述方法和系統能夠作為一個通用的平臺，通過擴展業務插件，同時支撐各種不同業務應用的運轉，並且可以靈活地擴展新的業務。
下面結合附圖和具體實施方式
對本發明作進一步詳細的說明。
圖1是本發明一種可靠的系統間消息通知系統的系統結構示意圖；圖2是本發明一種可靠的系統間消息通知方法的步驟流程圖；圖3是消息通知的註冊流程圖；圖4是消息通知的發送流程圖；圖5是消息通知的恢復流程圖；圖6是重試間隔確定方法的概念模式圖。
具體實施例方式
基於網際網路的電子商務在當今社會中佔據了越來越重要的地位。越來越多的商業實體通過網際網路組織信息流、資金流和物流，以消息通知作為交互模式的網際網路應用系統也越來越多。以銀行為例，用戶在銀行完成支付後，銀行需要將用戶支付的情況通過消息通知的形式告知商戶系統；以第三方安全交易平臺為例，當用戶在交易平臺上推進交易流程後，交易平臺需要將交易的當前狀態通知相關的外部商戶系統。這些都是典型的基於網際網路的消息通知。本發明適用於任何協作的系統之間，尤其適用於廣泛的網際網路。
參照圖1，是本發明一種可靠的系統間消息通知系統的結構示意圖。業務應用11可以為某個商業應用，它是消息通知過程的發起者。外部系統17可以為某個商業系統，它是消息的接收者。本發明所提供的通知系統用於發送所述業務應用11發來的通知消息，並能夠確保該通知消息通過網際網路可靠到達所述的外部系統17。所述通知系統可以包括資料庫13，用於保存待發送的新通知消息和等待重發的通知消息；通知客戶端12，用於將通知消息存放到所述資料庫中，並通過消息隊列14觸發消息通知立即發送；通知執行器152，用於發送新通知消息或重試的通知消息，若通知消息發送成功，則從資料庫13中刪除本條通知消息；否則對應所述通知消息設置重試時間，並更新資料庫13中的對應通知消息；通知恢復器151，用於檢查等待重試的通知消息，如果存在重試時間到期的通知消息，則通知所述通知執行器152。
如圖所示，資料庫13可以是任何通用的關係型資料庫，用以保存待發送的新通知消息和曾經發送不成功等待重發的通知消息。通知客戶端12可以為供業務應用11使用的一個客戶端模塊，嵌入到消息的業務系統中，業務應用11可以使用通知客戶端12註冊一個通知消息。一旦通知消息註冊成功，系統就能夠確保該通知消息到達消息的接收方，即使此時消息接收方不在線，或者網絡暫時無法連通。所述註冊可以為，通知客戶端12將業務應用11發來的通知消息存放到資料庫中，並通過消息隊列14觸發消息即時發送。所述業務系統是指針對業務應用11，進行相應的業務處理的系統。結合網上銀行與商戶之間的消息通知實例，所述消息的事務處理是指用戶在網上銀行進行實際支付，若支付完成則事務處理提交，否則還處於事務處理中；所述通知消息指用戶的支付結果，即是否完成支付。所述事務是一個技術上的專有名詞，表示具有ACID特性的一組操作，事務的ACID特性是實現消息通知與業務操作100％一致性的關鍵。當創建事務時，應確保事務具有某些可以自行管理的特性，這些特性就稱為ACID特性。ACID是指原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)。
將通知客戶端12嵌入到消息的業務系統中，可以在同一個資料庫事務中完成業務處理以及通知任務的註冊，完全可以避免業務處理和通知任務不一致的情況。所述一致為一通知消息只有當事務處理完成提交後，該通知消息才註冊成功，進行即時發送。所述資料庫事務中的資料庫可以是系統中保存消息通知請求的資料庫。一般說來，這個資料庫與業務系統保存業務數據的資料庫是同一個。如果是同一個資料庫，則可以避免使用複雜低效的分布式事務機制就能實現通知消息的註冊與業務數據的處理位於同一資料庫事務中。但也可以使用不同的資料庫，並通過分布式事務機制保證通知消息註冊與業務數據處理的一致性。
消息隊列14是一種標準的用於系統間異步消息通訊的中間件。通過使用消息隊列，消息的發送過程和接收過程之間是異步的，同時使得消息發送方和消息接收方不直接進行通訊，而是通過消息隊列進行間接通訊。這樣做最大程度地減小了消息發送方和消息接收方之間的相互依賴，使得消息發送方與消息接收方之間可以相對獨立地進行工作。目前的消息隊列一般都能夠做到當接收到消息之後，只要消息接收方工作正常，可以即時將消息傳遞給消息接收方。本實施例中，消息隊列14用以觸發通知消息的即時發送。
通知伺服器15可以為一臺或一組獨立運行的，用以專門負責通知消息發送和通知消息重發的伺服器，可以包括通知恢復器151、通知執行器152以及多種協議適配器153。其中，通知恢復器151為負責調度未成功發送的通知消息在恰當的時間進行重新發送的模塊；通知執行器152為負責執行實際的通知消息發送的模塊；多種協議適配器153中，每種協議適配器支持一種傳輸協議，通過網際網路完成與外部系統17的實際數據傳輸。通知業務處理插件庫16為各種業務插件161的管理器。業務插件161負責通知消息發送前的預處理和返回的通知結果處理，所述預處理和結果處理均與業務應用緊密相關，不同的業務應用，其處理過程也不相同。
參照圖2，是本發明一種可靠的網際網路系統間消息通知方法的步驟流程圖。當業務應用需要向外部系統發送一通知消息時，執行以下步驟即可可靠送達步驟s1，業務應用將自己的通知需求封裝成一個消息通知請求，發送至通知客戶端。
步驟s2，通知客戶端將所述通知消息進行註冊。一旦通知消息註冊成功，業務應用就可以繼續其它業務處理，所述系統就能夠確保該通知消息到達消息的接收方，即使此時消息接收方不在線，或者網絡暫時無法連通。
步驟s3，當通知消息註冊成功後，通知系統進行通知消息的發送。若發送成功，則消息通知任務結束；否則繼續步驟s4。
步驟s4，進行消息發送的恢復處理，調度未成功發送的通知消息在恰當的時間進行重新發送，繼續步驟s3。
在此過程中，步驟s4與步驟s1、步驟s2和步驟s3可以同時執行。下面分別對步驟s2、s3和s4進行詳細說明。
參照圖3，是消息通知的註冊流程圖，包括以下步驟步驟a1，通知客戶端接收所述業務應用發來的消息通知請求；所述消息通知請求可以包括消息通知的內容。
步驟a2，通知客戶端將所述通知請求存放到資料庫中，直到通知消息發送成功，這樣可以避免在發送過程中由於網絡、伺服器或程序系統不穩定造成的通知消息丟失且不可恢復的問題。
步驟a3，通知客戶端判斷所述消息的事務處理是否完成提交，若還處於事務處理中，則繼續執行步驟a4、步驟a5和步驟a6；若事務已完成提交，則通知客戶端自動觸發消息隊列，直接執行步驟a6。結合網上銀行與商戶之間的消息通知實例，所述消息的事務處理是指用戶在網上銀行進行實際支付，若支付完成則事務處理提交，否則還處於事務處理中；所述通知消息指用戶的支付結果，即是否完成支付。本實施例中，由於通知客戶端嵌入到業務系統中，能夠在業務事務內完成將通知任務註冊到資料庫中，這樣避免使用複雜的機制就實現了業務處理和通知註冊的一致性。
步驟a4，通知客戶端向事務管理器註冊一個事務同步器。所述事務管理器是對事務進行管理的軟體，包括事務同步器。所述事務同步器設置在通知客戶端，用於實現在事務提交之後通過消息隊列向通知伺服器發送一個立即發送通知消息的請求，可以保證通知的及時性。
步驟a5，當事務完成提交之後，事務同步器自動觸發消息隊列。
步驟a6，消息隊列向通知執行器發送一個立即發送通知消息的請求，驅動通知執行器進行發送，保證了通知的即時性。
參照圖4，是消息通知的發送流程圖，包括以下步驟步驟b1，通知執行器接收到通知客戶端通過消息隊列發來的新消息通知請求，或者消息恢復器發來的重試消息通知請求。如果同時收到消息隊列發來的新消息通知請求和消息恢復器發來的重試消息通知請求，則優選的，通知執行器執行多線程處理，可以同時發送新通知消息以及重試的通知消息。當然，也可以採用確定優先級進行發送。
步驟b2，通知執行器根據消息通知請求的類型，從業務插件庫中找到相應的業務插件，將消息通知請求交給業務插件進行預處理，得到實際的外部系統通知地址、通知協議和通知參數。
步驟b3，通知執行器根據通知協議選擇合適的協議適配器，將通知消息內容、通知地址和通知參數交給協議適配器進行實際的消息發送。
步驟b4，如果網絡、雙方伺服器與系統均正常工作，則消息通過網際網路到達外部系統，外部系統接收到消息並處理後返回處理結果；否則所述通知執行器能夠自動檢測到通知消息未到達外部系統，繼續步驟b8和b9。
步驟b5，通知執行器將返回結果交給業務插件，由業務插件完成相應的業務處理。在上述例子中，當收到外部商戶的返回結果之後，業務插件需要將交易的狀態變為已發貨，並且記錄發貨單的詳情，通知用戶發貨情況。由於通知伺服器本身是通用的，與具體業務無關，因此這些處理是由業務插件來完成的。
步驟b6，業務插件判斷本次發送是否需要重試。業務插件是根據是否有返回結果，以及返回結果的格式和內容是否有效決定。仍以上述例子為例，如果返回結果中包含有效的商戶發貨信息，則業務插件判斷消息通知是成功的；如果沒有返回結果，或者返回結果格式無效，或者外部商戶在返回結果中直接表明暫時無法處理，需要過一段時間重試，則業務插件判斷消息通知未成功，需要重試。
因為消息發送不成功的可能原因不但包括網絡或系統故障，還取決於業務處理是否能夠成功，而通用的通知伺服器可以判定網絡與系統的故障，但無法判定業務處理是否成功，因此將判定職責交給業務插件去完成。當然，明顯的網絡與系統故障是通知伺服器本身能夠判斷的，因此，當發生這種情況時，由通知伺服器直接決定需要重試。
步驟b7，如果業務插件表明本次消息不需要重試，則通知執行器從資料庫中刪除本條消息通知請求，成功完成通知發送。
步驟b8，如果由於網絡等原因發送的通知消息未到達外部系統，或業務插件表明本次消息需要重試，則通知執行器根據重試策略計算下一次重試需要等待的時間間隔，並用該間隔加上當前時間作為下一次消息發送重試的時間點。
步驟b9，對於等待重新發送的通知消息，通知執行器根據計算的重試時間，更新資料庫中對應消息通知請求的發送時間，並放棄本輪通知，等待通知恢復器的重新調度。
在上述通知發送流程中，通過擴展業務插件，可以實現在同一個消息通知系統中支持各種類型的業務通知；通過擴展協議處理器，可以實現在同一個消息通知系統上支持不同協議的通知。此外，通知的接收者不需要實現任何特殊的可靠消息通知協議，只需要根據業務的要求返回消息處理的結果，就能夠可靠接收來自消息提供方的消息。
參照圖5，是消息通知的恢復流程圖。當所述通知消息需要重新發送時，進入通知恢復流程。優選的，通知恢復器定時運行，在每一輪運行中，執行以下步驟步驟c1，通知恢復器等待定時時間，當時間點到開始運行。
步驟c2，從資料庫中查找重試時間到期的消息通知請求。檢查需要重試的消息通知請求，將步驟b8計算所得的重試時間與本輪的定時時間相比較，若有重試時間點小於或等於定時時間點的情況，則存在重試時間到期的消息通知請求，繼續步驟c3；否則放棄本輪重試，繼續步驟c4。
步驟c3，對於重試時間到期的通知消息，向通知執行器發送重試請求，逐條交給通知執行器進行通知發送。
步驟c4，等待下一定時時間點，進行下一輪運行。
通知恢復流程的定時時間一般是固定的，比如每隔1分鐘運行一次。定時時間間隔的大小關係到通知恢復的及時性，因此，這個時間間隔一般設置得越小越好，但必須在通知伺服器能夠承受的性能範圍內。此外，這個定時時間間隔與消息通知重試的間隔並不相同，消息通知重試的間隔時間是通過重試間隔確定方法針對每一條通知消息單獨計算和設置的。
在通知發送流程的步驟b8中，所述的重試策略可以採用常用的固定重試時間間隔，本發明優選採用下述的一種重試間隔確定方法進行重試時間間隔的確定。所述重試間隔確定方法，是針對網際網路上消息通知失敗的常見原因設計的，意在用儘可能少的重試次數、儘可能及時地將消息通知發送到消息接收方。
網際網路上跨系統的消息通知失敗的可能原因有以下幾種網絡暫時繁忙，造成傳輸協議超時；網絡短暫中斷；對方伺服器暫時繁忙，造成不響應請求；對方系統存在BUG，造成不響應請求或者請求處理出錯；對方伺服器宕機，造成不響應請求；網絡長時間故障，造成長達數小時以至於數天的中斷；對方系統長時間故障，造成長達數小時以至於數天不可用；對方系統不存在或者永久關閉。
從上述原因可見，造成消息通知不成功的原因既有可能在數分鐘內消失或緩解，也有可能長達數小時或者數天。消息通知的最佳重試策略應為當原因可以在數分鐘內消失或緩解時，消息通知能夠及時地發送給對方；而當原因需要數小時或者數天才能消失時，系統也能將消息通知發送給對方，而且不做太多無謂的嘗試。因此，本發明優選採用下述的一種重試間隔確定方法進行重試時間間隔的確定。
參照圖6，是所述重試間隔確定方法的概念模式圖。對所述確定方法說明如下假定有一組編號從1到n+1的盒子，1到n號盒子上都綁定一個定時器，盒子的編號越大，定時間隔越長，例如第一次間隔2分鐘，第二次間隔5分鐘，第3次間隔10分鐘等等。第n+1號盒子上沒有定時器，認為消息接收方永久不可達，放棄自動重試，等待人工恢復。
一個消息通知任務第i次(i＝1..n)發送不成功，則進第i個盒子；第i個盒子的定時器每次觸發都會重試本盒子中的所有消息通知任務；當一個消息通知任務第n+1次發送不成功時，則進第n+1個盒子，由於第n+1個盒子上沒有綁定定時器，因此系統將會放棄對該消息通知任務的自動重試，轉入人工處理。
此外，本發明中的通知系統針對不同類型外部系統的特點，對盒子上的定時器進行了調整，使之符合相應外部系統的故障模式。
採用圖6所示的重試間隔確定方法，如果消息通知任務重試的次數較少，說明造成消息通知發送不成功的原因在很短時間內消失了，則由於每次重試的時間間隔也較小，故可以保證故障恢復時消息通知的及時發送；如果消息通知任務重試的次數較多，說明造成消息通知發送不成功的原因屬於長期通信故障，則後來重試的時間間隔也較長，可以有效避免太多無效的重試嘗試，減少系統資源佔用，但也可以保證消息通知的確定送達。即上述重試間隔確定方法確保了短期通信故障能夠及時恢復消息通知，而對於長期通信故障則能夠避免大量無效的通知嘗試，兼顧了通知恢復的及時性和效率。
上述本發明一種可靠的系統間消息通知方法和系統，適用於任何協作的系統之間，尤其解決了系統之間通過網際網路進行消息通知時，由於網絡內在的不可靠性和系統軟、硬體故障造成的通知消息丟失且不可恢復的問題，確保消息的可靠、及時到達。本發明支持不同系統間的多協議傳輸，接收方不需要實現複雜的交互協議就能夠可靠接收通知消息，適合廣泛應用於網際網路。所述方法和系統還支持多業務處理，可作為一個通用的業務應用平臺。同時，可以進行多業務和多協議的靈活擴展。
以上對本發明所提供的一種可靠的系統間消息通知方法和系統進行了詳細介紹，本文僅以優選實施例對本發明進行說明。特別是，本發明所述的方法和系統適用於任何協作的系統之間，並不僅局限在基於網際網路的系統之間，只是優選保證了網際網路間的可靠消息通知，更適合廣泛應用於網際網路。所以，並不能因此即局限本發明的權利範圍，以上實施例的說明只是用於幫助理解本發明的方法及其核心思想；同時，對於本領域的一般技術人員，依據本發明的思想，在具體實施方式
及應用範圍上均會有改變之處。綜上所述，本說明書內容不應理解為對本發明的限制。
權利要求
1.一種系統間消息通知方法，其特徵在於，包括以下步驟將通知消息存儲；發送存儲的通知消息；若通知消息發送不成功，則對該通知消息設置重試時間，並更新存儲；檢查等待重試的通知消息，如果存在重試時間到期的通知消息，則執行發送步驟。
2.根據權利要求1所述的一種系統間消息通知方法，其特徵在於，還包括同時發送新通知消息以及重試的通知消息。
3.根據權利要求1所述的一種系統間消息通知方法，其特徵在於所述檢查為定時檢查。
4.根據權利要求1或2所述的一種消息通知方法，其特徵在於所述新通知消息的發送是受到觸發後執行。
5.根據權利要求1或2所述的一種系統間消息通知方法，其特徵在於，執行所述發送步驟前還包括判斷所述消息的事務處理是否完成，如果完成則觸發該消息的發送；否則註冊一個事務同步器，在消息的事務處理完成後再觸發該消息的發送。
6.根據權利要求1所述的一種系統間消息通知方法，其特徵在於，還包括根據所述通知消息選擇相應的協議適配器進行消息通知的發送。
7.根據權利要求1所述的一種系統間消息通知方法，其特徵在於，還包括根據所述通知消息選擇相應的業務插件進行消息通知的預處理以及返回的通知結果的處理。
8.根據權利要求1所述的一種系統間消息通知方法，其特徵在於所述的重試時間間隔隨著重試次數的增加而增大。
9.根據權利要求1所述的一種系統間消息通知方法，其特徵在於，所述的重試時間到期包括重試時間點小於或等於定時檢查的時間點。
10.一種系統間消息通知系統，其特徵在於，包括資料庫，用於保存通知消息；通知客戶端，用於將通知消息存放到所述資料庫中，並觸發消息通知立即發送；通知執行器，用於發送通知消息，若通知消息發送不成功，則對應所述通知消息設置重試時間，並更新所述資料庫中的對應通知消息；通知恢復器，用於檢查等待重試的通知消息，如果存在重試時間到期的通知消息，則通知所述通知執行器。
11.根據權利要求10所述的一種系統間消息通知系統，其特徵在於所述的通知恢復器定時運行。
12.根據權利要求10所述的一種系統間消息通知系統，其特徵在於，還包括消息隊列，通知客戶端通過所述消息隊列觸發所述通知執行器即時發送通知消息。
13.根據權利要求10所述的一種系統間消息通知系統，其特徵在於，還包括設置在所述通知客戶端的事務同步器，負責在消息的事務處理完成後通過所述消息隊列觸發通知執行器。
14.根據權利要求10所述的一種系統間消息通知系統，其特徵在於所述通知客戶端嵌入在消息的業務系統中。
15.根據權利要求10所述的一種系統間消息通知系統，其特徵在於，還包括至少一種協議適配器，每種協議適配器支持一種傳輸協議，用於系統間的數據傳輸。
16.根據權利要求10所述的一種系統間消息通知系統，其特徵在於，還包括至少一種業務插件，用於通知消息發送前的預處理和返回的通知結果的處理。
17.根據權利要求16所述的一種系統間消息通知方法，其特徵在於由所述業務插件判斷決定通知消息的發送是否成功。
全文摘要
本發明公開一種可靠的系統間消息通知方法和系統，能夠保證消息通知的可靠到達。該方法包括以下步驟將通知消息持久存儲；發送存儲的新通知消息或重試的通知消息；若通知消息發送成功，則刪除存儲的本條通知消息；否則對該通知消息設置重試時間，並更新存儲；定時檢查等待重試的通知消息，如果存在重試時間到期的通知消息，則執行發送步驟。所述方法和系統支持不同系統間的多協議傳輸，接收方不需要實現複雜的交互協議就能夠可靠接收通知消息，適合廣泛應用於網際網路。此外，還支持多業務處理，可作為一個通用的業務應用平臺。同時，還可以進行多業務和多協議的靈活擴展。
文檔編號H04L29/06GK1822533SQ20061006745
公開日2006年8月23日 申請日期2006年3月27日 優先權日2006年3月27日
發明者錢志龍, 程立, 李磊 申請人:阿里巴巴公司