Sun Java Enterprise System 2005Q4 技術摘要

第 2 章 Java Enterprise System 解決方案架構

本章簡介做為 Java Enterprise System (Java ES) 解決方案基礎的架構概念。本章說明如何使用 Java ES 元件 (系統服務元件和服務品質元件) 來支援分散式企業解決方案。

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

本章先介紹 Java ES 解決方案架構設計的結構架構，然後提供基於該結構架構的範例解決方案架構。

本章涵蓋以下主題：

Java Enterprise System 結構架構

Java ES 元件支援分散式企業強度軟體解決方案的部署。

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

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

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

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

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

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

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

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

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

基礎架構服務層級

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

圖 2–2 說明解決方案架構的基礎架構服務相依性這一要素。此圖中顯示的層級是圖 1–1 中基礎架構服務層的展開檢視。

圖 2–2 中的服務階層及它們之間的相依性構成了解決方案邏輯架構的重要一要素。這些基礎架構服務提供了瞭解 Java ES 系統服務元件 (請參閱系統服務元件) 作用的概念基礎。

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

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

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

下列段落描述了不同的基礎架構服務層級，並參照與 Java 程式設計語言輔件相關的各種服務。依從最低至最高的順序 (如圖 2–2 中所示) 描述這些服務層級：

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

圖 2–2 中顯示的服務層級反映各種基礎架構服務 (從最低層級的作業系統服務到最高層級的應用程式與整合服務) 彼此間的普遍相依關係。一般來說，每項服務都依賴於其下方的服務，而為其上方的服務提供支援。

不過，圖 2–2 沒有表示各基礎架構服務的嚴格分層。較高層級的服務可直接與較低層級的服務進行互動，而不需要仰賴中間層級。例如，某些執行階段服務可直接仰賴平台服務，而不需要其間有任何服務層級。此外，也可將其他服務層級如監視或管理服務納入到此概念性圖示中。

Java Enterprise System 基礎架構服務元件

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

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

備註 –

圖 2–3 中顯示的作業系統平台不是 Java Enterprise System 的正式部分，不過，包含它們的目的是顯示支援 Java ES 元件的作業系統平台。

Java Enterprise System 基礎架構服務相依性

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

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

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


元件	依賴	支援
Portal Server	Application Server 或 Web Server Access Manager Directory Server 如果配置為使用對應的通道：Calendar Server Messaging Server Instant Messaging
Messaging Server	Directory Server Access Manager (用於單次登入)	Calendar Server (用於電子郵件通知) Portal Server (用於訊息傳送通道)
Instant Messaging	Directory Server Access Manager (用於單次登入)	Portal Server (用於即時訊息傳送通道)
Calendar Server	Directory Server Messaging Server (用於電子郵件通知服務) Access Manager (用於單次登入)	Portal Server (用於行事曆通道)
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 Calendar Server Messaging Server Instant Messaging Access Manager
Service Registry	無	Applcation Server 式元件

第 2 要素：邏輯層

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

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

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

邏輯層架構基本上代表了圖 1–1 中分散式企業應用程式層。基礎架構服務層級中討論的 Java ES 系統服務元件提供對圖 2–4 中顯示的所有邏輯層內應用程式元件的支援。不過，邏輯層概念也適用於提供應用程式層級服務的系統服務元件，像是 Messaging Server 與 Calendar Server。

邏輯層說明

本節提供對圖 2–4 中顯示的四個邏輯層的簡短說明。這些說明所涉及的是使用 Java 2 Platform Enterprise Edition (J2EE^TM 平台) 元件模型實作的應用程式元件。但事實上，其他分散式元件模型 (如 CORBA) 同樣支援此架構。

用戶端層。用戶端層由一般使用者透過使用者介面直接存取的應用程式邏輯構成。用戶端層中的邏輯可以包括基於瀏覽器的用戶端、在桌面電腦上執行的 Java 元件或在手持裝置上執行的 Java 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 基礎架構服務元件為分散式軟體解決方案提供基礎的基礎架構支援。不過，這些解決方案中的一部分包括由 Java ES 元件直接提供的應用程式層級服務。這些解決方案使用邏輯層設計方法。

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

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

備註 –

圖 2–5 並非顯示完整的邏輯架構，其為簡化圖例，其中省略了若干 Java ES 元件。連接各元件的線代表彼此的互動。

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

第 3 要素：服務品質

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

解決方案架構的服務品質這一要素強調 Java ES 服務品質元件所發揮的作用。

服務品質

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

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

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


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

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

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

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

Java Enterprise System 服務品質元件

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

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

可用性元件。這些元件為部署的解決方案提供了近乎不間斷的正常執行時間。
存取元件。這些元件提供對系統服務的安全網際網路存取，通常也提供路由功能。
管理元件。這些元件為系統元件提供了增強的服務性。

下表顯示從架構觀點來看最重要的 Java ES 服務品質元件及受它們影響最大的系統品質。

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


元件	影響的系統品質
Communications Express	安全性延展性
Directory Proxy Server	安全性延展性
High Availability Session Store	可用性
Portal Server Secure Remote Access	安全性延展性
Sun Cluster	可用性延展性
Web Proxy Server	安全性效能服務性

Sun Cluster 軟體

Sun Cluster 軟體為 Java ES 元件與延展性 Java ES 基礎架構支援的應用程式提供高可用性服務。

叢集是一組鬆耦合的電腦 (叢集節點)，它們的共同作用讓使用者可透過單一用戶端檢視服務、系統資源及資料。叢集在內部使用備援電腦、互連、資料儲存區與網路介面，為以叢集為基礎的服務與資料提供高可用性。

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

下圖顯示的是支援 Messaging Server 與 Calendar Server 的資料儲存區服務的雙節點叢集。

圖 2–6 使用 Sun Cluster 節點的可用性設計

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

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

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

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

三個架構要素之組合

如果將圖 2–1 所示及以上各節中討論的架構三要素做為一個整體加以檢視，它們提供了用於設計分散式軟體解決方案的架構。這三要素 (基礎架構服務相依性、邏輯層及服務品質) 強調 Java ES 元件在解決方案架構中發揮的作用。

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

同樣地，解決方案架構的任一元件在不同的架構要素中，也都扮演著不同的角色。例如，Directory Server 可以既做為資料層 (第 2 要素) 中的後端元件，又做為持續性服務 (第 1 要素) 的提供者。

因為 Directory Server 以這二要素為中心，所以對此 Java ES 元件而言服務品質問題 (第 3 要素) 最重要。Directory Server 故障會對業務系統造成極大影響，因此此元件的高可用性設計非常重要；而且由於 Directory Server 的用途是儲存敏感的使用者或配置資訊，因此此元件的安全性設計也十分重要。

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

根據Java Enterprise System 結構架構所表示的結構架構概述詳細的設計方法超出了本書的範圍。不過，三要素結構架構強調了在部署基於 Java Enterprise System 的軟體解決方案時需要瞭解的重要設計層面。

範例 Java Enterprise System 解決方案架構

Java Enterprise System 支援眾多類型的軟體解決方案。

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

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

企業通訊方案

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

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

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


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

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

範例方案的邏輯架構

下圖顯示的是使用 Java ES 元件提供表 2–4 中所列入口網站、通訊及識別服務的邏輯架構。由於每個 Messaging Server 邏輯上獨立的配置均提供不同的服務，因此架構會將它們視為不同的元件。

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

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

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

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

如需關於 Java ES 解決方案邏輯設計的更多資訊，請參閱「Sun Java Enterprise System 2005Q4 部署規劃指南」。

範例方案的部署架構

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

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

如需關於 Java ES 解決方案部署設計的更多資訊，請參閱「Sun Java Enterprise System 2005Q4 部署規劃指南」。

本章的重要術語

本節說明本章中使用的重要技術術語，重點是理清這些術語間的關係及它們在 Java Enterprise System 環境中是如何使用的。

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