Sun Java Enterprise System 5 技術摘要

第 2 章 Java ES 解決方案架構

本章概述做為 Java ES 解決方案基礎的架構概念。本章說明如何將系統服務元件和服務品質元件用於支援分散式企業解決方案。

Java ES 解決方案架構有兩個層面：邏輯架構與部署架構。邏輯架構描述了解決方案的邏輯建構區塊 (軟體元件) 彼此之間的互動。部署架構描述邏輯架構與實體運算環境的對映。Java ES 元件在邏輯架構與部署架構中均發揮重要作用。

本章介紹 Java ES 解決方案架構設計的結構架構，並提供基於該結構架構的範例架構。本章包含以下各節：

Java ES 結構架構

Java ES 元件支援分散式軟體解決方案的部署。在由業務需求所要求的效能、可用性、安全性、延展性及服務性層級，若要達成需要的功能，這些軟體解決方案必須經過適當的設計。

設計企業適用解決方案時要涉及一些架構要素。這些要素代表不同的視角，可從其中檢視用於建構此類系統的許多軟體元件之間的互動。特別是，分散式系統的設計與下列三個架構要素有關：

基礎架構服務相依性。此要素強調系統服務元件在支援分散式解決方案中所起的作用 (請參閱系統服務元件) 。
邏輯層。此要素強調解決方案元件的邏輯及實體獨立性，以便在跨網路或網際網路環境中進行部署。
服務品質。此要素強調如何達到服務品質需求 (像是可用性、安全性、延展性及服務性)，包括服務品質元件的作用 (請參閱服務品質元件)。

下圖會顯示解決方案架構的這三個要素。

圖 2–1 Java ES 解決方案架構要素

這三要素共同組合成一個單一架構，其中包含軟體元件 (應用程式元件與基礎架構元件兩者) 間的關係，需要使用這些元件來達成軟體解決方案需具備的服務功能與服務品質。

以下章節會個別描述三個要素，然後是有關將三個要素合成為統一框架的內容。

第 1 要素：基礎架構服務相依性

分散式企業應用程式的互動軟體元件需要基本的基礎架構服務，讓分散式元件可以執行相互通訊、協調作業、實作安全存取等動作。本節說明這些 Java ES 元件在提供基礎架構服務時所扮演的關鍵角色。

基礎架構服務層級

設計分散式軟體系統時，不論它主要由自訂開發元件還是即開即用 Java ES 元件組成，都需要包含若干基礎架構服務。這些服務可在許多層級中作業。

圖 2–2 說明解決方案架構的基礎架構服務相依性。此圖顯示的層級是圖 1–1 中已展開的基礎架構服務層檢視。圖 2–2 中的服務階層及它們之間的相依性構成了解決方案邏輯架構的一重要要素。這些基礎架構服務提供 Java ES 系統服務元件的主要原理 (請參閱系統服務元件)。

一般而言，下圖中所顯示的服務分為以下三大群組：低階平台服務、高階應用程式服務與一組中介軟體服務，各群組的命名依據是其在其他兩個群組間的位置。

圖 2–2 第 1 要素：基礎架構服務層級

顯示各分散式服務基礎架構層級的圖形，按從最低層級的作業系統平台服務至最高層級的整合服務這一順序顯示。

以下內容描述了不同的基礎架構服務層級，並參照與 Java 程式設計語言工件相關的各種服務，然後按照由低到高的順序列出，如圖 2–2 所示：

作業系統平台。為任何在電腦上執行的程序提供基本支援。作業系統管理實體裝置及記憶體、執行緒和其他支援 Java 虛擬機器 (JVM^TM 機器) 所需的資源。
網路傳輸。為在不同電腦上執行的分散式應用程式元件間的通訊提供基本網路支援。這些服務包括對 TCP 和 HTTP 等協定的支援。其他較高層級的通訊協定 (請參閱訊息傳送層) 則要視這些基礎傳輸服務而定。
持續性。提供對存取與儲存靜態資料 (像是使用者、目錄或配置資訊) 與動態應用程式資料 (經常更新的資訊) 的支援。
訊息傳送。 提供對應用程式元件間的同步與非同步通訊的支援。同步訊息傳送指訊息的即時傳送與接收，且包括 J2EE 元件間的遠端方法呼叫 (RMI) 及與 Web 服務的 SOAP 互動。而在非同步訊息傳送通訊中，訊息發送並不需要依賴客戶是否已準備好立即接收訊息才能進行。非同步訊息傳送規格 (如 Java Message Service (JMS) 和 ebXML) 支援擔保穩定性及其他訊息傳送語義。
執行階段。提供任何分散式元件模型 (如 J2EE 或 CORBA 模型) 所需要的支援。除緊耦合分散式元件所需的遠端方法呼叫外，執行階段服務還包括元件狀態 (生命週期) 管理、執行緒池管理、同步化 (互斥鎖定)、持續性服務、分散式作業事件監視及分散式例外處理。在 J2EE 環境中，這些執行階段服務由應用程式伺服器或 Web 伺服器中的 EJB、Web 及訊息驅動 Bean 容器提供。
安全性與策略。提供對安全存取應用程式資源的支援。這些服務包括對一些策略的支援，這些策略管控以群組或角色為基礎的對分散式資源的存取，還包括單次登入功能。單次登入讓使用者能夠在通過分散式系統中一項服務的認證時便自動通過系統中其他服務 (J2EE 元件、業務服務和 Web 服務) 的認證。
使用者協作。所提供的服務在支援使用者間的直接通訊及企業與網際網路環境使用者間的協作方面扮演關鍵的角色。這些服務是應用程式層級的業務服務，一般由獨立伺服器 (如電子郵件伺服器或 Calendar Server) 提供。
整合。提供集合現有業務服務的服務。提供用來存取服務的共用介面 (如入口網站所採用的)，或是透過將這些服務在生產作業流程中予以協調的程序引擎將它們加以整合。整合也可以不同企業間的企業對企業互動方式來進行。

圖 2–2 中的服務層級反映了基礎架構服務彼此間的相依性，按從最低層級作業系統服務至最高層級的應用程式與整合服務這一順序顯示。一般來說，每項服務都依賴於其下方的服務，而為其上方的服務提供支援。但是，圖 2–2 並不代表基礎架構服務的嚴格分層限制。較高層級的服務可直接與較低層級的服務進行互動，而不需要仰賴中間層級。例如，某些執行階段服務可直接仰賴平台服務，而不需要其間有任何服務層級。此外，也可將其他服務層級如監視或管理服務納入到此概念性圖示中。

Java ES 基礎架構服務元件

Java ES 元件實作圖 2–2 中顯示的分散式基礎架構服務層級。下圖顯示了系統服務元件在不同層級內的位置。

圖 2–3 Java ES 系統服務元件

備註 –

圖中的較暗方塊指示未包含在 Java ES 中的元件。使用者協作元件並不包含於 Java ES 中，但常隨 Java ES 元件一起部署，並在 Java ES 架構內使用。這些元件為 Sun Java Communications Suite 的組成部份，在此文件中只做為說明參照之用。此外，顯示的作業系統平台並不是 Java ES 正式的組成部份，但包含在圖中以便顯示會支援 Java ES 元件的作業系統平台。

Java ES 基礎架構服務相依性

一般而言，在圖 2–3 中顯示的每個 Java ES 系統服務元件在基礎架構中，都依賴於其下方的元件，而為其上方的元件提供支援。在設計邏輯架構時，這些相依性及支援關係是重要因素。

下表顯示 Java ES 系統服務元件間的特定關係 (依從上至下順序列示)，如圖 2–3 所示。

表 2–1 Java ES 系統服務元件間的關係


元件	依賴	支援
Portal Server	Application Server 或 Web Server Access Manager Directory Server 如果配置為使用對應的通道：Calendar Server、Messaging Server 和 Instant Messaging [Calendar Server、Messaging Server 和 Instant Messaging 元件為 Sun Java Communications Suite 的部份可用元件。]	無
Access Manager	Application Server 或 Web Server Directory Server	Portal Server 如果配置為單次登入：Calendar Server、Messaging Server 和 Instant Messaging
Application Server	Message Queue Directory Server (用於管理式物件)	Portal Server Access Manager
Message Queue	Directory Server (用於管理式物件)	Application Server
Web Server	Access Manager (用於存取控制)	Portal Server Access Manager
Directory Server	無	Portal Server Access Manager Calendar Server Messaging Server Instant Messaging
Service Registry	Java DB	基於 Application Server 的元件
Java DB	無	Service Registry

第 2 要素：邏輯層

您可以這樣設想，分散式企業應用程式的互動軟體元件位於多個邏輯層中。這些層表示軟體元件的邏輯與實體獨立性 (以它們提供的服務的特性為依據)。

下圖說明解決方案架構的邏輯層這一要素。

圖 2–4 第 2 要素：分散式企業應用程式的邏輯層

在大部份的情況下，邏輯層架構代表圖 1–1 中的分散式企業應用程式層。基礎架構服務層級中討論的 Java ES 系統服務元件提供對圖 2–4 中顯示的所有邏輯層內應用程式元件的支援。雖然邏輯層概念大部份適用於自訂企業應用程式，但也適用於由 Sun Java Communications Suite 元件和某些入口網站服務所提供的協作服務。

邏輯層描述

本節簡述了圖 2–4 中所示的四個邏輯層。這些描述所參考的是使用 J2EE 平台元件模型實作的應用程式元件。但事實上，其他分散式元件模型 (如 CORBA) 同樣支援此架構。

用戶端層。用戶端層由一般使用者可透過使用者介面直接存取的應用程式邏輯構成。用戶端層中的邏輯可以包括基於瀏覽器的用戶端、在桌上型電腦上執行的 Java 元件或在掌上型裝置上執行的 Java^TM 2 Platform, Micro Edition (J2ME^TM 平台) 行動用戶端。
表示層。表示層由應用程式邏輯構成，應用程式邏輯的作用是準備資料以供傳送至用戶端層，以及處理來自用戶端層的請求以傳送至後端業務邏輯。表示層中的邏輯通常由 J2EE 元件，像是 Java Servlet 元件或 JSP 元件構成，這些 JSP 元件的作用是準備資料以便以 HTML 或 XML 格式傳送或接收供處理的請求。此層可能還包括入口網站服務，該服務提供對業務服務層中的業務服務的個人化、安全及自訂存取。
業務服務層。業務服務層由執行應用程式主要功能的邏輯構成：處理資料、實作業務規則、協調多位使用者及管理外部資源如資料庫或老舊系統。此層通常由符合 J2EE 分散式元件模型的緊耦合元件構成，像是 Java 物件、EJB 元件或訊息驅動 Bean。可將單個的 J2EE 元件組合起來，提供各種複雜的業務服務，如庫存服務或稅務計算服務。可以將單個元件與服務組合封裝為服務導向的架構模型內的鬆耦合 Web 服務，這些 Web 服務符合簡易物件存取協定 (SOAP) 介面標準。也可以將業務服務做為獨立伺服器 (像是企業行事曆伺服器或訊息傳送伺服器) 來建立。
資料層。 資料層是由一些服務所組成，這些服務會提供業務邏輯使用的永久性資料。這些資料可以是儲存在資料庫管理系統中的應用程式資料，也可以是儲存在簡易目錄存取協定 (LDAP) 資料存放區中的資源與目錄資訊。這些資料服務也可以包括從外部來源取得的資料，或從老舊運算系統存取的資料。

邏輯與實體獨立性

圖 2–4 中以圖例說明的架構要素以四個獨立的層代表，藉以強調元件的邏輯及實體獨立性。這些層表示在網路環境的不同電腦中如何分割應用程式邏輯：

邏輯獨立性。架構模型中的四個層代表邏輯獨立性：可以修改某層 (如業務服務層) 中的應用程式邏輯，而不會影響其他層中的邏輯。可以變更業務邏輯的實作，而不需要變更或升級表示層或用戶端層中的邏輯。舉例來說，這種獨立性表示在引進新的用戶端元件類型時，可不必對業務服務元件進行修改。
實體獨立性。這四個層也代表實體獨立性：您可以在不同硬體平台 (即採用不同的處理器配置、晶片組和作業系統) 上的不同層中部署邏輯。這種獨立性所帶來的益處是，能夠在最可因應各分散式應用程式元件運算需求且最適合最大化網路頻寬的電腦上執行這些元件。

如何將應用程式元件或基礎架構元件與硬體環境 (即部署架構) 對映需視眾多因素而定，而這些因素又會受軟體解決方案規模和複雜性的影響。如果是小型的部署，部署架構可能只會包含幾部電腦。若是大規模的部署，元件與硬體環境的對映可能會考量下列因素，不同電腦的速度與能力，網路連結的速度與頻寬，安全性與防火牆注意事項及重複元件策略以實作高可用性與延展性。

適用於系統元件的分層架構

如圖 2–3 所示，Java ES 基礎架構服務元件為分散式軟體解決方案提供了基本的基礎架構支援。部份解決方案包含了 Sun Java Communications Suite 元件和一些 Java ES 元件提供的應用程式層級服務。這些解決方案使用邏輯層設計方法。

例如，Messaging Server 提供的電子郵件通訊服務是使用若干個邏輯上獨立的 Messaging Server 配置實作的。這些獨立配置中的每一個均提供一組不同的服務。設計訊息傳送解決方案時，這些獨立配置表示為位於不同邏輯層的個別元件，如下圖所示 (其中連接各元件的線代表彼此的互動)。

備註 –

下圖並非代表完整的邏輯架構。其中省略了一些 Java ES 元件來簡化圖例。

圖 2–5 Messaging Server：分層架構範例

備註 –

通訊元件並不是 Java ES 的組成部份，但常隨 Java ES 元件一起部署，並在 Java ES 架構內使用。這些通訊元件為 Sun Java Communications Suite 的組成部份，在此文件中只做為說明參照之用。

由於將各 Messaging Server 功能按邏輯分割為不同的層，因而可以在同一實體環境中的不同電腦上部署邏輯上獨立的 Messaging Server 配置。實體分割在滿足服務品質需求方面提供了彈性 (請參閱第 3 要素：服務品質)。例如，實體分割為不同的實例提供了不同的可用性解決方案，也為不同的 Messaging Server 功能提供不同的安全性實作。

第 3 要素：服務品質

前兩個架構要素基礎架構服務相依性和邏輯層主要定義架構的邏輯層面，即需要哪些元件以何種方式進行互動，才能給一般使用者提供服務。對任何已部署解決方案而言，是否具備滿足服務品質需求的能力也是另一個同等重要的要素。

解決方案架構的服務品質要素會特別強調 Java ES 服務品質元件所扮演的角色。

服務品質

隨著網際網路和電子商務服務對業務營運的重要性日益增加，這些服務的效能、可用性、安全性、延展性與服務性已成為大規模、高效能部署架構在服務品質上的關鍵性需求。

若要設計出成功的軟體解決方案，您必須建立相關的服務品質需求，並且設計出能滿足這些需求的架構。可使用一些重要的服務品質來指定服務品質需求。下表概述了這些服務品質。

表 2–2 影響解決方案架構的服務品質


系統服務品質	描述
效能	衡量相對於使用者負載條件的回應時間和延時。
可用性	一種衡量一般使用者可存取系統資源與服務頻率的指標 (系統的正常執行時間)。
安全性	描述系統及其使用者的完整性之複雜因子組合。安全性包含系統的實體安全性、網路安全性、應用程式及資料安全性 (使用者的認證與授權) 以及資訊的安全傳輸。
延展性	隨時間推移在已部署系統中新增容量的能力。延展性通常牽涉在系統中新增資源，但不應要求對部署架構做出變更。
潛在容量	系統在不新增資源的情況下處理少見的尖峰負載用量的能力。
服務性	對已部署系統進行維護的易行度，維護包括系統監視、修復發生的問題及升級硬體與軟體元件等作業。

服務品質要素對解決方案部署架構會有極大的影響：如何在實體環境中部署應用程式元件及基礎架構元件。

各服務品質會影響部署架構且彼此關係密切。對某個系統品質的需求可能會影響對其他系統品質的設計。例如，較高層級的安全性可能會影響效能，而效能又會影響可用性。新增額外電腦透過備援解決所造成的可用性問題，可能會影響到維護成本 (服務性)。

瞭解各服務品質間的關聯方式及需要做何取捨，是能否設計出可同時滿足業務需求和業務限制之部署架構的關鍵所在。

Java ES 服務品質元件

數個 Java ES 元件的主要作用是增強系統服務元件或分散式應用程式元件提供的服務品質。這些軟體元件通常會與硬體元件 (如負載平衡器與防火牆) 搭配使用。

服務品質元件中介紹的 Java ES 服務品質元件歸納如下：

可用性元件。為部署的解決方案提供近乎不間斷的正常執行時間。
存取元件。提供對系統服務的安全網際網路存取，通常也提供路由功能。
監視元件。提供關於 Java ES 元件的即時資訊。

下表從架構觀點來列出最重要的 Java ES 服務品質元件，並列出這些元件影響最鉅的系統品質。

表 2–3 服務品質元件及所影響的系統品質


元件	影響的系統品質
高可用性階段作業儲存區	可用性
Monitoring Console	服務性
Portal Server Secure Remote Access	安全性延展性
Sun Cluster	可用性延展性
Sun Cluster Geographic Edition	可用性延展性
Web Proxy Server	安全性效能延展性

Sun Cluster 軟體

Sun Cluster 軟體為 Java ES 元件與延展性 Java ES 基礎架構支援的應用程式提供高可用性服務。叢集是一組鬆耦合的電腦，它統一提供對各種服務、系統資源與資料的單一用戶端檢視。叢集在內部使用備援電腦、互連、資料儲存區與網路介面，為以叢集為基礎的服務與資料提供高可用性。

Sun Cluster 軟體會持續地監視成員節點及其他叢集資源的運作狀態。發生故障時，Sun Cluster 軟體會為所監視的資源啟動容錯移轉，並使用內部備援實作對這些資源的近乎不間斷的存取。

Sun Cluster 資料服務套裝軟體 (有時稱為 Sun Cluster 代理程式) 可供所有 Java ES 系統服務元件使用。您也可以為自訂開發應用程式元件撰寫代理程式。

由於 Sun Cluster 軟體提供了控制能力，因此也能夠提供可延展服務。藉由運用叢集的全域檔案系統及叢集中的多重節點執行基礎架構或應用程式服務的能力，這些服務中增加的需求可以在多個同步運作的服務實例間達成平衡。經正確配置後，Sun Cluster 軟體便可為分散式企業應用程式提供高可用性與延展性。

由於支援 Sun Cluster 環境對備援的需要，在解決方案中包括 Sun Cluster 會大大增加實體環境中所需的電腦及網路連結數目。

與其他 Java ES 元件提供的服務不同的是，Sun Cluster 可用性服務是分散的對等式服務。因此，必須在叢集中的每部電腦上安裝 Sun Cluster 軟體。

Sun Cluster 軟體延伸由 Sun Cluster Geographic Edition 所提供，可防止應用程式發生意外中斷，所採用的方式是使用多個相互分隔的叢集，以及能夠在這些叢集之間複製資料的基礎架構。

備註 –

僅 Solaris^TM 作業系統 (Solaris OS) 可支援 Sun Cluster 和 Sun Cluster Geographic Edition。

三個架構要素之組合

在同時檢視時，三個架構要素提供了設計分散式軟體解決方案的結構架構，這些要素如圖 2–1 所示且在前述章節中有相關討論。三個要素 (基礎架構服務相依性、邏輯層與服務品質) 會特別強調 Java ES 元件在解決方案架構中扮演的角色。

每個要素均代表獨立的架構觀點。每種解決方案架構均需要將所有這些要素列為考量因素。例如，解決方案架構的每個邏輯層中的分散式元件 (第二個要素) 都需要獲得適當基礎架構元件 (第一個要素) 與適當服務品質元件 (第三個要素) 的支援。

同樣地，解決方案架構的任一元件在不同的架構要素中，也都扮演著不同的角色。例如，Directory Server 可以同時做為資料層 (第二個要素) 的後端元件以及持續性服務 (第一個要素) 的提供者。因為 Directory Server 以這二要素為中心，所以對此 Java ES 元件而言服務品質問題 (第三要素) 最重要。Directory Server 故障會對業務系統造成極大影響，所以此元件的高可用性設計便格外重要。由於 Directory Server 用於儲存敏感性的使用者或配置資訊，所以此元件的安全性設計也十分重要。

與 Java ES 元件相關的三個要素的互動會影響解決方案邏輯架構與解決方案部署架構的設計。

以 Java ES 結構架構中的結構架構為基礎的詳細設計方法不在本書所探討的範圍之列。不過，三要素結構架構特別強調部署以 Java Enterprise System 為基礎的軟體解決方案時需要重點瞭解的各設計層面。

Java ES 解決方案架構範例

Java ES 支援各種軟體解決方案。許多解決方案使用 Java ES 中包含的元件即可進行即開即用式設計和部署，而不必進行任何開發作業。其他的解決方案，開發作業量可能非常大，需要您開發自訂 J2EE 元件，以提供新的業務與表示服務。您可以將這些自訂元件封裝為符合 SOAP 介面標準的 Web 服務。許多解決方案都包含這兩種方法的組合。

本節提供一個範例，該範例從上一節的架構概念出發說明 Java ES 如何支援即開即用解決方案。

企業通訊方案

企業一般都會支援員工之間的通訊服務，特別是電子郵件及行事曆服務。某些企業發現讓員工以個人化的方式存取內部網站以及以整個企業層級認證及授權服務為基礎的其他網站，可以帶來許多益處。此外，這些企業希望可以在所有的企業服務中追蹤員工身份，因此可以使用單次 Web 登入功能來存取所有這類服務。

下表概述了這些特定的業務需求，僅代表一組業務需求範例。

表 2–4 業務需求摘要：通訊方案


業務需求	描述	需要的服務
單次登入	使用單次登入功能存取以單一識別為基礎的安全企業資源及服務，以便存取 Web 資源。	身份識別服務
訊息傳送行事曆	員工之間以及與外部世界的電子郵件傳送電子形式的員工行事曆及會議安排	通訊服務和協作服務
入口網站存取	單一、基於 Web 的、個人化的存取指的就是電子郵件、行事曆和內部網頁這類的通訊服務	入口網站服務

此外，企業對於提供上述服務的軟體系統，都有著效能、可用性、網路安全性及延展性的要求。

範例方案的邏輯架構

下圖顯示用以提供表 2–4 中所列、使用 Java ES 元件和 Sun Java Communications Suite 元件 (Messaging Server、Calendar Server、Instant Messaging 等) 的入口網站、通訊及身份識別服務的邏輯架構。由於 Messaging Server 的獨立邏輯配置會個別提供獨立的服務，因此架構會將他們視為個別的元件。

圖 2–6 企業通訊方案的邏輯架構

會將元件放置在水平要素 (代表標準邏輯層) 以及垂直要素 (代表基礎架構服務層級) 中。元件間的互動主要取決於下列項目：彼此做為分散式基礎架構服務的功能 (基礎架構服務層級之間的互動)，或是分層應用程式架構中的角色 (邏輯層中及各邏輯層之間的互動)。

在此架構中，Access Manager (存取儲存於 Directory Server 中的使用者資訊) 是 Portal Server 及表示層中其他網路型元件單次登入認證和授權的仲裁程序。Messaging Server 元件包含資料層中的訊息儲存區 (Messaging Server-STR) (傳送與擷取業務服務層中的元件)、HTTP 存取元件及表示層中的 Communications Express。

邏輯架構也會顯示各個元件之間的基礎架構服務相依性。例如，Portal Server 依賴 Communications Express 的訊息傳送與行事曆通道，還依賴 Access Manager 的認證與授權服務。這些元件都依賴 Directory Server 以取得使用者資訊及配置資料。多個元件都需要 Web Server 所提供的 Web 容器服務。

如需關於 Java ES 解決方案邏輯設計的更多資訊，請參閱「Sun Java Enterprise System Deployment Planning Guide」。

範例方案的部署架構

從邏輯架構移至部署架構時，服務品質需求會變得相當重要。例如，可能會使用受保護的子網路及防火牆為後端資料建立安全的屏障。若要達成多個元件的可用性及延展性需求，可以在多部電腦上部署這些元件並使用負載平衡器，來分散重複元件彼此間的請求。

但是，如果要求更高的可用性需求以及包含大量的磁碟儲存區，則其他的可用性解決方案會比較適合。例如，可以將 Sun Cluster 用於 Messaging Server 儲存區，而將多重主要複製用於 Directory Server。

如需關於 Java ES 解決方案部署設計的更多資訊，請參閱「Sun Java Enterprise System Deployment Planning Guide」。

本章的重要術語

本節說明本章中使用的重要技術術語，重點是闡明這些術語在 Java ES 環境中使用的方式。

應用程式元件: 一種執行某種特定運算功能的自訂開發軟體元件，將業務服務提供給一般使用者或其他應用程式元件。應用程式元件通常符合分散式元件模型 (像是 CORBA 與 J2EE 平台)。可以將這些元件 (以單一或組合方式) 封裝為 Web 服務。
架構: 一種顯示分散式應用程式 (或某些其他軟體系統) 的邏輯與實體建構區塊及它們彼此間關係的設計。就分散式企業應用程式而言，架構設計一般既包含應用程式的邏輯架構，又包含其部署架構。
業務服務: 代表多個用戶端執行業務邏輯 (並因此成為多重執行緒程序) 的應用程式元件或元件組合。業務服務也可以是做為 Web 服務封裝的分散式元件的組合，或者是獨立的伺服器。
用戶端: 請求軟體服務的軟體。用戶端可以是請求其他服務的服務，或是一般使用者存取的 GUI 元件。
部署架構: 一種描述邏輯架構與實體運算環境的對映的高階設計。實體環境包括企業內部網路或網際網路環境中的電腦、它們之間的網路連結，以及支援軟體所需的其他實體裝置。
邏輯架構: 一種描述分散式應用程式的邏輯建構區塊及這些建構區塊間關係 (或介面) 的設計。邏輯架構既包含分散式應用程式元件，又包含支援這些元件所需的基礎架構服務元件。
伺服器: 一種多重執行緒軟體程序 (區別於硬體伺服器)，提供分散式服務或一組結合式服務給經由外部介面存取該服務的用戶端。
Web 服務: 在可存取性、服務封裝和探索方面符合標準網際網路協定的服務。這些標準包括 SOAP 訊息傳送協定、WSDL (Web 服務描述語言) 介面定義和 UDDI (通用描述、探索及整合) 登錄標準。