?
復雜性的簡單管理
由于其業務可見性、靈活性及知識管理方面帶來的高額利潤，門戶技術成為了用于對整個企業的商業活動進行監控、查找和管理的流行選擇。對于構建高度動態的能夠聚集、組織和表示來自多個后端系統的信息的企業門戶來說，BEA WebLogic Platform具有很大的吸引力。不論門戶是用功能豐富的WebLogic Portal Server環境實現，還是通過像Jakarta Struts這樣的MVC框架實現，最新版的BEA WebLogic Platform 8.1提供了大量新特性用于創建功能強大的門戶環境。
但是由于企業門戶開始聚合數量不斷增長的跨越不同技術領域、地理界限，甚至是組織界限的服務，所以門戶架構師將需要找到管理環境復雜性的方法。無疑，在門戶與每一個服務之間構建一次性、可靠、點到點的集成不能從開發、部署或運行時方面進行伸縮。所以需要一種“服務網絡”的概念，它提供可靠傳輸、智能路由、高級服務管理特性，以及提供在高度分布式的聯合環境下運作的能力。
幸運的是，一種稱為企業服務總線（ESB；參見側欄“ESB：您的Web 服務網絡”）的新型基礎結構提供了甚至最苛求的門戶環境所要求的復雜級別。ESB是一種基于標準的面向服務的骨干，它能夠進行可靠連接和協調數百個應用程序端點。
ESB為需要連接跨越不同數據中心分布的各種異構系統的企業提供了一種理想的體系結構，同時還保持了絕對的事務完整性。此外，它還提供幾個通過部署時構造進行最初配置的高級服務，從而保護了門戶應用程序，即不必經常對它進行修訂和重新部署來管理后端上的更改。
即使是計劃部署一個門戶以將同構環境中的系統與許多后端服務集成，將ESB合并為集成網絡也有明顯的好處。綜合性的ESB供應商將會提供out-of-the-box管理、安全性、可靠性、高性能的服務請求、本機XML處理、復雜路由和轉換，以作為總線中的增殖特性。另外，作為面向服務體系結構（SOA）的一種基于標準的實現，ESB提供必要的抽象層來履行SOA的全部承諾。在不犧牲同構環境的傳統價值（即管理、安全性、可靠性、伸縮性和性能）的情況下，ESB提供了將底層服務實現無縫地重新部署到其他技術、地理或組織領域的能力。
本文中，我們將通過兩個關鍵用例來演示，使用BEA WebLogic Platform 8.1，將高度分布式的服務與門戶及Web應用程序相集成時ESB的威力和靈活性。在兩部分系列的下一部分中，將展示ESB如何通過操作感知、業務活動監控（BAM）和面向服務的業務過程管理來向組織提供附加值，從而讓門戶可以充分利用擴展企業中的服務的全部價值。
Avitek Medical Records：擴充其業務模型
WebLogic Platform 8.1配帶一個綜合的J2EE指南，稱作“Avitek Medical Records（Avitek醫療記錄）”，用來說明J2EE平臺的所有核心特性。該指南建模的基本思想圍繞這樣一種門戶(一種J2EE Struts應用程序)，它為病人、醫生和管理者提供查看整個醫療記錄集合的能力。另外，該應用程序展示了通過Web Services接口連接外部客戶機的能力，它提供了不通過表示層直接與Avitek服務交互的能力。
作為本文的前提，我們假設Avitek上的“業務量在急劇增長”并且已經獲得醫療記錄的三個新的來源以集成到門戶中。為了使情況復雜一點，新的來源在地理上跨越不可靠的網絡分布，并且包含混合的技術環境（多種J2EE應用程序服務器供應商、Microsoft .NET和定制的解決方案）。實際上，Avitek類似一種能適應變化的體系結構，因為它們很可能會增量地獲得信息的新來源，并會隨著時間慢慢地將這些來源遷移到最新最好的技術上。
盡管Avitek Medical Records的體系結構宣稱能夠使用HTTP/Web服務來集成新的醫療記錄來源，但是本文將通過一些關鍵用例來解釋僅僅使用Web Services環境是不夠的。
圖1
在談到純HTTP/Web服務方法的生存能力時，還存在一些與通信模型（請求/響應模型、單向通信模型和異步服務模型等）的可靠性、性能、豐富性以及服務質量、性能、管理和安全性相關的問題。為此，我們建議修改Avitek的體系結構以與ESB的概念相結合（見圖1）。
ESB是基于工業標準的JMS，將會提供一種企業級的骨干，以便可靠地將服務一起鏈接到內聚性操作單元中，它能夠服務于大多數門戶所需的全范圍的集成場景。本文將會介紹ESB就位后可用的許多場景中的幾個場景：
1.??? 前向緩存（Forward Cache）：為了低延遲、只讀訪問數據而將數據從分布式系統移動到靠近表示層的能力。
2.??? 聯合查詢（Federated Query）：在表示層有效地查詢多系統并異步地聚集響應的能力。
前向緩存服務
“前向緩存服務”用例解決需要把數據從back-office系統暴露到表示層這樣的問題。盡管表示層可以容易地通過請求/響應模型與back-office系統交互，但仍有一些原因使得這樣做行不通：
1.? back-office系統不能維持支持前端表示層所需要的負載。
2.? 請求/響應模型的延遲超出了表示層容許的范圍。
3.? 將back-office系統直接暴露給表示層會有風險——穩定性或是對現有服務級別的沖擊。
4.? back-office系統可能與表示層處于不同的地域；在兩個數據中心之間連接斷了的情況下，數據對于終端用戶來說應該仍然可用。
ESB可用于可靠地將變化轉發到表示層中的緩存中。這里的關鍵單詞是“可靠地”。在分布式基于SOA的環境中，需要將注意力集中到系統之間如何互操作以及在發生故障和停機時會發生什么事情上。很多時候，系統不能為這種類型的可靠性提供必要的消息重發和“未確定解決方案”。ESB可以消除系統中的這種復雜性（見圖2）。
圖2
從定義來看，ESB是一種可以在任意兩個實體間可靠通信的分布式服務網絡。ESB實現模塊提供的部署選項允許將服務質量調整成剛好滿足應用程序的需求。基于工業標準的JMS，兩個實體使用標準接口可靠地進行通信；ESB處理路由的復雜性并保證更改通知的傳遞。
幸運的是，Avitek演示不需要徹底地改變以利用ESB。給定ESB的基于標準的方法，ESB實現模塊通過JMS接口連接進來。Avitek演示中包含了一個MDB，該MDB對JMS連接進行偵聽，以將XML記錄“上載”到MedRec數據庫。一旦記錄被加載到數據庫中，這些數據就對使用標準技術對數據庫進行查詢的前端門戶可用。當然，這種模式還有待加強，以適應記錄刪除請求，或者甚至適應部分記錄更新（參見圖3）。
圖3
但這與標準的JMS實現程序的區別何在呢？JMS實現程序能在單一域中確保信息異步的傳遞。試圖連接多個JMS消息傳遞域通常需要某種定制的橋接，使得消息可以在多個域之間進行可靠的轉發。然而ESB實現模塊在分布式聯合環境中提供本地的端到端JMS通信，這消除了對定制橋接的依賴。另外，ESB還提供附加的基于標準的連接，例如Web services和JCA適配器（參考側欄“ESB提供商：附加值服務”），這允許在ESB上的任何地方靈活地部署服務。
另外需要考慮的是在表示層中數據如何進行緩存。Avitek演示依賴于將標準XML Schema存放在關系數據庫中。可是在有各種各樣信息單元的不同服務環境中，則更傾向于在不必定義關系結構的情況下存儲和處理不同格式的XML。
ESB實現模塊也許會提供嵌入式XML數據庫，采用一種“無schema”的方法來存儲、恢復以及查詢XML文檔，徹底的減少了為適應后端服務數據中的變化所需的數據庫管理時間。
也應該討論一些替代方法來與ESB進行比較和對比。BEA WebLogic 8.1也提供一些不同的方法，來滿足在不同域之間的這種松耦合和可靠的消息傳遞。
可靠的Web服務
?BEA WebLogic 8.1提供一種稱為“可靠SOAP消息傳遞”的新特性。該特性允許兩個不同的WebLogic服務器之間進行異步可靠的消息傳遞。雖然SOAP/Web服務是一種基于標準的方法，目前WebLogic 8.1通過專有的SOAP報頭和交互協議來實現可靠性。也許將來的能夠用像“WS—Reliability”這樣的基于標準的方法來實現。即使是使用象“WS—Reliability”這樣的基于HTTP的標準方法，需要高吞吐量和低延遲的特定用例將通過真正的“端到端”JMS解決方案來獲得更好的服務。
為了可靠的連接兩個跨越不同網絡和地理界限的系統，必須在每一個域中都駐留某種基礎結構，用以在發生故障時提供必要的“存儲和轉發”功能。ESB基礎結構通常是“輕量級”、易管理并且重點只放在集成服務上。此外，將ESB基礎結構部署到.NET 環境或甚至是另外的J2EE基礎結構，可能會得到更好的組織結構。預先計劃ESB當然可以避免以后可能出現的很多問題。
JMS消息橋
BEA WebLogic 8.1提供能夠在兩個不同的JMS實現之間轉發消息的JMS消息橋。這種方法當然提供了相對HTTP/Web服務方法的優勢，但ESB的基礎結構能在本地總線上提供必要的轉發、路由和消息優化功能。ESB也提供內聚管理和安全環境，簡化了部署。
聯合查詢
這種“聯合查詢”用例解決了在表示層中需要對多種后端系統進行查詢的問題。與“轉發服務緩存”用例不同的是，后端系統中的數據不能合理地得到緩存。這是因為：
1.?后端系統中數據的變化速率使得數據無法合理地得到緩存：查詢緩存的數據可能會造成數據不一致和結果錯誤。
2.?數據量太大：緩存轉發的數據在技術上和經濟上都不可行。
聯合服務查詢模式的另一方面是：請求花費的時間太長以至于無法完成（某些情況下，需要幾天）。例如，一個獨立系統可能會包含某種人工干預（例如確認）來完成工作流。因為其固有的異步特性，ESB能夠為這種模式提供強大的基礎。
聯合查詢模式至少有兩種變體。這里討論的變體根據查詢的持續時間進行變化。
對于表1中討論的兩種聯合查詢模式，ESB使用JMS的基本“發布—訂閱”消息傳遞模式來將請求有效地散播到多個后端系統（在本例中是訂閱者）。這些模式說明了實現功能的非常簡單的方法，ESB提供了實現大量技術所需的核心工具。ESB提供了一組豐富的通信模型，它們可以采用最有效的方式來適應門戶與后端系統之間的各種交互。
表1
為了闡明這個觀點，讓我們考慮對三個后端服務上的查詢。如果每個服務需要三秒鐘進行處理，連續地調用這些服務將至少耗費九秒鐘。ESB允許以并行的方式執行服務，使得全部的服務執行時間等于最長的服務的運行時間（在本例中是三秒鐘）。雖然這可以使用集中式多線程技術來實現，但ESB允許并發處理跨總線進行分布，這樣就消除了集中式的瓶頸，并提供了更大的可伸縮性潛力。
聯合查詢：實時請求
針對本例，我們增強Avitek，為醫生提供在多后端系統中查詢的能力，以便確定在某個時間段內得到輸血的患者的名單。
為了實現這種新特性，必須使用WebLogic Server 8.1中新的“JMS包裝”支持。這種特性能直接從EJB或者servlet中有效地發送或接收JMS消息。WebLogic Server 8.1能夠有效的管理JMS連接池，以確保消息能夠在門戶應用程序和JMS實現程序（或在我們例子中是ESB）之間進行快速路由。下面給出它的工作原理：
無狀態的會話bean包含了一個方法，它實現了已被廣泛接受的“JMSReplyTo”模式。當客戶端（servlet和JSP等）調用無狀態會話bean上的方法時，該方法將請求發布給ESB，ESB再將請求分發到在配置主題上偵聽的服務。這類服務的例子是JMS客戶端、Web服務或甚至是與應用程序交互的JCA適配器。
無狀態會話bean定義了一種方法，使得客戶端可以發送任意字符串請求。在XML中可以對它進行格式化。
public boolean sendRequest(String requestData, ArrayList a) {
JMS對象一旦建立，標準的“JMSReplyTo”模型就用于將請求與“返回地址”一起發布。所有響應都會返回到這個無狀態會話bean的實例上（參見清單1）。
最后，這個例子將等待來自ESB上的服務的特定數量的響應，或者直到超時發生為止（參見清單2）。
聯合查詢：長持續時間請求
對于本例，我們建立在前一個例子的基礎上，只是假定來自總線上的服務的響應將以更加不可預知的方式返回。這種模式使門戶用戶可以瀏覽到Web 站點的其它區域，同時響應也以異步方式聚合在用戶的會話中。用戶甚至可以注銷，然后重新登錄以檢查請求的狀態（參見圖4）。
圖4
對于本例，消息驅動bean用于異步收集響應，并將其保存在數據庫中。另一種情況是本地XML數據庫可以派上用場。如果系統用變化中的XML響應信息響應，也許將整個XML響應簡單地存儲到“無schema”數據庫中是最好不過的了。
ESB的一個主要特征是：所有的服務都通過一個“松耦合”的通信接口聯系在一起。與本例有關的好處是：新系統可以聯機進來，并立即被包括到聯合查詢中。由于基礎機制是“發布—訂閱”模式，所以新服務可以簡單地訂閱相關的主題并從門戶接收查詢請求。由于ESB允許在部署時動態發現和智能配置驅動的路由（基于內容和基于上下文等），所以可以保證門戶不受ESB上的服務變化的影響。
聯合查詢：實時請求與長持續時間請求的組合。有時候，可能值得在某個時間幀內收集來自總線上不同系統的結果（實時請求），但在初始時間幀過期后以異步方式收集響應（長持續時間請求）。為此，我們引入單獨的“通知主題”概念，以便當MDB成功地將響應保存到緩存時，允許無狀態會話bean（SSB）接收通知。SSB可以使用任意的業務邏輯來決定何時停止等待，允許門戶應用程序從緩存中讀取數據并將結果顯示給用戶（參見圖5）。
圖5
小結
雖然BEA WebLogic Platform 8.1是一種能處理多種應用程序方案（包括門戶）的強大平臺，但也有某些類型的門戶集成方案，它們是作為企業服務總線需要的。完全基于標準的基礎分布式網絡——ESB能夠創建敏捷、可互操作及可靠的面向服務網絡，以便把企業內外的服務鏈接在一起。由于今天Web服務標準發展到合并JMS提供程序的許多可用語義，所以ESB實現模塊將繼續實現標準并創建可互操作的網絡，使JMS應用程序能夠和Web 服務應用程序對話，反之亦然。同時，ESB將給某些門戶和Web應用程序開發者添加重大的價值，他們嘗試解決涉及異構系統、地理位置和組織的復雜集成方案。
下一部分中，我們將討論操作感知、業務活動監控以及集成工作流如何可以給這些應用程序增加附加值。
ESB：你的Web服務網絡
到現在，你可能會問，“Web服務怎樣？”。Web服務的承諾當然是跨完全不同技術、地域以及組織界限的集成能力。把ESB看作是Web Services的健壯網絡。ESB建立在Java Message Service（JMS）基礎上，它提供所需的關鍵特性，以便為相互連接的服務建立可靠、安全、可管理及高度執行的骨干。實際上，在許多可用的Web服務工具包中，ESB的基礎骨干已經變成可以識別的SOAP傳輸。針對新出現的許多Web Services標準，ESB提供了自己的解釋與實現，使門戶開發人員看不到不同服務間的網絡級互操作細節。許多復雜的Web服務主題，比如路由、工作流、事務、單用戶注冊安全、審計、高級監控和管理，都可以通過ESB基礎結構處理。
ESB實現模塊:增值服務
如前所述，許多ESB 廠商提供增值服務以幫助建立健壯的集成環境。在“前向緩存”用例環境中，有一些需要考慮的其它問題：
l連通性：JMS中的“J”代表“Java”，這是否意味著所有的系統必須符合Java？當然不是！ESB 充當SOA 環境下的“瑞士”，將完全不同技術集成到普通的可互操作網絡。尋找支持本地C/C++實現、MS/.NET、本地HTTP/SOAP支持及更高級別的適配器（JCA或定制）的ESB 實現模塊，以自動化集成過程。
l轉換：Avitek演示合并了在表示層中嵌入的轉換，以便將醫療記錄的不同表示轉換成Avitek形式。然而，在聯合開發環境中，系統某各部分的開發者可以建立到這種XML規范形式的轉換。在本例中，將轉換重新部署在接近初始點（和開發人員）不是更好嗎？尋找在ESB中任何位置都可以配置轉換的ESB實現模塊。
關于作者：Hub Vandervoort是 Sonic Software專業服務部門的副總裁。他具有20多年的顧問和高級技術主管的經驗，其中涉及網絡、通信軟件和Internet產業。在以前，Hub與人共同創建了三個創業風險投資公司，其中包括早期的面向消息中間件（MOM）領先廠商Horizon Strategies, Inc.。
Matt Rothera是Sonic Software（www.sonicsoftware.com）的見習經理，同客戶一起工作，幫助規劃、設計和部署實時、面向服務的體系結構。在超過15年的技術工作中，Matt已經同100個客戶一起工作，把它們的服務與內部應用程序、商業合作伙伴和企業門戶集成。