Sun Java Enterprise System 2005Q4 部署規劃指南

第 4 章 邏輯設計

在解決方案生命週期的邏輯設計階段期間,您會設計邏輯架構,顯示解決方案邏輯元件的相互關係。技術需求階段的邏輯架構和使用分析形成部署方案,它是部署設計階段的輸入資料。

本章包含以下各節:

關於邏輯架構

邏輯架構會識別實作解決方案需要的軟體元件,顯示元件之間的相互關係。技術需求階段期間判定的邏輯架構和服務品質需求會形成部署方案。部署方案是設計部署架構的基礎,會在下個階段 (亦即部署設計) 發生。

開發邏輯架構時,您不但要識別為使用者提供服務的元件,還要識別那些提供必要介體和平台服務的其他元件。基礎架構服務相依性和邏輯層提供兩種互補的方法來執行這個分析。

基礎架構服務相依性和邏輯層是作為 Sun JavaTM Enterprise System 基礎的解決方案架構三維中的兩個。下面列出了這三維,關於邏輯架構中也有對它們的說明。


備註 –

如需關於 Java Enterprise System 架構概念的更多資訊,請參閱「Sun Java Enterprise System 2005Q4 技術摘要」中的「Java Enterprise System 架構」一章。


邏輯架構藉由顯示必要的元件及其相依性,來描述基礎架構服務層級。邏輯架構也會將元件分配於邏輯層之間,這些邏輯層代表最終可由用戶端層存取的表示、業務和資料服務。服務品質需求並不是在邏輯架構中成形,而是與部署方案的邏輯架構相互搭配。

設計邏輯架構

設計邏輯架構時,請使用在技術需求階段確定的使用實例來判定提供解決方案必需的服務的 Java Enterprise System 元件。您也必須識別可為最初識別之元件提供服務的任何元件。

根據 Java Enterprise System 元件提供的服務類型將其放置在多層架構的環境中。瞭解元件是多層架構的一部份,可協助您稍後判定如何分配元件提供的服務,也可協助判定實作服務品質的策略 (例如延展性、可用性及其他)。

此外,您可以以其他觀點檢視邏輯元件,將元件放置在安全存取區域內。存取區域一節提供一個安全存取區域的範例。

Java Enterprise System 元件

Java Enterprise System 由互動軟體元件組成,這些元件提供可以用於建立企業解決方案的企業服務。下圖顯示隨附於 Java Enterprise System 的關鍵軟體元件。「Sun Java Enterprise System 2005Q4 技術摘要」提供關於 Java Enterprise System 元件和其所提供服務的額外資訊。

圖 4–1 Java Enterprise System 元件

顯示 Java Enterprise System 元件間關係的示意圖。

元件相依性

確定邏輯架構的 Java Enterprise System 元件時必須同時確定支援元件。例如,如果將 Messaging Server 確定為邏輯架構的必要元件,則邏輯架構也必須包括 Directory Server,也許還要包括 Access Manager。Messaging Server 在目錄服務上依賴 Directory Server,在要求單次登入的解決方案上依賴 Access Manager。

下表列出 Java Enterprise System 元件的相依性。請參閱元件相依性中關鍵元件間相依性的視覺表示。 設計邏輯架構時,請使用此表格及隨附的圖表來判定設計中的相依元件。

表 4–1 Java Enterprise System 元件相依性

Java Enterprise System 元件 

依賴 

Application Server

Message Queue 

Directory Server (可選擇) 

Calendar Server

Messaging Server (用於電子郵件通知服務) 

Access Manager (用於單次登入) 

Web Server (用於 Web 介面) 

Directory Server 

Communications Express

Access Manager (用於單次登入) 

Calendar Server 

Messaging Server 

Instant Messaging 

Web Server (用於 Web 介面) 

Directory Server 

Directory Proxy Server

Directory Server 

Directory Server

無 

Access Manager

Application Server 或 Web Server 

Directory Server 

Instant Messaging

Access Manager (用於單次登入) 

Directory Server 

Message Queue

Directory Server (可選擇) 

Messaging Server

Access Manager (用於單次登入) 

Web Server (用於 Web 介面) 

Directory Server 

Portal Server

如果配置為使用 Portal Server 通道: 

Calendar Server 

Messaging Server 

Instant Messaging 

Access Manager (用於單次登入) 

Application Server 或 Web Server 

Directory Server 

Portal Server Secure Remote Access

Portal Server 

Web Server

Access Manager (可選擇,用於存取控制) 


備註 –

元件相依性中列出的 Java Enterprise System 元件間的相依性並非全部的元件相依性。元件相依性並未列出在進行安裝規劃時必須考慮的相依性。如需完整的 Java Enterprise System 相依性清單,請參閱「Sun Java Enterprise System 2005Q4 安裝指南 (適用於 UNIX)」


圖 4–2 Java Enterprise System 元件相依性

本圖以視覺方式表現「表 4-1」中描述的相依性。

Web 容器支援

上一節元件相依性並未考慮執行 Portal Server 和 Access Manager 的 Web 容器。此 Web 容器可以由 Application Server、Web Server 或協力廠商產品提供。設計包含 Portal Server 或 Access Manager 的邏輯架構時,請確實考慮這些元件所需的 Web 容器。

Messaging Server 提供的邏輯上獨立的服務

可將 Java Enterprise System Messaging Server 配置為提供若干獨立的實例,並由這些實例提供以下邏輯上獨立的服務:

可將這些不同的 Messaging Server 配置提供的功能部署在不同的實體伺服器上,並可以在邏輯架構的不同層中加以表示。 由於這些 Messaging Server 配置代表不同層中邏輯上獨立的服務,因此在設計邏輯架構時請將這些配置視為邏輯上獨立的元件。範例邏輯架構一節提供一個邏輯上獨立元件的範例。

下表描述邏輯上獨立的 Messaging Server 配置。

表 4–2 Messaging Server 配置

子元件 

說明 

Message Transfer Agent (MTA)

可支援電子郵件的傳送,方法是透過處理 SMTP 連線、路由電子郵件以及將訊息傳遞到適當的訊息儲存區。可將 MTA 元件配置為支援從企業外部傳送的電子郵件 (內送),或是從企業內部傳送的電子郵件 (外傳)。 

Message Store (STR)

提供電子郵件的擷取和儲存。 

Message Multiplexor (MMP)

可支援電子郵件的擷取,方法是使用 IMAP 或 POP 協定,來存取電子郵件用戶端的訊息儲存區。 

Messenger Express Multiplexor (MEM)

支援透過代表以 Web 為基礎 (HTTP) 用戶端來存取訊息儲存區的方式擷取電子郵件。 

存取元件

Java Enterprise System 也包含提供系統服務存取的元件,這些服務通常來自企業防火牆外部。 Messaging Server 的某些配置也可以提供網路存取,像是針對訊息多重訊號組合器配置的 Messaging Server。下表描述提供系統服務遠端存取的 Java Enterprise System 元件。

表 4–3 提供遠端存取的 Java Enterprise System 元件

元件 

說明 

Directory Proxy Server

為多重 Directory Server 實例提供增強的目錄存取、模式相容性、路由和負載平衡。 

Portal Server、Portal Server Secure Remote Access

提供從公司防火牆外部對 Portal Server 內容與服務 (包括內部入口網站及網際網路應用程式) 的安全網際網路存取。 

Portal Server、Portal Server Mobile Access

提供從行動裝置對 Portal Server 的無線存取以及對其的語音存取。 

Messaging Server Message Multiplexor (MMP)

支援透過代表以 Web 為基礎 (HTTP) 用戶端來存取訊息儲存區的方式擷取電子郵件。 

提供遠端存取的元件通常部署在安全存取區域中,如存取區域一節的範例所示。

多層架構設計

Java Enterprise System 非常適合多層架構設計,在這種設計中,依據服務提供的功能將它們放置在各個層中。 每個服務都有獨立的邏輯,而且可供同一層或不同層的服務存取。下圖描述企業應用程式的多層架構,說明了用戶端、表示、業務服務和資料層。

圖 4–3 多層架構模型

下圖顯示多層架構中服務的關係。

下表描述多層架構設計中所描述的邏輯層。

表 4–4 多層架構中的邏輯層

層 

說明 

用戶端層

包含為一般使用者呈現資訊的用戶端應用程式。對 Java Enterprise System 而言,這些應用程式通常是郵件用戶端、Web 瀏覽器或行動存取用戶端。 

表示層

提供為一般使用者顯示資料的服務,可讓使用者處理和控制顯示方式。例如,Web 郵件用戶端或 Portal Server 元件允許使用者修改所接收資訊的表示方式。 

業務服務層

提供後端服務,這些服務通常在資料層接收資料,再將資料提供到表示層或業務服務層中的其他服務,或是直接將資料提供到用戶端層。例如,Access Manager 為其他 Java Enterprise System 元件提供識別服務。 

資料層

提供可由表示層或業務服務層內服務存取的資料庫服務。例如,Directory Server 提供 LDAP 目錄存取給其他服務。 

多層架構設計有數個優點。在部署設計階段期間,根據多層架構中的功能來放置服務,可協助您判定如何分散網路中的服務。您也可以瞭解架構中的元件如何存取其他元件的服務。這個視覺化的表示方法可協助您規劃可用性、延展性、安全性和其他服務品質解決方案。

範例邏輯架構

本節提供 Java Enterprise System 解決方案邏輯架構的某些範例。這些範例會顯示如何在多層架構的適當層中放置邏輯元件,然後再藉由研究使用實例來分析元件之間的關係。將本節的邏輯架構範例作為瞭解 Java Enterprise System 解決方案中邏輯架構設計的基礎。

第一個範例是一個基礎 Messaging Server 解決方案,它說明邏輯上獨立的 Messaging Server 元件如何與其他元件互動。第二個範例顯示基於身份識別部署的邏輯架構,可能適用於擁有 1000 至 5000 名員工的中型企業。

Messaging Server 範例

下圖顯示 Messaging Server 部署的基本邏輯架構。此邏輯架構只顯示 Messaging Server 必需的邏輯上獨立的元件。之後的圖例會說明這些元件彼此間的關係。


備註 –

Messaging Server 部署通常是包括其他 Java Enterprise System 元件的企業解決方案的一部份,如以識別為基礎的通訊範例中所示。


圖 4–4 Messaging Server 部署的邏輯架構

顯示多層架構中部署的 Messaging Server 方案的邏輯元件的示意圖。

下表描述Messaging Server 範例中所描述的元件。

表 4–5 Messaging Server 邏輯架構中的元件

元件 

說明 

電子郵件用戶端 

閱讀和傳送電子郵件的用戶端應用程式。 

Messaging Server MTA

將 Messaging Server 配置為訊息傳輸代理程式 (MTA) 以接收、路由、傳輸和傳送電子郵件。 

Messaging Server MMP

將 Messaging Server 配置為訊息多重訊號組合器 (MMP),把連線路由到相應的訊息儲存區以進行擷取和儲存。MMP 存取 Directory Server 來查詢目錄資訊以判定適當的訊息儲存區。 

Messaging Server STR

將 Messaging Server 配置為供擷取和儲存電子郵件的訊息儲存區。 

Directory Server

提供 LDAP 目錄資料的存取。 

邏輯架構不指定 Messaging Server 元件的服務複製。例如,企業部署通常會建立獨立的內送和外傳 MTA 實例,但Messaging Server 範例只顯示一個 MTA 元件。將邏輯元件複製到數個實例中,是您在部署設計階段期間所做的設計決定。

Messaging Server 使用實例

使用實例可協助您識別架構中邏輯元件彼此間的關係。根據使用實例對應元件之間的互動,透過這個動作,您可以看見元件互動的方式,這對部署設計相當有幫助。

一般而言,您會分析每個使用實例,以便在部署設計之前判定元件的互動。下列三個使用實例是典型的 Messaging Server 實例,它顯示了邏輯元件間的互動。

Procedure使用實例 1:使用者成功登入 Messaging Server

步驟
  1. 電子郵件用戶端傳送登入訊息至 Messaging Server Multiplexor (MMP)。

  2. MMP 請求 Directory Server 驗證使用者 ID 和密碼。

  3. Directory Server 將驗證傳回至 MMP。

  4. MMP 請求 Messaging Server Message Store (STR) 提供郵件清單。

  5. STR 請求 Directory Server 提供使用者的 LDAP 記錄。

  6. Directory Server 將使用者的 LDAP 記錄傳回給 STR。

  7. STR 將郵件清單傳回至 MMP。

  8. MMP 將郵件清單轉送到電子郵件用戶端。

    說明使用實例 1 Messaging Server 元件間資料流程的示意圖。

Procedure使用實例 2:已登入的使用者讀取及刪除郵件

步驟
  1. 電子郵件用戶端請求 Messaging Server Multiplexor (MMP) 提供要讀取的郵件。

  2. MMP 請求 Messaging Server Message Store (STR) 提供郵件。

  3. STR 將郵件傳回至 MMP。

  4. MMP 將郵件轉送到電子郵件用戶端。

  5. 電子郵件用戶端傳送「刪除郵件」動作到 MMP。

  6. MMP 轉送「刪除郵件」動作到 STR。

  7. STR 自資料庫中刪除郵件,並傳送確認到 MMP。

  8. MMP 將刪除確認轉送到電子郵件用戶端。

    說明使用實例 2 Messaging Server 元件間資料流程的示意圖。

Procedure使用實例 3:已登入的使用者傳送電子郵件

步驟
  1. 電子郵件用戶端將在用戶端撰寫的郵件傳送到 Messaging Server Message Transfer Agent (MTA)。

  2. MTA 請求 Directory Server 驗證使用者 ID 和密碼。

  3. Directory Server 將驗證傳回至 MTA。

  4. MTA 向 Directory Server 查驗每個收件者的目標網域。

  5. Directory Server 將每個收件者的目標網域傳回至 MTA。

  6. MTA 將郵件轉送給每個收件者。

  7. MTA 將郵件轉送至 Messaging Server Message Store (STR) 以將郵件儲存在寄件匣中。

  8. MTA 將確認傳送到電子郵件用戶端。

    說明使用實例 3 Messaging Server 元件間資料流程的示意圖。

以識別為基礎的通訊範例

此範例說明以識別為基礎的通訊解決方案,該方案適用於員工人數為 1 千至 5 千的中型企業。一般而言,設計邏輯架構需要徹底的業務分析,這個分析會在詳細的技術需求分析之後產生。不過,這只是理論性的範例,因此會假設已判定下列的業務需求。

此範例的使用實例會詳細說明登入程序、閱讀電子郵件、傳送電子郵件、個人化入口網站、同步化行事曆和其他類似的使用者活動。

下圖顯示此類以識別為基礎的通訊解決方案的邏輯架構。

顯示多層架構中部署的以識別為基礎的通訊方案之邏輯元件的示意圖。

身份識別型通訊範例的使用實例

對於具備此特性的部署解決方案而言,通常有許多個詳細的使用實例,描繪使用者與此解決方案提供之服務間的互動。此範例強調使用者從 Web 瀏覽器用戶端登入入口網站時,元件之間的互動。本範例會將登入方案分為兩個使用實例:

可將這兩個使用實例視為一個延伸的使用實例。不過,此範例分別討論這兩個使用實例以達到簡化的目的。

Procedure使用實例 1:使用者成功登入,入口網站擷取使用者的配置

步驟
  1. Web 瀏覽器用戶端傳送使用者 ID 與密碼至 Portal Server。

  2. Portal Server 請求 Access Manager 提供認證。

  3. Access Manager 請求 Directory Server 驗證使用者 ID 和密碼。

  4. Directory Server 驗證使用者 ID 和密碼。

  5. Access Manager 請求 Directory Server 提供使用者設定檔。

  6. Directory Server 傳回使用者設定檔。

  7. Portal Server 請求 Access Manager 提供使用者顯示設定檔。

  8. Access Manager 傳回入口網站配置。

  9. 入口網站配置顯示於 Web 瀏覽器用戶端。

    本圖描述使用實例 1 的身分識別型通訊方案元件之間的資料流程。

Procedure使用實例 2:Portal Server 顯示電子郵件和行事曆資訊

步驟
  1. 成功登入、認證及擷取入口網站配置後,Portal Server 請求 Messaging Server MMP 提供電子郵件。

  2. MMP 請求 Messaging Server STR 提供郵件清單。

  3. STR 將訊息清單傳回至 MMP。

  4. MMP 將郵件標題轉送至 Portal Server。

  5. Portal Server 請求 Communications Express 提供行事曆資訊。

  6. Communications Express 請求 Calendar Server 後端提供行事曆資訊。

  7. Calendar Server 後端將行事曆資訊傳回至 Communications Express。

  8. Communications Express 將行事曆資訊轉送至 Portal Server。

  9. Portal Server 將所有通道資訊傳送至 Web 瀏覽器用戶端。

    說明使用實例 2 以識別為基礎的通訊方案元件間資料流程的示意圖。

存取區域

另一種表示邏輯架構的元件的方法就是將這些元件放置在存取區域中,顯示架構如何提供安全的存取。下圖說明用於部署 Java Enterprise System 元件的存取區域。每個存取區域都會顯示元件如何在網際網路和企業內部網路之間提供安全的遠端存取。

圖 4–5 放置在存取區域中的邏輯元件

此圖顯示安全存取區域中如何放置 Java ES 元件。

下表描述存取區域中所描述的存取區域。

表 4–6 安全存取區域和其中所放置的元件

存取區域 

說明 

內部存取區域 (企業內部網路)

透過企業內部網路和網際網路之間的防火牆所強制執行的策略來存取網際網路。內部存取區域通常會被一般使用者用來進行 Web 瀏覽和傳送電子郵件。 

在某些情況下,也會允許直接存取網際網路以進行 Web 瀏覽。不過,網際網路之間的安全存取都是透過外部存取區域而提供的。 

外部存取區域 (DMZ)

提供網際網路之間的安全存取,作為關鍵後端服務的安全性緩衝。 

安全存取區域 (後端)

提供關鍵後端服務的限制存取,只能從外部的存取區域進行存取。 

存取區域不對前面範例中描述的邏輯層進行說明,而是著重描述哪些元件提供遠端和內部存取、這些元件與安全性措施 (像是防火牆) 的關係及必須執行的存取規則的視覺描述。 將多層結構設計和可顯示存取區域的設計搭配使用,可提供您規劃部署的邏輯模型。

部署方案

僅有完整的邏輯架構設計並不足以開始進行解決方案生命週期的部署設計階段。您必須將邏輯架構與技術需求階段期間判定的服務品質 (QoS) 需求相互搭配。邏輯架構和 QoS 需求的搭配就會組成部署方案。部署方案是設計部署架構的起始點,如第 5 章, 部署設計中所述。