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 中所示) 描述這些服務層級：
-
作業系統平台。為任何在電腦上執行的程序提供基本支援。作業系統 (像是 SolarisTM 作業系統、Linux 或 Microsoft Windows) 管理實體裝置以及記憶體、執行緒和其他支援 Java 虛擬機器 (JVMTM 機器) 所需的資源。
-
網路傳輸。為在不同電腦上執行的分散式應用程式元件間的通訊提供基本網路支援。這些服務包括對 TCP 和 HTTP 等協定的支援。其他較高層級的通訊協定 (請參閱訊息傳送層) 則要視這些基礎傳輸服務而定。
-
訊息傳送。提供對應用程式元件間同步和非同步通訊的支援。同步訊息傳送指訊息的即時傳送與接收，且包括 J2EE 元件間的遠端方法呼叫 (RMI) 及與 Web 服務的 SOAP 互動。而在非同步訊息傳送通訊中，訊息發送並不需要依賴客戶是否已準備好立即接收訊息才能進行。非同步訊息傳送規格 (如 Java Message Service (JMS) 和 ebXML) 支援擔保穩定性及其他訊息傳送語義。
-
執行階段。提供任何分散式元件模型 (像是 J2EE 或 CORBA 模型) 所需的支援。除緊耦合分散式元件所需的遠端方法呼叫外，執行階段服務還包括元件狀態 (生命週期) 管理、執行緒池管理、同步化 (互斥鎖定)、持續性服務、分散式作業事件監視及分散式例外處理。在 J2EE 環境中，這些執行階段服務由應用程式伺服器或 Web 伺服器中的 EJBTM、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 (J2EETM 平台) 元件模型實作的應用程式元件。但事實上，其他分散式元件模型 (如 CORBA) 同樣支援此架構。
-
用戶端層。用戶端層由一般使用者透過使用者介面直接存取的應用程式邏輯構成。用戶端層中的邏輯可以包括基於瀏覽器的用戶端、在桌面電腦上執行的 Java 元件或在手持裝置上執行的 Java 2 Platform Micro Edition (J2METM 平台) 行動用戶端。
-
表示層。表示層由應用程式邏輯構成，該邏輯的作用是準備資料以供傳送至用戶端層及處理來自用戶端層的請求以供傳送至後端業務邏輯。表示層中的邏輯通常由 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 服務品質元件及所影響的系統品質|
元件 |
影響的系統品質 |
|---|---|
|
延展性 |
|
|
High Availability Session Store | |
|
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 的軟體解決方案時需要瞭解的重要設計層面。
- © 2010, Oracle Corporation and/or its affiliates