本發(fā)明涉及軟件開發(fā)技術領域，尤其涉及基于工作流的數(shù)據(jù)集成系統(tǒng)。

背景技術：

工作流過程定義語言(wpdl)是由wfmc于1994年推出的基于元模型的為創(chuàng)建階段的工作流過程模型的輸入、輸出而建立的文本描述語言。而xml過程定義語言(xpdl)是wfmc于2001年5月發(fā)布的基于xml描述工作流過程定義接口規(guī)范。xpdl是wfmc用來標準化過程定義的語言，因此它的實體概述數(shù)據(jù)模型呈現(xiàn)了工作流定義中的最基本的組成實體。

工作流是一種對工作進行優(yōu)化的思想和技術，其主要的優(yōu)越性表現(xiàn)在工作流的基礎上改進控制策略，降低響應的控制成本,降低管理成本，避免不必要的和重復的工作，提高工作人員的工作效率,有利于提高軟件的復用率、靈活性和適應能力,通過對己經(jīng)完成的工作流實例的分析，找出存在的不足，進而不斷改進工作流程,改善工作質(zhì)量，自動提供為完成某個任務所需要的相關信息,可以大大縮短主要業(yè)務過程的處理時間,使工作內(nèi)容更加豐富，并且提高工作人員的業(yè)務能力，減少工作人員進行單調(diào)乏味并且十分耗時的文檔查找工作,通過在工作流模型中加入對可預計故障的處理策略來提高系統(tǒng)的柔性,提供系統(tǒng)日志功能,能夠適應一定程度的業(yè)務流程變化需要。

工作流管理系統(tǒng)在實際應用的過程中，尚有需要完善的內(nèi)容，工作流管理系統(tǒng)實現(xiàn)的復雜性：企業(yè)工作流管理系統(tǒng)的實現(xiàn)，不單要完成相應的過程定義，還要與現(xiàn)有系統(tǒng)的集成、開發(fā)相應的用戶界面、制定相應的管理規(guī)程與用戶操作規(guī)范，更可能需更改企業(yè)的整個業(yè)務流程操作規(guī)范以適應工作流管理系統(tǒng)，相應的，企業(yè)的管理體系也可能需要改變；工作流管理系統(tǒng)的安全性：工作流管理系統(tǒng)對系統(tǒng)運行中出現(xiàn)的并發(fā)訪問和異常處理等錯誤處理和中斷恢復功能支持比較薄弱，其運行性能也不足以處理大范圍、高強度的業(yè)務需求，這些都應該是應用中必須加以慎重考慮的主要問題；工作流技術 尚不成熟：盡管工作流技術至今已經(jīng)取得了很大的進步，但是相比起其他企業(yè)應用技術，例如關系數(shù)據(jù)庫技術，工作流技術依然處于自己技術發(fā)展的早期階段，各種標準及實現(xiàn)技術都還在研究與制定之中，工作流仿真技術的缺乏：工作流技術的仿真一直比較薄弱，整個工作流系統(tǒng)是不完善的。因為仿真方法與仿真工具的缺乏，大多時候人們只能通過人工判斷流程的表述的正確性，無法判斷和優(yōu)化工作流過程，各種工作流產(chǎn)品的標準化程度差，不同生產(chǎn)者的工作流產(chǎn)品都有自己的一套工作流模型、工作流定義語言及api接口，存在與其它產(chǎn)品不能很好交互的問題，原因在于不同廠家為了體現(xiàn)自己不同的特點，或多或少的對標準與規(guī)范的實現(xiàn)做了擴充和修改。

數(shù)據(jù)集成的出現(xiàn)幫助企業(yè)將后臺的的erp信息遷移到web層面上。數(shù)據(jù)集成能在一個公司的web層與oracle、sap、ibm、微軟等公司的后臺系統(tǒng)間提供一個“高速數(shù)據(jù)緩存”或數(shù)據(jù)信息分級。

數(shù)據(jù)集成能夠在一個企業(yè)的主服務器存儲的后臺信息的構建一份數(shù)據(jù)備份。當一個web客戶想要查詢一份訂單的處理狀態(tài)時，本次查詢就被傳遞到數(shù)據(jù)集成平臺。因此，無須每次都去訪問企業(yè)的主服務器。數(shù)據(jù)集成平臺可以根據(jù)實際的需要來判斷何時與主服務器進行同步以便使數(shù)據(jù)保持最新狀態(tài)^[12]。集成erp數(shù)據(jù)的電子商務應用是通過直接訪問erp數(shù)據(jù)和數(shù)據(jù)分級這兩個部分的有機結合來完成的，這其中包括利用一個主的數(shù)據(jù)服務器和一些高速的數(shù)據(jù)緩存^[10]。數(shù)據(jù)集成平臺以通過智能方式來根據(jù)實際情況將實時訪問和批量數(shù)據(jù)存取這兩種方法融合起來，以便從統(tǒng)一的erp平臺抽取數(shù)據(jù)。

數(shù)據(jù)從一個或多個源表集成到一個或多個目標表以及轉換成需要的信息類型(如xml)，數(shù)據(jù)傳輸?shù)牟襟E包括確認需要抽取數(shù)據(jù)的源、數(shù)據(jù)需要進行的轉換以及向何處發(fā)送數(shù)據(jù)。用戶可以通過圖形的化接口來完成數(shù)據(jù)映射的指定和轉換的制定。

由用戶定義的模塊來控制每一塊數(shù)據(jù)的同步并確認這些同步之間的內(nèi)部相關性。例如，如果一個目標表依靠其他代碼表的值，則使用一些模塊來控制一臺數(shù)據(jù)服務器需要以什么次序來進行這些目標表中的單個的數(shù)據(jù)移動。數(shù)據(jù)移動可以被定制為以批量方式或增量方式實時運行，以上均可以由管理員來進行創(chuàng)建和管理，以方便電子商務、控制erp、供應鏈管理、客戶關系 管理以及系統(tǒng)應用之間的數(shù)據(jù)同步^[11]。數(shù)據(jù)同步使用多進程、分布式優(yōu)化查詢、存儲內(nèi)的數(shù)據(jù)轉換和流水線并行操作來提供非常高的數(shù)據(jù)集成量和系統(tǒng)伸縮性。

etl是extract-transform-load的縮寫，即數(shù)據(jù)的提取、轉換、加載的過程，是bi/dw(businessintelligence)的關鍵和心臟，通過使用統(tǒng)一的規(guī)則進行集成并提高數(shù)據(jù)信息的生產(chǎn)價值，來負責完成數(shù)據(jù)信息從數(shù)據(jù)源頭向目標數(shù)據(jù)數(shù)據(jù)庫集成的過程，是構建數(shù)據(jù)倉庫的重要過程^[14]。假如將數(shù)據(jù)倉庫的模型設計類比成一座建筑的規(guī)劃藍圖，數(shù)據(jù)是建筑的磚瓦的話，那么etl就是整個建筑的建設過程。用戶需求分析和模型設計是整個項目中最難部分，而工作量最大的則是etl方案設計規(guī)劃和實施，從國內(nèi)外眾多實際應用中來看這一段流程時間基本上占整個項目時間的60％～80％。

信息是現(xiàn)代化企業(yè)非常重要的資源，是企業(yè)進行決策分析、科學管理的基礎。目前，很多企業(yè)花費巨量的時間和資金來搭建辦公自動化系統(tǒng)和聯(lián)機事務處理oltp系統(tǒng)，用以處理生產(chǎn)業(yè)務中產(chǎn)生的各種相關數(shù)據(jù)。統(tǒng)計顯示，整個企業(yè)的數(shù)據(jù)量會以每2～3年的時間成倍的增長，在這些數(shù)據(jù)潛在著巨大的商業(yè)價值，但是企業(yè)所關注的信息通常只占總數(shù)據(jù)量的2％～4％上下。所以，現(xiàn)有的數(shù)據(jù)信息資源仍然沒有被企業(yè)最大化地開發(fā)利用，于浪費了非常多的資金和時間，錯失規(guī)劃企業(yè)發(fā)展的最佳契機。因此，如何利用各種技術手段，把已有的業(yè)務數(shù)據(jù)轉換為決策信息、應用知識，已經(jīng)成為企業(yè)提高其核心競爭力的關鍵問題。而etl是能夠很好的解決該問題的一個技術手段。

etl的效果質(zhì)量問題主要表現(xiàn)為完整性、正確性、完備性、一致性、有效性、可獲取性和時效性等幾個方面。而影響etl質(zhì)量問題的因素有很多，由于歷史數(shù)據(jù)和系統(tǒng)遷移而造成的原因主要有以下幾個方面:業(yè)務系統(tǒng)在不同時期的業(yè)務流程有調(diào)整；業(yè)務系統(tǒng)在不同時期的系統(tǒng)之間存在數(shù)據(jù)格式的不一致；舊的系統(tǒng)和新業(yè)務、管理系統(tǒng)的數(shù)據(jù)同步的不完整而帶來的不一致性；舊的業(yè)務系統(tǒng)模塊在資產(chǎn)、財務、人事、辦公系統(tǒng)等相關數(shù)據(jù)信息的不一致。

實現(xiàn)etl，首先要實現(xiàn)的是etl轉換的過程。它主要集中地體現(xiàn)為以下幾個方面：

(1)建立etl過程的主外鍵約束對無依賴性的不合法數(shù)據(jù)，可暫時替換或者導出到相應錯誤數(shù)據(jù)日志文件中，以保證主鍵能夠惟一的被裝載。

(2)空值處理捕獲數(shù)據(jù)字段的空值，裝載或者替換為其他的定制數(shù)據(jù)，同時根據(jù)數(shù)據(jù)字段空值信息來實現(xiàn)分散加載到不同目標數(shù)據(jù)庫。

(3)規(guī)范化數(shù)據(jù)格式實現(xiàn)數(shù)據(jù)字段格式的約束定制，對于數(shù)據(jù)源中數(shù)值、時間、字符等數(shù)據(jù)，可自定制其加載格式。

(4)拆分數(shù)據(jù)根據(jù)業(yè)務需求對字段進行合適的分解。例，電話系統(tǒng)中目標號碼861237618919，可進行區(qū)號和電話號碼來分解。

(5)數(shù)據(jù)替換對于業(yè)務的原因，可完成缺失數(shù)據(jù)、無效數(shù)據(jù)的替換。

(6)驗證數(shù)據(jù)正確性可以利用lookup或者拆分功能來進行數(shù)據(jù)信息驗證。例如，目標號碼861237618919，進行區(qū)號和電話號碼分解后，可利用lookup返回電話網(wǎng)關或者交換機記載的主叫地區(qū)，進行電話號碼驗證。

(7)lookup查詢丟失數(shù)據(jù)，利用lookup實現(xiàn)子查詢，同時返回使用其他手段檢索到的丟失字段，保證數(shù)據(jù)字段的完整性。

etl過程在很大的程度上受到企業(yè)對源數(shù)據(jù)的理解深度的左右，即從業(yè)務的角度來審視數(shù)據(jù)集成是非常重要的。一個成功的etl設計規(guī)劃應該具有如下幾方面的功能：

(1)管理方式簡單；

(2)利用元數(shù)據(jù)模式，能夠集中管理；

(3)具有較強的拓展性；

(4)接口、集成、數(shù)據(jù)格式有嚴格的規(guī)范；

(5)無需在外部的其他數(shù)據(jù)源構建系統(tǒng)；

(6)讀取的數(shù)據(jù)準確、及時、完備；

(7)數(shù)據(jù)集成系統(tǒng)的業(yè)務流程能自動化執(zhí)行，并且能夠自動調(diào)度；

(8)基于框架的軟件系統(tǒng)，在系統(tǒng)功能發(fā)生改變時，應用程序只需很少調(diào)整即可；

(9)可以提供同豐富的數(shù)據(jù)系統(tǒng)接口，有很強的系統(tǒng)適應性；

科學的業(yè)務邏輯模型設計對etl非常重要。數(shù)據(jù)倉庫是現(xiàn)代企業(yè)具體、唯一、綜合的數(shù)據(jù)系統(tǒng)。數(shù)據(jù)倉庫的規(guī)劃設計一般有三范式、雪花模型和星 型模型，不管是哪種設計方法，都需要最大限度地包含主要的業(yè)務數(shù)據(jù)，將生產(chǎn)環(huán)境中凌亂的數(shù)據(jù)結構整合成為統(tǒng)一的、合理的、相關的新的結構，而etl能夠依照定制的模型去抽取源數(shù)據(jù)，完成轉換、清洗的流程，最終完成后插入到目標數(shù)據(jù)倉庫中去。

數(shù)據(jù)模型的重要性在于能夠對數(shù)據(jù)實現(xiàn)標準化的規(guī)定，完成統(tǒng)一的數(shù)據(jù)分類、統(tǒng)一的數(shù)據(jù)編碼和數(shù)據(jù)組織。而數(shù)據(jù)標準化規(guī)定的內(nèi)容主要有：業(yè)務規(guī)范統(tǒng)一、代碼數(shù)據(jù)統(tǒng)一。因此，etl根據(jù)模型的定義進行初始化抽取、增量抽取、慢速增長維、緩慢變化維、數(shù)據(jù)表加載等方式的數(shù)據(jù)集成，同時根據(jù)具體的業(yè)務需求生成相應的抽取策略、更新策略、集中策略、維持策略。

業(yè)務本身的數(shù)據(jù)以及對業(yè)務運行環(huán)境進行定義、描述的數(shù)據(jù)，稱為元數(shù)據(jù)。元數(shù)據(jù)是闡述數(shù)據(jù)的數(shù)據(jù)。因此，從某種角度上可以說，業(yè)務數(shù)據(jù)的主要作用是用于支持業(yè)務系統(tǒng)應用，而元數(shù)據(jù)則是業(yè)務客戶關系管理、企業(yè)門戶、決策支持、數(shù)據(jù)倉庫和b2b等各種應用所必須的構架。

元數(shù)據(jù)的最為典型應用為對業(yè)務對象的描述，如對數(shù)據(jù)庫、數(shù)據(jù)庫的表、表的列、列的屬性(如類型、約束、格式等)以及對主鍵或外鍵間的關聯(lián)等等的描述。在現(xiàn)今應用系統(tǒng)的分布性與異構性愈發(fā)的普遍的情況下，規(guī)定統(tǒng)一的元數(shù)據(jù)就顯得非常重要了。“信息孤島”以前是很多企業(yè)對其業(yè)務系統(tǒng)應用情況的一種缺憾和描述，而科學的元數(shù)據(jù)設計則能夠有效地勾畫出信息間的聯(lián)系。

而etl中元數(shù)據(jù)對于主要表現(xiàn)在：定義數(shù)據(jù)源的屬性及數(shù)據(jù)源的位置、確立源數(shù)據(jù)與目標數(shù)據(jù)間的對應規(guī)則和模式、確定關聯(lián)的業(yè)務邏輯和流程、在源數(shù)據(jù)加載前需要進行的其他必要的前置工作等等，通常貫穿整個數(shù)據(jù)倉庫系統(tǒng)，而要快速實現(xiàn)etl，則所有過程必須盡可能地參照元數(shù)據(jù)。

ajax是一種輕量級的解決方案，它操作的基礎是html或者是xhtml，使用的腳本語言是javascript，這可以保證它的純文本性質(zhì)，它具有更好的搜索引擎友好性；設計出色的ajax應用還可以很好地工作在舊版本的設備上；利用xml，json等ajax可以和其他應用程序方便地進行通信。

ajax將javascript技術和xmlhttprequest對象放在web表單和服務器之間。當用戶填寫表單的時候，數(shù)據(jù)發(fā)送給一些javascript代碼而不是直接 發(fā)送給服務器。相反，javascript代碼捕獲表單數(shù)據(jù)并向服務器發(fā)送請求。同時用戶屏幕上的表單也不會閃爍、消失或延遲。javascript代碼在幕后發(fā)送請求，用戶甚至不知道請求的發(fā)出。需要指出的是，該請求是異步發(fā)送的，就是說javascript代碼不用等待服務器的響應。與此同時，用戶可以繼續(xù)輸入數(shù)據(jù)、滾動屏幕和使用應用程序。然后，服務器將數(shù)據(jù)返回javascript代碼(仍然在web表單中)，后者決定如何處理這些數(shù)據(jù)。javascript代碼甚至可以對收到的數(shù)據(jù)執(zhí)行某種計算，再發(fā)送另一個請求，不需要用戶干預。這就是xmlhttprequest的強大之處，可以根據(jù)需要自行與服務器進行交互，用戶甚至可以完全不知道幕后發(fā)生的一切。結果就是類似于桌面應用程序的動態(tài)、快速響應、高交互性的體驗，但是卻擁有web應用程序的功能。

工作流與數(shù)據(jù)交換是緊密聯(lián)系的——工作流的設計合理與否是保證數(shù)據(jù)交換高效運作的前提，而數(shù)據(jù)交換的暢通無阻則是工作流體系的成效體現(xiàn)。電子政務辦公系統(tǒng)并不等同于辦公自動化系統(tǒng)，但在設計過程中仍然可以借鑒“第三代信息系統(tǒng)以知識管理為核心”的觀點。第三代信息提出的知識庫概念可以很好地運用到政務或者企業(yè)信息系統(tǒng)中來，而本文所提到的ajax技術完全能很好地調(diào)用知識庫，實現(xiàn)系統(tǒng)審計的功能，通過異步調(diào)用、事前驗證等先進技術，確保政務工作流程高效運作，減少回流的機率。知識管理能夠幫助組織去發(fā)現(xiàn)知道些什么、如何定位擁有專門知識的人、如何傳遞這些知識以及如何有效利用知識。^[這就意味著系統(tǒng)能夠在恰當?shù)臅r間，將正確的知識傳給正確的人，幫助他們采取正確的行動，避免重復錯誤和重復工作，幫助政府提供整體業(yè)務水平的提高。

工作流所提供的控制功能，可以為政務行為設定標準，使政務辦公嚴格按照流程進行，既杜絕了行政違規(guī)違法行為，也監(jiān)督了行政不作為的現(xiàn)象，保證政務辦公按時間節(jié)點開展，不因人為因素停滯。本系統(tǒng)通過工作流技術與數(shù)據(jù)交換技術的有效結合，為部門與部門之間的業(yè)務聯(lián)系提供了一貫到底的辦公流程。正因如此，各關系人很難再找出可以使自己工作延誤、停滯的理由?？绮块T履職流程具有專門的監(jiān)督機制對政務辦公流程進行監(jiān)控。根據(jù)處理進度，本系統(tǒng)的督辦模塊特別設計了警示燈，顯示綠黃紅三種顏色，用來提示該辦公流程還余下多少辦理時間，如：紅色表示已經(jīng)超期。本流程中 的其他關系人，如具有審核權限的分管區(qū)長可以實時查看工作流程的狀態(tài)。

例如，在傳統(tǒng)的公文流轉過程中，因部門領導出差而使流轉過程延誤的現(xiàn)象時有發(fā)生?；诠ぷ髁鞯恼辙k公系統(tǒng)為此提供了“領導外出申報審核”、“公務委托代辦”、“在辦狀態(tài)查詢”、“辦理時間設置”、“催辦、督辦警示標識”等功能，并可嚴格按照“滬府辦[2008]7號”文件設置辦文時間。

綜上所述，針對現(xiàn)有技術存在的缺陷，特別需要基于工作流的數(shù)據(jù)集成系統(tǒng)，以解決現(xiàn)有技術的不足。

技術實現(xiàn)要素：

本發(fā)明的目的是提供基于工作流的數(shù)據(jù)集成系統(tǒng)，便于對工作中的流程進行管理，自動化程度優(yōu)。

本發(fā)明為解決其技術問題所采用的技術方案是，

基于工作流的數(shù)據(jù)集成系統(tǒng)，該系統(tǒng)包括同步接口單元、模塊配置單元、發(fā)布同步單元、信息系統(tǒng)單元；

對數(shù)據(jù)集成，eai集成架構中的點到點架構雖然可以很好地將數(shù)據(jù)從一數(shù)據(jù)源轉換到另一源，但是每種點到點的構架方法都只是一種特例化的方法，而當數(shù)據(jù)源數(shù)目巨大時，很難以支持新的數(shù)據(jù)源加入，而etl指的是從異構的數(shù)據(jù)源抽取數(shù)據(jù)并進行轉換最后裝載到數(shù)據(jù)倉庫，針對etl概念，vassiliadis等人提出了一種過程模型，該etl過程模型從不同的數(shù)據(jù)源抽取數(shù)據(jù)然后經(jīng)過轉換最終裝載入目標數(shù)據(jù)庫中，相對于數(shù)據(jù)倉庫而言，數(shù)據(jù)集成領域的etl有其自身的一些特點，如數(shù)據(jù)差異性更大，不僅是結構化的數(shù)據(jù)，可能還涉及到半結構化數(shù)據(jù)和非結構化數(shù)據(jù)；同時數(shù)據(jù)抽取，轉換和加載等操作往往在不同的地方，需要遠距離傳輸，考慮到性能需求需要盡量減小網(wǎng)絡開銷，因此，可以通過對etl的擴展和修改以解決金融領域數(shù)據(jù)集成的問題；

經(jīng)過總體架構設計、集成開發(fā)、部署運行直至項目圓滿完成的一個流程，此流程作為實施人員進行高校數(shù)據(jù)集成時的指導，具體步驟是：

(1)搜集數(shù)據(jù)集成需求，并進行需求分析，整理成需求文檔，以便成為項目實施的基礎，因此需求分析是整個數(shù)據(jù)集成項目的關鍵；

(2)確定數(shù)據(jù)集成總體框架，對整理出的需求，構建數(shù)據(jù)集成的總體架構，以集成中心庫為中心，實現(xiàn)與各業(yè)務系統(tǒng)數(shù)據(jù)的交互；

(3)數(shù)據(jù)集成平臺的安裝：包括集成工具的安裝，數(shù)據(jù)庫的安裝；

(4)集成開發(fā)：根據(jù)需求和總體架構，利用集成工具，實施數(shù)據(jù)集成中實際業(yè)務需求的項目設計；

(5)部署運行：將實施完成的項目部署到服務器上，并進行相應的配置：

信息系統(tǒng)單元包含有公文交換總控模塊、公文信息緩存及備份模塊、公文流轉子系統(tǒng)：

公文交換總控模塊為各公文流轉子系統(tǒng)提供了交換請求接口，一旦交換中心接受到交換請求后，便根據(jù)請求的實際配置情況，主動抓取需要交換的公文數(shù)據(jù)進行區(qū)層面的保存及整理，隨后再將必要的數(shù)據(jù)主動推送到目標部門服務器，如果目標部門尚未配備公文服務器，則自動推送到區(qū)公用公文流轉子系統(tǒng)中，同時，交換中心還將適當?shù)挠|發(fā)各類消息提醒機制，主動提醒相關人員進行及時處理；

公文信息緩存及備份模塊該模塊將通過一定的效驗機制，緩存已經(jīng)交換過的公文格式、工作流程等方面的信息，從軟件設計上避免相關部門每次都交換此類信息而造成的性能低下等情況的發(fā)生，同時，還將對已交換數(shù)據(jù)做統(tǒng)一的備份和整理，保證某一部門的故障不會影響到其他部門系統(tǒng)的正常使用，保證工作的連續(xù)性。

進一步，同步接口單元包括了字段的轉換、清洗、拼接等方式，在一個數(shù)據(jù)集成任務中，oracledataintegrator的聲明設計是在稱為“接口(interface)”的里面使用關系圖(relationalparadigm)的形式去聲明這些規(guī)則的，數(shù)據(jù)源就人員基本信息表，目標就是教務系統(tǒng)系統(tǒng)，轉換就是基本信息表和單位表單之間的連接，以及每個單位的信息聚合，采用聲明設計，我們只需要把重點放在真正需要關心的地方，那就是信息系統(tǒng)的集成任務的規(guī)則，而不是集成過程的底層技術方面。

進一步，模塊配置單元在odi執(zhí)行的數(shù)據(jù)同步過程中，需要執(zhí)行很多個步驟，以完成整個的抽取、轉化功能，這就要使用到odi的知識模塊來完成這一系列的任務，km(knowledgemodules：知識模塊)在odi中是一組代碼 模板，在集成過程中，每一個km對應一個特定任務，整個數(shù)據(jù)集成過程通過選擇若干個km代碼模板生成執(zhí)行代碼而完成集成工作；

km具有抽象性和可重用性，它是對集成過程規(guī)則和過程的描述，是對邏輯任務的抽象，而與具體的物理對象(如數(shù)據(jù)表、物理路徑、列等)無關，在集成時，用戶通過調(diào)用這些規(guī)則和過程，將接口、模型、包中存儲的元數(shù)據(jù)信息(具體的數(shù)據(jù)庫連接、映射關系等)作為參數(shù)注入到km中，因此km類似于一個抽象接口，與具體的業(yè)務對象分離開來，從而使得一個km能夠被多個集成項目可用，因此km是對數(shù)據(jù)集成過程和規(guī)則的高度抽象和總結，通過開發(fā)一整套的km庫可以極大的降低數(shù)據(jù)集成的復雜度；

odi平臺為不同的集成場景和過程準備了多個km，用戶可以通過調(diào)用這些km完成不同的集成需求；另外km也允許用戶自己擴展、重寫，當已有km模板無法滿足集成需求時，可以通過自定義編寫km而完成特殊場景下的個性化需求；

odi根據(jù)集成過程和功能的不同將km分為以下幾大類：rkm(reversekm)、ck(checkkm)、lkm(loadkm)、ikm(integretionkm)、jkm(journalizingkm)、skm(servicekm),每一類km完成特定類功能。

進一步，發(fā)布同步單元信息是系統(tǒng)中變化數(shù)據(jù)的捕獲使用的是一個發(fā)布和訂閱模型，一個被系統(tǒng)識別的訂閱者—比如是信息系統(tǒng)到教務系統(tǒng)的一個集成過程—訂閱那些發(fā)生在信息系統(tǒng)中數(shù)據(jù)存儲的變更，在人事管理系統(tǒng)數(shù)據(jù)存儲中的數(shù)據(jù)變化能夠被數(shù)據(jù)集成系統(tǒng)的cdc架構捕獲并發(fā)布給訂閱者，并且這個過程是在任何時間都能夠獲得被跟蹤的變更，進而處理這些事件；

開發(fā)完接口，配置好系統(tǒng)執(zhí)行的知識模塊后，我們將接口拖入到開發(fā)包中，讓數(shù)據(jù)從數(shù)據(jù)源頭流入到目標數(shù)據(jù)庫中，經(jīng)過編譯后，就可以發(fā)布運行；

odi的實時同步和定時同步是odi集成過程的計劃執(zhí)行的方式，不管是全量還是增量都可以實現(xiàn)近實時同步，odi計劃的設置組合很多，如果要達到近實時同步，只需要在執(zhí)行那里設定啟動時，執(zhí)行循環(huán)那里設定多次，重復間隔設定你需要的時間，但是增量的實時同步的性能在大多數(shù)情況下是優(yōu)于全量的，原因是它本身已經(jīng)縮短了執(zhí)行時間，在odi系統(tǒng)中時間的設定可以設定到秒級。

進一步，信息系統(tǒng)單元內(nèi)部設置有公文辦理模塊、在辦狀態(tài)模塊、公文代辦模塊、公文查詢模塊；

公文辦理模塊通過公文辦理模塊能完成日常公文處理工作；

在辦狀態(tài)模塊通過該模塊能準確查詢公文的辦理情況；

公文代辦模塊能讓特殊用戶代表其它用戶辦理公文工作；

公文查詢模塊能讓用戶及時查詢已辦結的公文信息。

進一步，公文流轉子系統(tǒng)包含有：公文處理模塊、公文代辦模塊、公文查詢模塊；

公文處理模塊將實現(xiàn)13種公文的收文和發(fā)文工作，子模塊劃分為：發(fā)文擬辦、待收公文、待辦公文和待閱公文；

公文代辦模塊是實際工作中偶爾會遇到相關負責人員出差或因某些原因暫時離開崗位的情況，所以本系統(tǒng)還設置了公文代辦模塊，如，能夠讓臨時離開崗位的用戶將其公文處理的職責臨時指派給其他用戶，請其他用戶代為處理一段時間內(nèi)的公文，以提高工作效率，同時，用戶還可以隨時查詢他人為其代辦的工作情況；

公文查詢模塊分為兩類：公文的在辦狀態(tài)查詢和公文的歷史信息查詢；

在辦狀態(tài)查詢是指對目前正在流轉的公文工作進行查詢，以幫助用戶快速的找到相應的公文進行跟蹤和辦理；歷史信息查詢是指對已經(jīng)流轉完畢的公文進行查詢的閱覽，類似于歷史檔案的查詢，方便用戶獲取已經(jīng)存在的知識和經(jīng)驗，也為工作考核提供一定的數(shù)據(jù)依據(jù)。

本發(fā)明的優(yōu)點在于，整合整個校園的數(shù)據(jù)和應用，并將它們在一個統(tǒng)一的視圖中進行展現(xiàn)是一個復雜的任務。大量的不一致性不僅僅體現(xiàn)在校園各個系統(tǒng)的技術、數(shù)據(jù)結構和應用功能上，而且在整體的校園信息化體系結構上也存在著基本的差距。有一些集成需求是面向數(shù)據(jù)的，尤其是那些對大數(shù)據(jù)量的需求。還有一些其它的集成項目是基于事件驅動的體系架構(eda)或者面向服務的體系架構(soa)，如異步或同步的集成，設計新穎，是一項很好的設計方案，很有市場推廣前景。

附圖說明

下面結合附圖和具體實施方式來詳細說明本發(fā)明：

圖1是本發(fā)明公文系統(tǒng)軟件架構圖

圖2是本發(fā)明部署結構圖；

圖3是本發(fā)明公文交換總控服務器圖；

圖4是本發(fā)明區(qū)級公文緩存及備份模塊圖；

圖5是本發(fā)明政務數(shù)據(jù)交換平臺應用模圖；

具體實施方式

為了使本發(fā)明實現(xiàn)的技術手段、創(chuàng)作特征、達成目的與功效易于明白了解，下面結合圖示與具體實施例，進一步闡述本發(fā)明。

如圖1、圖2、圖3、圖4所示，基于工作流的數(shù)據(jù)集成系統(tǒng)，該系統(tǒng)包括同步接口單元、模塊配置單元、發(fā)布同步單元、信息系統(tǒng)單元；

對數(shù)據(jù)集成，eai集成架構中的點到點架構雖然可以很好地將數(shù)據(jù)從一數(shù)據(jù)源轉換到另一源，但是每種點到點的構架方法都只是一種特例化的方法，而當數(shù)據(jù)源數(shù)目巨大時，很難以支持新的數(shù)據(jù)源加入，而etl指的是從異構的數(shù)據(jù)源抽取數(shù)據(jù)并進行轉換最后裝載到數(shù)據(jù)倉庫，針對etl概念，vassiliadis等人提出了一種過程模型，該etl過程模型從不同的數(shù)據(jù)源抽取數(shù)據(jù)然后經(jīng)過轉換最終裝載入目標數(shù)據(jù)庫中，相對于數(shù)據(jù)倉庫而言，數(shù)據(jù)集成領域的etl有其自身的一些特點，如數(shù)據(jù)差異性更大，不僅是結構化的數(shù)據(jù)，可能還涉及到半結構化數(shù)據(jù)和非結構化數(shù)據(jù)；同時數(shù)據(jù)抽取，轉換和加載等操作往往在不同的地方，需要遠距離傳輸，考慮到性能需求需要盡量減小網(wǎng)絡開銷，因此，可以通過對etl的擴展和修改以解決金融領域數(shù)據(jù)集成的問題；

經(jīng)過總體架構設計、集成開發(fā)、部署運行直至項目圓滿完成的一個流程，此流程作為實施人員進行高校數(shù)據(jù)集成時的指導，具體步驟是：

(1)搜集數(shù)據(jù)集成需求，并進行需求分析，整理成需求文檔，以便成為項目實施的基礎，因此需求分析是整個數(shù)據(jù)集成項目的關鍵；

(2)確定數(shù)據(jù)集成總體框架，對整理出的需求，構建數(shù)據(jù)集成的總體架構，以集成中心庫為中心，實現(xiàn)與各業(yè)務系統(tǒng)數(shù)據(jù)的交互；

(3)數(shù)據(jù)集成平臺的安裝：包括集成工具的安裝，數(shù)據(jù)庫的安裝；

(4)集成開發(fā)：根據(jù)需求和總體架構，利用集成工具，實施數(shù)據(jù)集成中實際業(yè)務需求的項目設計；

(5)部署運行：將實施完成的項目部署到服務器上，并進行相應的配置：

信息系統(tǒng)單元包含有公文交換總控模塊、公文信息緩存及備份模塊、公文流轉子系統(tǒng)：

公文交換總控模塊為各公文流轉子系統(tǒng)提供了交換請求接口，一旦交換中心接受到交換請求后，便根據(jù)請求的實際配置情況，主動抓取需要交換的公文數(shù)據(jù)進行區(qū)層面的保存及整理，隨后再將必要的數(shù)據(jù)主動推送到目標部門服務器，如果目標部門尚未配備公文服務器，則自動推送到區(qū)公用公文流轉子系統(tǒng)中，同時，交換中心還將適當?shù)挠|發(fā)各類消息提醒機制，主動提醒相關人員進行及時處理；

公文信息緩存及備份模塊該模塊將通過一定的效驗機制，緩存已經(jīng)交換過的公文格式、工作流程等方面的信息，從軟件設計上避免相關部門每次都交換此類信息而造成的性能低下等情況的發(fā)生，同時，還將對已交換數(shù)據(jù)做統(tǒng)一的備份和整理，保證某一部門的故障不會影響到其他部門系統(tǒng)的正常使用，保證工作的連續(xù)性。

進一步，同步接口單元包括了字段的轉換、清洗、拼接等方式，在一個數(shù)據(jù)集成任務中，oracledataintegrator的聲明設計是在稱為“接口(interface)”的里面使用關系圖(relationalparadigm)的形式去聲明這些規(guī)則的，數(shù)據(jù)源就人員基本信息表，目標就是教務系統(tǒng)系統(tǒng)，轉換就是基本信息表和單位表單之間的連接，以及每個單位的信息聚合，采用聲明設計，我們只需要把重點放在真正需要關心的地方，那就是信息系統(tǒng)的集成任務的規(guī)則，而不是集成過程的底層技術方面。

進一步，模塊配置單元在odi執(zhí)行的數(shù)據(jù)同步過程中，需要執(zhí)行很多個步驟，以完成整個的抽取、轉化功能，這就要使用到odi的知識模塊來完成這一系列的任務，km(knowledgemodules：知識模塊)在odi中是一組代碼模板，在集成過程中，每一個km對應一個特定任務，整個數(shù)據(jù)集成過程通過選擇若干個km代碼模板生成執(zhí)行代碼而完成集成工作；

km具有抽象性和可重用性，它是對集成過程規(guī)則和過程的描述，是對邏輯任務的抽象，而與具體的物理對象(如數(shù)據(jù)表、物理路徑、列等)無關，在集成時，用戶通過調(diào)用這些規(guī)則和過程，將接口、模型、包中存儲的元數(shù)據(jù)信息(具體的數(shù)據(jù)庫連接、映射關系等)作為參數(shù)注入到km中，因此km類似于一個抽象接口，與具體的業(yè)務對象分離開來，從而使得一個km能夠被多個集成項目可用，因此km是對數(shù)據(jù)集成過程和規(guī)則的高度抽象和總結，通過開發(fā)一整套的km庫可以極大的降低數(shù)據(jù)集成的復雜度；

odi平臺為不同的集成場景和過程準備了多個km，用戶可以通過調(diào)用這些km完成不同的集成需求；另外km也允許用戶自己擴展、重寫，當已有km模板無法滿足集成需求時，可以通過自定義編寫km而完成特殊場景下的個性化需求；

odi根據(jù)集成過程和功能的不同將km分為以下幾大類：rkm(reversekm)、ck(checkkm)、lkm(loadkm)、ikm(integretionkm)、jkm(journalizingkm)、skm(servicekm),每一類km完成特定類功能。如下表1所示。

表1odi系統(tǒng)km包類型

下面我們就以系統(tǒng)中具體的ikm包來分析odi知識模塊的工作過程，ikm的作用是將轉換后的最終數(shù)據(jù)加載至目標中，ikm在使用前在確保所有數(shù)據(jù)都事先通過lkm加載到了臨時區(qū)域，ikm直接從臨時區(qū)域中獲取數(shù)據(jù)。ikm根據(jù)臨時區(qū)域位置的不同分為兩種類型。第一種類型為臨時區(qū)域在目標上的ikm，另一類為臨時區(qū)域不在目標端上，其處理過程為：首先在接口中根據(jù)實際場景選擇ikm類型，其中源是臨時區(qū)域的c$表，經(jīng)過轉化生成結果集，結果集存放在i$表中，再由i$表合并到目標表當中，如果加入ckm，則合并過程中不符合規(guī)則的數(shù)據(jù)通過ckm放到e$表當中。

首先ikm包需要在源數(shù)據(jù)庫中間建立一個臨時表，即存儲人員基本信息的臨時表，用于加載臨時數(shù)據(jù)。

在ikm創(chuàng)建完臨時數(shù)據(jù)后，就從源表人員基本信息表中讀取業(yè)務信息，插入到上一步所建立的臨時表中。

在進行與目標表數(shù)據(jù)進行一致性檢測的時候，需要同時標記需要更新的數(shù)據(jù)行。下面的語句為標記需要更新的臨時數(shù)據(jù)的sql語句。通過下面的語句，就可以搜索出哪些人員基本信息數(shù)據(jù)需要更新，方便隨后的步驟處理。

通過對信息系統(tǒng)和教務系統(tǒng)的人員基本信息數(shù)據(jù)進行比對，經(jīng)過標記需要處理的所有的數(shù)據(jù)后，odi就通過以下的語句向目標系統(tǒng)的數(shù)據(jù)庫提交更改臨時數(shù)據(jù)，準備需要集成的數(shù)據(jù)信息。

經(jīng)過上面的所有的處理之后，odi系統(tǒng)已經(jīng)在臨時表空間中表明了需要更新、插入的人員繼續(xù)信息，此時就需要將這些變換向目標表即教務系統(tǒng)更新信息，以完成整個數(shù)據(jù)集成工作。

進一步，發(fā)布同步單元信息是系統(tǒng)中變化數(shù)據(jù)的捕獲使用的是一個發(fā)布和訂閱模型，一個被系統(tǒng)識別的訂閱者—比如是信息系統(tǒng)到教務系統(tǒng)的一個集成過程—訂閱那些發(fā)生在信息系統(tǒng)中數(shù)據(jù)存儲的變更，在人事管理系統(tǒng)數(shù)據(jù)存儲中的數(shù)據(jù)變化能夠被數(shù)據(jù)集成系統(tǒng)的cdc架構捕獲并發(fā)布給訂閱者，并且這個過程是在任何時間都能夠獲得被跟蹤的變更，進而處理這些事件；

開發(fā)完接口，配置好系統(tǒng)執(zhí)行的知識模塊后，我們將接口拖入到開發(fā)包中，讓數(shù)據(jù)從數(shù)據(jù)源頭流入到目標數(shù)據(jù)庫中，經(jīng)過編譯后，就可以發(fā)布運行；

odi的實時同步和定時同步是odi集成過程的計劃執(zhí)行的方式，不管是全量還是增量都可以實現(xiàn)近實時同步，odi計劃的設置組合很多，如果要達到近實時同步，只需要在執(zhí)行那里設定啟動時，執(zhí)行循環(huán)那里設定多次，重復間隔設定你需要的時間，但是增量的實時同步的性能在大多數(shù)情況下是優(yōu)于全量的，原因是它本身已經(jīng)縮短了執(zhí)行時間，在odi系統(tǒng)中時間的設定可以設定到秒級。

在開發(fā)需要注意的問題：不管是增量，還是全量，都需要充分理解執(zhí)行計劃的設定。如果是多用戶訂閱，數(shù)據(jù)在沒有訂戶消費的情況下，不要提前將數(shù)據(jù)分發(fā)給訂戶，否則會造成臨時區(qū)域數(shù)據(jù)大量積壓，甚至超過原表的記錄。

進一步，信息系統(tǒng)單元內(nèi)部設置有公文辦理模塊、在辦狀態(tài)模塊、公文代辦模塊、公文查詢模塊；

公文辦理模塊通過公文辦理模塊能完成日常公文處理工作；

在辦狀態(tài)模塊通過該模塊能準確查詢公文的辦理情況；

公文代辦模塊能讓特殊用戶代表其它用戶辦理公文工作；

公文查詢模塊能讓用戶及時查詢已辦結的公文信息。

實現(xiàn)工作流功能，靈活的定義各類工作流程信息，便捷地進行事后調(diào)整，實現(xiàn)各類公文格式管理功能，利用所見即所得的方式讓用戶能夠方便的設置出符合國家和地方標準的公文格式，規(guī)范公文的處理、閱覽和打印，實現(xiàn)電子簽名功能，能夠在線顯示領導的手寫簽名，并進行加密控制，建立區(qū)級公文交換總控平臺，以保證各部門之間的信息同步、公文交換、消息提醒功能，同時提供緩存池，保證系統(tǒng)的高效運行，采用分層模式開發(fā)，與區(qū)認證中心、消息中心關聯(lián)，充分利用已有的公共服務組件平臺，調(diào)用已有接口，降低開發(fā)成本，優(yōu)化辦公系統(tǒng)框架，提高響應速度、改善用戶體驗、提高可用性，實現(xiàn)辦公系統(tǒng)及公文流轉與交換系統(tǒng)標準的數(shù)據(jù)接口，為日后第三方系統(tǒng)(如：檔案歸檔系統(tǒng)、信息公開系統(tǒng)等)的數(shù)據(jù)共享打下伏筆。

文交換過程將統(tǒng)一由區(qū)交換中心控制，所有交換數(shù)據(jù)都將在流經(jīng)交換中心后被主動推送至目標部門，以達到統(tǒng)一管理、統(tǒng)一備份、統(tǒng)一配置等目的。

進一步，公文流轉子系統(tǒng)包含有：公文處理模塊、公文代辦模塊、公文 查詢模塊；

公文處理模塊將實現(xiàn)13種公文的收文和發(fā)文工作，子模塊劃分為：發(fā)文擬辦、待收公文、待辦公文和待閱公文；

公文代辦模塊是實際工作中偶爾會遇到相關負責人員出差或因某些原因暫時離開崗位的情況，所以本系統(tǒng)還設置了公文代辦模塊，如，能夠讓臨時離開崗位的用戶將其公文處理的職責臨時指派給其他用戶，請其他用戶代為處理一段時間內(nèi)的公文，以提高工作效率，同時，用戶還可以隨時查詢他人為其代辦的工作情況；

公文查詢模塊分為兩類：公文的在辦狀態(tài)查詢和公文的歷史信息查詢；

在辦狀態(tài)查詢是指對目前正在流轉的公文工作進行查詢，以幫助用戶快速的找到相應的公文進行跟蹤和辦理；歷史信息查詢是指對已經(jīng)流轉完畢的公文進行查詢的閱覽，類似于歷史檔案的查詢，方便用戶獲取已經(jīng)存在的知識和經(jīng)驗，也為工作考核提供一定的數(shù)據(jù)依據(jù)。

政務數(shù)據(jù)交換平臺應用模型：

按照國家政務信息資源交換體系的要求，交換域內(nèi)交換平臺應用模型的結構包括交換前置系統(tǒng)、中心交換系統(tǒng)、交換網(wǎng)絡、共享信息庫、應用服務器、政務網(wǎng)絡，如圖5所示。交換平臺應用模型可以支持部門業(yè)務信息通過交換前置系統(tǒng)與其它部門業(yè)務信息之間的交換，可以支持部門業(yè)務信息通過交換前置系統(tǒng)與共享信息庫之間的交換，可以支持應用終端對共享信息庫的授權訪問。

調(diào)用應用系統(tǒng)資源的方法：

政務系統(tǒng)調(diào)用應用系統(tǒng)資源時，要求各應用系統(tǒng)按照信資源整合標準開發(fā)相對應的接口，通過調(diào)用各應用系統(tǒng)接口，將調(diào)用的資源信息組織成js的json字符形式將信息生成到辦公系統(tǒng)中進行處理。根據(jù)json字符組織形式解析json字符串，然后在相應頁面上顯示效果。

ajax技術在政務辦公系統(tǒng)中的應用

使用具有異步交互能力的ajax技術能夠提高站點的靈活性和性能，本系統(tǒng)在多個應用模塊中使用了ajax技術，使得客戶端與服務器的通信能夠異步進行，從而提高了用戶的使用體驗和系統(tǒng)的性能。該技術在本系統(tǒng)中主要應 用在如下幾個方面:

(1)數(shù)據(jù)校驗

在輸入表單內(nèi)容時，通常需要確保數(shù)據(jù)的唯一性。傳統(tǒng)做法是在頁面上設置校驗按鈕。用戶點擊之后，彈出一個校驗窗口；或者等表單提交到服務器端，由服務器判斷后在返回相應的校驗信息。前者，window.open操作本來就是比較耗費資源的，通常由window.showmodaldialog代替，即使這樣也要彈出一個校驗窗口；后者，需要把整個頁面提交到服務器并由服務器判斷校驗，這個過程不僅時間長，而且加重了服務器的負擔。若采用ajax技術，那么這個校驗請求完全可以由xmlhttprequest對象發(fā)出，通過異步方式將參數(shù)直接提交到服務器，由window.alert將服務器返回的校驗信息顯示出來，整個過程不需要彈出新窗口，也不需要將整個頁面提交到服務器，提高效率的同時，又不加重服務器負擔。

在系統(tǒng)開發(fā)中數(shù)據(jù)有效性驗證是必須的，數(shù)據(jù)的驗證的含義有兩方面，一是數(shù)據(jù)格式正確性驗證，另外一種是數(shù)據(jù)數(shù)值驗證。數(shù)據(jù)格式的驗證一般是在客戶端進行，以減少網(wǎng)絡數(shù)據(jù)傳輸和服務器端的負擔，而數(shù)據(jù)數(shù)值的驗證則需要在服務端進行。在使用ajax技術進行數(shù)據(jù)驗證時，應該確保數(shù)據(jù)格式驗證要優(yōu)先于數(shù)據(jù)數(shù)值驗證。在用戶端，用戶在表單文本域相應文字輸入完成后，即進行校驗，格式校驗在客戶端完成，否則就發(fā)出ajax異步請求在服務端進行數(shù)值校驗，用戶繼續(xù)其它操作，在服務器返回結果時就能看到輸入數(shù)值是否合法的提示，對于不合法的輸入用戶可以進行更正，利用數(shù)據(jù)驗證功能增強了系統(tǒng)的交互性能，避免了用戶的重復輸入，減少了重復刷新頁面給服務器帶來的負擔。

(2)數(shù)據(jù)動態(tài)加載

本系統(tǒng)涉及的政務數(shù)據(jù)量大，而菜單結構又較為復雜，菜單級別較多、每一級又含有上百個項目，如果用戶不對菜單進行操作或只對菜單中的一部分進行操作，則讀取的數(shù)據(jù)中有一部分會成為冗余數(shù)據(jù)而浪費用戶的資源，影響用戶體驗。

為了提高系統(tǒng)的數(shù)據(jù)加載速度，本系統(tǒng)使用ajax的樹形動態(tài)技術加載數(shù)據(jù)。以樹形動態(tài)加載文件需要用到兩個表：文件信息表和節(jié)點信息表。其中 文件信息表由文件的編號、名稱、描述、屬性、路徑和節(jié)點編號等字段組成；節(jié)點信息表用來記錄各個節(jié)點的變化，由節(jié)點的編號、描述、層次、父節(jié)點編號和子節(jié)點數(shù)量構成，文件信息表和節(jié)點信息表通過節(jié)點編號字段進行聯(lián)系。

系統(tǒng)管理者可根據(jù)需要設置文件節(jié)點編號，形成樹形結構，方便用戶查看。頁面首次加載時只加載根目錄數(shù)據(jù)和查看文件的url，如果一個根節(jié)點下有子節(jié)點，則在文件名稱前添加相關圖標，并給圖標指定一個id，同時對該節(jié)點創(chuàng)建一個onclick事件，點擊事件發(fā)生時系統(tǒng)將調(diào)用js的相關函數(shù)。如果子節(jié)點數(shù)據(jù)己經(jīng)顯示則隱藏并改變提示圖標，否則系統(tǒng)首先判斷是否己加載子節(jié)點數(shù)據(jù)，如果沒有則加載相應的子節(jié)點。

利用ajax技術和樹型結構動態(tài)加載文件信息時，只須對用戶所需要的節(jié)點內(nèi)容進行更新或加載，避免了一次加載所有數(shù)據(jù)所帶來的性能弊端，減少了數(shù)據(jù)冗余和數(shù)據(jù)流量、減輕了服務器負擔、節(jié)省了網(wǎng)絡帶寬，使系統(tǒng)響應速度更快。

在初始化頁面，只讀出第一級的所有數(shù)據(jù)并顯示，在用戶操作一級菜單其中一項時，會通過ajax向后臺請求當前一級項目所屬的二級子菜單的所有數(shù)據(jù)，如果再繼續(xù)請求已經(jīng)呈現(xiàn)的二級菜單中的一項時，再向后面請求所操作二級菜單項對應的所有三級菜單的所有數(shù)據(jù)，以此類推。簡而言之，就是“用什么取什么、用多少取多少”，杜絕數(shù)據(jù)的冗余和浪費，減少數(shù)據(jù)下載總量，而且更新頁面時不用重載全部內(nèi)容，只更新需要更新的那部分即可，相對于后臺處理并重載的方式縮短了用戶等待時間，也把對資源的浪費降到最低。在數(shù)據(jù)的加載同時，由于ajax技術的異步性特點使得用戶仍然可以繼續(xù)其他頁面的操作，用戶的使用體驗得到了很大的提升。

(3)多階段下載模式

下載速度是web應用系統(tǒng)面臨的巨大難題。隨著高新技術的不斷發(fā)展，網(wǎng)頁同樣包含了更多的多媒體信息、圖片以及更加豐富的內(nèi)容，導致下載速度越來越慢，影響用戶體驗。而ajax可以彌補這方面的不足

多階段下載(multi-stagedownload)是一個載入頁面的ajax模式，它可以實現(xiàn)不再隨機下載頁面內(nèi)容，而是由開發(fā)人員決定下載的時間、順序以 及內(nèi)容。具體來說，就是首先向用戶顯示最關心的內(nèi)容，然后再開始下載其它組件。如果用戶在所有組件下載完成之前離開頁面，則放棄后續(xù)下載；如果用戶在該頁面停留的時間較長，則在后臺載入其他功能，以便用戶需要時可以直接使用，縮短應用系統(tǒng)的響應時間。

(4)失效處理模式

傳統(tǒng)的web應用系統(tǒng)中經(jīng)常遇到服務器出錯的情況，一般來說，管理員不會提出額外的解決意見，僅根據(jù)頁面返回的狀態(tài)提示錯誤內(nèi)容大致分析原因，提交工作記錄，而用戶無法得到及時有效的解決方案。

以上顯示和描述了本發(fā)明的基本原理、主要特征和本發(fā)明的優(yōu)點。本行業(yè)的技術人員應該了解，本發(fā)明不受上述實施例的限制，上述實施例和說明書中描述的只是說明本發(fā)明的原理，在不脫離本發(fā)明精神和范圍的前提下本發(fā)明還會有各種變化和改進，這些變化和改進都落入要求保護的本發(fā)明范圍內(nèi)。本發(fā)明要求保護范圍由所附的權利要求書及其等同物界定。