Intranet、Internet服務器具有相同的名稱,運行原理與操作系統相似并與WWW服務器一
起共享網上的文本圖片瀏覽,但相似的方面僅此這些。實際上,公用和專用Web服務器是完全
不同的。
如果你正在Internet上建立網址,你想要一個能夠跟蹤訪問者并記錄他們所做所為的Wb
服務器。因為諸如人們如何到達網址以及逗留多長時間的信息對于銷售和教育工作而言至關
重要。但是,對于為職員建立的Intranet網址上,這一信息是毫無意義的。在Intranet中具備
強有力的記錄和跟蹤能力的Web服務器可能是多余的。
Intranet到底應該提供哪些性能?建立易于存取的內部保護設計,定制的簡單易修改的服
務器配置,Intranet套件工具,容錯設計,簡易的安裝和管理以及簡單的數據庫訪問,這些都是
Intranet所需要的。
當然,你會發現,很難買到一臺具有以上所有性能的Web服務器。接下來我們列舉一些原
則,這些原則將幫助你整理與Intranet有關的購買決策并確定每種類型的最佳產品。

安全性
Intranet服務器常常要求在機構內建立復雜的信任關系。要做到這一點,最佳捷徑是建
立授權:告訴系統你的姓名和密碼字,系統將允許你訪問服務器的所選區域。
但在Intranet上,事情并不這么簡單。訪問特權必須依照你的姓名、地址、工作部門、
標題和你的監督對象等多項指標。所以在安全性方面,Intranet服務器必須靈活。
如果公司的Web分布在多服務器和部門,這情況更是如此。Web服務器本來就是孤獨的—
—他們極少(如果曾經有過的話)在沒有大量應用級編程的情況下相互之間共享安全和授權。
即使在單一的Web服務器里,授權信息通常分布性較差。正規Web服務器安全樣機(model)要求
每個訪問區域都有一個授權文件。授權文件列有用戶名和密碼字,服務器配置文件可將用戶
與許可訪問區域連接。
這意味著用戶必須使用多用戶名稱和密碼字,才能到達不同的Intranet區域并且不能輕
易地使這些不同訪問方式同步。
這一規則的例外就是Microsoft公司的Internet信息服務器(IIS),它將Windows NT安全
性——用戶名稱、密碼字和最重要的訪問控制表性能——擴展至Web。用戶利用自已的Wino
wsNT用戶名和密碼字向IIS服務器證明自己的身份。然后IIS用這一信息限制用戶查看Winow
sNT保護模式樣機上的內容。
同時,公用Web服務器的一些授權和安全性能在Intranet上用途不大。傳統上,公用服務
,如在線銀行業的高級安全性依賴于加密通信和應用級安全的混合,如帳戶號或用戶名及相關
的密碼字便是如此。
在Intranet上,這通常是用不上的。與真正的用戶級安全性相比,在Intranet上附加服務
器級授權要簡單得多。通過強調高級服務器授權來滿足這些需求,類似IIS等產品的設計師就
能擺脫重新實施應用級安全的負擔。

定制化和修改
為了在Web服務器上增加功能,廠商們已實施了公共網關接口(CGI)調用和專有API。但在
建立位于執行和管理信息系統前端的高級應用時,這些產品則不夠靈活、有力和迅速。
靈活性問題經常出現的一個領域是預處理文本。預處理器是有益的,因為它賦予了HTM作
者無需編寫真正的應用代碼即可建立動態Web頁面的能力。這將降低開發費用并簡化維護。
所有服務器都配有具備各種能力的預處理器,高定制化的、基于Web的應用性能是一級的預處
理器性能,它們絕大多數情況下都是強有力的。
而且,要解決這一問題就必須研究CGI(和API)腳本(Script)或修改預處理器。這兩種方
式的協調很重要。許多CGI/API腳本都將對Web服務器的性能產生較大影響。另一方面,如果
修改預處理器,廠商每次發布重要版本的服務器時都要翻新這些修改內容。
有時,特殊的應用要求按服務器運行的方式修改。其中一些可用CGI或API腳本修改,而另
一些可能要求人工修改基本服務器。
如果你選擇修改服務器,你就需要Apache,它是由Apache Group公司負責產品維護的免費
產品。如果不普及的話,Apache算不了什么:它控制著公用Web服務器的空間,為45萬多個域服
務。這比Microsoft公司、Netscape公司和O'Reilly&Associates公司的域總量還要多。
Apache有兩個優點:它有完整的資源代碼,它還可被修改。Apache Group公司在Apache服
務器上安裝了插入框架間信號服務器的修改工作。盡管修改服務器資源代碼聽起來很危險但
Apache利用其開發框架消除了大量危險和不確定因素。

Intranet套件工具
如果你以建立應用而不是使用預處理器為重點,那么你需要一臺配有好的Intranet專用
套件工具的服務器。
編程Web應用不比編程任何其他應用簡單——只有編程圖形用戶接口(GUI)簡單一些,或
者看上去簡單一些。事實上,建立Intranet應用可能要比建立分布式系統、群件、電子郵件
和移向綜合Web的數據倉庫項目困難。
Intranet必須能提供大型主機提供的性能并且不能利用單一的區域或安全的本地文件系
統。
開發商們需要用一個Intranet專用成套工具幫助建立這些應用。
一個簡單的例子就是面向事務處理的應用,如保險費賠償程序。
由于Web是無狀態的,維護Intranet上在面向事務處理的應用屏面上的狀態信息就比維護
標準客戶/服務器系統狀態信息困難。每個屏面都是一個獨立的事務處理;屏面和屏面之間沒
有信息流。與帶有自己的GUI的應用不同,Web應用不能依賴于一個與用戶相連的未中斷持續
鏈路。HTTP可提供幾種用于維護狀態信息的方法。最受爭議的是cookies,它可提供一種不安
全的方式,幫助服務器在客戶機上存儲狀態信息并在客戶機運行應用時檢索信息。cookies受
到的爭議頗多,因為它混淆匿名如何在Web上運行和利用cookies進行跟蹤的概念。
任何情況下,Intranet應用通常不存在公用Web應用遇到的保密問題。但還有一個安全問
題,即cookies的內容直接處于用戶的控制之下,服務器不能依靠cookies在事務處理過程中避
免被破壞。
另一種在多屏面上跟蹤單一客戶機的技術與靜態URL有關,每個URL都被修改過以便存儲
一些狀態信息。這保證能夠奏效——直到用戶用其中一個URL標注一頁面并試圖在事務處理
完成后很長時間才回到這一頁面。URL也會失效,用戶就不知道下一個頁面在哪。
Cookies和 靜態 URL都是有用的,但在建立超過一屏的、強壯的應用時,這些URL就不夠
用了。程序員必須考慮諸如事務處理恢復、與授權系統的集成和數據庫連接等問題時,情況
尤為如此。
不幸的是,Web服務器采用平面方式編程:程序庫就在那兒,去用吧。
對于許多Web開發商來說,網址建立始于一個問題:"什么樣的代碼我能當模型使用"。It
ranet程序員們從樣品應用得好的成套工具和相關的應用資源代碼上獲益。
這方面好的實例就是Netscape公司的企業服務器,它在其AppFoundry、StarNine技術公
司的WebStar等產品上有許多樣品,包括超過100個樣本應用。兩種服務器都可為Web開發商提
供遷移的牢固的基礎,以便開發商發展新的應用并修改現有的應用。

容錯
當企業將各種各樣的重要應用移向基于Web的前端時,以前悠閑自得的Web服務器管理員
在運行服務器時必須假想企業是依賴于那些服務器的。Intranet服務器的應答時間和正常運
行時間對于企業是成功的關鍵。
企業的成功關鍵應用要求在具有故障排除能力或負荷共享能力的容錯服務器上運行。所
有這些特性都與粗糙的Internet正相反。
Microsoft公司、Netscape公司和其他少數幾家Web廠商保證他們能為Intranet提供"大
企業"型軟件。但是,他們不能獲取那些IT管理員的信任,這些管理員通常認為,傳統的計算機
廠商, 如DEC公司、HP公司和IBM公司能為他們建立軟件。
這種情況下,選擇服務器不如選擇系統重要。Windows NT在像工作組操作系統一樣流行
時并不能提供老的操作系統幾年來具有的容錯和負荷分享特性。NT在其網絡應用和TCP/IP實
施方面受到批評。
因此,一些IT管理員指責說,建立起來的任務——重要 Intranet應用正成為他們古老的
固態備用件——Unix和DigitalOpen的VMS。(如果IBM的MVS操作系統能使用一個好的Web服務
器,他們就能在上面建立Intranet。)
當你需要堅如磐石般的可信性、故障排除能力和負荷共享時,能提供內部群聚技術的Oe
nVMS不失為一個好的Intranet平臺選擇。Netscape的商業服務器、Process Software公司的
Purveyor和俄亥俄州立大學(OSU)Web服務器都在OpenVMS上運行。OSU Web服務器在安裝的數
量上領先。
DEC公司的后備辦公室操作系統還有另外一個優點。Windows NT就遭受了幾次由幾個對
立的系統發起的拒絕服務攻擊;很受歡迎的Unix平臺受到了半打的已公開的堆疊-溢出(Stak
-Overflow)攻擊。鑒于所有這些,OpenVMS幾乎未受任何破壞,這簡直不可思議。
作為對內裝負荷共享和容錯的替代性能,諸如Cisco 公司、IBM和Rosonate等公司提供了
一些位于Web服務器場前端的產品,它們可在眾多Web服務器中指引查詢并將根據服務器可用
性和負荷量記錄標記。借助這些類型的產品,Windows NT服務器場能像OpenVMS一樣可靠——
盡管所需費用較高。

簡易的安裝和管理
大多數Web服務器都由Internet服務供應商維護,而群集服務、Intranet服務器則由部門
管理。許多Intranet不只由1臺或2臺大型服務器組成,而是由幾打或幾百個小服務器組成,每
個服務器都由工作組操作,工作組對自己的議程比對保持Web服務器的活力更感興趣。
在這種環境下,簡易的安裝、管理和協調是成功的關鍵因素。滿足這種需求的一個方法
就是挑選一個可由各種平臺支持的單一服務器。如果能夠建立"公司標準",那么幫助桌面系
統就能像支持離線處理器和電子數據表一樣支持Web。
幾乎沒有Web服務器能在多平臺上運行。明顯的例外是Netscape公司的系列產品,它們可
提供在OpenVMS、Unix和Windows NT間相對不變化的接口。Netscape還有第二個優點:在We服
務器中,它的通過Web瀏覽器運行的管理接口是最強有力和最靈活的。由于Netscape的服務是
通過HTTP管理的,Netscape服務器的遠程控制非常簡單。對于那些傾向于編輯配置文件的用
戶,Netscape還支持該接口并提供關于如何進行人工維護配置的文件。
第二個措施是管理最簡易和最簡單的服務器并將它們提供給用戶。令人吃驚的是,這一
措施的一個不可能的競爭者是Macintosh。作為計算平臺,Macintosh的傳奇性的易用特點令
人感興趣并對小型部門服務器——如果不是非正統的——做出選擇。
盡管還可以從服務器控制臺指導管理,但最受歡迎的Macintosh Web服務器、StarNine公
司的WebStar和Netscape一起建立了基于Web的管理接口。
O'Reilly還在WebSite Professional提供了有記錄良好的和極易于管理的Web服務器。
盡管Windows95及NT平臺沒有Macintosh附帶的不干涉管理和協調方式,但將工作組Web服務器
置于常用平臺之上的想法是可行的。
無論選擇哪種操作系統平臺或服務器,部門的服務器管理員需要關于協調和整理服務器
的建議。因為Web的設計者不想放棄以前的訪問記錄,那么采取消除并存檔舊記錄的措施對于
服務器的長期健康就很重要。盡管平臺能夠支持它,但采取自動化方式卷動過長記錄將會有
極大的幫助。

數據庫訪問
應用開發商正轉向用基于Web的技術和Intranet打破公司信息系統周圍的MIS僵局。這樣
,Intranet應用就經常需要對存儲在公司數據庫系統里的信息進行存檔、存儲、處理和報告
。數據庫訪問的簡易性對于建立強有力的Intranet應用是很關鍵的。找到一個將HTML和SQ混
合到Web頁面上的簡單方式至關重要。
目標是能讓Web頁面在被裝入后展示查詢精確度的結果。同樣,無需腳本即可將HTML形式
和SQL查詢集成在一起的性能可以讓Intranet開發商以較低的費用獲得額外的能力。
Web商業服務器三大廠商——Microsoft、 Netscapet、 O'Reilly——都在其服務器中
配置了工具,無需費力即可將后備與SQL數據庫連接。這些服務器都依賴于強壯的SQL接口。
不幸的是,一些免費服務器沒有此類接口,或不能與這些服務器共同運行。這種情況下,人們
更加關心中間件并設計了價格較高的產品將真實的數據擴展至Web瀏覽器。產品范圍從可用
的到出眾的均在市場上可尋,如Teubner&Associates的3270-HTML轉換器。

底線
幾乎沒有Intranet規模足夠小,使用足夠簡單,能夠在單一Web服務器,或者甚至是單
一Web結構上生存。每個Intranet應用都要求由一個或另一個服務器來實施。了解了Wb
服務器之間需求的區別將是特別重要的。