因特網的三層基礎結構 (轉)[@more@]

因特網的三層基礎結構

在進入到千家萬戶以前，最終只能享用來自本地的內容單一、乏味的資料。今天，隨著URL在全球的普及，我們可以享用來自巴黎乃至皮奧里亞的的資料，而且就像讀取我們身邊伺服器的資料一樣簡單。 :namespace prefix = o ns = "urn:schemas--com::office" />

終端使用者一直期望著能享用更多種類的資料，但在因特網面世之前，卻沒有什麼可行的辦法達到這一目的。因特網的蓬勃發展為終端使用者提供了理想的資料分佈方法，並奠定了在全球範圍內資料的基礎。但儘管在基礎結構方面取得了這些改進，IT企業仍然不願意把他們的資料庫向大眾開放。

看來，我們還需要再耐心地等待幾年，才能看到IT企業以其認為有益的方式與大眾共享其資料庫。總部設在新墨西哥州阿爾伯克基市的整合商系統開發公司( CSD )負責銷售和市場營銷的副總裁Tom Herring說："使用大型機的企業多年來一直在尋求一種方法，以便能為終端使用者提供訪問資料庫的圖形化客戶機 ，但困難實在太大。"首先是問題，其次是建立這種系統的可行性究竟有多高的問題 。

瀏覽器/ 伺服器/資料庫的結構為上述IT企業所關心的問題提供瞭解決方案。嵌入在客戶機和伺服器之間，位於企業之前的Web伺服器能出色地防止者獲取企業的保密資料 。但更為重要的是，利用Web伺服器建立基於資料庫的應用變得相當的非常簡單。預裝在終端使用者臺式中的瀏覽器使開發人員不再需要為應用程式編寫複雜的圖形使用者介面了。如果這個應用程式非常受歡迎，IT 企業只需簡單地擴大其規模，並把工作量分佈在多個Web 伺服器上即可。此外，因為瀏覽器可自動使用者所需要的任何圖形使用者介面以及全球資訊網主頁，所以，資訊科技企業也不再需要參與分發了。

基於Web的資料庫應用程式即為三層應用程式的典型例子，它有一個顯示層、一個邏輯層和一個資料層。從全球資訊網上分佈的成千上萬的三層應用程式就能看出，這種三層在因特網開發方面已經非常普及。實際上，三層模式在整個業非常流行，其優點正得到越來越多的人的認可。用專家的話說，這種三層模式作為軟體開發的主流體系結構將很快成功地取代二層模式。

 

 

為什麼不採用二層模式？

 

Apptivity 應用伺服器製造商、總部設在馬薩褚塞州貝德福德市的Progress軟體公司副總裁Dennis Moore建議，如果您想得到一層、二層和三層模式體系結構的最恰當的比喻，那麼就可以看一看食品的生產過程。在一層模式中，您自己採集食品。在二層模式中，您直接從當地農場購買食品。而在三層模式中，您從超級市場購買食品，而超級市場從多家農場採購食品。

初看起來，從荷蘭運來蕃茄比直接從當地農場購買更低，成本更高，而且還不如自己種。但我們都清楚事實恰恰與此相反。大型專業化農場可以更高的效率生產食品，從而能夠彌補運輸、貯存和分銷的附加成本。消費者把食品的生產委託給若干專業化農場後，最終不但能節省開支，還能獲得品種更多的食品，並確保在不發生全球性災害的前提下總能有充足的食品供應。如果大型企業教會我們新的方式，那麼這就是規模經濟的價值。

Progress公司的Moore先生認為，客戶機/伺服器的領域也是類似的道理。雖然二層客戶機/伺服器模式在基於PC的一層應用程式基礎上更進了一步，但是。計算機系統開發公司的Herring先生說："客戶機/伺服器做出了很多承諾，但技術上卻達不到。"

客戶機/伺服器向終端使用者做出的承諾之一就是，使用者可廣泛地訪問資料。在客戶機/伺服器出現之前，對駐留在全球各地眾多資料庫中的龐大的資料來說，終端使用者只具備有限的。而儲存這些資料的大型機的嚴密程度甚至超過了諾克斯堡。對那些為數極少的，能夠訪問資料倉儲的應用程式---通常是3270終端上的應用程式---它們實在太笨重和乏味，足以使終端使用者放棄整個想法。

與終端使用者缺乏經驗的情形一樣，我們也不能保證肯定能與資料進行互動，並根據資料進行交易。資料是一種神聖的東西，只有那些精通相應工具的專家才會擺弄。

當然，客戶機/伺服器面臨的問題是，對每個希望使用應用程式的使用者來說，您都得去他們的計算機上軟體。從很多方面看，這種模式非常麻煩。首先，在每臺計算機上逐個安裝軟體非常耗費時間，更不要說成本了。其次，在個人計算機的世界裡，每臺計算機都不相同，要進行維護就更麻煩了。例如，基於的應用開發工具製造商、紐約州紐約市Jyacc公司旗下Prolific公司總裁Frank Vafier建議說："有時，您需要安裝的DDL (動態連結庫)會與其它程式的DLL發生衝突。"

第三，Herring先生認為，因為在二層模式下，顯示和邏輯被封閉在一個層內，客戶機就會非常大，或者至少比較大，因而會消耗本機儲存空間和系統資源。

換句話說，Vafier先生說："除非您需要大量使用應用程式，否則就根本不值得安裝這些東西。對偶爾使用的使用者來說，應用程式根本沒用。" Vafier先生舉例說明了向大眾市場推出的二層客戶機/伺服器應用程式在早期曾經經歷過的失敗，並專門談到最初的家庭銀行應用程式和Federal Express Corp. (聯邦快遞公司)開發的軟體包跟蹤程式（不是基於Web的）。

第三層

 

近來，我們普遍認為出現各種線上資料庫應用程式是很自然的事情 ---但是這些應用程式，不論其目的和用途為何，在幾年前甚至不可能出現。不論我們是制訂自己的旅行計劃，還是線上訂購圖書或光碟，乃至查閱僱員的401K記錄，用Vafier先生的話說，這種在"源頭進行交易"的能力是任何新的應用程式都必須具備的功能。

除了極少的幾個例外情況外，使這些應用程式成為可能的是在客戶機與資料庫之間增加的一個層---即Progress公司的Moore先生所謂的"中間層"，他說："中間層對計算的作用是把會話、通訊負載和工作本身打包，分成可以管理的塊，這樣就能進行有效的處理。"

中間層(又稱邏輯層、應用 伺服器或資訊)可很多功能。這些功能中有一些曾經是由客戶機或資料庫執行的，但中間層所提供的很多功能都是全新的。

Sun Microsystems公司北美Java中心總經理Stu Stern說，在基於Web的資料庫應用程式領域，中間層所執行的最基本任務可能就是提供安全性。中間層駐留在企業內防火牆以外，並以全球資訊網伺服器的形式構成客戶機與資料庫堡壘之間的可靠門戶。

在純粹的三層系統中，中間層的任務是提供應用程式邏輯---程式的核心部分。Stern先生認為，把應用程式邏輯放置在客戶機層或資料層會產生很大麻煩，因為"前端和後端系統常隨需求的變化而有較大的變動。"如果把應用程式邏輯構築在起協調作用的中間層內，就能確保不論前端或後端如何變化，編碼的大部分都能保持不變。

最後，企業還依靠中間層確保應用程式能被終端使用者所獲得。在大型系統中，這就會涉及在伺服器之間保持負載平衡、管理客戶機的連線以及代理在客戶機和資料庫之間來回傳輸的資訊等功能。Prolific公司的Vafier先生認為，對Web應用尤為重要的是：能夠將應用程式邏輯分佈在多臺伺服器上，從而提高其計算處理能力。他說："如果二層客戶機/伺服器應用程式是成功的，那麼希望使用它的使用者的數量會比您預想的多得多。如果是基於Web的應用，這個數量可能是100倍或1000倍。"

為什麼現在才採用三層體系結構？為什麼不早些採用呢？ 如果每個人都認為三層體系結構更好，那麼為什麼直到現在它才出現呢？

實際上，三層體系結構的想法並不新鮮。正在使用IBM公司的Customer Information Control System ( CICS ---客戶資訊控制系統)和BEA系統公司的Tuxeda事務處理(TP)監視器等的Progress公司的Moore先生說："三層結構早就是可能的。"實際上，如果您好好尋找的話，您就會在很多地方看到生產過程採用了三層應用程式。

航空公司的訂票系統一直是三層應用程式的典型例子。Moore先生說："您聽說過航空公司的檢票員寫字非常糟糕，一生都在打字這個嗎？"實際情況是，一臺小型電腦執行一個專門設計的客戶程式，客戶機又與其它地方非常專門的應用伺服器對話，而這個伺服器可能是IBM公司的CICS或其它上的TP監視器，這些伺服器又與後臺的資料來源對話。這種應用程式肯定具備三層系統的特點：客戶機、應用伺服器和資料庫都分別安裝在不同的系統元件上。

但是，建立和維護三層應用程式曾經是令所有人頭疼的難題，只有最頑強或背水一戰的開發小組才會對它持之以恆。計算機系統開發公司的Herring先生說："我們以前都是安排最好的程式設計師開發這些專案。但他們都說非常難。"如果不是現在在每臺電腦上都安裝了全球資訊網瀏覽器，開發商可能現在還在琢磨在終端使用者的計算機上建立和安裝客戶機程式呢。目前，只有公司的PowerBuilder等少數開發工具可以用來建立這類應用程式。而且，為了獲得多數資料庫應用程式所要求的交易功能---可靠的傳送、兩階段提交等等---您就必須僱傭精通中介軟體的開發人員。

Sun公司的Stern先生說："從邏輯上和物理上劃分這三個層肯定是好想法。但我也很清楚，在短期內，您的工作量肯定更大。"因此，絕大多數客戶機/伺服器開發商都跳過開發中間層這一步，而把工作重心放在直接在GUI客戶機上建立應用 邏輯這方面。

所以，三層應用程式的開發僅僅被那些真正需要它的系統採用了，如自動櫃員機(ATM)銀行應用程式和上面提到的航空公司訂票系統等。一般說來，考慮採用三層模式進行開發的應用程式具有以下特點：它們要求能可靠地傳送資訊，必須能支援大量的潛在客戶---即它們均要求具備良好的可擴充套件性和。

但開發商應用三層模式的主要原因可能並非因為這是構造應用程式的正確方法，而是因為在很多情況下它比二層模式的開發更容易。因此，三層模式應該感謝可下載的瘦客戶機。Progress公司的Moore先生說："三層模式的簡單程度堪與一層模式媲美。"

Java也對三層體系結構的普及有重大貢獻。開發商無不認為，Java是建立聯網的應用程式的最佳語言。

Moore先生說："從設計上看，Java是一種簡單的網路計算體系結構，"它對三層系統的成功面世起到了至關重要的作用---下載瘦客戶機的能力、內建的網路安全性以及這種語言的其它卓越功能---如，從一臺計算機向另一臺計算機功能在Java中就很容易。

現在採用三層體系結構後會有什麼益處？

現在，三層體系結構已經被開發商公認為應用程式開發中最有效的模式，但如果要使三層結構成為真正可用的系統，還需要在哪些方面做出改進呢？

Sun公司的Stern先生認為，首先，中間層還必須經過完善，而不僅僅是能支援全球資訊網和客戶機。Stern先生說："客戶機裝置比比皆是，"他暗示的是下一代掌上型電腦、電話、電視、尋呼機等等。

中介軟體製造商已經開始著手新增對不同元件體系結構的支援。總部設在弗吉尼亞州雷斯頓市的ICL公司負責請求代理(ORB)產品的市場營銷經理Ian Hunter說："目前有三大主流技術。"這些技術包括：Microsoft公司的元件物件模型(COM)和分散式COM，CORBA和ORB解決方案(見" OTM稱雄" )和Java。Hunter先生說："企業為中介軟體市場開發的任何解決方案都必須包括這三種技術。"

在這方面，ICL公司的DAIS系列中最近又新增了兩種新產品：COM2CORBA ---一種可將Windows應用程式連結到基於CORBA的企業應用程式的開發軟體，和J2 --- Java版本的DAIS ORB 。其他中介軟體製造商也不甘落後。例如，馬薩褚塞州紹斯伯勒市以PRC（程式呼叫)產品著稱的Nobl公司最近宣佈推出可在至少4種中介軟體環境：COM、CORBA、Java和RPC上支援可互動操作性的一種應用程式開發工具：Nouveau。

向n層以上發展

 

所以，如果計算機系統已經成功地從一層模式發展到二層，直到現在的三層結構，那麼還會怎樣發展呢？

Progress公司的Moore先生認為："從邏輯角度看，計算機體系結構的下一個發展階段應該是所謂的全分散式計算這樣的概念。在這樣的模式中，實際上既不存在客戶機，也不存在伺服器---任何部分都可以作為客戶機，也可以作為伺服器。"但Moore先生又指出，在全分散式計算模式下，也就失去了三層結構中大受歡迎的專門化的好處。對全分散式應用程式進行管理也將非常困難。Moore先生說："三層模式是仍可管理的最成熟的應用體系結構。"

這並不是說就不存在改進的餘地了。ActiveWeb應用整合系統製造商、加里福尼亞州聖克拉拉市Active軟體公司的技術總監Rafael Bracho對未來的展望是，我們將採用n層體系結構，而非二層或三層結構。這種模式要求在建立中間層時有更大的靈活性，同時還要保持三層模式的顯示層、邏輯層和資料層。

例如，Bracho先生描述了一種新的客戶跟蹤應用程式。Bracho先生說："有關您的客戶的資訊可能散佈在整個企業，並被不同的應用程式處理著。如果您想建立您需要的應用程式，那麼中間層內的應用程式彼此之間必須能夠對話。"