系統(tǒng)erp架構(gòu)設(shè)計(jì)方案

ERP系統(tǒng)架構(gòu)設(shè)計(jì)方案年5月版本控制版本注釋作者時(shí)間1.0ERP系統(tǒng)架構(gòu)設(shè)計(jì)方案初稿麥仲博-05-28一、前言二、架構(gòu)設(shè)計(jì) 2.1架構(gòu)分析 2.2架構(gòu)定義 2.3架構(gòu)闡明 2.4軟件邏輯構(gòu)造三、具體功效簡(jiǎn)述3.1自定義工作流解決方案3.2多語(yǔ)言解決方案3.3消息公布/訂閱系統(tǒng)方案3.4報(bào)表&打印方案四、系統(tǒng)平臺(tái)&支撐組件五、系統(tǒng)網(wǎng)絡(luò)構(gòu)造六、開(kāi)發(fā)管理層面一、前言一種公司級(jí)的商業(yè)軟件能夠滿足顧客需要、正常運(yùn)行、易于維護(hù)、易于擴(kuò)展，必須擁有一種良好的軟件架構(gòu)支撐。本文重要是分析和構(gòu)建一種公司級(jí)商業(yè)軟件架構(gòu)。二、架構(gòu)設(shè)計(jì) 2.1架構(gòu)分析公司級(jí)的商業(yè)軟件架構(gòu)在技術(shù)層面的規(guī)定重要體系在高性能、強(qiáng)健性和低本錢。高性能對(duì)于公司級(jí)商業(yè)軟件來(lái)說(shuō)，軟件架構(gòu)需要盡量地使軟件含有最高的性能，支持最大的并發(fā)性。強(qiáng)健性公司級(jí)的商業(yè)軟件規(guī)定軟件是可靠的和無(wú)缺點(diǎn)的?，F(xiàn)在的架構(gòu)普通是，效勞器模式的。軟件的可靠和強(qiáng)健重要依賴與效勞器。效勞器的穩(wěn)定通過(guò)良好的代碼和完備的測(cè)試能夠解決這個(gè)問(wèn)題。低本錢公司級(jí)商業(yè)軟件尚有一種很重要的規(guī)定：低本錢。軟件架構(gòu)規(guī)定簡(jiǎn)樸、易掌握，復(fù)雜度低，易于維護(hù)和擴(kuò)展，易于測(cè)試。2.2架構(gòu)定義本架構(gòu)以XML為整個(gè)系統(tǒng)的交互接口，涉及系統(tǒng)架構(gòu)內(nèi)部和外部。整個(gè)系統(tǒng)分為界面展示層，流程控制層和數(shù)據(jù)存儲(chǔ)層。2.3架構(gòu)闡明系統(tǒng)架構(gòu)圖Erp架構(gòu)中各核心效勞之間滿足松散耦合特性，含有定義良好的接口，可通過(guò)拆分與組合，能夠有針對(duì)性地構(gòu)建滿足不同應(yīng)用場(chǎng)景需求的Erp應(yīng)用系統(tǒng)。適配器在集成環(huán)境中需要復(fù)用已有的應(yīng)用系統(tǒng)和數(shù)據(jù)資源，通過(guò)適配器能夠?qū)⒁延袘?yīng)用系統(tǒng)和數(shù)據(jù)資源接入到ERP應(yīng)用系統(tǒng)中。通過(guò)適配器能夠?qū)崿F(xiàn)已有資源與ERP系統(tǒng)中其它效勞實(shí)現(xiàn)雙向通訊和互相調(diào)用。首先通過(guò)適配器能夠?qū)崿F(xiàn)對(duì)已有資源的效勞化封裝，將已有資源封裝為一種效勞提供者，可覺(jué)得ERP應(yīng)用系統(tǒng)中的效勞消費(fèi)者提供業(yè)務(wù)和數(shù)據(jù)效勞，另首先通過(guò)適配器，也能夠使已有資源能夠消費(fèi)ERP應(yīng)用系統(tǒng)中的其它效勞。資源倉(cāng)庫(kù)資源倉(cāng)庫(kù)重要功效是提供效勞描述信息的存儲(chǔ)、分類和查詢功效。對(duì)于廣義的資源倉(cāng)庫(kù)而言，除了提供效勞類型的資源管理外，還需要提供對(duì)其它多個(gè)資源的管理能力，可管理對(duì)象涉及：人員和權(quán)限信息、流程定義和描述、資源封裝效勞、效勞實(shí)當(dāng)代碼、效勞布署和打包內(nèi)容、以及環(huán)境定義和描述信息。資源倉(cāng)庫(kù)首先需要提供效勞描述能力，需要能夠描述效勞的多個(gè)屬性特性，涉及：效勞的接口描述、效勞的業(yè)務(wù)特性、效勞的質(zhì)量特性(如：平安、可靠和事務(wù)等)以及效勞運(yùn)行的QoS屬性。連通效勞連通效勞是ERP根底技術(shù)平臺(tái)中的一種重要核心效勞，典型的連通效勞就是公司效勞總線(EnterpriseServiceBus，ESB)，它是效勞之間互相通信和交互的骨干。連通效勞的重要功效是通信代理，如效勞消費(fèi)的雙向交互、代理之間的通信、代理之間的通信質(zhì)量保障以及效勞運(yùn)行管理功效等。連通效勞還需要確保傳輸效率和傳輸質(zhì)量。連通效勞普通應(yīng)用于連接一種自治域內(nèi)部的各個(gè)效勞，在自治域內(nèi)部效勞都是相對(duì)可控的，因此連通效勞更多應(yīng)當(dāng)考慮效率問(wèn)題。2.3.4流程效勞流程效勞是為業(yè)務(wù)流程的運(yùn)行提供支撐的一組原則效勞。業(yè)務(wù)流程是一組效勞的集合，能夠按照特定的次序并使用一組特定的規(guī)那么進(jìn)行調(diào)用。業(yè)務(wù)流程能夠由不同粒度的效勞構(gòu)成，其本身可視為效勞。流程效勞是業(yè)務(wù)流程的運(yùn)行環(huán)境，提供流程驅(qū)動(dòng)，效勞調(diào)用，事務(wù)管理等功效。流程效勞需要支持機(jī)器自動(dòng)解決的流程，也需要支持人工干預(yù)的任務(wù)操作，它支持的業(yè)務(wù)流程重要合用于對(duì)運(yùn)行解決時(shí)間規(guī)定不高的，多方合作操作的業(yè)務(wù)過(guò)程。2.3.5交互效勞交互效勞實(shí)現(xiàn)人與效勞之間的交互功效。交互效勞就是需要提供一組完整的功效，以實(shí)現(xiàn)人與效勞的便捷交互，既能支持多個(gè)交互渠道(如瀏覽器方式，富客戶端方式和移動(dòng)接入方式等)，也能支持多個(gè)交互能力(如單點(diǎn)登錄、個(gè)性化、支持多個(gè)資源的統(tǒng)一內(nèi)容管理等)。2.3.6協(xié)作效勞協(xié)作效勞用來(lái)解決自治域之間及自治域內(nèi)部的交互通信。協(xié)作效勞強(qiáng)調(diào)原則的采用，強(qiáng)調(diào)平等協(xié)作。具體實(shí)現(xiàn)技術(shù)時(shí)將更多的考慮采用WCF有關(guān)技術(shù)，以實(shí)現(xiàn)流程協(xié)同，效勞交互，和多個(gè)質(zhì)量屬性管理(如事務(wù)管理、可靠傳輸和平安管理等)。2.3.7平安效勞像ERP這樣強(qiáng)調(diào)松散耦合的分布式集成系統(tǒng)，平安性顯得尤為重要。平安有時(shí)被稱為一種“事關(guān)全局的考慮〞，是全方位的問(wèn)題，它跨越ERP參考架構(gòu)模型的各個(gè)局部。平安效勞向ERP參考架構(gòu)模型中其它效勞提供根本的平安效勞功效，涉及：身份驗(yàn)證、訪問(wèn)控制、數(shù)據(jù)加密、數(shù)據(jù)完整性和抗抵賴性，以及平安信任、身份聯(lián)邦、平安會(huì)話、平安方略等。2.3.8信息效勞信息效勞特指為運(yùn)用上述多個(gè)根本的核心效勞提供信息管理和使用的效勞。具體涉及提供元數(shù)據(jù)管理功效，以一種統(tǒng)一的方式描述ERP系統(tǒng)中所需要使用的多個(gè)信息數(shù)據(jù)。它也提供對(duì)多個(gè)類型數(shù)據(jù)(涉及構(gòu)造化數(shù)據(jù)和非構(gòu)造化數(shù)據(jù))，以及分布在不同地方的數(shù)據(jù)進(jìn)行統(tǒng)一的訪問(wèn)管理。信息效勞其目的是使應(yīng)用系統(tǒng)能夠統(tǒng)一、透明、高效地訪問(wèn)和操縱位于網(wǎng)絡(luò)環(huán)境中的多個(gè)分布、異構(gòu)的數(shù)據(jù)資源，為實(shí)現(xiàn)全局?jǐn)?shù)據(jù)訪問(wèn)、加緊應(yīng)用開(kāi)發(fā)、增強(qiáng)網(wǎng)絡(luò)應(yīng)用和方便系統(tǒng)管理提供支持。2.3.9運(yùn)行管理工具運(yùn)行管理工具提供界面和諧的圖形化方式的監(jiān)控和管理工具，提供對(duì)多個(gè)資源和效勞對(duì)象的運(yùn)行管理功效。監(jiān)控管理工具需要管理核心效勞，也需要管理應(yīng)用效勞。能夠查看各個(gè)效勞的運(yùn)行狀態(tài)和歷史信息，也能對(duì)效勞進(jìn)行啟動(dòng)、停止、暫停、恢復(fù)、版本升級(jí)等管理控制操作，同時(shí)需要提供分析和統(tǒng)計(jì)功效，能夠根據(jù)效勞運(yùn)行信息實(shí)現(xiàn)對(duì)系統(tǒng)的調(diào)節(jié)和優(yōu)化操作。2.4軟件邏輯構(gòu)造軟件架構(gòu)圖框架從層次構(gòu)造上分重要分為：表達(dá)層、效勞層、業(yè)務(wù)層、數(shù)據(jù)層◆表達(dá)層表達(dá)層由UI〔UserInterface〕和UI控制邏輯構(gòu)成。c/s選用wpf+智能客戶端,b/s選用mvcWPF的出現(xiàn)解決了三個(gè)問(wèn)題:更快速的去開(kāi)發(fā)更豐富的顧客體驗(yàn):使用WPF,能夠在更快速的時(shí)間內(nèi)開(kāi)發(fā)出來(lái)更加豐富的界面,滿足顧客的需求。WPF借助XAML來(lái)運(yùn)用標(biāo)記而不是編程語(yǔ)言〔如C#〕來(lái)構(gòu)造精美逼真的顧客界面(UI),只要稍微含有某些HTML根底知識(shí)，就能夠快速地掌握XAML中的大局部?jī)?nèi)容。消除顧客界面差別:wpf能夠以IE為宿主的?；騍ilverlight軟件開(kāi)發(fā)團(tuán)體的協(xié)作問(wèn)題:在軟件團(tuán)體中,我們比擬熟悉Developer、DBA、Tester、ITPro、Architect等。Designer可能往往被我們無(wú)視,但事實(shí)上,Designer的工作成果才是與客戶距離近來(lái)的。并且Designer與Developer如何配合工作,是諸多團(tuán)體所頭疼的,而WPF正能夠解決此問(wèn)題。智能客戶端的優(yōu)勢(shì)1)充足運(yùn)用終端設(shè)備的優(yōu)勢(shì)2)能夠調(diào)用wcf3)支持在線和離線兩種狀態(tài)4)能夠猶如Web應(yīng)用程序普通簡(jiǎn)樸方便的布署mvc內(nèi)置AJAX支持。本身含的MVC〔模型-視圖-控制器)和本系統(tǒng)MVVM(Model-View-ViewModel)就是雙胞胎，在demo里已有較好的集成*注：因xaml和html是標(biāo)記語(yǔ)言，此層大局部可用代碼生成器生成。◆效勞層采用微軟的WCF，WindowsCommunicationFoundation(WCF)是Microsoft為構(gòu)建面對(duì)效勞的應(yīng)用提供的分布式通信編程框架平臺(tái)，是.NETFramework3.5的重要構(gòu)成局部。使用該框架，開(kāi)發(fā)人員能夠構(gòu)建跨平臺(tái)、平安、可靠和支持事務(wù)解決的公司級(jí)互聯(lián)應(yīng)用解決方案。WCF從一開(kāi)始就是工程化的，能夠簡(jiǎn)化應(yīng)用程序的開(kāi)發(fā)與布署，減少開(kāi)發(fā)本錢。用于構(gòu)建面對(duì)效勞的應(yīng)用程序，不管這些程序是獨(dú)立的桌面應(yīng)用程序，還是Web應(yīng)用程序和效勞，還是高端的公司應(yīng)用程序。◆邏輯、業(yè)務(wù)層業(yè)務(wù)層封裝了實(shí)際業(yè)務(wù)邏輯，包含數(shù)據(jù)驗(yàn)證，事物解決，權(quán)限解決等業(yè)務(wù)有關(guān)操作，是整個(gè)應(yīng)用系統(tǒng)的核心。因此設(shè)計(jì)一種能夠真實(shí)反映實(shí)際需要的業(yè)務(wù)層是非常必要的，我們將實(shí)際業(yè)務(wù)具體分為業(yè)務(wù)數(shù)據(jù)與業(yè)務(wù)操作兩局部。業(yè)務(wù)數(shù)據(jù)DomainModel那么是根據(jù)實(shí)際業(yè)務(wù)按照現(xiàn)實(shí)方式用OO思想建模，這樣很適合業(yè)務(wù)復(fù)雜的系統(tǒng)。普通采用自定義數(shù)據(jù)實(shí)體〔CustomDataEntity〕方式體現(xiàn)。自定義數(shù)據(jù)實(shí)體，有著良好的性能，編譯時(shí)的類型檢查，數(shù)據(jù)體現(xiàn)方式非常直觀符合實(shí)際業(yè)務(wù)的操作方式等優(yōu)點(diǎn)，但需要自己定義維護(hù)類，在分布式環(huán)境下需要自己編寫序列化辦法。此階段負(fù)責(zé)數(shù)據(jù)交換(傳輸)的業(yè)務(wù)實(shí)體被稱之為DTO〔DataTransferObject〕。DTO要能夠支持：數(shù)據(jù)綁定、數(shù)據(jù)驗(yàn)證、歷史統(tǒng)計(jì)、級(jí)聯(lián)觸發(fā)、合并集合、序列化與反序列化，要實(shí)現(xiàn)一種大的遞歸，從其中的任何一種對(duì)象開(kāi)始，能夠找出整個(gè)傳遞的全部數(shù)據(jù)。(1)、數(shù)據(jù)的綁定支持。要實(shí)現(xiàn)IEditableObject接口，對(duì)于狀態(tài)的變化要實(shí)現(xiàn)INotifyPropertyChanged接口，這樣才干夠?qū)崿F(xiàn)數(shù)據(jù)的觸發(fā)，這樣就要實(shí)現(xiàn)一種對(duì)象能夠找到其全部的集合，一種集合要能夠其全部的對(duì)象，這樣同樣，就必須實(shí)現(xiàn)從對(duì)象、集合、對(duì)象的遞歸，再進(jìn)一步一點(diǎn)，就實(shí)現(xiàn)了數(shù)據(jù)的級(jí)聯(lián)觸發(fā)，實(shí)現(xiàn)了雙向數(shù)據(jù)觸發(fā)、綁定。數(shù)據(jù)源的每個(gè)屬性變更，要能夠在界面上反映出來(lái)，綁定界面的變化，能夠統(tǒng)計(jì)到后臺(tái)的數(shù)據(jù)源，并且要能夠支持回滾。對(duì)于容納這些數(shù)據(jù)的ObservableCollection集合也支持綁定解決。(2)、數(shù)據(jù)驗(yàn)證。實(shí)現(xiàn)IDataErrorInfo接口(3)對(duì)于歷史統(tǒng)計(jì)。當(dāng)實(shí)現(xiàn)IEditableObject這個(gè)接口，那么必然實(shí)現(xiàn)了歷史統(tǒng)計(jì)。能夠找到集合的全部更改的統(tǒng)計(jì)，涉及刪除的統(tǒng)計(jì)。對(duì)于單個(gè)對(duì)象而言是能夠得到歷史統(tǒng)計(jì)和現(xiàn)在數(shù)據(jù)，對(duì)于集合而言，那么能夠找出差別集，同時(shí)，集合也要含有集合回滾的功效。(4)級(jí)聯(lián)觸發(fā)，那么是在實(shí)現(xiàn)數(shù)據(jù)綁定的根底上的，對(duì)于常見(jiàn)的主從構(gòu)造，當(dāng)從對(duì)象的一種屬性變化了，要能夠自動(dòng)告知其所在的集合、集合再告知所在的對(duì)象數(shù)據(jù)變化了，如果是多層構(gòu)造，那么能夠自動(dòng)的從最底層開(kāi)始一路告知到頂層。(5)合并集合、集合的解決。集合的解決與數(shù)據(jù)綁定是直接相稱的。數(shù)據(jù)源找出差別集之后，要對(duì)差別集進(jìn)行解決，解決完之后，要對(duì)原始集合進(jìn)行更進(jìn)一步的解決，要把兩個(gè)集合進(jìn)行合并解決，重要是為了同時(shí)引用。(6)同時(shí)，另外要實(shí)現(xiàn)的就是Data與SDO之間的轉(zhuǎn)換以及其它格式的數(shù)據(jù)與SDO、Data數(shù)據(jù)之間的數(shù)據(jù)轉(zhuǎn)換，比方Binary/Xml/Text/Key/文獻(xiàn)/等，最根本的是SDO與Data之間的轉(zhuǎn)換，這些轉(zhuǎn)換根據(jù)需要，有時(shí)候是單向的，有時(shí)候是雙向的，根據(jù)業(yè)務(wù)需求而定。(7)序列化與反序列化，重要是涉及到Binary和XML序列化。業(yè)務(wù)操作業(yè)務(wù)操作負(fù)責(zé)對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)行多個(gè)業(yè)務(wù)有關(guān)的解決，例如驗(yàn)證，流向，整合，事物，權(quán)限等，但它不負(fù)責(zé)有關(guān)對(duì)數(shù)據(jù)源的操作。采用整合業(yè)務(wù)數(shù)據(jù)與業(yè)務(wù)方式來(lái)操作，將業(yè)務(wù)數(shù)據(jù)與有關(guān)的業(yè)務(wù)操作封裝在一起稱為業(yè)務(wù)實(shí)體，業(yè)務(wù)實(shí)體作為統(tǒng)一的業(yè)務(wù)層為表達(dá)層提供效勞，同時(shí)也負(fù)責(zé)作為DTO在各個(gè)層次間傳輸，這樣完整的DomainModel設(shè)計(jì)方式，每個(gè)業(yè)務(wù)實(shí)體都能夠做為一種單獨(dú)組件形式存在，對(duì)于組件化復(fù)用有著莫大的好處?！魯?shù)據(jù)層數(shù)據(jù)層的宗旨就是為數(shù)據(jù)源提供一種可供外界訪問(wèn)的接口，我們應(yīng)當(dāng)選用一種能夠提供數(shù)據(jù)源無(wú)關(guān)的抽象數(shù)據(jù)訪問(wèn)接口并通過(guò)在其下掛接多個(gè)不同的DataProviador來(lái)訪問(wèn)數(shù)據(jù)源的數(shù)據(jù)層組件，這樣做便于移植到不同的數(shù)據(jù)源上。從紛繁蕪雜的關(guān)系數(shù)據(jù)模型中抽象出概念模型。這樣開(kāi)發(fā)人員能夠只需著眼概念模型，而不必要去關(guān)心紛繁蕪雜的關(guān)系數(shù)據(jù)模型，從而提高開(kāi)發(fā)效率。那么如何能夠做到這一點(diǎn)？答案就是：Linq和ADO.NETEntityFrameworkLINQ幾乎支持你所盼望的全部數(shù)據(jù)源：數(shù)據(jù)對(duì)象、SQLServer數(shù)據(jù)庫(kù)、XML和數(shù)據(jù)集，固然也支持ADO.NETEntity(LINQtoEntities),LINQ有以下優(yōu)勢(shì)：無(wú)需復(fù)雜學(xué)習(xí)過(guò)程即可上手下面我給出一種簡(jiǎn)樸的C#例如。String[]QueryString={"One","Two","Three","Four","Five"};要想查找其中長(zhǎng)度不不大于3的字符串，你能夠使用下列查詢語(yǔ)句：varThisQuery=fromStringValueinQueryStringwhereStringValue.Length>3selectStringValue;編寫更少代碼即可創(chuàng)立完整應(yīng)用。更快開(kāi)發(fā)錯(cuò)誤更少的應(yīng)用程序。無(wú)需求助奇怪的編程技巧就可合并數(shù)據(jù)源。讓新開(kāi)發(fā)者開(kāi)發(fā)效率更高。ADO.NETEntityFramework涉及1.實(shí)體數(shù)據(jù)模型(EntityDataModel),開(kāi)發(fā)人員通過(guò)EDM抽象出非常適宜的模型。2.非常強(qiáng)大的client-view/mappping引擎，用于映射數(shù)據(jù)關(guān)系3.EntitySQL語(yǔ)言和LINQ查詢對(duì)EDMschemas的全方面支持4.ojbectserviceslayer供您選擇以何種方式去解決查詢成果。比方〔行，列或作為對(duì)象〕。5.提供一種開(kāi)放的模型使ADO.NETEntityFramework能夠解決其它的數(shù)據(jù)存儲(chǔ)。6.EntityFramework實(shí)現(xiàn)了樂(lè)觀的并發(fā)模式〔OptimisticConcurrencyModel〕7.事務(wù)解決三、具體功效簡(jiǎn)述3.1工作流解決方案工作流引擎：該局部為工作流模型的核心局部，用于生成、管理、角度和監(jiān)控工作流的各個(gè)活動(dòng)執(zhí)行狀況，并實(shí)現(xiàn)對(duì)應(yīng)的人機(jī)交互。由于采用XPDL等語(yǔ)言定義的工作流文獻(xiàn)記載了對(duì)應(yīng)的業(yè)務(wù)邏輯，隱藏工作流引擎通過(guò)解析該文獻(xiàn)來(lái)理解業(yè)務(wù)流轉(zhuǎn)的邏輯。然后根據(jù)某種運(yùn)行模式按照解析出來(lái)的業(yè)務(wù)邏輯進(jìn)行驅(qū)動(dòng)，最后實(shí)現(xiàn)業(yè)務(wù)流程的流轉(zhuǎn)。工作流定義接口：通過(guò)該接口能夠進(jìn)行工作流程的分析、建模、描述和歸檔等工作，并將設(shè)計(jì)完畢的業(yè)務(wù)流程生成工作流引擎能夠識(shí)別的語(yǔ)言。工作流客戶接口：解決工作流運(yùn)行過(guò)程中需要人為參加的操作。工作流調(diào)用應(yīng)用程序接口：工作流引擎調(diào)用外部應(yīng)用程