企業套用系統

狹義的企業套用系統是指運行在企業內的單純的軟體系統，而廣義的套用系統則是由標準化的管理模式、知識化的業務模型以及集成化的軟體系統三個層次構成。

基本介紹

• 中文名：企業套用系統
• 外文名：Enterprise application system
• 類型：計算機科學
• 學科：跨學科
• 性質：系統
• 概念：運行在企業內的單純的軟體系統

介紹

廣義的企業套用系統由三個層次構成：管理模式、業務模型與軟體系統。業務模型體現了企業內先進的管理模式，並直接表現為軟體系統的行為，業務模型的可重構性是影響企業套用系統重構能力的關鍵因素。傳統的企業建模方法，如CIM2OSA、GRA I/GIM等，通常將模型的重點放在如何使用不同視圖對企業進行完備描述，較少考慮模型本身的動態性。

狹義的企業套用系統是指運行在企業內的單純的軟體系統，而廣義的套用系統則是由標準化的管理模式、知識化的業務模型以及集成化的軟體系統三個層次構成，如圖1所示。

企業套用系統的層次結構

現代企業面臨巨大的市場壓力，這就要求企業業務流程不斷變化，以便適應市場變化的需求，流程重組又是很頻繁的事情。客觀上，企業應用程式必須通過重構才能快速回響企業業務流程的變化，那么，重構的易操作性和靈活性就十分重要。並且，伴隨著電子商務的普及。跨企業供應鏈協作需求也日益增加。因此，需要有一種技術能夠將構建於不同時期、不同類型的異構系統以及跨企業邊界的軟體系統進行靈活的整合。套用系統架構的選擇!實際上是在系統實現的功能與系統實現的複雜性間尋求一種折衷。在這種背景下，基於各種架構或模型的企業套用系統應運而生了。

套用系統架構

設計和性能是實際框架選擇的兩個基本點，善於平衡才是框架選擇的主要宗旨。輕量級框架和重量級框架解決問題的側重點是不同的。

輕量級框架側重於減小開發的複雜度，相應的它的處理能力便有所減弱（如事務功能弱、不具備分散式處理能力），比較適用於開發中小型企業套用。採用輕量框架一方面因為儘可能的採用基於POJOs 的方法進行開發，使套用不依賴於任何容器，這可以提高開發調試效率；另一方面輕量級框架多數是開源項目，開源社區提供了良好的設計和許多快速構建工具以及大量現成可供參考的開原始碼，這有利於項目的快速開發。例如目前Tomcat+Spring+Hibernate 已經成為許多開發者開發J2EE 中小型企業套用偏愛的一種架構選擇。隨著可供選擇的框架層出不窮，開發者可以根據需要對應於企業套用三個層次的輕量級框架選擇，本文第2 節的內容可供選擇參考。而作為重量級框架EJB 框架則強調高可伸縮性，適合與開發大型企業套用。在EJB 體系結構中，一切與基礎結構服務相關的問題和底層分配問題都由應用程式容器或伺服器來處理，且EJB 容器通過減少資料庫訪問次數以及分散式處理等方式提供了專門的系統性能解決方案，能夠充分解決系統性能問題。輕量級框架的產生並非是對重量級框架的否定，甚至在某種程度上可以說二者是互補的。輕量級框架在努力發展以開發具有更強大，功能更完備的企業套用；而新的EJB 規範EJB3.0 則在努力簡化J2EE 的使用以使得EJB 不僅僅是擅長處理大型企業系統，也利用開發中小型系統，這也是EJB 輕量化的一種努力。對於大型企業套用以及將來可能涉及到能力擴展的中小型套用採用結合使用輕量級框架和重量級框架也不失為一種較好的解決方案。

基於EJB 的重量級框架

由於 EJB 容器能夠很好的處理系統性能、事務機制、安全訪問許可權以及分散式運算等問題，基於EJB 框架進行開發能保證企業套用平滑發展，而不是發展到一種規模就重新更換一套軟體系統，且可以保證開發人員將大部份精力集中在業務邏輯的開發上。採用EJB 框架開發的企業套用具有必須繼承或依賴EJB 容器的特點。EJB 充分考慮到了頂級大型項目的需求，使用它幾乎能解決企業級套用涉及到的所有問題，相應的基於EJB 框架也是一個功能複雜的重量級框架。

J2EE1.4 標準規定的EJB 2.1 框架缺少設計且實現起來有些過於複雜。當前J2EE5.0 的新規範提出的EJB 3.0 的目標就是簡化開發，借鑑了一些基於POJO 的思想，它相對於EJB2.1 中兩個重要的變化分別是：一是使用了Java5 中的程式注釋工具，注釋取代了過多的XML 配置檔案並且消除了嚴格組件模型需求；二是採用了基於Hibernate 和TopLink 思想的O/R Mapping 模型。

J2EE5.0 的新規範中定義企業套用三個層次的標準實現為：表現層採用JSF（Java Server Face），JSF 的開發流程的核心是事件驅動，組件和標籤的封裝程度非常高，很多典型套用已經不需要開發者去處理http。整個過程是通過IoC(依賴注入)來實現的；業務組件層採用EJB3.0 的Session Bean。EJB3.0 允許開發者使用藕合鬆散的組件來開發套用。這些組件通過自己發布的商業接口來耦合，不必像EJB 2.1 規範定義的那樣一個Bean 必須遵守的嚴格的組件模型，每一個EJB 類必須從某一種抽象類中繼承，並為容器提供了回調的鉤子；持久層採用EJB3.0 實體Bean 持久化模型，吸收了Hibernate 的一些思想採用O/R Mapping 模式， EJBQL也有許多重要的改變。

基於POJOs 的輕量級框架

在基於POJOs 輕量級框架上開發的應用程式無需依賴於EJB 容器可獨立運行，對應於Java 企業套用三個層次的輕量級框架技術分別都得到了一定的發展，這三個層次流行的框架如下：

目前比較流行的開源表現層框架主要有Struts 和Tapestry。Tapestry 與Struts 套用框架不同的是，它是基於組件，而不是面向腳本語言（比如JSP 和Velocity）的，組件是由一個定義檔案(以XML 的格式)、一個HTML 模板、一個JAVA 類構成的；業務組件層輕量級解決方案也不少，包括Spring、Hivemind 等。但是目前使用最為廣泛的還是Spring框架，Spring 框架是一個基於IoC 和AOP（面向方面編程）的構架。採用IoC 使得它可以很容易的實現bean 的裝配，提供了簡潔的AOP 並據此實現事務管理等，但是它不具備處理套用分散式的能力。Spring 的核心要點是：支持不綁定到特定J2EE 服務的可重用業務和數據訪問對象。這樣的對象可以在不同J2EE 環境 （Web 或 EJB）、獨立應用程式、測試環境之間重用；持久層框主要有Hibernate 和各種JDO 產品，以及iBATIS。Hibernate 是一個開源的O/R Mapping 框架，它對JDBC 進行了非常輕量級的對象封裝，可以套用在任何使用JDBC 的場合，可以在套用EJB 的J2EE 框架中取代CMP，完成數據持久化的重任。iBATIS 是一個簡易的SQL Map 工具，它是將手工編寫的在xml 配置檔案中的SQL 語句映射成Java對象。

表現層框架比較

MVC 設計模式不再是某一種表現層框架的特點而是這幾種框架的共性。Struts 框架由於出現時間早，所以使用相對廣泛，它的社區非常活躍，很容易找到很多現成的開源功能標籤以供使用以及樣例程式可供參考。但是它的組件在頁面中顯示的粗粒度，以及框架類的限制在很多情況下會表現得過於死板，給表示層的開發會帶來一些額外的代碼開銷。JSF 在很大程度上類似Struts，只是JSF 的組件概念沒有象Struts 那樣必須繼承ActionForm 的限制，JSF 在事件粒度上要比Struts 細膩。JSF 有的另外一個優勢就是其身後有Sun 公司和其他的一些大公司的支持。Tapestry 是一個完全組件的框架，Tapestry 的組件可以被套嵌並包裹其它組件，因此可以組合形成一個更大的組件或邏輯頁面。組件的行為模式為Web 頁面編程提供了很大的方便，事件處理也方便很多。所以，如果做一個對頁面要求靈活度相當高的系統就可以考慮選用Tapestry。

業務組件層框架比較

EJB 2.1 框架有些過於複雜了，有如下缺點：① EJB 模型需要建立許多組件接口和實現許多不必要的回滾方法；②EJB 的部署描述複雜而容易出錯；③開發人員不能脫離EJB容器測試。對於以上缺點JCP (Java Community Process)制訂的EJB3.0 標準框架做了相應的改進，該框架為所有主要的J2EE 廠商支持。EJB3.0 和Spring 兩個框架結構都有一個共同核心設計理念：將中間件服務傳遞給耦合鬆散的POJOs。

EJB3.0 框架與套用伺服器高度整合，服務整合代碼也包裝在一個標準接口後面。EJB 框架一方面有成熟的EJB 容器支持，基於EJB 框架的企業套用性能優良；另一方面EJB 容器設計因為考慮了多方面的功能，所以在其核心上總是會顯得臃腫，這也是一種重量表現。不需要的東西存在肯定會影響效率，EJB 不能根據項目需求對EJB 整體包括EJB 容器進行可配置式的切割。Spring 框架處於套用伺服器和服務庫的上方，服務整合的代碼屬於框架，並暴露於套用開發者。它與套用伺服器整合的能力相對EJB3.0 要弱。但是Spring 框架模組的可分離配置體現了它優於EJB3.0 的靈活性。

持久層框架比較

容器管理持久性（CMP）是對EJB 中Entity Bean 進行持久性管理的方式。EJB2.1 持久性模型過於複雜並且存在基礎缺陷。EJB3.0 持久層針對EJB2.1 的缺陷做了相應改進，採用與Hibernate 類似的機制。Hibernate 相對而言其基本優勢如下：①Hibernate 使用 Java 反射機制而不是位元組碼增強程式來實現透明性；②Hibernate 的使用簡單；③映射的靈活性很出色，它支持各種關係資料庫， 從一對一到多對多的各種複雜關係。Hibernate 也有一些缺點，它限制所使用的對象模型 (例如，一個持久性類不能映射到多個表)。使用iBATIS 提供的O/R Mapping 機制，對業務邏輯實現人員而言，面對的是純粹的Java 對象， 這一層與通過Hibernate 實現O/R Mapping 而言基本一致，而對於具體的數據操作，Hibernate 會自動生成SQL 語句，而iBATIS 則要求開發者編寫具體的SQL 語句。相對Hibernate 等 “全自動”O/R Mapping 機制而言，iBATIS 以SQL 開發的工作量和資料庫移植性上的讓步，為系統設計提供了更大的自由空間。作為“全自動”ORM 實現的一種有益補充，iBATIS 的出現顯得別具意義。