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