SQL Server 2005中Service Broker應用的組成

SQL Server 2005中的新內容Service Broker，可用來建立以非同步訊息為基礎的應用。Service Broker應用是一個或者多個程式的集合，能夠完成一套相關的任務。為了更加深入的瞭解其涵義，讓我們來看看組成應用的各個物件。

訊息器
訊息是Service Broker應用中資訊傳遞的基本單元。在Service Broker內部，訊息是按傳送順序進行接收,並且保證每個訊息只會傳送和接收一次。而且訊息保證不會丟失。有時，某個訊息已被髮送，但是沒有馬上收到。當發生這種情況時，Service Broker會儲存訊息並嘗試再次傳送。訊息帶有確認資訊以確保經他們傳遞的資訊就是他們所等待接收餓。可以傳遞的訊息最大可達2G。

會話
當訊息在Service Broker應用中傳遞使使用會話（或者對話）方法。會話一般針對特別任務生成，當任務完成以後就會被刪除。會話才是Service Broker最主要的資訊交換結構，而不是訊息。會話發生在兩個服務端點之間：發起會話的服務(發起方)，以及接受會話需求的服務（目的方）。

佇列
在Service Broker應用中，訊息以佇列方式儲存等待接受處理。在內部，Service Broker佇列是一種特殊的表格，能夠通過指明佇列名稱的SELECT語句進行檢視，不能在佇列中執行INSERT, UPDATE, 或者DELETE語句。儲存在佇列中的訊息即使重新啟動伺服器也不會丟失。

服務
服務程式是讀取並處理佇列中的訊息的程式。這種服務可以是特定的儲存程式，或者連線資料庫的不同程式。每個服務必須與佇列相關。正如先前所提到的，會話發生在服務之間。

會話組
會話組用來接連訊息的處理過程並使之相互關聯。每個會話是會話組中的一份子。主要的概念是有些訊息與其他訊息相關，會話組將這些相關的會話按照要求的順序結合在一起。事實上，所進行的處理具有對會話組裡的全部訊息的高階連續訪問許可權，直到處理完成。

Service Broker 應用還有很多其他相關的部分。以上提到的各個部分在Service Broker起主要作用。您對它們越熟悉，您就會更熟練的掌握Service Broker應用的編寫。現在，我們來看如何使用Service Broker應用來實現業務交易。

業務處理
業務流程中的任務很少按照同步進行。這些流程經常由彼此獨立的任務組成，但是很可能同時發生，可能重疊，可能需要流程中別的步驟的支援。這種情況經常出現在生產產品的過程中，特別是客戶訂製的生產過程，比如汽車生產。

當有人預訂一輛定製的汽車，汽車各個部件的生產過程並不彼此依賴。例如，這些部件可以同時生產。但是在最後階段，當進行組裝時你會遇到下面的問題：

·取決於前一步驟的步驟。
·如果出現錯誤會對整個專案的成功起絕對性影響的步驟。
·需要購買者補充資訊的步驟。

除了這種情況以外，如果潛在購買者取消了訂單，那麼進行補償的程式也要符合邏輯。您可能對有類似特徵的業務流程比較熟悉。

當資料庫執行這樣的流程時，經常按一系列資料庫交易進行處理，每個交易都有單獨的基本任務。當其中一個資料庫交易被接受或退回時，這一系列相關的業務交易通常都無法以此方法完成。這些交易必須被設計成失敗時，通過邏輯判斷退回業務交易。整個業務程式都很難進行，因為這些獨立的交易實際上是於彼此相關的，他們都包含同樣的總體目標。這是Service Broker這樣的佇列結構的實際價值所在。

在Service Broker應用中，目前的處理方法是可能的，也經常是人們所需要的。您能夠以這種方法建立應用模式，使模式更符合業務流程。在我們定製的汽車行業的例子中，您能夠以這樣的方式設計應用，使得跟蹤底盤的模組和跟蹤引擎的模組能夠同時出現。更好的，對這兩個獨立的零件的處理通過對話組可以相互聯絡。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-558073/，如需轉載，請註明出處，否則將追究法律責任。