對于一個企業應用而言，
    1.從業務表現的角度是由不同的功能（或功能模塊，如客戶管理、產品管理、訂單管理等等）組合而成的
    2.從系統結構的角度則每個功能又分為頁面（用戶界面）、流程（界面流轉控制）、業務處理、數據等不同的層次
    3.從技術實現的角度這些層次最終能夠運轉起來滿足功能的要求又依賴于代碼、數據和運行環境等軟件基本要素。
    以下是一個企業應用典型的構成要素圖：

    實際上，一個企業應用系統的應用架構就是通過功能、層次、軟件要素這三個相互影響的維度有機結合形成的。沒有人懷疑架構對于企業應用的重要意義，某種意義上，架構可以說是系統的靈魂。良好的應用架構取決于對這三個維度的有效合理的切分和組合。

    傳統的J2EE應用項目，由于已經提供了JAVA程序語言和對象級接口的數據傳遞方式和基于JVM的java運行環境這些軟件要素，應用架構需要考慮的是從軟件層次上主要遵循MVC的設計模式，在功能實現上通過合理的對象設計以及模式應用來進行保證。

    這就意味著，對一個J2EE企業應用項目組而言，既需要非常熟悉相關的業務領域知識，同時對技術環境的熟悉程度和把握能力都要求較高，這樣對項目的實施造成了很大的壓力。

    所以，在Java的開源世界里，有很多技術組織在研究架構技術，我們常見的像Struts、Spring、Hibernate都是屬于這種范疇，這些開源架構因良好解決了我們應用架構設計的很多問題而備受推崇，然而，我們也清醒認識到，這些架構要么只解決了部分層次的問題（如Strtus、Hibernate等）、要么就是提供了完整架構（如Spring），但沒有與之配套的完整的工具的支持，使得在項目中，整合這些架構成為項目的應用架構并為之建立與之匹配的一套開發支持環境成為了新的問題，對于項目完成后的應用可維護性更是無暇顧及。

    面向構件的架構提供一套體系完整的應用架構：
    1.從應用功能維度上，是通過構件包來承載業務功能的，一個應用可以由多個構件包構成，每個構件包實現了一組具有相關性的業務功能，實際上可以將構件包理解為業務功能分解后的功能模塊。
2.從軟件層次維度上，每個構件包又按照MVC的思想抽象形成了不同層次的構件元素，由上而下包括頁面構件層、展現構件層、業務構件層、運算構件層、數據構件層，每個層次具有鮮明的特征，完成相應的使命，同時引入了具有很強擴展能力的XML總線技術，實現各個層次之間的數據傳遞，并提升各個層次數據的擴展能力。構件層次結構圖如下：

    針對以上構件層次結構圖中的各個要素的作用和特征詳細描述如下：
    數據構件層采用X-R Mapping技術，主要實現與企業系統數據庫的數據實體映射，達到數據持久層管理的目的，降低應用與數據庫結構和數據庫類型的耦合度，提升企業應用在數據層次的擴展能力。另外，數據層還提供了數據字典的管理能力，它使得應用層的業務配置具有強大的靈活性，基本數據屬性的變化都可以通過參數配置完成。

    運算構件層實際上是對計算機處理操作的構件化封裝，因為應用的業務功能最終都是通過計算機的計算能力完成的，計算處理一定是與代碼相關的，而且依賴于具體的計算機語言，正因為這個層次具有與業務無關性，是可以預先實現的，面向構件技術體系可以提供預制的構件庫，使得在開發一個企業應用時，基本上業務處理所需要的計算功能都已經提供了。當然，構件可以進行擴展，在即使應用中不夠的情況下，也可以使用JAVA開發出新的運算構件。總體而言，在開發一個企業應用過程中，在這個層次上花費的工作量將變得少而且簡單。

    業務構件層主要實現應用邏輯的處理過程，其實現方式是通過構件組裝環境將許多運算構件通過可視化方式組合成復雜的業務處理過程(應用邏輯)，提高開發、測試、維護效率。傳統方式下采用代碼實現業務邏輯的過程變成了畫業務流程圖的過程。也使得了應用的邏輯與具體的代碼實現進行了有效的分離。

    展現構件層是連接用戶界面與業務處理的中間層次，例如頁面的某個處理請求（按鈕或者連接）將會激活相應的展現構件，展現構件將用戶提交的數據傳遞給相應的業務構件進行調用，根據調用的返回，再定位到另一個用戶界面，并把業務處理的返回數據傳遞到相應頁面上。

    頁面構件層主要提供對應用系統用戶界面的支持。

    XML數據總線是面向構件技術體系一個很重要的技術特性，通過XML的DOM方式，封裝了應用的三大數據區：Session數據區（SessionContext）、Request數據區（RequestContext）、業務處理數據區（BizContext），構成整個應用的數據總線區。這樣，在面向構件應用中，各種數據都被規范成了XML的格式，而數據的傳遞則采用Xpath的尋址方式。而這種數據傳遞方式使得應用開發中對接口的處理與原來基于對象接口的方式有了較大差異。構件的接口相當于確定了接口數據在總線中的固定位置，運行時根據不同的實例，對應位置上的內容可能不一樣，而傳統的接口只確定接口的對象類型和對象的變量名，在調用具體接口時完成對象的實例化。

    通過上面的描述，我們可以看到這個架構的2個重要特點：
    1）應用邏輯與代碼是相對分離的。應用系統中的應用邏輯是體現企業業務特點和經營管理理念的，是企業業務知識和管理流程的載體，而企業的業務內容和管理模式是動態成長的，這就需要對應用系統進行維護以適應這種變化。當應用邏輯獨立于具體的代碼實現后，通過圖形化的方式表達的應用邏輯就變得易于進行調整以適應新的變化。
    2）應用邏輯與數據是相對分離的。傳統的方式下，代碼、業務邏輯、數據是三位一體的，當數據通過XML總線方式獨立于應用邏輯后，將使得應用系統在數據的擴展能力上有了較大的提升。

    僅僅有這樣一個應用架構是不夠的，需要有與之配套的工具或環境的支持，這種支持，就是由EOS產品的各個部分來提供的，例如，通過EOS Studio，能夠實現基于構件包的各種層次構件的可視化開發；通過EOS Server，實現對可視化構件的解釋，使之成為J2EE環境的標準分布式應用，另外，實現對運行時數據總線的管理；通過EOS Manager，實現對應用的部署和管理、監控。

    當這種面向構件的架構與一體化的配合環境結合起來后，EOS的優勢就顯現出來：

    分層的構件體系和XML總線使得應用系統架構具有了良好的開放性和擴展能力
    一體化可視化的開發運行環境屏蔽了復雜的技術細節
    提高了開發效率
    方便于系統的后期維護