有三種最共通的型樣如下:
精簡型 Web 用戶端 - 最常用於網際網路型應用程式,最不容易控制用戶端的配置。用戶端只需要標準的 Web 瀏覽器(可呈現表單)。所有商業邏輯都在伺服器上執行。
重型 Web 用戶端 - 在架構上,大量商業邏輯都在用戶端機器上執行。用戶端通常利用動態 HTML、Java Applet 或 ActiveX 控制項來執行商業邏輯。與伺服器之間的通訊仍然透過 HTTP 來執行。
Web 交付 - 除了使用 HTTP 通訊協定進行用戶端和伺服器的通訊之外,也可能採用其他通訊協定(例如 IIOP 和 DCOM)來支援分散式物件系統。Web 瀏覽器主要扮演分散式物件系統的遞送和儲存裝置的角色。
上述清單不能算是完整,尤其在幾乎每年都發生技術革新的行業中,更不僅止於此。就整體而言,他們能代表 Web 應用程式最共通的架構型樣。不論任何型樣,單一架構採用多種型樣不足為奇。
「精簡型 Web 用戶端」架構型樣適用於網際網路型應用程式,但只能保證最小的用戶端配置。在滿足用戶端瀏覽器提出的網頁要求時,所有商業邏輯都在伺服器上執行。
此型樣最適用於網際網路型 Web 應用程式,或用戶端運算能力很低或無法控制配置的環境。
大多數電子商務網際網路應用程式皆採用此型樣,如果只因為客戶的用戶端能力不強就排除任何客戶群,這樣並不符合商業概念。一般的電子商務應用程式會竭盡所能將觸角伸向最大的客戶群;畢盡,Commodore Amiga 使用者的鈔票和 Windows
NT 使用者的鈔票一樣好。
「精簡型 Web 用戶端」架構型樣的主要元件存在伺服器上。在許多方面,此架構代表最小的 Web 應用程式架構。主要元件如下:
用戶端瀏覽器 - 任何可呈現表單的標準 HTML 瀏覽器。瀏覽器扮演一般的使用者介面裝置。運用在「精簡型 Web 用戶端」架構時,唯一提供的另一項服務是能夠接受和傳回
Cookie。應用程式使用者利用瀏覽器來要求網頁:HTML 或伺服器。傳回的網頁包含完整格式化的使用者介面 - 文字和輸入控制項 - 由瀏覽器呈現在用戶端畫面上。使用者和系統之間的所有互動皆透過瀏覽器完成。
Web 伺服器 - 所有用戶端瀏覽器的主要存取點。在「精簡型 Web 用戶端」架構中,用戶端瀏覽器只透過 Web 伺服器來存取系統,Web 伺服器可接受網頁要求 - 靜態 HTML
或伺服器網頁。視要求而定,Web 伺服器可能起始伺服器端的一些處理流程。如果網頁要求的對象是伺服器 Script 化網頁、CGI、ISAPI 或 NSAPI 模組,Web 伺服器將委派給適當的 Script
直譯器或執行檔模組來處理。無論何種情況,傳回的結果一定是 HTML 格式化網頁,適合由 HTML 瀏覽器來呈現。
HTTP 連線 - 用戶端瀏覽器和 Web
伺服器之間最常使用的通訊協定。此架構元素代表用戶端和伺服器之間的一種非連線性通訊類型。用戶端或伺服器之間每次彼此傳送資訊時,兩者之間就會建立一個全新和獨立的連線。HTTP 連線的另一種形式是透過 Secure
Sockets Layer (SSL) 的安全 HTTP 連線。這種連線會採用公開/私密加密金鑰技術,將用戶端和伺服器之間傳輸的資訊加密。
HTML 網頁 - 含有不經過任何伺服器端處理的使用者介面及內容資訊的網頁。這些網頁通常包含敘述文字,例如指示或說明資訊,或 HTML 輸入表單。當 Web 伺服器收到 HTML
網頁的要求時,伺服器只是擷取並傳送檔案,不會往回過濾發出要求的用戶端。
伺服器網頁 - 經過某些伺服器端處理的網頁。這些網頁通常在伺服器上實作為 Script 化網頁(Active Server Pages、Java Server Pages、Cold Fusion
網頁),且由應用程式伺服器或執行檔模組(ISAPI 或 NASAPI)上的過濾程式來處理。這些網頁可能存取所有伺服器端資源,包括商業邏輯元件、資料庫、舊版系統及商務會計系統。
應用程式伺服器 - 執行伺服器端商業邏輯的主要引擎。應用程式伺服器負責執行伺服器網頁上的程式碼、可以放在與 Web 伺服器相同的機器上,且甚至可以在與 Web
伺服器相同的處理空間內執行。在邏輯上,應用程式伺服器是一個獨立的架構元素,因為只關切商業邏輯的執行,且可以使用完全不同於 Web 伺服器的技術。
下圖顯示「精簡型 Web 用戶端」架構的邏輯觀點圖解。
精簡型 Web 用戶端最小架構
「精簡型 Web 用戶端」最小架構欠缺一些在 Web 應用程式中常見的選用元件;最常見的就是資料庫。大多數 Web 應用程式會使用資料庫來永久保存商業資料。有時,資料庫也可能用來儲存網頁本身(但這種資料庫用途代表不同的架構型樣)。由於
Web 應用程式可能運用許多技術來保存商業資料,所以此架構元件有一個更通用的術語:「持續性」。「持續性」元件也可能採用「交易處理監視器 (TPM)」。
由伺服器網頁中的 Script 將存取途徑導向「持續性」元件,可謂資料庫連接至系統最簡單的方法。實際上,直接存取會利用標準的資料存取程式庫來代勞,例如 RDO、ADO、ODBC、JDBC、DBLib
等。在此情況下,伺服器網頁必須瞭解資料庫綱目。以關聯式資料庫系統而言,必須建構和執行必要的 SQL 陳述式,才能存取資料庫中的資料。在小型和不複雜的 Web
應用程式中,這已足以應付一切。不過,在較大型和更健全的系統中,建議使用完整的商業物件層。
商業物件元件封裝商業邏輯。此元件通常經過編譯並在應用程式伺服器上執行。商業物件架構元件有一項優點,即其他 Web 或用戶端伺服器系統可利用相同的元件來呼叫相同的商業邏輯。例如,網際網路型店面可能採用伺服器網頁和「精簡型 Web
用戶端」架構型樣,以處理所有消費者活動,但帳務部門可能需要更精確地存取資料和商業邏輯,且適合採用主從架構系統,而非 Web 系統。帳務部門的系統可以使用與 Web
前端相同的應用程式伺服器上的相同商業元件,但仍然使用自己較複雜的用戶端軟體。
因為關聯式資料庫是各行業最常用的資料庫類型,應用程式伺服器和資料庫之間通常還會存在一個架構元件。在物件和關聯式資料庫之間,此元件提供對映服務。此對映層本身有許多實作方式。此元件的相關細節已超出本頁討論範圍。
此架構型樣常見的其他選項包括舊版系統的整合及電子商務應用程式;商務會計系統。兩者皆透過商業物件來存取(或缺少正式商業物件元件的系統所使用的應用程式伺服器)。舊版系統可能包括會計系統或製造排程系統。商務會計系統可讓網際網路 Web
應用程式接受和處理信用卡付款。對於想要進入線上交易市場的小型企業,有許多商務會計系統可供選擇。在大型企業中,此元件很可能是現有系統的一個介面,該系統有能力處理信用卡要求。
有了這些選用元件,「精簡型 Web 用戶端」架構型樣的邏輯觀點將更完整。下圖顯示邏輯觀點。
精簡型 Web 用戶端邏輯觀點
在非 Web 應用程式上也可能發現有許多 Web 應用程式的伺服器元件。Web 應用程式後端的設計和架構,幾乎就像是任何大型電腦或主從式架構系統的設計一樣。Web 應用程式採用資料庫和交易處理監視器 (TPM)
的理由,就像其他系統一樣。Enterprise Java Beans (EJB) 和 Microsoft 的 Transaction Server (MTS) 是隨著 Web 應用程式一起出現的新工具和技術,但同樣適用於其他應用程式架構。
Web 應用程式伺服器端元件的架構和設計,與任何主從架構系統完全一樣。由於此架構型樣著重於 Web 和 Web 應用程式專用的元件,對於後端伺服器架構的詳細評論已超出這個型樣的範圍。
此架構型樣的主要動態基礎表示只有在回應用戶端提出的網頁要求時,才會執行商業邏輯。用戶端會透過 HTTP 通訊協定向 Web 伺服器要求網頁,以這種方式來使用系統。如果所要求的網頁是 Web 伺服器檔案系統上的 HTML
檔案,則直接提取該檔案,然後傳回給發出要求的用戶端。
如果網頁是 Script 化網頁,亦即網頁包含可解譯的程式碼(必須經過處理才能傳回給用戶端),則 Web 伺服器會將這項動作委派給應用程式伺服器。應用程式伺服器會解譯網頁中的
Script,且可能接受指示與伺服器端資源互動,例如資料庫、電子郵件服務、舊版系統等。Script 化程式碼可存取(經由應用程式和 Web
伺服器)網頁要求夾帶的特殊資訊。這項資訊包括使用者輸入的表單欄位值,以及附加至網頁要求的參數。最後產生的結果是一個經過適當格式化的 HTML 網頁,適合傳回給用戶端。
網頁也可能是執行檔模組,例如 ISAPI 或 NSAPI DLL。DLL 或動態鏈結程式庫是一種經過編譯的程式庫,可由應用程式伺服器在執行時期載入和執行。此模組可存取網頁要求的相關細節(表單欄位值和參數),與 Script
化網頁的細節一樣。
此型樣的動態行為重點是只有在處理網頁要求時才會呼叫商業邏輯。達成網頁要求之後,結果將傳回給發出要求的用戶端,同時終止用戶端和伺服器之間的連線。達成要求之後,商業流程有可能繼續存在,但這不是正常現象。
這種架構最適用於可在使用者接受的回應時間內完成伺服器回應的應用程式(以及在用戶端瀏覽器允許的逾時值以內)。這通常是在幾秒鐘之內。如果應用程式必須可讓使用者啟動並監視持續很久的商業流程,則這可能不是最適當的架構型樣。不過,可以利用「推送技術」,讓用戶端監視長時間執行的流程。推送技術通常只是運用伺服器的定期輪詢機制。
此架構型樣的另一項主要的結果是複雜使用者介面的功能有限。由於瀏覽器扮演整個使用者介面交付機制,所有使用者介面小組件和控制項皆必須透過瀏覽器提供。在常見的瀏覽器及 HTML
規格中,這些只是少數的文字輸入欄位和按鈕。另一方面,如此嚴格限制的使用者介面究竟是否有利,可能尚有爭議。簡單扼要的使用者介面規格也可避免開發團隊浪費時間研究又「酷」又「帥」的介面,只要很簡單的介面就夠了。
「重型 Web 用戶端」架構型樣透過用戶端 Scripting 和自訂的物件,例如 ActiveX 控制項和 Java Applet,將「精簡型 Web 用戶端」型樣進一步擴充。「重型 Web
用戶端」型樣的名稱源自於用戶端可實際執行系統的一些商業邏輯,因此,不單純只是一般性使用者介面儲存區而已。
最適合採用「重型 Web 用戶端」架構型樣的 Web 應用程式包括可預先假設特定的用戶端配置和瀏覽器版本、預期有複雜的使用者介面,及/或可在用戶端執行一定數量的商業邏輯。「精簡型 Web 用戶端」和「重型 Web
用戶端」型樣的差異,主要是瀏覽器在執行系統商業邏輯時扮演的角色有所不同。
使用者介面功能強大和用戶端可執行商業邏輯,兩者是採用「重型 Web 用戶端」的兩個主要動機。複雜的使用者介面可用來檢視和修改三維模型,或製作財務圖表。有時,ActiveX
控制項可用於對用戶端監視設備進行通訊。例如,醫療機構可能利用可測量血壓、血糖指數及其他生命徵象的醫療器材,每天在遠端監控病患,然後決定將探病次數縮減為每週兩次。
商業邏輯有時只在用戶端執行。在這種情況下,執行流程所需的全部資料應該都在用戶端上。邏輯可能只是驗證輸入的資料而已。或檢查日期的正確性,或比對其他日誌(例如,生日應該早於第一次獲准進入醫院的日期)。依據系統的商業規則,有些欄位可能會根據目前輸入的值而啟用或停用。
用戶端 Script、Applet、控制項及外掛程式最常以強化使用者介面的形式運用在網際網路上。Java Script 通常用於改變 HTML 網頁上的按鈕或功能表項目的顏色或影像。Java Applet 和 ActiveX
控制項通常用來建立複雜的階層式樹狀檢視畫面控制項。
Shockwave ActiveX 控制項和外掛程式是今日網際網路上最常用的使用者介面元件。不但可呈現互動式動畫,主要是為網站添加生動的圖形,此外也用來顯示模擬和掌握體育活動。
有許多網站採用 Microsoft 的 Agent 控制項,在輔助使用者導覽網站的瀏覽器中接受語音指令和執行動作。
姑且不論網際網路,有一家醫療軟體公司已開發一套 Web 化企業內部網路應用程式來管理病患記錄和收費。Web 化使用者介面使用大量用戶端 Scripting 來執行資料驗證,並協助使用者導覽網站。除了 Script,應用程式也利用幾個
ActiveX 控制項來管理 XML 內容,XML 內容為資訊的主要編碼架構。
用戶端和伺服器之間的所有通訊,例如在「精簡型 Web 用戶端」型樣中,皆透過 HTTP 完成。由於 HTTP 是一種「無連線」的通訊協定類型,用戶端和伺服器之間通常不會有開啟的連線。只有在傳送網頁要求時,用戶端才會傳送資訊。這表示用戶端
Scripting、ActiveX 控制項及 Java Applet 僅限與用戶端的物件互動。
「重型 Web 用戶端」型樣會利用特定的瀏覽器功能在用戶端執行商業邏輯,例如 ActiveX 控制項或 Java Applet。ActiveX 控制項是經過編譯的二進位可執行程式,可透過 HTTP 下載到用戶端,再由瀏覽器來呼叫。由於
ActiveX 控制項實質上為 COM 物件,因此可完全支配用戶端資源。也可與瀏覽器及用戶端系統本身進行互動。因此,ActiveX 控制項(尤其是在網際網路上)通常交由第三方信任機構來「鑑別」。
最新版的一般 HTML 瀏覽器也已接受用戶端 Scripting。HTML 網頁可內嵌以 Java Script 或 VB Script 撰寫的 Script。此 Scripting
功能可讓瀏覽器本身執行(更正確地說是解譯)可能在系統商業邏輯中的程式碼。使用「可能」這個字眼是因為用戶端 Script 通常只與外表的使用者介面有關,並非實際為商業邏輯的一部分。無論何者,HTML
網頁中可能內嵌必須依此表達的重大架構性元素(亦即 Script)。
因為「重型 Web 用戶端」型樣實際上只是「精簡型 Web 用戶端」型樣的延伸,大部分重大架構性元素都一樣。「重型 Web 用戶端」型樣額外增加的元素包括:
用戶端 Script - HTML 格式化網頁內嵌的 JavaScript 或 Microsoft® VirtualBasic® Script。瀏覽器會解譯
Script。W3C(網際網路標準機構)已定義瀏覽器提供給用戶端 Script 的 HTML 和「文件物件模型」介面。
XML 文件 - 以「伸延伸標記語言 (XML)」格式化的文件。XML 文件代表無使用者介面格式化的內容(資料)。
ActiveX 控制項 - 用戶端 Script 中可參照的 COM 物件,必要時可「下載」至用戶端。就像任何 COM
物件一樣,也具有用戶端資源的完整存取權。保護用戶端機器所採用的原則安全機制是透過鑑別和簽章來實施。當 ActiveX 控制項即將下載至用戶端時,網際網路瀏覽器可
預先配置為不接受或警告使用者。鑑別和簽章機制只是透過第三方信任機構來建立控制項作者的身分識別。
Java Applet - 在瀏覽器環境內執行的一個獨立且經過編譯的元件。基於安全理由,對用戶端資源的存取權限會受到限制。Java Applet
可做為複雜的使用者介面元素,以及應用在非使用者介面的用途,例如剖析 XML 文件,或用來封裝複雜的商業邏輯。
Java Bean - 實作一組特定介面的 Java 元件,透過這些介面,可輕鬆將此元件納入更大更複雜的系統中。Bean 這個術語反映出元件所具備的小規模特性和單一用途。一整杯的咖啡通常會用到多顆咖啡豆
(Bean)。ActiveX 就好比在 Microsoft 架構中的 Java Bean。
下圖顯示「重型 Web 用戶端」架構的「邏輯觀點」圖解。
重型 Web 用戶端架構型樣的邏輯觀點
「重型 Web 用戶端」型樣的主要動態包括「精簡型 Web 用戶端」型樣的主要動態,再加上在用戶端執行商業邏輯的能力。如同「精簡型 Web 用戶端」型樣,用戶端和伺服器之間的所有通訊皆於網頁要求期間完成。不過,一部分商業邏輯可能以
Script、控制項或 Applet 在用戶端執行。
網頁傳送至用戶端瀏覽器時,可能包含 Script、控制項及 Applet。這些可能只是加強使用者介面,或對商業邏輯做出貢獻。欄位驗證是最簡單的商業邏輯用途。用戶端 Script
可用來檢查輸入是否有效,不只是單一欄位而已,可涵蓋任何特定網頁的所有欄位。例如,可讓使用者配置自己的電腦系統的電子商務應用程式,可能利用 Script 來防止指定不相容的選項。
為了使用 Java Applet 和 ActiveX 控制項,必須在 HTML 網頁的內容中指定。這些控制項和 Applet 可以在網頁的任何 Script 之外獨立執行,或由網頁中的 Script 來啟動。HTML 網頁中的
Script 可回應瀏覽器傳送的特殊事件。這些事件可能指出瀏覽器已剛完成載入網頁,或使用者的滑鼠剛才橫越網頁的特定區域。
它們可以存取瀏覽器的「文件物件模型 (DOM)」介面。此介面是 W3C 標準,可讓 Script、控制項及 Applet 存取瀏覽器和網頁中的 HTML 內容。Microsoft 和 Netscape 在此模型上的實作成果是「動態
HTML (DHTML)」。DHTML 不只是 DOM 介面的實作而已,更是含有事件的 DHTML,這在本文撰寫時尚未納入 DOM Level 1 規格中。
「文件物件模型」的核心是一組專門處理 XML 文件的介面。XML 是一套靈活的語言,可讓設計師自己建立特殊用途的標籤。DOM 介面可讓用戶端 Script 存取 XML 文件。
在用戶端使用特殊元件,可以將 XML 當做在用戶端和伺服器之間交換資訊的標準機制。ActiveX 控制項或 Java Applet 可以放在用戶端,獨立地要求和傳送 XML 文件。例如,HTML 網頁中內嵌的 Java
Applet,可以從 Web 伺服器提出 XML 文件的 HTTP 要求。Web 伺服器會尋找並處理所要求的資訊,但不是傳回 HTML 文件,而是傳回 XML 格式化文件。尚在用戶端的 HTML 網頁中執行的 Applet 可以接受
XML 文件、剖析文件,並與瀏覽器現有的 HTML 文件互動,將內容顯示給使用者。整個過程都是在用戶端瀏覽器的單一 HTML 網頁內發生。
到目前為止,跨瀏覽器實作的可攜性為此型樣最大的成果。並非所有 HTML 瀏覽器都支援 Java Script 或 VirtualBasic Script。此外,只有 Microsoft Windows 用戶端才能使用 ActiveX
控制項。即使只採用特定廠牌的用戶端瀏覽器,在「文件物件模型」實作上仍會有些微的差異。
使用用戶端 Scripting、控制項或 Applet
時,對於每一個打算支援的用戶端配置,測試團隊必須進行完整的測試情境。因為重要的商業邏輯在用戶端執行,所有涉及的瀏覽器必須保持一致和正確的行為。切勿假設所有瀏覽器都有相同的行為。不僅相同的程式碼在不同的瀏覽器中可能有不同的行為,即使在不同作業系統上執行的
相同瀏覽器,也可能呈現不一致的行為。
「Web 交付」架構型樣的名稱源自於將傳統的分散式物件主從式架構系統改成以 Web 為主要交付機制。就一種見解看來,這種應用程式實際上是分散式物件主從式應用程式,且剛好以 Web
伺服器和用戶端瀏覽器為重要的架構元素。不論這種系統是否為具有分散式物件的 Web 應用程式,或具有 Web
元素的分散式物件系統,最終的系統都一樣。基於這兩種見解都是同一個系統,且分散式物件系統一向被視為需要小心建模的系統,更加彰顯出本文的重點,Web 應用程式也必須像其他任何軟體系統一樣地建模和設計。
在可充分掌握用戶端和網路配置的情況下,最適合採用「Web 交付」架構型樣。在無法或難以掌握用戶端配置的情況,或網路通訊不穩定的情況,此型樣很顯然就不適用於這種網際網路應用程式。
此架構的強大之處在於有能力運用 Web 應用程式內現有的商業物件。由於用戶端和伺服器之間可以建立直接和持續的通訊,當可克服前述兩種 Web 應用程式型樣的限制。用戶端將更有能力執行重要的商業邏輯。
此架構型樣不太可能單獨使用。實際上,此型樣會結合前述一或兩種型樣。對於不需要複雜使用者介面的系統部分,或在用戶端配置不足以支援大型用戶端應用程式的情況下,一般的系統會採用前述一或兩個架構型樣。
CNN 互動式網站是網路上最忙碌的其中一個新聞站台。大部分公開操作方式是透過慣用的瀏覽器和簡單的 HTML 3.2 來完成,不過,網站的背後是由瀏覽器、伺服器及分散式物件形成的一個複雜的 CORBA
網路。已發佈的「分散式運算」是此系統的一項個案研討。
有一家醫療軟體公司已建立 Web 應用程式來管理病患、病歷及收費。系統的收費部分只由整個使用者群組的極少數人使用。大多數舊式收費系統是以 FoxPro 撰寫。新的 Web 型系統採納舊式 FoxPro
舊版程式碼,且透過一些轉換公用程式,為使用者介面和商業邏輯建置 ActiveX 文件。 產生的系統是一個處理病患和病歷的「重型 Web 用戶端」Web 應用程式,同時與執行收費作業的「Web 交付」Web 應用程式整合。
「Web 交付」和其他 Web 應用程式架構型樣的最大差異在於用戶端和伺服器的通訊方法。在其他型樣中,主要的機制是 HTTP,這是一種無連線通訊協定,在涉及使用者和伺服器的互動活動時,設計師的能力會嚴重受到牽制。「Web
交付」型樣的重要架構性元素包括「精簡型 Web 用戶端」型樣的所有元素,另外再加上這些元素:
DCOM - 分散式 COM 是 Microsoft 的分散式物件通訊協定。允許一台機器的物件與另一台機器的物件互動並呼叫方法。
IIOP -「網際網路交互 ORB 通訊協定」是 OMG 的 CORBA 通訊協定,可以與網際網路上的物件產生互動(或任何 TCP/IP 網路)。
RMI (JRMP) -「遠端方法呼叫」是 Java 與其他機器上的物件產生互動的方法。JRMP(Java 遠端方法通訊協定)是 RMI 原生的通訊協定,但不是唯一可用的通訊協定。RMI 可透過 CORBA
的 IIOP 來實作。
下圖顯示「Web 交付架構」型樣的「邏輯觀點」圖解。
Web 交付架構型樣的邏輯觀點
「Web 交付」架構型樣的主要動態是利用瀏覽器來交付分散式物件系統。瀏覽器用來包含使用者介面和商業物件,這些物件在瀏覽器之外獨自與伺服器層的物件通訊。用戶端和伺服器物件之間的通訊是透過 IIOP、RMI 及 DCOM 通訊協定來執行。
在這種分散式物件主從架構系統中,使用 Web 瀏覽器的主要優點在於伺服器有一些內建的功能,可以從伺服器自動下載所需的元件。網路上新出現的電腦只需要相容的 Web
瀏覽器,立即可使用應用程式。用戶端不必手動安裝特殊軟體,因為瀏覽器會為使用者代勞。元件是以配合需要的方式來交付和安裝在用戶端。Java Applet 和 ActiveX
控制項會自動傳送至用戶端放入快取。當這些元件啟動時(在載入適當的網頁之後),即可參與伺服器物件的非同步通訊。
到目前為止,跨瀏覽器實作的可攜性為此型樣最大的成果。使用此型樣需要穩定的網路。用戶端和伺服器物件之間的連線比 HTTP 連線存留更久,因此,偶爾遺失伺服器(其他兩種架構不會有這種問題)會對此型樣造成嚴重的問題。
|