Service Broker是一個計算機系統函式。
基本介紹
- 外文名：Service Broker
- 意義：生成可靠且可擴展的應用程式
- 來源：SQL Server 2005
- 性質：建立以異步訊息為基礎的套用
簡介,概述,訊息器,會話,佇列,服務,會話組,業務處理,
簡介
SQL Server Service Broker 為訊息和佇列應用程式提供 SQL Server 資料庫引擎本機支持。這使開發人員可以輕鬆地創建使用資料庫引擎組件在完全不同的資料庫之間進行通信的複雜應用程式。開發人員可以使用 Service Broker 輕鬆生成可靠的分散式應用程式。
使用 Service Broker 的應用程式開發人員無需編寫複雜的內部通信和訊息，即可跨多個資料庫分發數據工作負荷。因為 Service Broker 會處理會話上下文中的通信路徑，所以這就減少了開發和測試工作。同時還提高了性能。例如，支持網站的前端資料庫可以記錄信息並將進程密集型任務傳送到後端資料庫以進行排隊。Service Broker 確保在事務上下文中管理所有任務以確保可靠性和技術一致性。
概述
Service Broker 可幫助資料庫開發人員生成可靠且可擴展的應用程式。由於 Service Broker 是資料庫引擎的組成部分，因此管理這些應用程式就成為資料庫日常管理的一部分。
Service Broker 為 SQL Server 提供佇列和可靠的訊息傳遞。Service Broker 既可用於使用單個 SQL Server 實例的應用程式，也可用於在多個實例間分發工作的應用程式。
在單個 SQL Server 實例內，Service Broker 提供了一個功能強大的異步編程模型。資料庫應用程式通常使用異步編程來縮短互動式回響時間，並增加應用程式總吞吐量。
Service Broker 還會在 SQL Server 實例之間提供可靠的訊息傳遞服務。Service Broker 可幫助開發人員通過稱為服務的獨立、自包含的組件來編寫應用程式。需要使用這些服務中所包含功能的應用程式可以使用訊息來與這些服務進行互動。Service Broker 使用 TCP/IP 在實例間交換訊息。Service Broker 中所包含的功能有助於防止未經授權的網路訪問，並可以對通過網路傳送的訊息進行加密。
SQL Server 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套用中，目前的處理方法是可能的，也經常是人們所需要的。您能夠以這種方法建立套用模式，使模式更符合業務流程。在我們定製的汽車行業的例子中，您能夠以這樣的方式設計套用，使得跟蹤底盤的模組和跟蹤引擎的模組能夠同時出現。更好的，對這兩個獨立的零件的處理通過對話組可以相互聯繫。
