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 虛擬機器 (JVMTM 機器) 所需的資源。
-
網路傳輸。為在不同電腦上執行的分散式應用程式元件間的通訊提供基本網路支援。這些服務包括對 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 系統服務元件間的關係
第 2 要素：邏輯層
您可以這樣設想，分散式企業應用程式的互動軟體元件位於多個邏輯層中。這些層表示軟體元件的邏輯與實體獨立性 (以它們提供的服務的特性為依據)。
圖 2–4 第 2 要素：分散式企業應用程式的邏輯層
在大部份的情況下，邏輯層架構代表圖 1–1 中的分散式企業應用程式層。基礎架構服務層級中討論的 Java ES 系統服務元件提供對圖 2–4 中顯示的所有邏輯層內應用程式元件的支援。雖然邏輯層概念大部份適用於自訂企業應用程式，但也適用於由 Sun Java Communications Suite 元件和某些入口網站服務所提供的協作服務。
邏輯層描述
本節簡述了圖 2–4 中所示的四個邏輯層。這些描述所參考的是使用 J2EE 平台元件模型實作的應用程式元件。但事實上，其他分散式元件模型 (如 CORBA) 同樣支援此架構。
-
用戶端層。用戶端層由一般使用者可透過使用者介面直接存取的應用程式邏輯構成。用戶端層中的邏輯可以包括基於瀏覽器的用戶端、在桌上型電腦上執行的 Java 元件或在掌上型裝置上執行的 JavaTM 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 基礎架構服務元件為分散式軟體解決方案提供了基本的基礎架構支援。部份解決方案包含了 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 |
服務性 |
|
安全性 延展性 |
|
|
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 所提供，可防止應用程式發生意外中斷，所採用的方式是使用多個相互分隔的叢集，以及能夠在這些叢集之間複製資料的基礎架構。
備註 –
僅 SolarisTM 作業系統 (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 為基礎的軟體解決方案時需要重點瞭解的各設計層面。
- © 2010, Oracle Corporation and/or its affiliates