一種信息系統服務可擴展機制的研究
2007-01-01 00:00:00張毅李懷璋馬波
計算機應用研究 2007年2期
摘 要：針對當前我國農業信息服務無法集成，農業信息系統不具備可擴展性的狀況，提出了一種基于已有商業構件框架之上的服務可擴展農業信息平臺，進行了平臺服務可擴展機制的設計與實現。試驗證明，該機制在對系統整體性能影響較小的前提下，通過制定標準的農業信息數據XML規范，將系統各部件劃分為獨立的信息服務構件，并在平臺中提供服務管理、服務數據交換和系統功能接口，有效地實現了農業信息平臺的信息服務可擴展特性。
關鍵詞：信息系統； 可擴展； 服務； 軟件構件
中圖法分類號：TP391文獻標識碼：A
文章編號：1001—3695(2007)02—0079—04
農業信息網絡是我國未來農業信息化發展的戰略重點。制定統一的信息描述規范，促進各類農業信息系統，如專家系統、地理信息系統、衛星遙感信息系統的數據交換是構建全國農業信息傳輸系統、建立農業基本數據庫群的基礎，也是國家“金農”工程的重點內容之一[1]。在此背景下，要求農業信息系統伴隨其應用環境的不斷變化而隨之演化，使原有系統能與新的農業信息服務進行整合，以滿足新的用戶需求，即實現農業信息服務可擴展。現有的成功的農業信息系統，如中國農業信息科技網[2]等均不具有農業信息服務可擴展性。因此需要為農業信息化平臺引入信息服務可擴展機制，從而為建立全國農業信息網絡打下基礎，也為將來國家統一農業信息服務數據標準作好準備。
應用構件技術將系統功能抽象為服務，使可擴展系統的實現成為可能[3]。我們在農業信息化平臺關鍵技術開發及應用項目中，提出了一種基于已有商業構件框架和XML[4]格式數據交換機制的農業信息服務平臺可擴展系統框架，設計實現了支持農業信息服務可擴展的關鍵機制。通過這種服務可擴展機制，可滿足農業信息化系統方便用戶定制、系統服務模塊可獨立開發、農業信息服務可靈活快速組合的需求[5]。
1 可擴展農業信息服務平臺框架
為了實現農業信息服務可擴展，首先必須解決兩個問題：①一個新的農業信息服務如何動態地加載到原有應用系統中；②不同農業信息服務之間如何實現數據交換。構件技術為動態加載系統部件提供了參考[3]，可擴展標記語言（XML）是已被廣泛應用的標準數據交換方法。農業信息平臺的實現也需要基于已有的構件框架技術[6]和XML技術來實現其農業信息服務可擴展的功能。
該平臺設計為建立在已有商業構件框架基礎上的農業應用平臺。平臺中服務間的數據交換統一采用XML數據格式，XML作為一種可擴展、自描述的數據編碼格式，有利于實現交互性良好的消息交換場景。農業信息服務平臺和建立于平臺上的農業信息服務構件構成了最終的農業信息服務應用系統。通過平臺內部的服務可擴展機制，可以實現服務的動態加載和服務間的數據交換。建立在本平臺之上的農業信息服務應用系統結構如圖1所示。
系統分為兩層，底層是農業信息服務平臺，負責服務數據的交換和農業信息化領域相關邏輯的實現；平臺之上是不同的農業信息服務構件，它們實現了不同的農業信息服務功能，各服務可以通過平臺提供的接口交換服務數據。平臺與平臺之上的服務都可以與其他系統通過XML或其他數據格式交換數據。
2 服務可擴展機制的設計
服務可擴展機制是農業信息平臺的核心機制，可擴展機制的設計實現包括標準的數據交換方式定義、信息服務構件定義以及平臺中服務管理模塊的設計。
2.1 服務數據的標準交換機制
服務的交互需要定義其交互的協議語義，本平臺采用XML數據格式作為標準的數據交換機制。使用XML進行數據交換有兩種方式[7]：①基于接口語義（Interface Semantic）的方式。在這種方式中，XML數據信息標志了進行數據交換所需調用的接口。XML-RPC就是使用的這種方式。②基于消息流語義（Payload Semantic）的方式。在這種方式中所有的數據交換協議和內容全部表示在字符信息中。方式①是類型安全的，但是當交互雙方之一的程序改變后，相關模塊需要重新開發和編譯，自適應性較差，不能滿足農業信息化平臺中農業信息服務松散耦合的要求；方式②更加靈活，交互語義被封裝在消息內容中，語義修改不影響交互接口定義，交互雙方完全松散耦合，但缺點是這種方式是非類型安全的，存在交互語義不匹配的問題。在系統設計中，為了獲得完全的擴展性，我們使用基于消息流語義的XML數據交換方式。
通過定義一組有意義的XML標簽可以實現數據標準化的目的。每個信息服務為其提供的服務信息數據定義相關的標準XML數據標簽，服務構件開發人員在遵從該服務標簽規范（可以是一個書面規范）的基礎上開發新的服務構件。例如農業新聞信息的標簽如下：
<農業新聞標題> 描述農業新聞標題
<農業新聞內容> 農業新聞的內容
<農業新聞來源> 新聞地區
<農業新聞類別> 描述新聞類別，如技術、經濟
標簽也可以通過定義XML Schema文件來實現。新聞服務信息的內容用XML格式表示如下：
<農業新聞服務>
<農業新聞標題>預防小麥凍害，播期把好三關
<農業新聞內容>…具體內容…
<農業新聞類別>技術
<農業新聞來源>山東
其他服務可以依據新聞服務XML標簽規范，解析新聞服務信息，并作進一步的處理。
2.2 信息服務構件定義
將建立于農業信息平臺之上的信息服務構件定義為：提供獨立的信息源或實現獨立的農業信息處理功能，能與平臺實現數據交互，并可獨立開發與發布軟件功能模塊。一個完整的農業信息服務模塊具有如下特征：
(1)具有完整獨立的功能。提供一個完整的子系統功能，可以實現農業信息系統某方面的需求。例如農業新聞服務用于提供農業新聞信息，擁有完整的Web用戶訪問界面，為用戶提供新聞的輸入接口。
(2)提供服務數據訪問接口。平臺通過該接口可訪問該服務的相關功能和服務數據；該接口還負責將本信息服務的服務數據轉換為XML格式的數據信息。例如，平臺可以訪問農業新聞服務的訪問接口，得到所需的XML格式的農業新聞信息。
(3)實現平臺數據訪問接口。該接口可訪問平臺提供的其他服務信息，這些服務信息為XML數據格式；該接口還負責將這些XML格式的數據解析為本服務可以理解的數據格式。
系統中服務是松散耦合的，它們之間的數據交換都必須通過平臺來完成。描述一個服務調用序列示例如圖2所示。專家系統服務需要訪問平臺相關接口，以獲得XML格式的近期天氣信息（由天氣服務模塊提供），并能解析天氣信息，綜合處理后提供更有參考價值的專家信息。一個農業信息服務構件的標準定義如圖3中虛線以上的部分所示。2.3 平臺服務管理模塊的設計
平臺中服務管理模塊是實現農業信息平臺服務可擴展機制的核心模塊。平臺服務管理模塊結構如圖3虛線下方所示，系統中其他的服務模塊均建立在其上，通過該模塊的內部機制實現服務間信息的交換。服務構件通信和基本管理功能，如構件發布、構件替換、構件激活、構件鈍化和構件接口調用等功能均通過現有的商業構件平臺框架實現，而建立在這些商業構件平臺之上的農業信息平臺服務管理模塊所需實現的功能如表1所示。
(1)服務構件管理。發布服務構件時需要同時向平臺的服務管理模塊進行注冊。具體注冊信息包括向平臺描述自己的模塊名稱、實現類以及服務數據接口等。每個服務構件的注冊信息也可以通過XML數據文件來描述。一個典型的服務部署描述文件如下：
description=\"獲得新聞服務信息\">
其中
(2)服務間數據訪問。服務間數據訪問機制利用平臺中已注冊的服務信息，對平臺之上的服務數據交換提供了支持。為了實現該功能，需要對服務請求進行規范定義。平臺中的服務引擎解析該服務請求，查找提供相關信息的服務，調用其服務數據訪問接口，而后返回服務信息。一個服務請求的示例如下：
<用戶ID>100021
服務請求并不需要指明本服務需要哪些其他服務為其提供信息，只需指明需要哪些服務信息。而具體查找這些服務信息由平臺上哪個服務提供，則由平臺中的服務引擎完成。
以專家系統的請求為例，服務引擎的工作原理如圖4所示。這種服務間數據訪問的設計實現了服務之間的完全松散耦合，只需要基于農業信息平臺標準的XML標簽，各服務就可以實現數據交換。
(3)系統功能接口。該接口提供平臺上的農業信息服務調用系統的通用功能，如用戶訪問權限查詢。當某個用戶進行新聞服務信息輸入操作前，該信息服務模塊會調用系統功能接口中的相關函數查詢該用戶的權限，以判斷是否能夠進行該操作。一些平臺相關的領域信息，如農產品的分類、地區的定義等也包含在該模塊中，其他各服務可通過系統功能接口獲得這些公用信息。
3 服務可擴展機制的實現
3.1 技術選型
根據第2節確定的系統設計和需求，我們需要實現服務構件的發布、裝載、激活、替換等構件系統基本功能，并最終選擇了J2EE平臺。J2EE是由Sun公司定義的企業應用程序模型，它利用Java 語言的標準體系結構定義，簡化了企業應用方案開發、部署和管理相關復雜問題的體系結構。J2EE 5.0[9]為其最新版本。J2EE 5.0與其較早版本相比，其最大的特點即易于開發性，通過在組件源代碼中使用元數據標記，大大簡化了系統配置工作。截至本文撰寫之時，J2EE 5.0尚未發布正式版本，JBOSS 4.0.3實現了其預覽版的功能。本農業信息化平臺正是實現在該預覽版本之上，為將來使用正式版J2EE 5.0作好了準備。
3.2 信息服務模塊的實現
信息服務模塊的實現是一個J2EE的完整EJB3工程，包含了數據層、邏輯層和表示層的實現。信息服務模塊的服務數據功能通過EJB3的Entity Bean實現。通過應用J2SE1.5的Annotation特性，開發中大大簡化了數據庫相關操作的復雜性。信息服務模塊業務邏輯通過EJB3的Session Bean和Message Bean實現。JBOSS服務器中的EJB可以實現跨EAR包訪問，這也為服務間的交互提供了技術基礎。
每個服務的服務數據訪問接口和平臺數據訪問接口均在Bean中實現。信息服務構件不必從特定的接口進行派生，但需要對實現服務數據訪問接口的接口函數類型進行約束，從而提供系統統一的服務數據訪問接口。一個典型的服務訪問接口函數聲明如下：
string getNewsInfo(String xmlPlatformInfo);
其中輸入參數為平臺調用時的輸入信息，其格式為XML格式；返回參數也是一個XML格式的信息，該信息中包含了當前服務根據輸入參數返回的本服務信息。
3.3 平臺服務管理模塊的實現
服務構件管理模塊提供服務構件注冊、服務構件查詢等功能。該模塊具有自己的相關服務管理頁面（本平臺中為Web頁面）。用戶在JBOSS服務器上發布其信息服務的EAR包后，通過該界面上傳XML格式的服務描述文件來完成該服務的注冊。平臺接收這個文件并解析其內容，在系統中注冊該服務，并將服務信息登記在數據庫中。
平臺提供的服務間數據訪問接口支持服務數據的相互訪問和數據交換，其內部通過一個服務引擎來實現服務查找和調用的功能。各服務通過JNDI或IOC[9]的方式調用平臺提供的數據訪問接口。一個使用IOC方式調用的代碼片斷如下，ServiceManager中實現了服務間數據訪問接口(getRelativeServInfo)的接口：
@EJB ServiceManager smanager;…
smanager.getRelativeServInfo(…)…
與之相反，因此平臺中調用各服務信息模塊的服務數據訪問接口時，需要使用Java的反射機制，結合J2EE平臺的JNDI方法來調用各個信息服務模塊相關功能。服務引擎中調用一個服務構件的服務數據訪問接口的代碼示例如下：InitialContext ctx=new InitialContext();
Object SMp=ctx.lookup(servicename);
if (SMp!=1){
//反射得到服務信息訪問接口函數
Class cls=Class.forName(servicename);
if (cls==1) return 1;
Method method=cls.getDeclaredMethod(methodname， paramclasses);
Object[] paramobjects=new Object[1];
paramobjects[0]=userContext;
userContext=(String)(method.invoke(SMp，paramobjects));}
系統功能接口中實現了系統公共功能，如根據用戶ID查詢用戶權限的功能，還包含查詢該用戶的一些服務偏好（如所關注的地區、農產品種類等）的功能。與服務間數據訪問接口相同，各服務可以通過JNDI或IOC的方式來調用該接口中的功能。
4 系統性能分析
系統模塊解耦（Decouple）和采用XML作為數據組織與傳輸方式會對系統效率帶來影響，我們通過試驗測試了影響的程度，并在此基礎上提出了系統改進的方案。
試驗環境：PC機，P4 1.8GHz，512MB內存；紅旗Linux 4.1操作系統；MySQL Server 4.1數據庫；JBOSS 4.0.3應用服務器；JDOM XML解析器；100Mbps局域網。
試驗內容：執行新聞服務數據查找操作，因為該操作不包含復雜的數據庫操作，并且在操作過程中省略了信息顯示等耗時的工作，因此可以將可擴展機制給系統性能帶來的影響放到最大。具體試驗操作分為兩種：①使用原始的J2EE調用方式，即直接調用新聞服務相關操作接口；②通過調用平臺數據接口，返回并解析XML格式新聞信息。方式①是在一個獨立的EAR包內測試。方式②的操作涉及三個EAR包，分別是新聞服務構件、農業信息平臺和新聞服務測試構件。
根據查詢的數據量不同，得到的結果如表2所示。表中第一行表示數據表查詢操作所返回的記錄行數，另外四行是執行操作所花費的統計平均時間（單位為ms）。其中，第二行和第三行中的數據是執行第一個試驗操作的數據；第四行和第五行的數據是執行第二個試驗操作的數據；第二行和第四行是服務器執行調用所花費的時間；第三行和第五行是客戶端從Web頁面完成操作所花費的時間。
表2 數據查找操作結果
數據量(條)/平均用時(ms)1101001 00010 000
Exp Ⅰ(avg)
12.218.866612.75 400.2
＜4007908001 80012 890
Exp Ⅱ(avg)
25.253128.2871.88 296.8
＜4008208602 05015 070
從表2中數據可以看到：
(1)對比第二行和第四行的數據可以發現，使用服務可擴展機制會給系統效率帶來影響。這些額外系統開銷主要由兩類操作造成：①不同模塊間接口查詢和調用；②XML數據包裝與解析。
（2）當操作的數據量在1 000行以內時，服務可擴展機制的額外計算時間小于0.3s。占用整個操作的時間花費不超過15%（該試驗已將影響放到最大）。
相對于網絡傳輸和頁面顯示的時間開銷，用小于0.3s的額外時間獲得系統的服務可擴展性是值得的。系統性能改進的方法有：①將系統中常用服務構件納入平臺中，固化為平臺的一部分；②選用效率更高的XML解析器（本實驗中使用JDOM）；③根據統計操作結果，優化服務引擎。
5 總結
通過在農業信息化平臺中引入服務可擴展機制，使得在已有農業信息系統上擴展新的農業信息服務成為可能。服務開發人員在完成新服務功能的基礎上，只需添加服務數據訪問接口和平臺數據訪問接口，并遵循標準的XML格式農業數據規范，就可以將該服務集成到已有的農業信息系統中。已有的農業信息系統通過一個適配器（Adapter）也可以實現與本農業信息化平臺的集成。
試驗數據表明，該機制在支持系統可擴展性的同時，只對系統整體性能帶來了較小的影響。在最壞的情況下，單個服務操作增加的運行時間不會超過不使用該機制時的運行時間的15%。通過固化服務到平臺和提高XML數據解析效率等方法，可以進一步提高系統效率。
該平臺的下一步工作包括：擴充標準農業信息數據規范的定義內容，提供更高效的服務引擎和在平臺集成中的農業業務流程（Agriculture Business Process）等。
本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。
