信息社會對信息交流方式的要求越來越高，傳統的靜態工作模式已不適應即時獲取信息滿足協同工作的需要。本文以辦公系統為背景，將Java技術、XML技術、工作流技術及消息傳遞中間件技術有機結合，構建了一個動態即時協同工作的信息平臺。該平臺基于XML協同動態工作流驅動和可視化的工作流建模工具(X-Wrokflow)，滿足了用戶可視化流程自定義要求；基于XML的協同消息服務驅動，實現了用戶間在協同辦公平臺內的在線信息交流，實時性好，滿足了人們對信息即時協同的工作需要。以下就有關功能實現問題進行討論。
1 協同動態工作流驅動及X-Workflow的實現
1.1 引擎的結構
　　工作流引擎主要包含下列功能：解釋流程定義；生成過程實例；控制流程實例的創建、激活、掛起和終止等，實現流程活動導航；引導流程活動的進行，包括順序和并行操作期限調度工作流相關數據解釋等；確定需要用戶處理的工作項，提供用戶交互接口；維護工作流控制數據和工作流相關數據，與用戶或應用程序" title="應用程序">應用程序傳遞工作流相關數據；調用外部應用程序和連接工作流相關數據的接口；跟蹤具體流程實例的歷史等。一個工作流引擎^[1]的過程流轉系統可以表示為一個三元組,其中，D表示過程定義，I表示過程實例，M表示過程流轉控制系統。過程實例是過程流轉的主體，它是在系統控制下由過程定義模型復制并添加相應的狀態信息生成的。控制系統控制多個實例、監控和修改實例的狀態。圖1表示過程定義、實例與流轉控制的關系。

1.2 基于XML的公文流轉系統工作流過程模型DT-XPDL
　　工作流模型描述表現形式有兩種：描述性語言和圖形設計工具。前者用語句描述工作流動規則，后者采用結點表示人、設備、應用程序等實體對象，用鏈表示文檔傳遞、請求、指令等。為了方便交互和在不同的模型之間實現轉換，人們提出了稱之為“工作流過程規范語言”的規范描述語言。現有的工作流過程建模語言主要有以下幾類：(1)基于IPO(Input-Process-Output)的語言，如在IBM MQSeries Workflow使用的活動網絡，過程中的每一個基本活動都由輸入(I)、處理(P)、輸出(O)三個部分組成。這類語言按照活動執行順序描述工作流過程。(2)基于對話行為(Speech-Act-based)的方法，有時也叫做語言行為方法。(3)基于約束的建模方法，如由GLANCE 提出的廣義過程結構語法(Generalized Process Structure Grammar)。(4)基于角色建模的過程描述方法，如角色活動圖RAD(Role Activity Diagrams)。(5)基于形式化表示的建模方法，如基于Petri網的建模方法。
　　(1)工作流過程定義語言WPDL
　　1994年WfMC推出的工作流過程定義語言WPDL(Workflow Process Definition Language)是為創建工作流過程模型的輸入、輸出而建立的一種元語言。WPDL的關鍵詞是基于WfMC詞匯表中所定義的術語，術語清晰地描述了元模型中的過程實體。WPDL的實體類型不能再被擴展，但用戶定義的屬性可添加到單個實體類型中，工作流過程定義包括一個或多個工作流過程活動。
　　(2)XML過程定義語言XPDL
　　WfMC支持異構工作流管理系統與產品之間的互操作性。由于Internet與Web的普及和標準化以及XML的良好特點，可利用Internet、Web及XML來解決互操作問題。2001年WfMC發布了一個基于XML描述的工作流過程定義接口規范——XML過程定義語言XPDL(XML Process Definition Language)^[2]。XPDL與WPDL都是基于同一個工作流過程的元模型，只是在XML描述格式基礎上對WPDL進行映射并做了適當的添加和修改。由于XML具有不可比擬的優點，基于XML描述的過程定義語言大大擴展了WfMC在基于B/S結構的應用范圍，因此，XPDL已成為工作流過程模型的主要描述形式。
　　(3)面向公文流轉系統的基于XML的過程定義語言DT-XPDL
　　參考WfMC推出的WPDL/XPDL，結合我國辦公系統中公文流轉業務流程特點，建議采用面向公文流轉系統的基于XML的過程定義語言DT-XPDL (Document Transfer XML-based Process Definition Language)，以實現工作流過程引擎。
1.3 動態工作流引擎的實現
　　(1) 過程實例的狀態
　　過程模型實例^[3]有四個轉換狀態：初始、運轉、暫時、結束。四個狀態在工作流控制系統控制下可相互轉移，如圖2所示由圖可見，對完成的過程實例，將移出工作流運轉系統，以保證完成的實例不再占用系統資源，從而避免了對活動實例處理效率的影響。

　　(2) 實例管理
　　引擎通過輪詢控制狀態的轉換。對于過程實例,引擎用XML的元素對其進行描述。在DOM數的構造中,這些實例處于樹的最底層，相當于葉子結點,引擎通過元素名對它們逐次訪問。當用戶登錄進入系統時，引擎會將待處理元素的信息返回給用戶，如果沒有該用戶要處理的信息，引擎不采取任何行動。當用戶進入系統時，如有用戶要處理的實例，則該實例將進入新的待處理隊列，由用戶發送處理請求，直到實例處理或用戶推出系統，實例將掛在待處理隊列中等待處理。
　　(3) 主動式
　　為實現主動交互和協調，實例運轉時，可通知客戶處理事件，由客戶行為驅動下一步運轉方向和狀態，在運轉中改變工作流程，以實現“動態工作流”。因此必須有某種機制引擎，在需要時主動通知客戶進行下一步處理。由于協作是基于Web的，并使用了XML技術，為了在瀏覽器中解析XML，可利用Applet、Servlet和JSP相結合的方法。服務器的Servlet和瀏覽器端的Applet通過XML在Web上交換信息。當服務器有消息要通知客戶時，Servlet向Applet發送XML格式的信息，Applet通過瀏覽器執行Javascript解析XML，獲得所需信息，以窗口消息方式通知客戶。主動式交互的機制如圖3所示。客戶與服務器的通信信息都是XML格式的信息，這種格式是自定義的，利用XML作為通信格式，不僅易于擴充，在當前基于Web的實現中，還具有易于跨越網絡代理和防火墻的優點。

　　(4) 動態工作流引擎的實現
　　動態工作流引擎負責讀取由可視化流程設計器生成的XML流程定義文件，并對其進行解析和運行。當用戶需要創建流程實例時，流程引擎先創建該流程對應的XML描述文件的副本，作為整個流程運行中的參考，流程引擎的XML解析器負責把設計期的流程和對象轉化為運行期的流程實例和對象，即把基于XML存儲的信息，轉化為基于數據庫存儲的信息。在這個過程中，借助數據持久化技術實現數據庫層的隔離。流程實例創建后將在流程引擎的控制框架下被動運行。流程引擎負責流程的調度、接收用戶端的輸入，根據用戶的輸入和流程規則進行流程分支的選擇，按照條件進行流程的跳轉、暫停、恢復和中斷。
　　流程引擎分為四個包：①engine包。負責讀取流程配置信息，創建和銷毀流程實例，定義流程對象基類、流程監聽接口等。②designtime包。復制解析設計期的XML文件，并分解相應的對象，以方便傳輸到數據庫。③runtime包。負責對運行期對象進行管理，如動態解析流程參與者、動態路由選擇、流程事件監聽、用戶腳本支持等。④organization包。定義了流程運行所需參與者類型，如：員工、角色、部門、小組等，該包以接口的形式存在，以適應工作流系統跨應用系統運行。以下是對其中關鍵的對象原型設計^[4]的討論。
1.4 可視化流程設計器的實現
　　為了更好地使用協同辦公平臺，對工作流系統實現完全圖形化和可視化操作界面是非常有必要的。由于協同辦公平臺是基于Web實現的，為與平臺保持兼容和易于使用，可視化流程設計器的設計應注意以下幾點：(1)必須采用純Web技術實現。(2)支持所見即所得的設計，采用拖拉方式對流程進行設計和修改，隱藏技術細節，讓用戶能更專注于自己關心的流程。(3)能生成標準化的XML流程定義文件。在系統的可視化流程設計中，采用純Web技術進行開發，而不采用任何類似于ActiveX插件、Java Applet等本地化技術，使設計器能更好地兼容各種瀏覽器和操作系統平臺。(4)在支持所見即所得方面，設計器可采用Html+JavaScript+XML的技術進行開發，以完全實現流程元素的動態創建、拖曳、粘接、自動驗證等功能。可視化流程設計的結果是一個標準的XML文檔，它是對所設計流程的一個XPDL描述。該XML文檔將作為流程引擎創建并運行于流程的入口，參與流程運行的全過程；可視化流程設計的另一個結果是一個XML文件，該文件由動態工作流引擎進行解釋并執行。按上述分析和設計，即可實現基于XML的動態工作流的可視化設計器^[5](X-WorkFlow，XWF)，用戶只需按要求生成流程，無需編程。
1.5 流程跟蹤監控的實現
　　流程跟蹤監控是流程引擎的外圍模塊，用于給用戶提供操作接口。流程參與者通過這個接口，可以實時、可視化地對流程的流轉情況進行跟蹤，對處理情況進行查詢。而流程管理者還可以在流程圖上對流程進行管理，包括對參與者的管理、對流程流向的控制以及改變流程狀態等。其功能主要有：經辦流程跟蹤查詢；經辦流程統計；流程超期提醒；所有流程統計；流程監控等。
1.6 可視化流程頁面編輯器的實現
　　可視化流程頁面編輯器^[5-7]是可視化流程設計器的一個輔助設計工具，其作用是讓用戶的可視化設計在流程中能提供需要使用的相關表單界面。其結果將作為流程設計器的相關屬性，在運行時由控制框架調用，并展現給用戶。可視化流程頁面編輯器實質上是一個基于瀏覽器的可視化HTML編輯器，其輸出結果就是一段HTML代碼，其功能有：文件上傳功能；上傳文件類型限定功能；圖文混排功能；所見即所得功能；表格功能；表單及常用控件支持；Word文件轉換功能等。
2 協同消息服務中間件SCMS的實現
2.1 消息傳遞機制
　　SCMS系統負責將信息按照通信協議所定義的消息格式進行打包，然后將打包后的消息放入消息發送隊列，并釋放一個信號。該信號觸發發送線程，使其從消息發送隊列中讀出消息，通過消息通道代理利用傳輸協議和物理連接將消息發送到遠程系統。任一成員系統信息發送，只需直接調用JMS規范提供的應用接口函數^[8]。SCMS是根據消息的目的地址綁定接收對象的，又通過通道代理調用接收對象的接口函數，將消息放入接收對象的消息接收隊列。因此，在發送方完成消息發送的同時，接收方也完成了消息接收。接收方只需直接從自身消息接收隊列中讀出消息、解包，并根據消息的類型進行相應的處理。SCMS的工作模式參照了JMS中所描述的點對點模式和發布/訂閱模式，消息傳送有三種形式：一對一、一對多、多對多。在JMS規范中，一對一采用點對點模式，一對多和多對多采用發布/訂閱模式。
　　點對點傳輸消息建立在消息隊列基礎上，每個客戶端" title="客戶端">客戶端對應一個消息隊列，客戶端發送消息到對方的消息隊列中，從自己的消息隊列讀取消息。隊列將發送給它們的消息一直保留，直到消息被消費或消息到期。發布訂閱模式(Pub/Sub)是客戶將消息提交給某個主題，發布者和訂閱者通常是匿名的，并能動態發布或訂閱消息，Pub/Sub系統必須保證某個主題的所有發布者(Publisher)發布的信息準確無誤地發送到這個主題的所有消息訂閱者(Subscriber)。主題把消息分發給當前的調用者之后就不再保留這些消息。
2.2 點對點模式的具體實現
　　SCMS利用共享內存提供模擬發送隊列和接收隊列，提供核心和應用之間的一個消息傳輸通道，起到對發送消息和接收消息的控制和緩沖作用，如圖4所示。客戶端A對應隊列QA，客戶端B對應隊列QB。客戶端A要發消息給客戶端B，則客戶端A把消息發到客戶端B的隊列QB中，客戶端B再從隊列QB中讀取消息。同樣，客戶端B要發消息給客戶端A，則客戶端B把消息發到客戶端A再的隊列QA中，客戶端A從隊列QA中讀取消息。

3 SCMS基于Web的客戶端實現
　　由于整個協同辦公平臺是基于瀏覽器應用的，但瀏覽器又不直接支持JMS的相關服務，因此在瀏覽器端采用Java Applet技術實現符合JMS規范的無界面消息收發的應用程序，并使用JavaScript腳本對其進行封裝。這樣Web程序就可以用操作普通對象的方式來操作消息對象，使用基于互聯網的消息服務。如圖5所示，瀏覽器端主要由三個對象組成：Message、MessageServer和MessageClient。Message對象是對XML消息對象的一個封裝，以方便JavaScript對消息進行操作，同時它也是MessageClient和MessageServer之間傳遞的標準對象；MessageServer對象主要實現消息轉發的功能，即接收服務器端的消息，并轉發給已注冊的本地窗口，同時接收本地待發送的消息，并發送到服務器端；MessageClient對象負責接收本地服務器轉發的消息，并給應用程序提供相關的接口以進行消息的收發，該對象是瀏覽器端程序直接使用的對象。