下面我們來解釋一下上面的基礎體系架構，上面這種體系架構方案，區別於 Microsoft. Net。我們知道J2EE 作為基礎的底層架構，結合的門戶和集成的框架，它體現了這樣一種基本觀點：即真正的客戶需要的基於開放式標準的架構。這種架構希望確保交互能夠全方位地進行，並且不會受到任何專有因素的干擾。因此，標準是為了促使我們考慮的問題：他們的基礎設施的開放程度如何？怎樣進行連接？
可見，基礎J2EE體系架構的職能其實是將這兩個要素連接在一起，以便支持用戶交互，並將企業基礎設施用於提供交互所需的功能。 使任何用戶都能夠隨時隨地通過他們自己選擇的設備與我的企業進行安全且高度可用的交互。此外，從企業角度講，我希望使任何用戶的交互都遵守我的業務規則，並且具有高度的安全性，從而提高企業資源的安全性，同時為用戶信息提供保護。從 IT 基礎設施的角度來看，資源可以是人員、信息、數據或應用程序；既可能是打包的應用程序（例如
實現外部應用、實現 Boss的EJB應用），也可能是可以在
其他應用服務器中，甚至是 Microsoft.net 應用程序中運行的自定義應用程序。
該基礎體系構架的另一個組件是各功能之間的通信方式，我們稱之為通信機制。例如，在 Microsoft.net 中，該機製為 Web 服務。在 WebSphere 中，該機制可能是 Web 服務，也可能是其他選項。
基礎設施的開放性問題需要進行兩個方面的開放性測試。首先，如果編程模型能夠部署在多種操作系統中，可以由獨立的標準組織進行修改，並且可以通過多種來源獲得，那麼我們就認為該編程模型是開放的。如果編程模型通過了上述三項測試，即可被稱為開放的。
其次，如果通信機制可以在不同的編程模型之間進行通信，那麼我們就稱之為開放的。這是一種比較簡單的測試。例如，Web 服務實際上就是開放的通信機制。
在目前的業界的理解，通常”業務集成”
將涉及下面的幾個領域的功能實現和提供。
消息數據傳輸機制/Messaging
消息代理/Message Broker
模型和模擬/Modeling and Simulation
人員參與的工作流/Human Workflow
自動處理的流程/Process Automation
監控和管理/Monitoring
因此當企業構建應用程序時，可以在構造方式上進行一定的標準化。這種標準化的方式實際上類似企業基礎設施的功能就是進行連接、管理用戶交互，並使用戶交互能夠驅動和訪問待執行的操作；當然，這必須遵守業務規則。
這種架構中，企業應只搭建一個基礎架構。而在當我們考慮要連接的對象（各類應用）時，可以將連接對象定義為資源，即資源可以是人員、數據、應用程序甚至流程。這種做法的依據是基礎架構設施應支持多個用戶和多項資源的連接，滿足企業不停的業務增長的需求，和逐步的建設。如下圖示：
1.3.2 企業服務總線 (Enterprise Service Bus)技術
ESB 是一種體系結構模式，支持虛擬化通信參與方之間的服務交互並對其進行管理。它提供服務提供者和請求者之間的連接，即使它們並非完全匹配，也能夠使它們進行交互。此模式可以使用各種中間件技術和編程模型實現。
在 ESB 模式中，服務交互的參與方並不直接交互，而是通過一個總線交互，該總線提供虛擬化和管理功能來實現和擴展 SOA 的核心定義。IBM ESB 模式提供以下幾方面的虛擬化：
位置和標識：參與方不需要知道其他參與方的位置或標識。例如，請求者不需要知道請求是否可以由某個提供者提供服務。您可以隨意添加或刪除服務提供者，而不會帶來任何干擾。
交互協議：參與方不需要採用相同的通信協議或交互方式。表達為 SOAP/HTTP 的請求可能由僅理解 Java 遠程方法調用 (RMI) 的提供者提供服務。
接口：請求者和提供者不需要就公共接口達成協議。ESB 可以通過將請求消息轉換為提供者所期望的格式來處理此類差異。
（交互）服務質量 (QoS)：參與方聲明其 QoS 要求，包括性能和可靠性、請求的授權、消息內容的加密/解密、服務交互的自動審核以及如何對請求進行路由（如根據工作負載分佈標準將請求路由到可用的實現）。描述請求者和提供者的 QoS 要求和功能的策略可以由服務自己實現或者由進行不匹配補償的 ESB 實現。
因此 ESB 模式使請求者不用了解服務提供者的物理實現——從應用程序開發人員和部署人員的角度來看均是如此。總線負責將請求交付給提供所需功能和 QoS 的服務提供者。提供者接收他們要響應的請求，而不知道消息的來源。ESB 本身對使用它的服務請求者和提供者均不可見。應用程序邏輯可以使用各種編程模型和技術調用或交付服務，而無需考慮是直接連接還是通過 ESB 傳遞的。連接到 ESB 是部署決策；應用程序源代碼不會受到影響。
ESB 支持許多交互類型，包括單向、請求/響應、異步、同步和發佈/訂閱。它還支持複雜事件處理（在複雜事件處理中，可能會觀測到一系列事件），以產生一個事件作為該系列中的關係的結果。
下面的圖1 對基本 ESB 模式進行了描述。消息流過將各個通信參與方相互連接在一起的總線。某些參與方會調用其他參與方提供的服務；而其他參與方則會向感興趣的使用者發佈信息。端點與 ESB 交互的位置稱為服務交互點 (SIP)。例如，SIP 可以是 Web 服務端點、WebSphere MQ 隊列或 RMI 遠程對象的代理。服務註冊表將捕獲描述以下內容的元數據：SIP 的要求和功能（例如，提供或需要的接口）、它們希望與其他 SIP 的交互方式（例如，同步或異步，通過 HTTP 或 JMS）、它們的 QoS 要求（例如，首選的安全、可靠交互）以及支持與其他 SIP 交互的其他信息（例如，語義注釋）。
將總線插入參與方之間，提供了將它們的交互通過稱為中介
的構造進行協調的機會。中介對請求者和提供者之間動態傳遞的消息進行操作。對於複雜的交互，可以按順序將中介連在一起。中介模式部分討論了實現這些虛擬化、QoS 和管理概念的常用中介模式。
ESB 模式為 SOA 實現提供了靈活且易於管理的方法。總線透明地插入端點之
以下文章點擊率最高
Loading…