在信息產業高速發展的今天，企業間的競爭將更加激烈。隨著規模的不斷擴大和業務的不斷更新，企業迫切需求完整的分布式解決方案，用于管理復雜的異構環境，實現不同硬件設備、軟件系統、網絡環境及數據庫系統之間的完整集成。
背景介紹
縱觀人類計算機的發展歷史，每隔十年至十五年，信息產業就會發生周期性的變革，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所示。