們就還應該重新考慮用一個“更好“的服務實現來代替，新的服務實現必須具有更好的服務質量。
2.2 什麼是面向服務的體系架構
面向服務的體系結構是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯繫起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平台、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。
這種具有中立的介面定義（沒有強制綁定到特定的實現上）的特徵稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用程序的每個服務的內部結構和實現逐漸地發生改變時，它能夠繼續存在。而另一方面，緊耦合意味著應用程序的不同組件之間的介面與其功能和結構是緊密相連的，因而當需要對部分或整個應用程序進行某種形式的更改時，它們就顯得非常脆弱。
對松耦合的系統的需要來源於業務應用程序需要根據業務的需要變得更加靈活，以適應不斷變化的環境，比如經常改變的政策、業務級別、業務重點、合作夥伴關係、行業地位以及其他與業務有關的因素，這些因素甚至會影響業務的性質。我們稱能夠靈活地適應環境變化的業務為隨需應變的（On Demand）業務，在隨需應變的業務中，一旦需要，就可以快速地對完成或執行任務的方式進行必要的更改。
值得注意的是，Web Services並不是實現 SOA 的惟一方式。例如 CORBA 是另一種方式，同樣，面向消息的中間件（Message-Oriented Middleware）系統（比如 IBM 的 MQ）也是一種選擇。但是為了建立體系結構模型，用戶所需要的並不只是服務描述。用戶需要定義整個應用程序如何在服務之間執行其工作流。尤其需要找到業務的操作和業務中所使用的軟體的操作之間的轉換點。因此，SOA 應該能夠將業務的商業流程與它們的技術流程聯繫起來，並且映射這兩者之間的關係。例如，給供應商付款的操作是商業流程，而更新您的零件資料庫，以包括進新供應的貨物卻是技術流程。因而，工作流還可以在 SOA 的設計中扮演重要的角色。
此外，動態業務的工作流不僅可以包括部門之間的操作，甚至還可以包括與不為您控制的外部合作夥伴進行的操作。因此，為了提高效率，您需要定義應該如何得知服務之間的關係的策略，這種策略常常採用服務級協定和操作策略的形式。
最後，所有這些都必須處於一個信任和可靠的環境之中，以同預期的一樣根據約定的條款來執行流程。因此，安全、信任和可靠的消息傳遞應該在任何 SOA 中都起著重要的作用。
2.3 面向服務的體系結構所帶來的好處
如前所述，企業正在處理兩個問題：迅速地改變的能力和降低成本的要求。為了保持競爭力，企業必須快速地適應內部因素（如兼并和重組）或外部因素（如競爭能力和顧客要求）。需要經濟而靈活的 IT 基礎設施來支持企業。
我們可以認識到，採用面向服務的體系結構將給我們帶來幾方面的好處，有助於我們在今天這個動蕩的商業環境中取得成功：
SOA 提供了一個抽象層，通過這個抽象層，企業可以繼續利用它在 IT 方面的投資，方法是將這些現有的資產包裝成提供企業功能的服務。組織可以繼續從現有的資源中獲取價值，而不必重新從頭開始構建。
在面向服務的體系結構中，集成點是規範而不是實現。這提供了實現透明性，並將基礎設施和實現發生的改變所帶來的影響降到最低限度。通過提供針對基於完全不同的系統構建的現有資源和資產的服務規範，集成變得更加易於管理，因為複雜性是隔離的。當更多的企業一起協作提供價值鏈時，這會變得更加重要。
從現有的服務中組合新的服務的能力為需要靈活地響應苛刻的商業要求的組織提供了獨特的優勢。通過利用現有的組件和服務，可以減少完成軟體開發生命周期（包括收集需求、進行設計、開發和測試）所需的時間。這使得可以快速地開發新的業務服務，並允許組織迅速地對改變做出響應和減少上市準備時間。
通過以鬆散耦合的方式公開的業務服務，企業可以根據業務要求更輕鬆地使用和組合服務。這意味資源副本的減少、以及重用和降低成本的可能性的增加。
通過 SOA，企業可以未雨綢繆，為未來做好充分的準備。SOA 業務流程是由一系列業務服務組成的，可以更輕鬆地創建、修改和管理它來滿足不同時期的需要。
SOA 提供了靈活性和響應能力，這對於企業的生存和發展來說是至關重要的。但是面向服務的體系結構決不是靈丹妙藥，而遷移到 SOA 也並非一件可以輕而易舉就完成的事情。請別指望一個晚上就將整個企業系統遷移到面向服務的體系結構，我們推薦的方法是，在業務要求出現或露出苗頭時遷移企業功能的適當部分。
2.4 應用系統的的整合與ESB
ESB（Enterprise Service Bus，即企業服務匯流排）是傳統中間件技術與XML、Web服務等技術結合的產物。ESB提供了網路中最基本的連接中樞，是構築企業神經系統的必要元素。
企業服務匯流排ESB就是一種可以提供可靠的、有保證的消息技術的最新方法。ESB中間件產品利用的是Web服務標準和與公認的可靠消息MOM協議介面(例如IBM的WebSphere MQ)。ESB產品的共有特性包括：連接異構的MOM、利用Web服務描述語言介面封裝MOM協議，以及在MOM傳輸層上傳送簡單對象應用協議(SOAP)傳輸流的能力。大多數ESB產品支持在分散式應用之間通過中間層如集成代理實現直接對等溝通。
企業服務匯流排（Enterprise Service Bus，ESB）的概念是從面向服務體系架構(Service -Oriented Architecture， SOA)發展而來的，與以服務為導向的應用架構體系（SOA）緊密連接在一起， 是SOA核心組成部分，是SOA架構中應用整合的骨幹。SOA描述了一種IT基礎設施的應用集成模型，其中的軟構件集是以一種定義清晰的層次化結構相互耦合，其中，一個ESB是一個預先組裝的SOA實現，它包含了實現SOA分層目標所必需的基礎功能部件。在SOA架構上發布的業務服務是ESB的”用戶”，這些基於SOA架構的業務系統所開放出來的服務通過ESB進行交互。它們的交互請求被以事件的方式進行發布和訂閱。
2.4.1 企業應用整合與ESB
企業應用整合(EAI)的概念在IT界提出和討論已經有幾年的歷史了，最初大家談到的EAI的概念，相對後來EAI的發展來看，可以說是一個狹義上的EAI，正如其字面上的含義”Enterprise Application Integration”，即企業應用整合，僅指企業內部不同應用系統之間的互連，以期通過應用整合實現數據在多個系統之間的同步和共享。
伴隨著EAI技術的不斷發展，它所被賦予的內涵變得越來越豐富。現在大家談到的EAI的概念，具有更為廣義的內涵，它已經被擴展到業務整合(Business Integration)的範疇，業務整合相對EAI來說是一個更寬泛的概念，它將應用整合進一步拓展到業務流程整合的級別。業務整合不僅要提供底層應用支撐系統之間的互連，同時要實現存在於企業內部應用與應用之間，本企業和其他合作夥伴之間的端到端的業務流程的管理，它包括應用整合，B2B整合，自動化業務流程管理，人工流程管理，企業門戶以及對所有應用系統和流程的管理和監控等方方面面。
EAI的目標是支持對現有IT系統的重新利用，通過EAI技術能夠將不同的軟體和系統串聯起來，延長這些應用系統的生命周期。傳統的EAI，往往使用如CORBA和COM等的消息中間件進行分散式，跨平台的程序交互，修改企業資源規劃以達到新的目標，使用中間件、XML等方法來進行數據分配。因此，實際上傳統的EAI是部件級的重用。很不幸的是，基於部件的架構沒有統一的標準，因此，各個廠商都有各自不同的EAI解決方案，你會看到各種各樣的中間件平台。如果EAI碰到了異構的IT環境，就必須分別考慮怎樣在各個不同的中間件之間周旋，來實現合理的互聯方式，你不得不考慮各種複雜的可能性。因此，你所見過的大多數傳統EAI解決方案都比較笨重。
如果我們選擇傳統的Hub模式來構建SOA基礎架構，從純粹邏輯的角度，可能會出現哪些問題呢？首先，整個SOA架構的性能，如果每個服務的請求都經過中央Hub的中轉，那麼Hub的負擔會很重，速度會隨著參與者的增多而愈來愈慢；其次，這樣的系統會很脆弱，一旦Hub出錯，整個SOA架構都會癱瘓；最後，這樣的架構會破壞SOA的開放性原則，參與者運行在一個相對封閉的環境中，擴展起來十分麻煩。因此，這也不是理想的SOA架構。
ESB為基礎的架構與前面的Hub結構有什麼不同呢？首先，它比單一Hub的形式更開放，匯流排結構有無限擴展的可能；其次，真正體現了SOA的理念， 一切皆為服務，服務在匯流排(BUS)中處於平等的地位。即使我們需要一些Hub，那麼它們也是以某種服務的形式部署在匯流排上，相比上面的結構要靈活的多。這就是ESB，我們需要給它一個明確的定義：ESB是一種在鬆散耦合的服務和應用之間標準的集成方式。它可以作用於：
★ 面向服務的架構 -分散式的應用由可重用的服務組成
★ 面向消息的架構 – 應用之間通過ESB發送和接受消息
★ 事件驅動的架構 – 應用之間非同步地產生和接收消息
用一句較通俗的話來描述它：ESB就是在SOA架構中實現服務間智能化集成與管理的中介。而它與SOA的關係要相對好理解一些：ESB是邏輯上與SOA 所遵循的基本原則保持一致的服務集成基礎架構，它提供了服務管理的方法和在分散式異構環境中進行服務交互的功能。可以這樣說，ESB是特定環境下(SOA架構中)實施EAI的方式：首先，在ESB系統中，被集成的對象被明確定義為服務，而不是傳統EAI中各種各樣的中間件平台，這樣就極大簡化了在集成異構性上的考慮，因為不管有怎樣的應用底層實現，只要是SOA架構中的服務，它就一定是基於標準的。
以下文章點擊率最高
Loading…