體系結構中的集成需求
討論至此，集成已限定為通過基于組件的服務進行的應用程序的集成，但是集成這個主題比這要寬泛得多。在估計一個體系結構的需求時，必須考慮一些集成的類型或“方式”。您必須考慮如下幾方面：
- 應用程序集成
- 終端用戶界面集成
- 應用程序連接
- 流程集成
- 信息集成
-
構建集成開發模型。
終端用戶界面集成涉及如何集成特定用戶訪問的全部應用程序和服務來提供可用、高效、一致的界面。它是一個正在發展的主題，而新的發展在近期將主要取決于 Portal 服務器使用方面的進展。雖然 Portlet 已經可以通過 Web 服務調用本地服務組件，但是新技術（比如用戶遠程 Portlet 的 Web 服務）將使內容和應用程序提供者能夠創建交互式服務，這些服務在因特網上可以通過 Portal 即插即用，從而為很多新的集成提供了可能。
應用程序連接是一種集成方式，它涉及體系結構必須支持的所有類型的連接。在一個層次上，這意味著數據的同步和異步通信、路由、轉換和高速分布、以及網關和協議轉換器等等。而在另一個層次上，它還與輸入和輸出或源（sources）和匯（sinks）的虛擬化有關，正如您在 EWA 的通道（Channel）和協議轉換程序（Protocol Handlers）中所看到的。這里的問題在于數據移入、移出以及在實現體系結構的框架中移動的方式。
流程集成涉及開發映射到業務流程和為業務流程提供解決方案的計算流程、將應用程序集成到流程以及集成一些流程與其他一些流程。雖然第一項需求可能看起來似乎無關緊要，不過就是體系結構提供一個模擬基本業務問題的環境，但是，如果在這一層中不進行充分的分析，體系結構的任何實現注定都將失敗，不管它采用的技術是多么的巧妙。將應用程序集成到流程可能包括企業中的應用程序，也可能涉及調用遠程系統中的應用程序或服務，而這些遠程系統多半屬于業務合作伙伴。同樣地，流程層集成可能涉及整個流程的集成而不僅僅是來自外部源的單個服務，比如供應鏈管理或金融服務這樣橫跨多個機構的流程。為了滿足這樣的應用程序和流程的集成需求，可以使用像 BPEL4WS 這樣的技術，而應用程序框架也可以使用程序配置 Scheme（比如在 EWA 中看到的）。實際上，可以在底層使用 BPEL4WS 來構造一個高層配置 Scheme，然后通過一個引擎來驅動，這個引擎不僅提供流管理，而且還提供其他功能。然而，在構建這一切之前，您應該首先了解體系結構方面的需求，然后，再構建合適的基礎架構。
信息集成是一個流程，其作用在于為所有需要它的應用程序提供對企業中全部數據的一致訪問，而不管這些應用程序是以什么形式需要它，也不受數據的格式、來源或位置的限制。在實現時，這項需求可能包括 適配器和轉換引擎，不過它通常要比這復雜。而關鍵的概念往往是數據的虛擬化，這可能包括 數據總線（Data Bus）的開發，企業中的所有應用程序都通過標準服務或接口從數據總線中請求數據。因此，不管數據是來自電子數據表、本地文件、SQL 或 DL/I 數據庫，還是來自內存中的數據存儲，都可以將數據提供給應用程序。永久存儲中的數據格式可能還不為應用程序所知。應用程序更不知道管理數據的操作系統，因而訪問 AIX 或 Linux 系統中的本地文件的方式與這些文件放在 Windows、OS/2、ZOS 或其他系統中時訪問它們的方式相同。同樣地，數據的位置也是透明的；由于它是由共同的服務提供的，所以是由訪問服務而不是由應用程序來負責查詢數據（無論是本地的還是遠程的），然后按照請求的格式提供數據。
應用程序開發環境的最后一項需求是，必須考慮可能在企業中實現的集成的所有方式和層次，并且為它們的開發和部署做好準備。要想真正做到健壯，開發環境必須包括（和執行）一種方法來明確地規定如何設計和構建服務和組件，以便促進重用、消除冗余和簡化測試、部署和維護。
上面列出的所有集成方式在任何企業中都有一定程度的體現，盡管在某些情況下它們可能是簡化的，或者沒有明確地進行定義；因而，在著手設計新的體系結構框架時，您必須全面的考慮它們。特定的 IT 環境可能只有很少的數據源類型，因此，消息集成可能會很簡單。同樣地，應用程序連接的作用域可能也很有限。雖然如此，如果希望框架能夠隨著企業的成長和變化成功地繼續得以保持，則框架中的集成功能仍然必須由服務提供，而不是由特定的應用程序來完成。