在信息產業高速發展的今天，
企業
間的競爭將更加激烈。隨着規模的不斷擴大和業務的不斷更新，企業迫切需求完整的分佈式解決方案，用於管理複雜的異構環境，實現不同硬件設備、軟件系統、網絡環境及數據庫系統之間的完整集成。
背景介紹
縱觀人類計算機的發展歷史，每隔十年至十五年，信息產業就會發生週期性的變革，1950年至1970年期間，企業主要採用大型主機－終端的體系結構，企業應用
系
統則採用單一、集中的方式爲用戶提供資源共享服務。80年代初期，開放系統與關係型數據庫管理系統被企業大量採用，有別於集中式系統，應用程序邏輯分散在
主從兩端。隨着Windows的普及，90年代則是圖形化的應用時代，Client/Server體系結構也被廣泛採用。90年代後期，信息產業出現了分
布式對象技術，應用程序可以分佈在不同的系統平臺上，通過分佈式技術實現異構平臺間對象的相互通信。將企業已有系統集成於分佈式系統，可以極大地提高企業
應用系統的擴展性。90年代末出現的多層
分佈式應用爲企業進一步簡化應用系統的開發指明瞭方向。
在傳統的Client/Server結構中，應用程序邏輯通常分佈在客戶端
和服務器
兩
端，客戶端發出數據資源訪問請求，服務器端將結果返回客戶端。Client/Server結構的缺陷是，當客戶端數目激增時，服務器的性能將會因爲無法進
行負載平衡而大大下降。而一旦應用的需求發生變化，客戶端和服務器端的應用程序則都需要修改，這樣給應用的維護和升級帶來了極大的不便，而且大量數據的傳
輸也增加了網絡的負載。爲了解決Client/Server存在的問題，企業只有向多層分佈式應用轉變。企業應用的多層架構如圖1所示。
在多層分佈式應用中，客戶端和服務器之間可以加入一層或多層應用服務程序，這種程序稱爲“應用服務器”(Application
Server)。開發人員可以將企業應用的商業邏輯放在中間層服務器上，而不是客戶端，從而將應用的業務邏輯與用戶界面隔離開，在保證客戶端功能的前提
下，爲用戶提供一個瘦的(thin)界面。這意味着如果需要修改應用程序代碼，則可以只在一處(中間層服務器上)修改，而不用修改成千上萬的客戶端應用程
序。 從而使開發人員可以專注於應用系統核心業務邏輯的分析、設計和開發，簡化了企業系統的開發、更新和升級工作，極大增強了企業應用的伸縮性和靈活性。
當企業需要建立基於Web的商業應用系統時，多層分佈式體系結構同樣提供了強大優勢，爲基於Web的商業應用提供了“瘦客戶”的體系結構，使基於瀏覽器的
客戶可以與Intranet資源進行有效交互，並且不需要在客戶端進行復雜的應用配置工作。多層分佈式解決方案在異構平臺間架起了橋樑，可以使基於Web
的商業應用與企業已有系統集成在一起。
目前，在我國的企業中，大量採用的還是Client/Server體系結構，而在西方發達國家，企業由傳統的應用系統向多層分佈式應用系統的轉變已經成爲業界主流。相信在我國，多層分佈式系統將得到更爲廣泛的應用。
多層分佈式應用帶來的挑戰
儘管多層分佈式體系結構爲企業提供了極大優勢，但比起傳統的Client/Server方式，開發多層分佈式應用具有更大的難度，給開發人員帶來了新的技術挑戰。主要包括了以下三個方面：
1.分佈式對象標準的多樣化
企業要構建多層分佈式系統，必須遵循分佈式的工業標準，基於什麼樣的標準直接影響到企業應用系統的開放性和可擴展性。目前分佈式對象的標準主要有三
種：Microsoft 的DCOM、Sun Microsystems的Enterprise JavaBeans/RMI以及OMG(Object
Management Group)組織的CORBA(Common Object Request Broker
Architecture)。DCOM是基於Windows環境的分佈式對象標準，因此支持的平臺種類有限。RMI與Enterprise
JavaBean是以Java語言爲主體的分佈式對象架構，適合大型企業的跨平臺需求，但現實的應用系統環境一般是由多種不同的程序語言建立起來的，只依
賴一種程序語言構建的企業應用是很少見的。CORBA是由800多個大型軟、硬件公司參與的OMG組織所制定的分佈式對象標準，獲得IBM、Sun
Microsystems、Oracle、Sybase、Novell、Netscape等大型公司的支持，CORBA標準實現了不同平臺之間對象的通信
及互操作，軟件供應商只要遵循應用對象與ORB間通信的IDL(Interface Definition
Language)，便能夠以對象的形式提供服務或獲得服務，ORB使開發人員完全不需要考慮異構平臺、不同的通信協議或不同程序語言造成的差異，而專注
於應用邏輯的開發。可見，CORBA提供了開放、靈活的分佈式標準，適於企業構建多層分佈式應用系統。
2.多層分佈式應用的開發是很複雜的
如果用傳統方式開發多層分佈式應用，則需要開發人員具有較深的計算機系統級知識，需要掌握諸如併發性、安全性、可伸縮性及事務處理等各個方面的知識。而且
需要實現對系統資源訪問的有效管理，如對線程、內存、數據庫連接、網絡連接的管理。而這些複雜工作極大地耗費了開發人員的精力，限制了開發工作的進展。而
企業應用系統的開發更多地要求開發人員專注於商業邏輯方面的開發，而不是在系統級開發上浪費更多時間。
3.分佈式應用的分發、管理也是一個挑戰
大多數的分佈式應用是由成百上千的組件組成的，而在分發時，每一個組件都有屬性需要進行配置。通常，對組件屬性的配置方式依賴於組件所在的平臺。
因此，應用被分發後，如何管理分散的組件將是一個挑戰。管理者需要確保應用的組件能夠正確運行、可以位於企業網內的任何機器上，並能及時發現處理錯誤(包
括系統錯誤、網絡中斷、應用錯誤等情況)。
傳統意義上的網絡系統管理(比如：SNMP)只能通過分析主機的狀態，獲得應用程序運行的情況，但對於分佈式應用系統來說，一個應用並非運行於某一臺主機，因此，管理者需要管理整個網絡的狀態，這就需要有恰當工具的支持。
多層分佈式應用的需求
開發企業多層分佈式應用，通常有以下方面的需求：
1.易於開發
雖然多層分佈式體系結構要求有較深的計算機系統級知識作爲基礎(比如：數據庫、事務處理、網絡安全、CORBA技術等)，但對於IT開發人員來說，要求在
不用深入瞭解系統底層複雜技術的情況下，能夠在一個友好的可視化集成開發環境(IDE)中，快速、容易地開發出功能強大的多層分佈式應用系統。
2.簡化分發、管理工作
開發人員要求能夠在一個集成開發環境中測試、修改分佈式應用程序，以提高應用的性能，並可以實現在同一環境中對應用的分發、管理。由於許多應用包括了成千
上萬分佈於企業各處的組件，因此，需要一個集中化的管理工具，用於管理、控制分佈式應用，並實現錯誤檢測、更正的功能。
3.企業應用的魯棒性要求
一個完善的企業分佈式多層應用，應該滿足事務處理、安全管理、容錯、負載平衡、可伸縮性、高性能方面的要求。
4.具有開放的、基於工業標準的體系結構
企業需要的是開放的、基於工業標準的解決方案，可以實現與其他符合標準的系統進行交互。
5.可以實現與各種數據庫及已有系統的集成
企業分佈式應用必須能夠訪問企業的數據資源，而企業數據通常存儲在當前流行的大型數據庫上(如：Oracle、Sybase等)，或通過TP
Monitor(如：IBM CICS、BEA Tuxedo)訪問，因此要求企業分佈式系統能夠與數據庫及已有系統集成在一起。
6.支持不同平臺環境
企業多層分佈式應用需要支持不同的平臺環境，服務器一端應該支持Windows NT或 UNIX平臺，而且不同平臺的客戶都可以訪問服務器上的應用，包括：HTML、Java applets 、Java 應用、Dynamic HTML、C++應用等。
企業應用服務器
基於上述原因，當企業向多層分佈式應用轉變時，需要應用服務器(Application
Server)的支持，從而可以將不同的應用技術集成在一起，使多層分佈式應用的開發、分發、管理變得更加容易。現在已經有很多企業使用了應用服務器技
術，也極大地增強了企業應用的性能。但在我國處於應用中的應用服務器技術，還不能完全滿足企業建立多層分佈式應用的需求，這些應用服務器主要分爲以下兩
類：
1.基於Web的應用服務器
基於Web的應用服務器一般提供了基於Web的Interner應用的開發環境，適於建立基於Web的Client/Server應用系統。在這種體系
下，Web應用服務器通常運行在Web
Server上，用來處理客戶請求。通常用ODBC和JDBC連接數據庫。這種類型的應用服務器一般易於使用，並且支持基於EJB(Enterprise
JavaBeans)的服務器應用程序開發。但這種應用服務器存在的缺陷有：不支持事務處理、安全性差、對已有交易系統支持有限、性能較低。基於Web的
應用服務器體系結構如圖2所示。
2.基於中間件的應用服務器
基於中間件的應用服務器通過與已有系統(如：TP
Monitors)進行集成，可以爲企業提供更強大的功能，包括：事務處理、安全管理、容錯、負載平衡等，但多數解決方案都是基於
Client/Server體系結構的，或僅限於三層體系結構，不適於建立分佈式的Web應用，而且沒有一個有效的開發管理環境。基於中間件應用服務器體
繫結構如圖3所示。
