對構建企業面向服務的體系結構（Service-Oriented Architecture，SOA）中間件應用程序感興趣嗎？Judith Myerson 將向您提供四種可能的方法：自頂向下 (top-down)、自底向上 (bottom-up)、旁路 (sideway) 和嵌入式 (embedding)，同時幫助您探究每種方法的各種利弊。您還會了解到如何確定中間件應用程序可以支持的共享 SOA 的最大數目。
引言
在我的關于企業級 SOA 系列的第一篇文章“在企業級 SOA 中使用 Web 服務，第 1 部分: 使用多重 SOA 來消除企業系統之間的差異”中，我曾談及使用 SOA 消除企業系統差異的場景，展示了如何重用來自一個或多個 SOA 的 Web 服務（以數據為中心且具有業務邏輯），以及如何將它們組合到組織控制之下的一個復合應用程序中。
在第二篇文章“在企業級 SOA 中使用 Web 服務，第 2 部分: 使外部 Web 服務互操作性最優”中，我給出了不引起多重 SOA 過載的服務互操作性實例，從簡單的協議共存到復雜的多平臺互操作性。并且您了解了如何更改每個 Web 服務的服務類型、位置和平臺來實現原始應用程序的業務流程。
本系列的第三部分“在企業級 SOA 中使用 Web 服務，第 3 部分: 將您的 SOA 合并成三維的整合中心以提高速度和可靠性”中，我解釋了您可以如何將 Web 服務和非 Web 服務的多重 SOA 合并成單個三維的集成中心來連接到各種后端企業大型機系統。在本文中，我將解釋您可以如何使用來自 IBM? Rational? 軟件的開發工具在三維空間中開發企業 SOA 中間件應用程序。同時您還將了解到如何將 Web 服務組件組合成跨多重 SOA 的中間件應用程序，以及如何使用下面四種不同的方法來開發它們：
讓我們首先從物理和邏輯的角度研究每種方法。
邏輯和物理 Web 服務
物理 Web 服務即在存儲庫中所發布和找到的 Web 服務。創建一個邏輯 Web 服務后，可以繼續將一個邏輯 Web 服務與另一個物理 Web 服務組合起來，創建一個新的邏輯 Web 服務以供使用。之后，您可以將最后得到的邏輯 Web 服務與另一個物理或邏輯 Web 服務組合起來。您也可以將邏輯 Web 服務轉換成物理 Web 服務組件，以在存儲庫中發布和發現它們。
通過定義中間件應用程序的業務模型和物理 Web 服務組件的業務模型之間的關系，您可以創建邏輯 Web 服務的 SOA 中間件應用程序。為此，您可以使用 Rational Software Architect 和 Rational Software Modeler 中的一個或同時使用它們來支持使用統一建模語言（Unified Modeling Language，UML）的模型驅動 (model-driven) 開發，以及支持分別記錄系統的不同視圖的 UML 可視化建模設計。
自頂向下方法
自頂向下方法從 Web 服務或非 Web 服務中間件應用程序金字塔（請參見圖 1）的頂端開始。您需要將其劃分成更小的 Web 服務或組件，在金字塔的每個低層繼續這個過程，直到最小的部分或組件到達金字塔的底部為止。系統的所有部分都將順利地集成在一起并進行互操作。
圖 1. 自頂向下方法
然而，互操作性可能具有不同的含義，這取決于應用程序的預定用途。例如，如果應用程序是以數據為中心，那么互操作性就是以數據為中心的。但是如果應用程序的主要目標是實現業務流程，那么互操作性就是基于流程的。
現在，讓我們從邏輯的角度來研究自頂向下方法。自頂向下方法考慮由企業 SOA 中間件應用程序組成的應用程序的目標。這個目標又分成子目標，每個子目標更進一步分成更小的單元。這個過程一直繼續下去，直到達到 SOA 中間件應用程序的金字塔的底部為止。
顯然，確保所有子目標都順利地進行互操作非常重要。如果目標針對的是提供一個服務或一組服務，那么服務互操作性就成為首要關注的事情。然而，如果目標針對的是實現策略和規則，那么我們就需要將重點放在策略的互操作性上。
在現實世界中，并不存在單純的以數據為中心、基于流程或策略互操作性。相反，我們通常碰到的都是數據、流程、服務和策略互操作性混合在一起。每種互操作性類型所占的比例可以動態地變化，這取決于每個 Web 服務如何模塊化、設置優先級、最優化，以及如何通過松耦合的方式使彼此的交互達到最大程序。同樣，它也依賴于 Web 服務所運行的平臺（例如開放的 Eclipse 體系結構）。
自底向上方法
從物理的角度來說，自底向上方法將基本的 Web 服務組件定義為最小的基礎部分。這使您可以將它與上一層更大的元素組合在一起，繼續這個過程，直到所有部分都在金字塔頂點處集成為一個完整的復雜 Web 服務和關系的中間件應用程序為止，如圖 2 所示。
圖 2. 自底向上方法
這個物理角度假定系統的所有部分都可以順利地進行互操作。互操作性的含義依賴于 Web 服務交互的類型：以數據為中心、業務流程或組合。應用程序之間互操作性的每種類型所占的比例可以動態地變化。
從邏輯的角度來說，自底向上方法從作為 SOA 企業目標的基礎構件的子目標（例如服務組件）開始。作為一名開發人員，您可以與分析人員一起，將它們組合成上一層的更大目標。繼續這個過程，直到所有的子目標都在金字塔的頂點處集成為一個 SOA 中間件的企業目標為止。
確保所有的子目標都將順利地進行交互非常重要。如果子目標針對的是提供一個服務或一組服務，我們首要關注的事情就是子目標之間的服務互操作性。然而，如果子目標針對的是實現策略和規則，那么我們關心的事情就變成子目標之間的策略互操作性。
旁路方法
從物理的角度來說，旁路方法（如圖 3 所示）允許您在自頂向下或自底向上方法的旁路添加或刪除 Web 服務組件。這使您能夠在保持現有中間件完整的同時，更好地響應變更的設計和開發需求。旁路角度假定要添加的組件將可以與現有的組件順利地交互。同樣，它也假定要刪除的組件將不會破壞剩余組件之間的互操作性。
圖 3. 旁路方法
從邏輯的角度來說，旁路方法使您能夠從在自頂向下或自底向上方法的旁路添加邏輯 Web 服務的子目標開始。這使您可以添加諸如新的 Web 服務的服務類型和位置這樣的子目標。您可以使用任一方法的旁路從邏輯 Web 服務中刪除子目標。
您還可以更改 Web 服務的子目標，以便重用它來開發各種中間件應用程序。請確保在邏輯上添加、刪除或者更改子目標時，Web 服務之間的互操作仍然能夠在生產環境中順利地進行。您還需要確保在測試環境中運行的 Web 服務能夠順利地出色工作。
嵌入式方法
從物理和邏輯的角度來說，嵌入式方法是上述三種方法的混合，至少要嵌入金字塔某層中的兩級或三級深。在這個嵌套、兩級嵌入式方法示例中，您可以在自底向上方法中嵌入自頂向下方法（請參見圖 4），或者反過來。您也可以在自頂向下或自底向上方法中嵌入旁路方法。
圖 4. 嵌入式方法
您可以獲得三級嵌套的嵌入式方法。例如，通過將旁路方法嵌入到自頂向下方法，接著嵌入到自底向上方法，您可以做到這一點。您也可以將自頂向下方法嵌入到第二個自頂向下方法，接著再嵌入到自底向上方法。
決定使用哪種方法
在開放的體系結構中開發 SOA 中間件應用程序依賴于（舉例）您想要使用哪種關系型或 WebSphere? 包。正如前面提到的，您可以使用 Rational Software Architect 和 Rational Software Modeler 來對企業 SOA 中間件進行建模，將 Web 服務當作對象、關系實體或者兩者的混合。您也可以使用 Rational Web Developer for WebSphere Software for Linux?、Windows? 2000、Windows 2003 Server 和 Windows XP 來簡化您的 Web 服務開發。
結束語
開發企業 SOA 中間件需要事先計劃好可以將多少 SOA 作為中間件應用程序組合在一起。最好就使用哪些方法開發中間件的問題與業務分析人員小組進行溝通。您還將發現，解決了這些問題使開發企業 SOA 中間件更加容易。您可以為中間件應用程序開發這樣的 SOA，它們既重用，又可以交互和集成。而且通過事先決定使用哪些方法或方法的組合，使分析人員設計和分析中間件的工作變得簡單。分析人員能夠確定使用哪種方法以及將多少個 SOA 組合在一起，因為中間件基于它們之間各種類型的互操作性，并且可能引起企業 SOA 過載。