【正文】 視圖 (View)： 代表用戶交互界面，對于 Web 應(yīng)用來說， 最常見的是 HTML 界面，但有可能為 XHTML、 XML、 Applet 等其他 視圖 形式 。 SpringAOP 是基于字節(jié)碼 技術(shù)和 Java 動(dòng)態(tài)代理技術(shù)實(shí)現(xiàn)的 AOP 框架，比 AspectJ簡單易用，是 Spring Framework 的一個(gè)組成部分。 目前比較 具有代表性的 AOP 實(shí)現(xiàn)有： AspectJ、 Spring。 AOP 使得我們可以從一個(gè)更高的抽象概念來理解系統(tǒng)，這對于大型系統(tǒng)的開發(fā)非常有意義。 AOP框架 AOP 是“ Aspect Oriented Programming”的縮寫，中文翻譯為“面向方 /切 面編程” 。 SpringIoC 是一個(gè)開源的 IoC 框架 ， 使用基本的 JavaBeans 來管理對象 ，相比 EJB容器具有簡單、可測試性、松耦合性等特點(diǎn) 。 系統(tǒng) 一但 引入實(shí)現(xiàn)了 IoC 模式的容器，就可以它用來管理對象的生命周期、依賴關(guān)系等，從而使得應(yīng)用程序的配置和依賴性規(guī)范與實(shí)際的應(yīng)用程序代碼分開 ，提高了系統(tǒng)的可 重用性及 可 維護(hù)性 ，并降低了代碼的耦合程度 。 IoC框架 IoC 是“ Inversion of Control”的縮寫，中文翻譯為“控制反轉(zhuǎn)” 或者“依賴注入” 。 “輕量級 J2EE”模仿了 J2EE 的架構(gòu)，在保留了 J2EE 可擴(kuò)展性、可維護(hù)性等優(yōu)點(diǎn)的同時(shí)，它提供了更高效的開發(fā)平臺，降低了開發(fā)成本，成為一種更實(shí)用的信息化平臺。 [9] 框架技術(shù) 介紹 J2EE 雖然有著嚴(yán)謹(jǐn)?shù)恼w架構(gòu)、全方位的組件設(shè)計(jì)、優(yōu)秀的分布式平臺，但是 它 17 17 的 EJB 組件模型 卻 同時(shí)也 帶來了開發(fā)、部署成本高、開發(fā)者學(xué)習(xí)曲線陡峭等限制 ，使得小型企業(yè)很難在實(shí)際應(yīng)用中使用 。 Java IDL 使用 CORBA 命名 (CosNaming)服務(wù)定位遠(yuǎn)程對象。 Java IDL 使用 CORBA 命名 (CosNaming)服務(wù)定位遠(yuǎn)程對象，包括兩種命名服務(wù)，一種是臨時(shí)命名服務(wù) (通過 tnameserv 工具提供 )，另一種是持久命名服務(wù) (通過 orbd 工具提供 )。J2SE 以及 J2SE 平臺的 Java IDL 遵循 CORBA 規(guī)范。 [9] JavaIDL Java IDL 是 J2SE 平臺的一部分。 RMIIIOP 提供和其它用各種語言實(shí)現(xiàn)的 CORBA 對象之間的互操作性，這通常要求所有的遠(yuǎn)程接口最 初都是以 Java RMI 接口的形式定義的 (或者在一些很小的編程限制下直接編寫 IDL 接口文件 )。使用 CosNaming 命名服務(wù)需要訪問 Java 的 Orb，所以注冊和查找服務(wù)器對象時(shí)， RMIIIOP 要比 RMI/JRMP 復(fù)雜一些。 RMIIIOP 還支持在應(yīng)用程序組件只見的按引用 (by reference)或按值 (by value)方式傳遞任何類型的 Java 對象，這為分布式應(yīng)用程序的開發(fā)帶來了極大的方便性。 使用 RMIIIOP，可以不用學(xué)習(xí) CORBA IDL，就能夠編寫 Java 平臺下的 CORBA應(yīng)用程序。和 CORBA 一樣，RMIIIOP 基于由 OMG 中許許多多廠商和用戶參與制定的開 放標(biāo)準(zhǔn)。 [9] RMIIIOP 使用 IIOP 協(xié)議的 RMI 一般稱為 RMI— IIOP(Java RMI over IIOP)。 RMI/JRMP 還支持分布式垃圾收集 (Distributed Garbage Collection， DGC)特性。 RMI 框架提供了訪問 RMI 注冊表的簡單方法： JRMP 服務(wù)器應(yīng)用程序可以使用 ()方法注冊遠(yuǎn)程服務(wù)對象到 RMI注冊表： JRMP客戶機(jī)可以使用 ()方法查找服務(wù)器對象，得到所需服務(wù)接口。 建立服務(wù)器對象 之后，就可以 分 布這個(gè)對象，即讓分布式 客戶機(jī)能夠訪問 RMI服務(wù)器。 JRMP 使用的存根 (Stub)用 JRMP 協(xié) 議 與 服 務(wù) 器 框 架 通 信 。使用RMI/JRMP 可以通過 HTTP 服務(wù)器信 通，這需要在發(fā)送消 息時(shí)加上一個(gè)HTTPostHeader 標(biāo)識符，在接收消息時(shí)加上一個(gè) HTTPResponseHeader 標(biāo)識符。 Java RMI(RMI/JRMP) 使用 JRMP 的 RMI 一般稱為 RMI/JRMP，或簡稱 Java RMI。Sun 的 J2SE 平臺還包含 ORB 軟件和 Java IDL API，它本質(zhì)上是 CORBA 的 Java 語言映射的實(shí)現(xiàn)。 RMI 支持兩種引用層消息協(xié)議 — JRMP 和 IIOP。 Java RMI(Java Remote Method Invocation， Java 遠(yuǎn)程方法調(diào)用 )是 Java 平臺的分布式對象通信模型 。 EJB 全稱 Enterpise JavaBean，企業(yè) Java 組件 ，是 J2EE 的 組件模型 。 COM 全稱 Component Object Model，組件對象模型 。 [9] CORBA 全稱 Common Object Request Broker Architecture，公共對象請求代理體系結(jié)構(gòu)，是由 OMG(Object Management Group，對象管理 組織 )組織制訂的一種標(biāo)準(zhǔn)的面向?qū)ο髴?yīng)用程序體系規(guī)范。 Java 分布式對象技術(shù)簡介 分布式對象技術(shù)是分布式計(jì)算技術(shù)和面向?qū)ο笏枷胂嘟Y(jié)合的一種技術(shù)，系統(tǒng)中的對象以分布式的方式相互作用，構(gòu)成一個(gè)完整的面向?qū)ο蟮姆植际较到y(tǒng)。 一般包括了企業(yè)基礎(chǔ)建設(shè)系統(tǒng)如企業(yè)資源計(jì)劃 (ERP)、 15 15 大型機(jī)事務(wù)處理、數(shù)據(jù)庫系統(tǒng)以其他遺留信息系統(tǒng)。 服務(wù)器端業(yè)務(wù)邏輯層是整個(gè)系統(tǒng)的功能邏輯核心 ，專注于企業(yè)的業(yè)務(wù)處理。 EJB 技術(shù)是服務(wù)器端的組件，主要用于處理分布式應(yīng)用程序。 服務(wù)器端表現(xiàn)層將服務(wù)器端的業(yè)務(wù) 處理 和結(jié)果 數(shù)據(jù)返回分離開來，降低了系統(tǒng)業(yè)務(wù)和表現(xiàn)之間的耦合性 ，提高了系統(tǒng)的可重用性及可維護(hù)性 。 其中 Servlet 是一種實(shí)現(xiàn)了多線程請求響應(yīng)模型的技術(shù)，克服了傳統(tǒng) CGI(Common Gateway Interface)程序效率低的問題 ； JSP 是基于 Servlet 的便于編寫網(wǎng)頁的顯示層技術(shù)，它會被 JSP 容器編譯為Servlet 的 class 文件 ， Servlet 和 JSP 都需要有 Web 容器支持 。 服務(wù)器端表現(xiàn)層指的是將業(yè)務(wù)邏輯返回的數(shù)據(jù)通過某種格式傳遞給客戶端表現(xiàn)層。 [23] 客戶端表現(xiàn)層是用來 把客戶請求的信息展現(xiàn)到客戶面前，主要有如下幾種技術(shù)：純 HTML 技術(shù)、 Java Applet、 一般的 Java 程序 、其他的 J2EE 客戶端如移動(dòng)設(shè)備 。 J2EE提供了一系列的組件、架構(gòu)以及相關(guān)技術(shù)，來為企業(yè)提供一 個(gè)高度可重用的開發(fā)環(huán)境。 RUNA WFE 的運(yùn)行時(shí)效果如圖 16。然而它最大的缺點(diǎn)就是在對 jBPM 進(jìn)行封裝之后，產(chǎn)生了自己的 IDE 插件、流程定義語言，比較封閉，不適合與現(xiàn)有項(xiàng)目的集成。當(dāng)然，我們也可以看到， Enhydra Shark 由于其嚴(yán)格遵循 WfMC 規(guī)范的流程定義體系，也使得它在報(bào)告中獲得較高的評價(jià)。 根據(jù)這份報(bào)告，可以看出在眾 多的開源工作流系統(tǒng)中， jBPM 項(xiàng)目在各項(xiàng)評比中都占據(jù)優(yōu)勢。 12 12 圖 15 開源工作流管理組件調(diào)查報(bào)告 [14] 如圖 15 是選自 Optaros 公司 (美國的開源軟件研究及解決方案咨詢公司 )2021 年底發(fā)布 的調(diào)查報(bào)告“ Realize the Benefits of Open Source”。這些產(chǎn)品都是成熟的商業(yè)產(chǎn)品，需要購買其許可證 進(jìn)行使用 ，而且 使用比較復(fù)雜，需要一定的培訓(xùn)時(shí)間。 6. 工作流模型的分析和仿真工具： 目前 ， 越來越多的用戶要求能夠?qū)δＰ瓦M(jìn)行評估和性能測試 ， 仿真和性能監(jiān)控工具的引入 ， 將不可避免地成為新一代工作流產(chǎn)品的發(fā)展趨勢。當(dāng)工作流非正常中斷時(shí)，工作流產(chǎn)品也無法保證能夠正確地恢復(fù)數(shù)據(jù)。 10 10 5. 工作流事務(wù)管理： 目前大部分工作流產(chǎn)品不支持事務(wù)的概念，甚至不能保證活動(dòng)的執(zhí)行是一個(gè) ACID (Atomicity、 Consistency、 Isolation、 Durability)的事務(wù)。 4. 工作流互操作：互操作的研究主要包括兩方面：工作流模型的互操作和工作流系統(tǒng)的互操作。多 Agent、移動(dòng) Agent 技術(shù)為工作流管理的移動(dòng)計(jì)算提供了強(qiáng)有力的支持。目前的產(chǎn)品還僅限于允許在瀏覽器中初始化和控制工作流。以下主要討論工作流實(shí)現(xiàn)技術(shù)的發(fā)展趨勢。 在工作流技術(shù)應(yīng)用日益得到重視的今天，對工作流技術(shù)的研究也正在向更深層次進(jìn)行。 4. 輔助工具缺乏 。 3. 性能問題 。為了保證系統(tǒng)正常運(yùn)行 ， 必須進(jìn)行并發(fā)控制 ， 防止出現(xiàn)“臟數(shù)據(jù)”等現(xiàn)象。 2. 并發(fā)訪問和出現(xiàn)錯(cuò)誤時(shí)缺乏正確和可靠的支持。 在工作流管理系統(tǒng)開發(fā)的早期 ， 由于缺少統(tǒng)一的標(biāo)準(zhǔn) ， 大多數(shù)工作流產(chǎn)品之間互不兼容。但是在以下幾個(gè)方面工作流技術(shù)還存在著一些不足之處，需要進(jìn)行更多的工作。應(yīng)用主要描述用于完成企業(yè)經(jīng)營過程所采用的工具或手段，如采用軟件或決策支持軟件完成某個(gè)具體的企業(yè)業(yè)務(wù)功能。角色或組織實(shí)體決定了參與某個(gè)活動(dòng)的人員或組織單元，它主要描述企業(yè)經(jīng)營過程中參與操作的人員和組織單位。 4. 工作流相關(guān)數(shù)據(jù)：工作流相 關(guān)數(shù)據(jù)的屬性包括數(shù)據(jù)名稱、數(shù)據(jù)類型值等。 3. 轉(zhuǎn)換條件：主要負(fù)責(zé)為過程實(shí)例的推進(jìn)提供導(dǎo)航依據(jù)，主要參數(shù)包流過程條件 (flow condition，過程實(shí)例向前推進(jìn)的條件，也稱前后條件 )、執(zhí)行條件 (execution condition，執(zhí)行某個(gè)活動(dòng)的條件 )和通知條件 (notification condition，通知不同用戶的條件 )。當(dāng)工作流 運(yùn)行在分布的環(huán)境下時(shí)，在活動(dòng)的屬性中還應(yīng)該包括執(zhí)行該活動(dòng)的工作流機(jī)的位置。過程模型反映了企業(yè)中一個(gè)經(jīng)營過程的目的，即這個(gè)過程要實(shí)現(xiàn)的目的和最終要達(dá)到的目標(biāo)。 [7] 8 8 圖 14 過程定義元模型 [7] 如圖 14 是 WfMC 定義的過程元模型。 4. 接口 4(工作流執(zhí)行服務(wù)之間互操作接口 )：為不同的工作流系統(tǒng)之間的互連提供相應(yīng)的標(biāo)準(zhǔn)。工作項(xiàng)的處理、對過程實(shí)例的控制、各種信息的顯示等均通過此接口進(jìn)行傳遞。 參考模型中各接口的功能描述如下： 1. 接口 1(工作流過程定義輸入 /輸出接口 )：用于實(shí)現(xiàn)過程定義工具同工作流執(zhí)行服務(wù)之間的交互，為工作流過程定義信息的交換提供標(biāo)準(zhǔn)的互換格式和API 接口。在這個(gè)參考模型中，對工作流系統(tǒng)的相關(guān)概念給出了詳細(xì)的描述，同時(shí)描述了組成工作流系統(tǒng)的各個(gè)功能模塊的功能，以及各個(gè)功能模塊之間的接口功能定義。 7 7 圖 13 工作流參考 模型 [7] 由于工作流系統(tǒng)的多樣性，為實(shí)現(xiàn)彼此的互連和互操作，有必要為不同工作流系統(tǒng)提供一個(gè)共同的設(shè)計(jì)框架，對工作流系統(tǒng)的結(jié)構(gòu)加以標(biāo)準(zhǔn)化。 WfMC 提出了有關(guān)工作流管理系統(tǒng)的一些規(guī)范。 [6] 工作流管理系統(tǒng) WfMC 給出的工作流管理系統(tǒng)的定義是：工作流管理系統(tǒng)是一個(gè)軟件系統(tǒng)，它完成工作流的定義和管理，并按照在計(jì)算機(jī)中預(yù)定義好的工作流邏輯推進(jìn)工作流實(shí)例的執(zhí)行。 工作項(xiàng) (Work Item)：在過程實(shí)例中等待參與者處理的活動(dòng)實(shí)例。 過程實(shí)例 /活動(dòng)實(shí)例 (Process Instances/Activity Instances)：實(shí)際運(yùn)行中的一個(gè)過程 / 6 6 活動(dòng)。 人工活動(dòng) (Manual Activity)：在業(yè)務(wù)過程的執(zhí)行過程中無需借助計(jì)算機(jī)就能實(shí)現(xiàn)的活動(dòng)。根據(jù) 是否需要人工提供數(shù)據(jù)或完成某些任務(wù)，活動(dòng)可以分為人工活動(dòng)和自動(dòng)活動(dòng)兩類。使用它可以充分利用企業(yè)資源，有效地跟蹤工作過程，提高工作過程定制的速度與質(zhì)量。 工作流管理系統(tǒng) (WfMS)：一種能定義、創(chuàng)建和管理工作流執(zhí)行的系統(tǒng)。業(yè)務(wù)過程的計(jì)算機(jī)形式表示，它定義的是過程運(yùn)行中涉及到的各種參數(shù)：如業(yè)務(wù)過程的開始和終止條件、各個(gè)工作環(huán)節(jié)及相互之間的控制流 動(dòng)與數(shù)據(jù)流動(dòng)關(guān)系等。 [6] 業(yè)務(wù)過程 (BusinessProcess)：是指為了實(shí)現(xiàn)某個(gè)目標(biāo)，在部分或者全部組織機(jī)構(gòu)和人員的參與下，在參與者和組織機(jī)構(gòu)之間進(jìn)行文檔、信息、任務(wù)的傳遞或處理而進(jìn)行的一系列相互關(guān)聯(lián)的活動(dòng)。 使用工作流作為經(jīng)營過程的實(shí)現(xiàn)技術(shù)首先要求工作流系統(tǒng)能夠反映經(jīng)營過程的如下幾個(gè)方面的問題：即業(yè)務(wù)過程是什么 (由哪些活動(dòng)、任務(wù)組成，也就是結(jié)構(gòu)上的定義 )、怎么做 (活動(dòng)間的執(zhí)行條件、規(guī)則以及所交互的信息，也就是控制流與信息流的定義 )、由誰來做 (人或者計(jì)算機(jī)應(yīng)用程序，也就是組織角色的定義 )、做得怎樣 (通過工作流管理系統(tǒng)對執(zhí)行過程 進(jìn)行監(jiān)控 )。這些參數(shù)包括對過程中每一個(gè)步驟的定義、步驟間的執(zhí)行順序、條件以及數(shù)據(jù)流的建立、每一步驟由誰負(fù)責(zé)以及每個(gè)活動(dòng)所需要的應(yīng)用程序。任務(wù)的觸發(fā)順序和觸發(fā)條件用來定義并實(shí)現(xiàn)任務(wù)的觸發(fā)、任務(wù)的同步和信息流(數(shù)據(jù)流 )的傳遞。在工作流中定義了任務(wù)的觸發(fā)順序和觸發(fā)條件。 4 4 工作流的相關(guān)定義 在工作流技術(shù)發(fā)展的過程中，不同的研究者和工作流產(chǎn)品供應(yīng)商從不同的角度給出了工作流的定義，以下給出幾個(gè)具有代表性的定義： 工作流管理聯(lián)盟 (WfMC)給出的工作流定義是：工作流是一類能夠完全或者部分自動(dòng)執(zhí)行的經(jīng)營過程，它根據(jù)一系列過程規(guī)則、文檔、信息或任務(wù)能夠在不同的執(zhí)