敏捷構建-面向企業應用的開發平臺

最近寫了篇文章，貼出來供大家分享

題目      敏捷構建-面向企業應用的開發平臺

 

摘  要:     隨着企業軟件應用的逐步深化，客戶對軟件開發的工期、質量等要求越來越高，軟件開發成本持續升高，所以軟件企業的應用開發必須從高效率、高質量的角度出發，採用敏捷構建的方法，實現快速開發、交付、實施，而這一切必須依託一套完成的軟件開發平臺解決方案，只有這樣才能適應當前軟件行業的需要，在激烈的競爭中，特別是參與國際化的競爭中，保持領先地位。

                  當前業界，無論是高級管理者還是普通開發人員，都已經達成共識，對於IT技術公司，平臺是基礎設施，不管面向的業務領域是什麼，都必須基於一個平臺去構建，無論是個性化IT服務，軟件產品，還是電子商務，門戶網站，抑或是SOA，SAAS，雲服務，雲計算，凡是成規模的企業，都是基於平臺運作。凡是還在從頭開始編碼的公司，要麼被淘汰了，要麼即將被淘汰。是否具備基礎平臺或構建平臺的能力已經成爲軟件企業核心競爭力之一。

                  企業應用軟件提供商可以通過多年積累對主要的行業解決方案和主打的項目類別進行一些產品、系統的固化，形成積累，從而在後續同類方案、同類項目中實現以往研發成果的複用、減少人員投入，這樣就可以解放出更多的人力來拓展其他項目，獲取更多收入，提高企業的生產效率。瑞友科技的GAP平臺就是這樣的研發積累形成的平臺產品。GAP平臺全稱是UFIDA Software Engineering Global Application Platform，是北京瑞友科技股份公司集多年應用開發實施經驗所提煉的快速應用開發平臺。

                  本文主要闡述了GAP平臺的整體架構，以及在平臺的開發過程中採用的一些創新性的技術，包括面向業務服務的開發（SOA），領域驅動設計（Domain-Driven Design），基於資源文件的組件技術，工作流技術等，基於此可以實現企業應用軟件開發的敏捷構建，並形成一個完成的企業應用軟件生態圈，技術、業務、解決方案、外圍應用集成相輔相成，將極大的提高IT服務企業的核心競爭力，也是企業應用開發領域中的模式創新。

 

關鍵詞:     企業應用，開發平臺，領域驅動，業務服務，組件技術

 

1     綜述

1.1    背景

隨着企業軟件應用的逐步深化，客戶對軟件開發的工期、質量等要求越來越高，軟件開發成本持續升高，所以軟件企業的應用開發必須從高效率、高質量的角度出發，採用敏捷構建的方法，實現快速開發、交付、實施，而這一切必須依託一套完成的軟件開發平臺解決方案，只有這樣才能適應當前軟件行業的需要，在激烈的競爭中，特別是參與國際化的競爭中，保持領先地位。

從應用開發和應用外包的具體內容綜合來看，兩者有很大一部分其實描述的是相同的服務內容，只是具體實施者或服務提供者有所不同，由於服務提供方和提供形式的差異形成不同的商業形態，但從服務內容根本上完全可以看作是同類內容。對於這部分相同的內容，就是圍繞企業級應用系統生命週期而產生的各種IT服務。這部分內容可以統稱爲“應用服務”。

所謂應用服務，就是專業服務商爲企業客戶的管理類應用系統提供他們需要所有服務的統稱。應用服務是IT服務的一個重要細分市場。它的主要特點有三個：（1）必須基於統一的平臺；（2）提供覆蓋應用系統的全生命週期服務；（3）服務形式多樣。所以，一般情況下，應用服務也可以籠統地稱爲“基於平臺的IT服務”。

由此可見，對於應用軟件開發商，平臺是基礎設施，不管面向的業務領域是什麼，都必須基於一個平臺去構建，無論是個性化IT服務，軟件產品，還是電子商務，門戶網站，抑或是SOA，SAAS，雲服務，雲計算，凡是成規模的企業，都是基於平臺運作。如何去構建平臺，有多種方式，一般情況下，企業應用軟件提供商可以通過多年積累對主要的行業解決方案和主打的項目類別進行一些產品、系統的固化，形成積累，從而在後續同類方案、同類項目中實現以往研發成果的複用、減少人員投入，這樣就可以解放出更多的人力來拓展其他項目，獲取更多收入，提高企業的生產效率。

瑞友科技的GAP平臺就是這樣的研發積累形成的平臺產品，是北京瑞友科技股份公司集多年應用開發實施經驗所提煉的快速應用開發平臺。

Global Application Platform（以下簡稱GAP）平臺不僅是一套快速開發應用軟件的輔助工具，而且提供了很高複用度的大規模軟件定製開發模式。作爲開放性的開發平臺，GAP致力於解決當前軟件開發過程中的三個關鍵問題：軟件過程問題，軟件複用問題，快速開發問題。並通過對這些問題的解決爲客戶提供更好的軟件質量、降低客戶的總體成本。GAP平臺致力於解決大規模的 JavaEE 項目中遇到的共性問題，提供完整的 JavaEE 架構庫，解決JavaEE項目中遇到的80%以上共性的技術問題。提供集成快速開發工具，支持快速業務應用定製開發，從而提高開發效率，增加軟件的複用度，提升企業的項目交付能力，提高整個軟件企業的敏捷性。

GAP平臺基於SOA思想構建，強調面向業務服務的架構體系，基礎框架採取了輕量級的構建方法，同時在開發中使用領域驅動開發方法和組件式設計來提高組件的複用率和靈活性。核心架構控制在靈活輕量的規模內，以CBD(Component-Based Development)的方式集成平臺中的衆多模塊，強調組件內部高內聚，組件間保持鬆耦合，各組件既能獨立運行，也可以插件的方式集成到整個平臺體系中來，實現企業應用開發的敏捷構建。

1.2    應用平臺特點

一般來說，面向企業應用的快速開發平臺，應該具備如下特點：

一、穩定性

n          成熟清晰的分層架構

n          具備多年項目積累

二、安全性

n          提供安全可靠的數據傳輸和存儲

n          多維度、細粒度的權限控制

三、規範性

n          基於業界成熟規範

n          完善的開發規範和指南

n          學習曲線低

四、擴展性

n          平臺基於SOA思想進行構建

n          開放的API，面向接口編程

n          基於組件的設計，分層的開發思想

n          靈活適應業務需求變更

五、全面的系統監控

n          提供對日誌、流程、數據和性能的分析監控功能

六、提升開發效率

n          提供大量可複用組件和業務引擎

n          提供集成開發環境

n          敏捷構建，快速實施

 

2     系統架構

2.1    技術體系

GAP平臺的技術框架主要基於JavaEE技術體系構建，遵循業界國際標準，採用先進技術，分層領域驅動，採用Spring技術、OSGi技術和O/R Mapping技術，整合Web框架Struts和JSF，形成核心技術框架GAP-Mainframe，屏蔽異構底層環境，爲上層建築提供各類基礎服務。目前GAP平臺的應用系統、通用組件庫、業務組件庫和業務套件等，都是基於該技術體系進行構建。

2.2    分層架構

層級理論是構建複雜系統的一個基本原則。對於軟件這樣複雜的人造事務，發現層級和運用層級，是分析和解決問題的基本原則。軟件層級的劃分不但爲解決複雜軟件開發探索一條可行的方法，同時也爲應用軟件產業鏈的完善起到推動作用，使得企業之間的協作關係更加清晰。

層（layer）這個概念在計算機領域是一個應用相當廣泛的概念。計算機本身就體現了一種層的概念：系統調用層、設備驅動層、操作系統層、CPU指令集。每個層都負責自己的職責。網絡同樣也廣泛存在層的概念，最著名的是OSI的七層協議。

使用層級理論最難的問題還是各個層都有些什麼，以及要承擔何種責任。以往的軟件開發過程中大都自覺或者不自覺的利用層級理論來幫助提高開發效率。如抽象公共控件，開發基礎類，編寫開發輔助工具等行爲都是層級理論的具體應用。但是目前開發過程中普遍存在的問題是缺乏對整個應用軟件進行系統、完整的層次劃分，從而導致軟件中各部分之間的服務關係不明瞭，對支撐平臺的開發缺乏明確的進度規劃和目標。

GAP平臺在設計初期就對企業應用軟件的層級進行了細緻的劃分，並在長達6年的開發、構建、完善過程中一直遵循這一分層架構。GAP平臺的分層架構圖如下：

 

（圖一）分層架構圖

n          技術環境

           主要指異構的項目實施環境，由於瑞友科技提供的是個性化的IT服務而非標準化的產品，我們在項目開發、測試、實施的過程中必須面對各種各樣軟硬件環境，包括各種服務器、操作系統、應用中間件、數據庫等。基於GAP平臺構建的項目能夠保證項目可以運行在各種異構的技術環境中，目前GAP平臺支持的操作系統有Windows Server、Aix、 Solaris、HP-Unix、Linux等，應用中間件有WebLogic、WebSphere、Sun APP Server、JBoss、 Tomcat等，數據庫有Oracle、SQLServer、DB2等。

n          服務框架

           是GAP平臺的核心和基礎，它爲構建上層應用系統提供各種基礎服務和擴展機制，包括日誌服務、緩存服務、異常處理、事務處理、集羣支持策略、分佈式調用、配置服務、數據持久化、數據源服務、監控服務等，除此之外，服務框架層還集成了多個web框架，包括struts和jsf，基於領域驅動思想提供了對JavaEE四層架構的支持：

           展現層：提供完善的界面展示框架和豐富的界面控件，解釋來自UI層的命令

         控制層：用來協調應用活動，轉發請求，處理調用方式等，它不包含業務邏輯，它不持有業務對象的狀態

         領域層：本層包含關於領域的信息。這是業務軟件的核心所在。在這裏保留業務對象的狀態，對業務對象和它們狀態的持久化被委託給了持久化層。

           持久化層：本層作爲其他層的支撐庫存在，它提供了數據對象之間的通信，實現對業務對象的持久化，屏蔽數據存儲層的環境影響。

n          引擎、組件和工具

           服務框架層之上是基本的業務支撐引擎、通用組件和快速開發工具，支撐引擎包括工作流引擎、規則引擎、全文檢索引擎、報表引擎，通用組件包括組織權限、工作流平臺、消息平臺、接口服務平臺、業務日誌、任務調度、站內短信、預警平臺、內容管理等，快速開發工具包括GAP-IDE、項目管理器、代碼生成器、數據字典等，這一層的組件把技術環境和具體業務邏輯進行了很好的隔離，在商業環境的運行規則發生改變的情況下，依然能保證整個系統的穩定性。

n          業務組件

 

         業務組件與通用組件不同，業務組件層主要包含爲解決企業特定業務職能而抽象的業務模型及其實現。每個業務組件代表企業某個相對獨立業務或者業務鏈條，每個業務組件都具備相關的領域知識，基於每個領域的成熟解決方案構建而成，這樣的業務組件不同於某個應用系統中簡單劃分的業務模塊，它是高度抽象化，高度可擴展的。目前我們規劃的領域主要包括金融領域業務組件、保險領域業務組件、物流領域業務組件。

n          業務套件

           業務組件層之上是業務套件，業務套件的概念是由GAP平臺項目創新性提出，它既不是傳統意義上的標準化成品，也不是細粒度的業務組件和技術組件，而是粗粒度的業務組件集合，每個領域的業務套件基於GAP平臺底層框架構建，選取通用組件，引擎和該領域的業務組件進行擴展開發，形成一系列該領域的業務套件。業務套件可以理解爲傳統意義上的準產品，

n          領域應用

         領域應用層就是針對特定用戶特定項目進行的個性化項目開發，解決特定領域的應用問題，領域應用層通常會依賴一個或多個業務套件，同時根據客戶的個性化需求還會使用到相關的業務組件、通用組件和支撐引擎。這是整個軟件結構中的最上層，它調用下面各個層次的服務，形成最終呈現給客戶優質的軟件產品。

 

        五個層級自定向下依賴，形成一個完整的企業應用開發解決方案。

2.3    功能架構

目前GAP平臺的功能架構如下：

（圖二）功能架構

整個GAP平臺由以下幾部分組成：

n          基礎框架，提供各種基礎服務，包括主框架，通用列表控件和性能監控等

n          統一的集成開發環境GAP IDE，在提供標準IDE開發調試功能的基礎上，又開發和集成了大量快速的開發和部署插件，以滿足業務開發人員的使用

n          應用系統，包括工作流平臺，組織權限系統，接口服務平臺，消息平臺和數據字典

n          組件庫，包括業務日誌，規則引擎，WEB控件，全文檢索引擎，任務調度，報表工具，站內短信，論壇等

 

        在整個平臺的開發過程中，我們使用了大量紛繁複雜的技術，進行了持續的自主研發，不斷創新與完善，同時基於不重新發明輪子的原則，選用了部分優秀的開源項目進行集成和二次開發。整個平臺的技術體系，敏捷的開發過程和技術創新，都保證了平臺的先進性和創新性，同時保證了瑞友科技的技術先進性和業務敏捷性。

3     技術創新

在長達六年的平臺建設過程中，我們進行了大量的技術創新，來保證平臺的敏捷性和先進性，一下簡要介紹幾個主要的技術創新點。

3.1    面向業務服務的開發

3.1.1      什麼是業務服務

SOA是一套成熟的方法論和架構體系，隨着相關技術體系和標準的成熟，OSOA組織在2007年3月發佈了SCA 1.0（服務組件架構） 和SDO 2.1（服務數據對象），同時市場上的ESB（企業服務總線）產品逐漸成熟，這標誌着無論是在方法論還是技術實現方面，SOA已經成爲企業新一代首選的、先進的、成熟的、標準的應用架構。

SOA是一個完整的軟件軟件架構體系，包括運行環境、編程模型、技術標準、策略及其方法論，其核心思想是服務，並涵蓋服務的整個生命週期：建模、開發、裝配、運行、管理。基於對SOA體系的理解，我們認爲SOA的核心理念是業務驅動，其目標是爲了滿足隨需應變的業務需求，所以我們在GAP平臺的體系架構中創新性提出了業務服務（Business Service）的概念。

每個業務服務表示一個完整的業務單元，多個業務服務組成一個完整的業務模塊，多個業務模塊組成一個子系統，多個子系統組成一個完成的項目或產品。例如針對訂單的管理，其業務邏輯是由業務服務OrderService及其相關的領域對象實現，OrderService構建完成之後，由於其基本覆蓋了訂單相關的所有業務邏輯，是一個相對獨立的業務單元，所以它可以被多個業務模塊複用，甚至可以被系統外部的環境訪問，整個系統都是有這樣的Business Service，其複用率和擴展性將大大增強。

從語義上來看，我們提出的業務服務並不特指某一種技術或標準，比如Web Service。在不同的軟件環境中，業務服務的具體表現形式可以進行動態轉換。例如在容器內部，每個BS將以Service Bean的形式爲上層環境提供服務，屬於直接調用，而在容器外部（異構環境或同構環境不同應用系統），BS又會根據具體的業務需求表現爲Web Service，RMI，HttpInvoke等，與其他系統進行遠程交互。

 

3.1.2      面向業務服務的開發

 

基於Business Service的技術架構圖如下

（圖三）基於Business Service的技術架構圖一

 

從上圖可以看出，GAP平臺技術體系的核心是Business Service，我們完全面向業務服務編程，所有的業務服務以IOC的方式注入到系統中，系統的業務邏輯，事務，領域模型，數據倉庫都由業務服務單元處理，各個業務單元通過組合，可以形成一個業務組件（Component）爲上層體系提供服務。

由於整個系統是基於業務服務構建的，我們可以很容易基於業務服務提供多種類型的訪問方式，包括最普通的本地調用，爲異構系統提供基於SOAP和WSDL的Web Service訪問，爲富客戶端提供RMI遠程調用，同時還提供一些輕量級的遠程訪問方式，例如HttpInvoker和hessian、burlap等分佈式遠程訪問等，可以支撐各種異構系統的集成和數據交換。

業務服務管理模塊可以爲內外部系統提供服務註冊功能，把基礎框架，各應用系統和組件庫中的組件提供的各種業務功能註冊爲一個服務，具體的技術實現包括Web Service，RMI，MQ等，同時提供服務的訂閱、發佈和監控機制，還可以引入其他系統的標準Web Service。通過對業務服務的管理，可以使GAP平臺在構建業務應用時變得更靈活且能夠更快的響應不斷變化的業務需求和業務整合，針對異構系統的整合和交互，變得透明而簡單。

同時業務服務還可以註冊到工作流系統中，通過業務表單的形式爲企業流程管理提供服務。

 

GAP平臺的技術體系和基於業務服務的設計思想，可以在下圖中完整的體現出來：

（圖四）基於Business Service的技術架構圖二

 

3.2    領域驅動設計

3.2.1      領域驅動設計簡介

2004年著名建模專家Eric Evans發表了他最具影響力的著名書籍：《Domain-Driven Design –Tackling Complexity in the Heart of Software》（中文譯名：領域驅動設計—軟件核心複雜性應對之道），書中提出了“領域驅動設計(簡稱DDD)”的概念。

領域驅動設計事實上針對是OOAD的一個擴展和延伸，DDD基於面向對象分析與設計技術，對技術框架進行了分層規劃，同時對每個類進行了策略和類型的劃分。領域模型是領域驅動的核心思想，採用DDD的設計思想，業務邏輯不再集中在幾個大型的類上，而是由大量相對小心的領域對象（類）組成，這些類具備自己的狀態和行爲，每個類是相對完整的獨立體，領域模型就是由這樣許多的細粒度的類組成。基於領域驅動的設計，保證了系統的可維護性、擴展性和敏捷性，在處理複雜業務邏輯方面有着先天的優勢。

領域驅動設計分層結構如下：

（圖五）DDD分層架構

（表一）DDD各層含義

用戶界面/展現層	負責向用戶展現信息以及解釋用戶命令。
應用層	很薄的一層，用來協調應用的活動。它不包含業務邏輯。它不保留業務對象的狀態，但它保有應用任務的進度狀態。
領域層	本層包含關於領域的信息。這是業務軟件的核心所在。在這裏保留業務對象的狀態，對業務對象和它們狀態的持久化被委託給了基礎設施層。
基礎設施層	本層作爲其他層的支撐庫存在。它提供了層間的通信，實現對業務對象的持久化，包含對用戶界面層的支撐庫等作用。

 

領域模型的基本要素包括：實體、值對象、工廠、倉庫、服務，如下圖所示

（圖六）DDD要素和模式關係

 

3.2.2      基於DDD的創新

我們基於DDD的創新點主要有兩個：

第一，我們在GAP平臺的開發過程中，結合我們的產品特點，針對領域驅動的四層模型進行了細分，形成了GAP平臺自己獨有的分層架構模型。

如下圖所示：

（圖七）GAP平臺分層架構模型

View：展示層，由於GAP平臺主要面向B/S架構，展示層主要由web資源文件組成，包括JSP，JS和大量的界面控件，採用了AJAX技術，負責向用戶展現豐富的界面信息，並執行用戶的命令

Control：控制層，負責展示層請求的轉發、調度和驗證，同時處理後臺返回的異常信息，同時控制層可以通過Action做遠程的請求

Domain：領域層，是系統最爲豐富的一層，主要負責處理整個系統的業務邏輯。這一層主要包括上一章提到業務服務和領域模型，同時負責系統的事務管理

Persistence：持久化層，主要負責數據持久化，支持O/R Mapping和JDBC，對數據源的訪問提供多種訪問方式。

另外，我們引入了Spring的IOC容器，系統的控制層、領域層和持久化層元素都有IOC容器統一管理，實現完全的接口分離和解耦。

 

 

第二，在保證DDD核心思想的基礎上，我們對DDD的基本要素進行了擴展，以滿足GAP平臺的實際需求，如下圖所示：

（圖八）GAP平臺領域模型

GAP平臺領域驅動設計要素主要分爲以下幾種：

業務服務：遵循GAP平臺的設計思想，核心仍然是業務服務（Business Service），一個業務服務可以由一個或多個領域模型（DomainModel），值對象（VO），實體（Entity）和數據訪問對象（DAO）組成，去完成一個完成的業務邏輯單元。業務服務主要負責事務處理和維護各個領域對象之間的關係，同時爲上層訪問提供服務。

領域模型：真正處理業務邏輯的類，例如訂單（OrderModel），具備自己的屬性和行爲、狀態，可以聚合VO和Entity，持久化數據可以委託給Entity，如果沒有聚合Entity，也可以直接被持久化。

實體類：只具備需要持久化的屬性，被領域對象聚合，被DAO調用實現數據的持久化。如果業務邏輯相對簡單，可以合併到領域模型中。

值對象：不具備唯一標識，不進行持久化的對象，一般用來進行參數傳遞。

數據訪問對象：不處理業務邏輯，主要負責領域模型或實體類的持久化。提供多種持久化方式。

 

那麼如何在GAP平臺中實現一個領域模型設計呢？可以按照如下步驟進行：

1.          確定業務服務（Business Service），根據業務需求和功能模塊劃分，確定業務單元，每個Business Service是一個業務單元，覆蓋相關的領域對象。

2.          定義領域對象（Domain Model，VO，Entity），根據業務單元的業務邏輯定義領域對象，通過UML方法和設計模式描述領域對象。

3.          定義領域對象的屬性和關聯關係，確定領域對象的各種屬性和各個領域對象之間的關聯關係

4.          爲領域對象增加行爲，根據業務需求（系統用例和界面原型等）爲領域對象增加行爲，並定義哪些方法要被業務服務所用

 

    經過多年的平臺建設和項目應用，我們創造了一套適合企業敏捷構建的領域設計方法，並進行了重要實踐。目前大量項目已經採用了這種方法進行企業應用系統構建，並取得了成果。事實證明我們在領域驅動設計方面取得了重大創新和突破。

3.3    組件裝配技術

3.3.1      組件技術

目前業界言必提服務，組件技術說的越來越少了，但對於企業應用開發領域，組件技術恰恰是非常必要的，是提升複用率和敏捷構建的基礎，也是很多應用開發平臺沒有解決好的關鍵問題。

組件技術提出的很早，但是業界對於組件的定義並沒有完全達成一致，通常而言這個術語表示一個軟件模塊，這個模塊可以獨立地作爲應用程序的一部分發布，或者被組裝到更大的組件中去。這樣看來，小到一個動態鏈接庫，一個COM組件，一個Web Service，大到工作流，組織權限管理，規則引擎等，都可以叫組件。

構建一個組件並不困難，關鍵是如何把一些規模較大的組件進行裝配與合併，形成一個更大的系統，這是業界的難題。造成這個難題的原因是基於瀏覽器的應用！軟件發展到現在，大部分應用都是基於internet或intranet的，軟件載體是瀏覽器。這就造成了現代的企業應用軟件具備大量的資源文件，資源文件已經成爲軟件產品的主體之一，而不僅僅是原來的可編譯二進制文件，例如jar，dll，exe等，這些資源文件包括：jsp文件，腳本文件，properties屬性文件和各種xml配置文件，如何處理和組裝這些資源文件是企業應用開發平臺不可避免的問題，這也是當前的流行技術SCA和OSGi沒有解決的，SCA和OSGi各自提出了優秀的技術架構和模型去解決組件的裝配、解耦以及異構系統集成的問題，但是沒有涉及到資源文件的處理。

很多企業有自己的開發平臺，也開發了很多組件，但是當項目組需要從組件庫選取組件進行開發時，發現必須依賴組件的構建文檔，進行手工複製組件，組件集成，修改各種複雜的資源文件，合併，最終形成一個項目，再導入IDE環境進行開發，測試。這樣大大降低了企業應用開發的敏捷性和生產率，而且依賴手工構建，必然導致這樣那樣的錯誤，使組件的複用率大打折扣。

 

3.3.2      GAP平臺的組件裝配機制

GAP平臺在開發的過程中，同樣遇到組件裝配的問題，目前GAP平臺共18個大型組件，組件之間的交互可以通過接口進行分離，但是資源文件的依賴關係是組件裝配無法迴避的問題。由於Web開發的規範限制，每個組件都會使用到一些公共文件，包括web.xml，公用的jsp文件，公用的配置文件等，而每個組件由於採用的技術需要，在這些公用文件中會增加自己的配置信息，這就爲組件裝配增加了難度。

爲了保證組件開發的獨立性，我們採用了各個組件獨立開發，然後再統一裝配的原則。基於以上原則，我們採用瞭如下創新技術完美實現了組件的構建和裝配。

主要實現技術：ANT技術，Xdoclet技術，Eclipse的Plug-in技術和WTP的facets機制

實現步驟：

1.          各個組件獨立構建，編寫自己的ant腳本，提出各組件自己需要的資源文件和二進制文件

2.          各個組件提取自己在公用文件中使用的配置信息，形成獨立的數據文件，該數據文件只包含自己需要的配置信息。

3.          把公共資源文件做成模板，並在其中設置其他組件需要的Merge Point，例如

         

<XDtMerge:merge file="workflow-global-js.data"></XDtMerge:merge>

 

          該Merge Poing在自動構建時由Xdoclet進行解析處理，把該段內容替換成workflow-global-js.data文件中的內容，完成合並工作。

4.          使用ant技術編寫TotalBuile腳本，負責調用各個組件自己的ant腳本，構建完成的GAP插件內容

5.          使用Eclipse的Plug-in及其WTP的facets技術實現GAP平臺項目管理器插件，其主要完成的工作如下：

a)          提供GAP項目創建嚮導

b)         增加選擇GAP組件的wizard page，顯示當前版本提供的所有組件，用戶可以自定義自己需要的平臺組件

c)          提供配置功能，通過配置文件設置各個組件ID，名稱，關聯和分組關係，依賴關係，URL和頁面展示方式等

d)         設置基本環境變量，複製資源文件，設置項目所需classpath，根據merge point進行文件的merge

e)          刪除構建文件，項目創建完成

（圖九）GAP平臺組件裝配

如上圖所示，通過GAP項目管理器，可以實現對各個組件的完美裝配，項目開發人員可以根據客戶的業務需求，靈活選擇需要的組件，組件裝配完成之後即形成一個完成的Project框架，導入GAP平臺的開發工具VenusTools2009，即可進行設計、開發、調試、運行，保證了企業應用系統構建的靈活性和擴展性。

4     結論

面向企業應用的開發平臺是IT服務的基礎，也是未來的發展趨勢，瑞友科技在長達6年的時間內始終堅持科技創新，自主研發的路線，到目前爲止形成了以軟件平臺技術爲基礎的核心競爭力。基於該平臺，可有效促進外包服務企業承接個性化IT服務項目，降低軟件外包服務企業的入門門檻的技術難度。同時這一研究成果也爲進一步實施中國軟件國際化戰略，提升中國軟件在世界範圍內的影響，擴大和鞏固國產軟件和中國品牌在國際市場的競爭優勢，培育國際化的軟件企業發揮應有的作用和示範效果。

 

GAP平臺主要解決的問題是：

1、   企業應用軟件的層次模型

2、   基於組件的開發與設計，各組件既能獨立運行，也可組合裝配形成完整應用

3、   具有網絡拓撲結構的跨企業組織模型，細粒度的權限控制

4、   具有技術環境兼容性的B/S柔性軟件框架

5、   國際化軟件開發環境

6、   基於運行時動態組構的計算機輔助應用軟件開發工具

7、   以消息總線、數據總線和控制總線爲基礎的業務流平臺

 

本文同時還闡述了GAP平臺的三個主要的技術創新點，如下：

1.          面向業務服務的開發

2.          基於領域驅動的設計

3.          組件裝配技術

目前GAP平臺的最新版本是3.5，基於GAP平臺的對外合作已經全面展開。在現有的平臺基礎上，我們已經開始構建GAP5.0的開發內容，以期有更多的技術創新和研發成果，爲中國企業應用領域做出更大的貢獻。

 

References:

 [1]     Richardson, Chris. POJOs IN ACTION. 出版社: Oreilly & Associates Inc, 2008. [書籍]

 [2]     (美)Eric Evans;孫向暉(註釋), 領域驅動設計--軟件核心複雜性應對之道(註釋版). 出版社:人民郵電出版社 2007. [書籍]

 [3]     王紫瑤;南俊傑;段紫輝;錢海春;陳荻玲;李冬, SOA核心技術及應用. 出版社: 電子工業出版社

 [4]     http://www.eclipse.org/articles/Article-BuildingProjectFacets/tutorial.html, Extending WTP Using Project Facets