【正文】 EEPlat 簡(jiǎn)介 云鶴平臺(tái)（ EEPlat）是元數(shù)據(jù)驅(qū)動(dòng)的 PaaS 應(yīng)用基礎(chǔ)平臺(tái)。提供了完整的元模型體系，實(shí)現(xiàn)了面向業(yè)務(wù)領(lǐng)域的配置編程，可以大幅度得提高生產(chǎn) 率，可幫助用戶(hù)實(shí)現(xiàn)低成本、高質(zhì)量、易擴(kuò)展的信息管理系統(tǒng)。 EEPlat 可以開(kāi)發(fā)的應(yīng)用包括MIS（管理信息系統(tǒng)）、 OA（辦公自動(dòng)化）、 CRM（客戶(hù)關(guān) 系管理）、 HR（人力資源管理）、 ERP（企業(yè)資源計(jì)劃）等。由于 EEPlat 支持多租戶(hù)環(huán)境以及傳統(tǒng)單租戶(hù)環(huán)境，所以 EEPlat 可以部署在幾乎所有的 環(huán)境下： 1. 面向單服務(wù)器環(huán)境（ ），針對(duì) 中小規(guī)模應(yīng)用。 2. 面向集群環(huán)境的（ ），針對(duì)健壯性和穩(wěn)定性要求高的關(guān)鍵應(yīng)用、中大規(guī)模應(yīng)用。 3. 面向大規(guī)模集群、分布式環(huán)境或云計(jì)算環(huán)境（ ），作為云計(jì)算中的 PaaS 平臺(tái)，方便創(chuàng)建 SaaS 應(yīng)用，可運(yùn)行在各種私有云和公共云上面。 基于 EEPlat 的應(yīng)用可以在 , 和 之間進(jìn)行移植，一套應(yīng)用可以運(yùn)行在不同環(huán)境中。 總 Eeplat 特點(diǎn)： 1. 可用：體現(xiàn)在已經(jīng)經(jīng)過(guò)很多項(xiàng)目、公司實(shí)際使用的檢驗(yàn)。 2. 實(shí)用：體現(xiàn)在項(xiàng)目開(kāi)發(fā)過(guò)程中極大提高生產(chǎn)效率、降低開(kāi)發(fā)成本。 3. 易用：以配置代替編程，門(mén)檻降低，業(yè)務(wù)人員可直接參與開(kāi)發(fā)。 4. 靈活： ? 通過(guò)工作流配置，靈活變動(dòng)業(yè)務(wù)流； ? 通過(guò)服務(wù)配置，靈活變動(dòng)程序邏輯和程序流； ? 通過(guò)頁(yè)面配置，靈活變動(dòng)頁(yè)面外觀； ? 通過(guò)業(yè)務(wù)對(duì)象配置，靈活增減業(yè)務(wù)實(shí)體屬性； EEPlat 還沒(méi)有大規(guī)模推廣，只有一些公司在使用，但已經(jīng)顯現(xiàn)出其卓越的開(kāi)發(fā)效率?，F(xiàn)在使用 EEPlat 產(chǎn)品作為基礎(chǔ)開(kāi)發(fā)平臺(tái)的公司有： 1. 北京虎蜥信息技術(shù)有限公司 2. 北京紫楓科技開(kāi)發(fā)有限公司 3. 北京中標(biāo)文通信息技術(shù)有限公司 4. 北京冠軟信息技術(shù)有限責(zé)任公司 5. 北京中源潤(rùn)豐科技有限公司 上 述公司利用 EEPlat 的實(shí)施的項(xiàng)目涉及的行業(yè)有政府、金融、石油、教育、制造等行業(yè)，客戶(hù)包括國(guó)土資源部、國(guó)家海洋局、武警總部、沈陽(yáng)飛機(jī)工業(yè)公司、遼 河油田、松原油田、紹興銀行、民生銀行、學(xué)而思教育等多家知名單位。軟件的生產(chǎn)率根據(jù)項(xiàng)目性質(zhì)的不同可以提升 38 倍，并且人員的要求不高。 EEPlat 平臺(tái)為上述公司降低了人力成本，縮短了開(kāi)發(fā)時(shí)間，擁有了競(jìng)爭(zhēng)上的成本優(yōu)勢(shì)，獲得了比同行更豐厚的利潤(rùn)。 技術(shù)架構(gòu) 總體技術(shù)架構(gòu) 云鶴平臺(tái) (EEPlat)的核 心理念是提供模型驅(qū)動(dòng)、在線聲明式配置的方式完成應(yīng)用的開(kāi)發(fā)。為此， EEPlat 確立 了微內(nèi)核、元模型、插件體系、總線集成的體系結(jié)構(gòu)。為了概念一致性， EEPlat 獨(dú)立實(shí)現(xiàn)了 O/R Mapping 框架， HMVC 界面框架，流程引擎等。系統(tǒng)為 SOA 架構(gòu)，在元模型層面提供了對(duì) WebService 的支持，即平臺(tái)中每個(gè)服務(wù)都是可被調(diào)用的 Restful WebService?？傮w技術(shù)架構(gòu)見(jiàn)下圖： UI 技術(shù)架構(gòu) EEPlat 平臺(tái)在界面控制模式方面，充分考慮到傳統(tǒng)的 MVC 模式的優(yōu)缺點(diǎn)，最終采取了層疊式 MVC 模式，即 HMVC。 。 HMVC 模式即 HierarchicalModelViewController 模式，也可以叫做 Layered MVC。 HMVC 模式把客戶(hù)端應(yīng)用程序分解為有層次的父子關(guān)系的 MVC。反復(fù)應(yīng)用這個(gè)模式，形成結(jié)構(gòu)化的客戶(hù)端架構(gòu)。 它的優(yōu)點(diǎn)主要有： 1. 把界面分成了多個(gè)部分，降低了依賴(lài)性。 2. 支持鼓勵(lì)重用代碼，組件或者模塊。 3. 在今后的維護(hù)中，提高了可擴(kuò)展性。 服務(wù)層技術(shù)架構(gòu) EEPlat 的服務(wù)層和 UI 層是松耦合的。一般情況下， UI層通過(guò)服務(wù)層提供的Restful WebService 進(jìn) 行交互。服務(wù)層實(shí)現(xiàn)的核心是 聲明式業(yè)務(wù)對(duì)象 。 1. 聲明式業(yè)務(wù)對(duì)象的服務(wù)可以通過(guò) 業(yè)務(wù)對(duì)象總線 進(jìn)行互操作。 2. 聲明式業(yè)務(wù)對(duì)象的粒度可大可小，可以是一個(gè)實(shí)體表，也可以是一個(gè)較大的業(yè)務(wù)模塊。 3. 服務(wù)可以調(diào)用多個(gè)規(guī)則，規(guī)則本身可以根據(jù)上下文環(huán)境判斷是否可以執(zhí) 行，從而完成復(fù)雜的業(yè)務(wù)邏輯而無(wú)需編碼。 4. 服務(wù)可以調(diào)用腳本或 Java Class 完成平臺(tái)不能配置或不易配置的業(yè)務(wù)邏輯。 元數(shù)據(jù)驅(qū)動(dòng) 所謂元數(shù)據(jù)（ metadata）即描述數(shù)據(jù)的數(shù)據(jù) (data about data)，在 EEPlat 中，對(duì)于描述業(yè)務(wù)系統(tǒng) (包括業(yè)務(wù)數(shù)據(jù)、邏輯和 UI)的元數(shù)據(jù)我們稱(chēng)之為模型（ model）或聲明式業(yè)務(wù)對(duì)象 （ Declarative Domain Object），下面圖文中元數(shù)據(jù)、模型、聲明式業(yè)務(wù)對(duì)象的概念可以互相替換，如下圖： 元模型體系 在模型的基礎(chǔ)上， EEPlat 又進(jìn)行 了進(jìn)一步的抽象，稱(chēng)之為元模型（ metamodel） ,這樣又進(jìn) 一步提高了系統(tǒng)的靈活性和可擴(kuò)展性。 EEPlat 擁有世界領(lǐng)先的元模型體系。元模型是聲明式業(yè)務(wù)對(duì)象的模型，聲明式業(yè)務(wù)對(duì)象由元模型描述。 EEPlat元模型體系是對(duì)企業(yè)信息化、電子政務(wù)等 信息化領(lǐng)域業(yè)務(wù)的高度抽象，擁有自 描述和動(dòng)態(tài)擴(kuò)展特性，能準(zhǔn)確得完成業(yè)務(wù)領(lǐng)域模型的描述。 元模型從承擔(dān)職責(zé)的角度分為功能元模型、業(yè)務(wù)對(duì)象元模型、服務(wù)元模型、規(guī)則元模型、工作流元模型、組織元模型、 UI 元模型等。 業(yè)務(wù)對(duì)象元模型主要描述業(yè)務(wù)功能的靜態(tài)結(jié)構(gòu)，服務(wù)元模型主要完成 業(yè)務(wù)邏輯，同時(shí)負(fù)責(zé)業(yè)務(wù)對(duì)象元模型之 間的交互；工作流元模型主要完成業(yè)務(wù)流程及業(yè)務(wù)對(duì)象元模型的協(xié)作；組織元模型通過(guò)組織元模型之間的職責(zé)關(guān)系可以實(shí)現(xiàn)靈活的組織結(jié)構(gòu)， UI元模型是菜單、面 板、表格、表格元素、功能樹(shù)等的 UI 模型的元模型，可以實(shí)現(xiàn)復(fù)雜的界面表現(xiàn)，如下圖： 1. EEPlat 元模型是聲明式業(yè)務(wù)對(duì)象的模型，是對(duì)信息管理系統(tǒng)的合理抽象。在元模型體系下，聲明式業(yè)務(wù)對(duì)象是通過(guò)元數(shù)據(jù)（配置數(shù)據(jù)）進(jìn)行描述。 2. 聲明式業(yè)務(wù)對(duì)象在 EEPlat 執(zhí)行引擎的引導(dǎo)下形成用戶(hù)可用的界面、邏輯等構(gòu)成的業(yè)務(wù)系統(tǒng)，本質(zhì)上執(zhí)行引擎對(duì) EEPlat 元數(shù)據(jù)的解析。 3. 對(duì)應(yīng)于 OMG 提出的 MOF， EEPlat 只有三層： o 信息層（ information layer）：利用 EEPlat 開(kāi)發(fā)的信息管理系統(tǒng) o 模型層（ model layer）：聲明式業(yè)務(wù)對(duì)象 o 元模型層（ metamodel layer）： EEplat 元模型 業(yè)務(wù)對(duì)象總 線 總線的基本概念 1. 數(shù)據(jù)總線是業(yè)務(wù)對(duì)象之間共享數(shù)據(jù)、交換數(shù)據(jù)的唯一媒介。 2. 數(shù)據(jù)總線存在存、取兩種操作。 3. 數(shù)據(jù)總線的生命周期是是 Session，也就是說(shuō)從用戶(hù)會(huì)話開(kāi)始到用戶(hù)會(huì)話結(jié)束數(shù)據(jù)總線是一貫和連續(xù)的。 4. 數(shù)據(jù)總線是 線程獨(dú)享的、線程安全的，一個(gè)線程對(duì)數(shù)據(jù)總線的改變不會(huì)影響到其他線程對(duì)數(shù)據(jù)總線的使用，每個(gè)線程都是使用的總線的副本。 數(shù)據(jù)總線的構(gòu)成方式 數(shù)據(jù)總線有下面幾部分構(gòu)成，每個(gè)組成部分我們稱(chēng)之為節(jié)點(diǎn)： FORM節(jié)點(diǎn) FORM 的構(gòu)建 FORM 的類(lèi)型是 BOInstance。 FORM 指對(duì) HTTP GET 的 QueryString 的封裝或?qū)TTP POST 數(shù)據(jù)的封裝，它可以是界面上 FORM 的值，也可以是通過(guò) AJAX 方式傳遞的參數(shù)。如 /mvccontroller/a=1amp。b=2amp。 c=3,那么 FORM 的構(gòu)建過(guò)程是 這樣的： BOInstance form = new BOInstance()。 (“a”,”1”)。 (“b”,”2”)。 (“c”,”3”)。 FORM 的獲取 DOService 的參數(shù)是怎樣獲取 FORM 的值的？ 首先，參數(shù)的類(lèi)型是 FORM,確定是從總線的 FORM 中取值。 其次，查看參數(shù)是否配置了屬性？ ? 如果配置了屬性 String parameterValue = (屬性的全名 )。 屬性的全名 的構(gòu)成：屬性所在業(yè)務(wù)對(duì)象的名稱(chēng) + _+屬性的名稱(chēng)。 如果 parameterValue 得到的是 null，參數(shù)還會(huì)按照 “ 沒(méi)有配置屬性 ” 取值。 ? 如果沒(méi)有配置屬性 String parameterValue = (參數(shù)的名稱(chēng) )。 如果 parameterValue 得到的是 null，參數(shù)會(huì)查看是否配置了默認(rèn)值，如果配置了默認(rèn)值則取默認(rèn)值，否則直接返回 null。 當(dāng)使用 API 時(shí)，可以通過(guò) ().getFormInstance()獲取 Form 節(jié)點(diǎn) USER節(jié)點(diǎn) USER 的構(gòu)建 USER 的類(lèi)型是 BOInstance。 FORM 指對(duì)登陸用戶(hù)封裝， USER 是在登陸自定義動(dòng)作里面創(chuàng)建的。 //service 是指根據(jù)用戶(hù)名、密碼查詢(xún)登陸用戶(hù)的服務(wù) users = ()。 if (users != null amp。amp。 () 0) { BOInstance user = (BOInstance) (0)。 SessionContext us = (SessionContext) ().getAttribute( userInfo)。 if(us == null){ us = new SessionContext()。 ().setAttribute(userInfo, us)。 } /////為用戶(hù)添加他的崗位： (stationuid, (fdgangweiid))。 ///為用戶(hù)添加他所在的部門(mén)： (deptuid, tt)。 (user)。 } USER 的更改 例 : 把當(dāng)前用戶(hù) 名改為 admin,界面皮膚改為 red ? WEBService 方式 /wd/servicecontroller?dataBus=setUserContextamp。contextKey=usernameamp。contextValue=adminamp。 contextKey=skinamp。contextValue=red ? 代碼方式 ().getUser().putValue(username, admin)。 ().getUser().putValue(skin, red)。 USER 的獲取 參數(shù)關(guān)于對(duì) USER 獲取有 5 中類(lèi)型分別是 : 1. TYPE_LOGIN_ID: 獲取登陸用戶(hù)的 UID，如果為空則返回 ’666666’。 2. TYPE_LOGIN_NAME: 獲取登陸用戶(hù)的名稱(chēng)，如果為空則返回 null。 3. TYPE_LOGIN_MAIN_DEPT: 獲取用戶(hù)所在的部門(mén) uid。 USER 在構(gòu)建過(guò)程中必須添加 deptuid 的值才可以獲取到 ,否則返回 null。 4. TYPE_LOGIN_MAIN_STATION: 獲取用戶(hù)的崗位 uid。 USER 在構(gòu)建過(guò)程中必須添加 stationuid 的值才可以獲取到 ,否則返回 null。 5. TYPE_LOGIN_KEY: 根據(jù)缺省值里面的配置返回 USER 在構(gòu)建過(guò)程中 對(duì)應(yīng)的值，可以得到 USER 里面的所有的值。可以用這種類(lèi)型得到前四種類(lèi)型的值，前四種類(lèi)型其實(shí)是這種類(lèi)型的特例 ,如 TYPE_LOGIN_MAIN_STATION 這個(gè)類(lèi)型可以用 TYPE_LOGIN_KEY 代替，只要在缺省值里面配置字符串 ’stationuid’。并且還要更靈活，如果表達(dá)崗位不用 stationuid, 我們只要在缺省值里面配置相應(yīng)的字符串。 當(dāng)使用 API 時(shí)，可以通過(guò) ().getUser()獲取 User 節(jié)點(diǎn) GLOBAL_UID節(jié)點(diǎn) 創(chuàng)建 : 服務(wù)的返回類(lèi)型為刷新 CURRENT 總線和全局總線時(shí)。 獲取 : ? WEBService 方式 /wd/servicecontroller?dataBus=getContext ? 代碼方式 ().getThreadContext().getInstance() ECHO_STR 節(jié)點(diǎn) 創(chuàng)建 : ().getThreadContext().setEchoValue(echoValue) 獲取 : ? WEBService 方式 /wd/servicecontroller?dataBus=getContext ? 代碼方式 ().getThreadContext().getEchoValue() SEARCH_LIST節(jié)點(diǎn) 創(chuàng)建 :