基于微服務(wù)的過程感知信息系統(tǒng)CBPs改進設(shè)計

李紅衛(wèi),周 盛,鄭 瑋

(中航西安飛機工業(yè)集團股份有限公司,陜西 西安 710089)

1 技術(shù)發(fā)展背景

由于采用了新的互聯(lián)網(wǎng)技術(shù),如云計算和新興的商業(yè)模式,組織能夠建立協(xié)作網(wǎng)絡(luò),以靈活的方式執(zhí)行協(xié)作業(yè)務(wù)流程(CBPs)。協(xié)作網(wǎng)絡(luò)由自治的、地理分布的和異構(gòu)的組織組成,這些組織協(xié)作以實現(xiàn)共同目標(biāo)。在協(xié)作網(wǎng)絡(luò)中組織之間的整合和協(xié)作是通過CBP建立和執(zhí)行的。CBP指定了組織為實現(xiàn)共同業(yè)務(wù)目標(biāo)而執(zhí)行的角色之間交互的全局視圖,它作為所涉及的組織間協(xié)作的合同基礎(chǔ)[1-4]。協(xié)作網(wǎng)絡(luò)的實施要求組織可以執(zhí)行業(yè)務(wù)流程管理(BPM)生命周期到商定CBP的各個階段。CBP管理的這些階段需要進行以下處理,包含組織自主權(quán);去中心化執(zhí)行;消息交換的全局視圖;點對點交互;充分表達通信。

當(dāng)前基于互聯(lián)網(wǎng)技術(shù)的CBP解決方案要求每個組織開發(fā)、實施和維護流程感知信息系統(tǒng)(PAIS)。PAIS是執(zhí)行組織的集成業(yè)務(wù)流程所必需的,無論是使用自身的資源和基礎(chǔ)設(shè)施如硬件、軟件、網(wǎng)絡(luò)等,還是吸引任何業(yè)務(wù)流程即服務(wù)(BPaaS)云解決方案,都需要依靠PAIS得以實現(xiàn)。其中,IBP定義了組織必須執(zhí)行的公共和私人活動,以完成CBP中約定的消息交換,然而依賴自身的PAIS增加了組織的復(fù)雜性和成本,因為必須在本地配置和實施訂閱云服務(wù),以此相互交互。其中。最為重要的是使用可以使組織能夠在協(xié)作網(wǎng)絡(luò)中應(yīng)用CBP管理的技術(shù),從而能夠以合理的成本訪問易于集成的PAIS[5-7]。其在應(yīng)用中流程如下:

第一步是提供一個合適的解決方案,允許組織根據(jù)指令同意執(zhí)行的CBP按需生成的內(nèi)容,并運用云計算技術(shù)部署和制定PAISs?，F(xiàn)有研究也發(fā)現(xiàn),實施基于的云解決方案基礎(chǔ)設(shè)施即服務(wù)(IaaS)模型可以帶來更敏捷的協(xié)作,其可以允許在任何時候建立協(xié)作,并更流暢地制定相關(guān)流程。這也使得提供平臺即服務(wù)和軟件即服務(wù)(SaaS)組織更加方便[8-11]。其在應(yīng)用中所達成的解決方案解決了實施Pais所需的IT基礎(chǔ)設(shè)施的高成本和復(fù)雜性的不足,同時改變了Pais平臺過于僵化的問題。然而,其在應(yīng)用中仍然存在額外的挑戰(zhàn),必須在CBPs平臺和執(zhí)行中將由每個組織的IBPs執(zhí)行的活動的第三方或遺留系統(tǒng)之間完成重要的集成工作。此外,如消息交換的全局視圖需要高級的全局監(jiān)控服務(wù),這即使在云中也難以實現(xiàn)。

值得注意的是,面向CBP的云解決方案必須處理與此范式相關(guān)的典型問題,例如便攜性、彈性和隱私。為了構(gòu)思一個獨立于云提供商的平臺,必須考慮可移植性。當(dāng)制定幾個IBP和PAISs時,彈性對于提高性能非常重要,因此使用適當(dāng)?shù)膹椥钥刂破鳌⒍x正確的指標(biāo)以及選擇哪些組件應(yīng)該具有彈性或不具有彈性是必要的[12-16]。這導(dǎo)致了面向用戶提供適當(dāng)?shù)姆?wù)質(zhì)量(QoS)級別需要具有適當(dāng)程度的靈活性。一方面,微服務(wù)可以改善云平臺和外部系統(tǒng)之間的集成,將微服務(wù)定義為IBP的流程活動和執(zhí)行它的外部系統(tǒng)之間的接口,這使得平臺的核心微服務(wù)能夠在不考慮與外界連接的情況下完成工作。只需要將核心微服務(wù)與外部系統(tǒng)的微服務(wù)連接起來的適當(dāng)且設(shè)計良好的接口和輕量級協(xié)議[17]。另一方面,容器化允許在不使用任何標(biāo)準(zhǔn)的情況下處理云計算環(huán)境中的可移植性問題,因為容器本身是可移植的,編排系統(tǒng)在容器級別可以實現(xiàn)適當(dāng)?shù)目s放機制,如果微服務(wù)使用容器來實現(xiàn)它們,可以從這種方法中受益。隨著IBPs的每個活動被實現(xiàn)為微服務(wù),所有業(yè)務(wù)流程本質(zhì)上都可以在活動粒度上進行擴展。最后,可以在微服務(wù)級別應(yīng)用跨所有剩余服務(wù)的身份服務(wù),確保每個組織所需的隱私。

2 CBPs相關(guān)方法

云計算是創(chuàng)建基于互聯(lián)網(wǎng)的分布式系統(tǒng)的新范例。從商業(yè)角度來看,云計算可以被視為提供按需服務(wù)的一種模式,允許組織僅在使用資源或應(yīng)用程序時為其付費按使用量付費,而不是面對硬件和軟件基礎(chǔ)設(shè)施的采購和維護成本。云計算主要有三種服務(wù)模式:SaaS、PaaS和IaaS。其中,在SaaS模型中,應(yīng)用程序作為服務(wù)提供,用戶通過互聯(lián)網(wǎng)按需訪問。PaaS模型為構(gòu)建云應(yīng)用程序提供開發(fā)服務(wù),而IaaS模型意味著通過虛擬化來提供硬件資源。云計算還提供了不同的部署模式,例如私有云、社區(qū)云、公共云和混合云[18-23]。在私有云中,基礎(chǔ)設(shè)施僅由一個組織運營,并由該組織或第三方管理;在社區(qū)云中,多個組織共同構(gòu)建和共享相同的云基礎(chǔ)架構(gòu),該基礎(chǔ)架構(gòu)可以由第三方或其中一個組織托管;在公共云中,服務(wù)提供商擁有云架構(gòu)的全部所有權(quán),擁有自己的策略、價值、利潤、成本計算和收費模式;混合云則是私有云、社區(qū)云或公共云的組合。除此之外,云聯(lián)合一詞包括來自不同提供商的服務(wù),這些服務(wù)聚合在一個池中,支持基本的互操作性特性。云計算為需要更復(fù)雜編排的其他模型提供了基礎(chǔ),為數(shù)據(jù)計算、存儲和交付功能提供API。

2.1 微服務(wù)和容器

微服務(wù)軟件架構(gòu)范例作為一種靈活執(zhí)行和獨立部署面向服務(wù)的軟件系統(tǒng)的方法受到了廣泛關(guān)注。這種架構(gòu)風(fēng)格的特點是一組小的獨立服務(wù),在自身進程中運行并通過輕量級機制進行交互,它們共同符合單個應(yīng)用程序。

微服務(wù)架構(gòu)通常與面向服務(wù)的架構(gòu)(SOA)進行比較。SOA通常與Web服務(wù)協(xié)議、工具和格式相關(guān)聯(lián),例如SOAP、WSDL(Web服務(wù)描述語言)和WS-*系列標(biāo)準(zhǔn),而微服務(wù)需要使用簡單且輕量級的通信協(xié)議,該協(xié)議增強了服務(wù)之間的解耦,例如REST over HTTP,可以依賴多種格式(XML、JSON)。

將應(yīng)用程序?qū)崿F(xiàn)為一組像微服務(wù)這樣的自治組件的缺點是它們形成了一個分布式系統(tǒng),這也導(dǎo)致在應(yīng)用中處理難度明顯提升。面對這些困難,需要一個功能齊全的微服務(wù)架構(gòu),以滿足系統(tǒng)架構(gòu)的處理需求,并解決面臨的主要問題。在應(yīng)用中需要完成以下任務(wù):(1)服務(wù)發(fā)現(xiàn)組件;(2)一個配置服務(wù)器將源代碼與其配置解耦,無需重新部署代碼即可更改應(yīng)用程序配置;(3)負載均衡器組件,為了使應(yīng)用程序具有可擴展性,能夠?qū)蝹€服務(wù)上的負載分布到多個實例中;(4)斷路器組件,用于為協(xié)同工作的服務(wù)之間的依賴關(guān)系的鏈故障產(chǎn)品提供容錯;(5)邊緣服務(wù)器,API網(wǎng)關(guān)模式的實現(xiàn),用于將外部API作為接口暴露給外界;(6)集中式日志服務(wù),能夠檢測新的微服務(wù)實例并從中收集日志事件;(7)一個監(jiān)控服務(wù)能夠分析每個微服務(wù)的硬件資源消耗,當(dāng)響應(yīng)時間和/或硬件資源的使用變得不可接受時,幫助發(fā)現(xiàn)問題的根本原因[24-26]。

2.2 協(xié)作業(yè)務(wù)流程

為了執(zhí)行協(xié)作,組織通過定義和執(zhí)行協(xié)作業(yè)務(wù)流程(CBP)來集成業(yè)務(wù)流程,就共同的業(yè)務(wù)目標(biāo)達成一致,協(xié)調(diào)行動并交換信息。協(xié)作的實現(xiàn)意味著組織可以貫穿業(yè)務(wù)流程管理(BPM)生命周期考慮到CBP的介入。期間分析和設(shè)計在BPM生命周期的各個階段,組織不僅必須定義自身的CBP,還必須定義內(nèi)部業(yè)務(wù)流程(IBP),這些流程對組織的公共和私有行為進行建模,并支持其在協(xié)作中執(zhí)行的交互和角色。為了處理組織自治問題,CBP被定義為抽象過程,因此,其不能被一個集中的過程感知信息系統(tǒng)直接執(zhí)行。相反,它們是通過各組織的綜合業(yè)務(wù)計劃以分散的方式執(zhí)行的,并由各自的工作地點差價調(diào)整數(shù)指數(shù)執(zhí)行。

履行BPM生命周期的階段包括開發(fā)、配置和部署PAISs,這是每個組織執(zhí)行其IBP和互操作管理CBP所需的,組織間的協(xié)作依賴于組織實施Pais的能力,以便能夠執(zhí)行自身的IBPs,并與其他Pais進行交互,以實現(xiàn)CBPs中商定的消息交換。最后,執(zhí)行階段包括通過每個組織的PAISs實際頒布IBP實例來“頒布”CBP,以執(zhí)行組織需要執(zhí)行的私人活動,以及與它們之間的消息交換相關(guān)的公共活動[27]。

因此,協(xié)作可以從兩個不同的角度來定義:(1)考慮交互的控制流的全局視角。(2)考慮每個組織的公共和/或私人活動以及它們之間的交互點,即為本地視角。這些視角和所涉及的流程類型之間的對應(yīng)關(guān)系,如圖1所示。

圖1 協(xié)作的本地視角與全局視角執(zhí)行模式

全局視角描述了協(xié)作的全局和公共行為以及參與者的責(zé)任。這種行為由CBP表示,作為定義參與者之間交互發(fā)生順序的單個控制流。這個視角可以通過使用編排圖(BPMN)和交互協(xié)議(UP-ColBPIP)來定義和描述。本地視角描述了基于每個參與者活動的協(xié)作行為。從這個角度來看,協(xié)作被描述為業(yè)務(wù)流程的組合,這些業(yè)務(wù)流程定義了每個參與者的獨立行為以及它們之間的交互。每個參與者都有自己的控制流和交互點。根據(jù)這個觀點,可以為每個參與者定義兩種業(yè)務(wù)流程:接口流程和整合流程。接口流程根據(jù)支持相互接收和發(fā)送消息的活動來描述參與者的公共和外部可見的操作。相反,集成過程描述了支持參與者在協(xié)作中所扮演的角色所需的公共和私人行為。私有行為添加了參與者內(nèi)部業(yè)務(wù)邏輯所必需的內(nèi)部活動和事件。

3 基于微服務(wù)的CBPs的架構(gòu)原理

3.1 微服務(wù)平臺提供的主要服務(wù)

在開始使用所提供的云服務(wù)之前,組織必須在云平臺中注冊并加入?yún)f(xié)作網(wǎng)絡(luò),并準(zhǔn)備好就新的合作達成一致,宣布CBP將被執(zhí)行。一旦所有組織都同意CBP模型,該平臺將提供云服務(wù),從CBP模型中為每個組織生成IBP模型。每個IBP模型都包含從相應(yīng)組織的角度來看執(zhí)行協(xié)作所需的活動,但它仍然是一個不完整的模型,必須用附加信息來實現(xiàn),如私人行為、數(shù)據(jù)和資源。在完整的概念I(lǐng)BP模型中,有一些服務(wù)允許用特定PAIS支持的執(zhí)行細節(jié)來配置它們,以便實現(xiàn)IBPs的可執(zhí)行實現(xiàn)。最后,該平臺為PAISs的按需生成提供服務(wù),PAISs將執(zhí)行已配置的IBP。一旦所有Pais生成并配置了各自的可執(zhí)行IBP模型,組織就可以利用云服務(wù),通過Pais分布式執(zhí)行IBP實例來支持CBP的執(zhí)行。所有的IBP都已經(jīng)實例化和生效,消息傳遞和監(jiān)控服務(wù)就開始了,這些服務(wù)使組織能夠了解協(xié)作的全局狀態(tài)。

3.2 微服務(wù)平臺架構(gòu)

由于組織無法通過公開或管理敏感信息的公共服務(wù)參與協(xié)作,因此在以前的架構(gòu)中,建議此類組織使用私有云與公共服務(wù)所在的公共云進行交互。這使得組織有了更多的自主權(quán),并且滿足了其中一些組織想要維護和保存其IBP的私有信息和活動的要求。公共云包括支持平臺所有功能的組件,包括管理與建立協(xié)作相關(guān)的方面的組件,以及必須對所有組織都具有全球性的其他功能;相反,私有云只有實現(xiàn)所有者組織的流程所必需的組件,以及提供與公共云和其全球服務(wù)的連接的存根。使用微服務(wù)可以部署在不同的云提供商上,甚至在私有基礎(chǔ)設(shè)施上。用于訪問協(xié)作和CBPs存儲庫等的服務(wù)需要對所有組織都是全局的,需要部署在公共云上。每個組織需要以私有方式訪問的其余服務(wù)也可以部署在公共云中。但是也允許其他配置,因此任何組織都可以在私有云中部署他們所需的私有服務(wù)。部署在不同云中的服務(wù)通過通信服務(wù)相互通信。這意味著平臺的最終實現(xiàn)可以在云聯(lián)盟或混合云模型上完成,不會有任何不便。該平臺的架構(gòu)基本上分為五類組件/服務(wù):基本組件/服務(wù)、共同事務(wù)、CBPs服務(wù)、BPs服務(wù)和PAISs服務(wù)。

基本組件和服務(wù)組包括提供功能齊全的微服務(wù)平臺所需的典型組件和服務(wù),即允許解決這種架構(gòu)范式所暗示的挑戰(zhàn)的眾所周知的組件或服務(wù),其中一些是微服務(wù)的典型模式的實現(xiàn)。

(1)服務(wù)發(fā)現(xiàn):允許注冊所有微服務(wù),以及通過URL或IP地址將所需服務(wù)映射到實例的端點。

(2)配置服務(wù)器:為每個服務(wù)提供獨立于其實現(xiàn)的配置設(shè)置。

(3)負載平衡器:將單個服務(wù)的負載分布到其多個實例中。

(4)服務(wù)自動縮放器:根據(jù)觀察到的指標(biāo)(如CPU利用率或其他與應(yīng)用程序相關(guān)的指標(biāo))自動擴展服務(wù)實例的數(shù)量。

(5)日志服務(wù):從每個微服務(wù)收集日志事件,并以結(jié)構(gòu)化和可搜索的方式解釋和存儲這些日志事件。

(6)監(jiān)控服務(wù):當(dāng)響應(yīng)時間和/或硬件資源使用率變得過高時,收集監(jiān)控服務(wù)故障所需的數(shù)據(jù)。

(7)對等通信服務(wù):在不同云提供商/私有基礎(chǔ)架構(gòu)中部署的平臺服務(wù)之間提供異步和可擴展的通信。

公共服務(wù)提供的功能被其余微服務(wù)提供的其余功能廣泛使用。

(1)身份服務(wù):管理在平臺中注冊的所有用戶和組織的身份,確保他們可以訪問所有公共數(shù)據(jù)(如CBPs存儲庫中的信息),保留每個組織的私有數(shù)據(jù)。

(2)前端服務(wù):提供支持用戶交互的接口,并將其請求委托給相應(yīng)的微服務(wù)。

其余三組服務(wù)提供平臺提供的業(yè)務(wù)核心服務(wù)。CBP服務(wù)允許訪問CBP存儲庫、建立協(xié)作和監(jiān)控CBP執(zhí)行。

(1)CBPs知識庫服務(wù):管理對CBP模型庫的訪問,該庫存儲協(xié)作網(wǎng)絡(luò)、組織間協(xié)作及其CBP模型。這些服務(wù)只能從公共云中獲得,所有組織都可以訪問。

(2)CBP到IBPs轉(zhuǎn)換服務(wù):提供實現(xiàn)以前工作中提出的基于MDA方法的操作從CBP模型生成特定組織的IBP模型。此方法意味著模型到模型的轉(zhuǎn)換過程,該過程將CBP模型和目標(biāo)組織角色作為輸入,并自動生成IBP模板模型作為輸出,該模型包含組織為在CBP中履行目標(biāo)角色而必須實施的公共和私有活動以及控制流。

(3)CBPs管理服務(wù):管理與建立協(xié)作關(guān)系相關(guān)的方面,協(xié)商選擇他們參與的協(xié)作網(wǎng)絡(luò)中所有組織同意的CBP模式。這項服務(wù)也只能從公共云中獲得,所有組織都可以訪問。

(4)CBPs舞蹈服務(wù):允許在不同的獨立IBP實例之間進行協(xié)調(diào),這些實例被制定來執(zhí)行CBP的實際執(zhí)行,協(xié)調(diào)這些IBP之間的異步消息交換,以實現(xiàn)協(xié)作。這項服務(wù)需要在公共云上實施。

(5)CBPs監(jiān)控服務(wù):負責(zé)監(jiān)控當(dāng)前的CBPs執(zhí)行狀態(tài),服務(wù)也必須在公共云上實現(xiàn)。

IBPs服務(wù)基本上是對訪問IBPs存儲庫的服務(wù)進行分組,并根據(jù)CBP到IBPs轉(zhuǎn)換服務(wù)。

(1)IBPs存儲庫服務(wù):管理對IBP模型存儲庫的訪問,該存儲庫存儲每個組織擁有的IBP模型,以及組織可以定義在從CBP到IBP的轉(zhuǎn)換發(fā)生時使用的模板。

(2)IBPs管理服務(wù):管理每個組織的IBP模型,從IBPs存儲庫中保存/檢索它們,并允許添加組織所需的私有活動,以完成從它們參與的CBP生成的模板。

最后,PAIS服務(wù)包括用于訪問PAIS存儲庫、配置和部署每個組織的可執(zhí)行IBP模型、編排它們的執(zhí)行以及提供與外部服務(wù)和/或以前存在的遺留系統(tǒng)交互的接口的服務(wù)。

(1)PAISs知識庫服務(wù):存儲已配置的每個組織的可執(zhí)行IBP模型,鏈接到執(zhí)行活動所需的所有外部服務(wù)和/或遺留系統(tǒng)。

(2)IBPs配置服務(wù):根據(jù)將制定可執(zhí)行IBP模型的PAISs,從完全完整的IBP生成可執(zhí)行模型的規(guī)范,定義所有公共和私有行為以完成每個組織執(zhí)行這些模型所需的活動,包括執(zhí)行CBP編排所需的所有活動。

(3)PAISs管理處:按需管理每個組織的Pais,創(chuàng)建它們,加載和部署從Pais存儲庫中檢索的可執(zhí)行IBP模型,并充當(dāng)IBPs編排服務(wù),它將負責(zé)制定法律。

(4)IBPs編排服務(wù):一旦制定了PAIS,該服務(wù)將管理IBP的執(zhí)行,在執(zhí)行IBP時需要調(diào)用的活動和服務(wù)之間進行編排。

(5)活動接口服務(wù):充當(dāng)與執(zhí)行IBPs活動的外部程序或遺留系統(tǒng)交互的邊緣服務(wù)器。

然后,考慮到它必須提供的服務(wù),平臺架構(gòu)足夠靈活,在云計算和微服務(wù)方面也必須考慮靈活性。必須為所有服務(wù)提供彈性,因此需要與服務(wù)自動縮放器和負載均衡器一起計算基本組的組成部分?？紤]到平臺被設(shè)想為獨立于云提供商或私有云基礎(chǔ)設(shè)施,可移植性是另一個重要問題;利用微服務(wù)架構(gòu)可以通過容器基礎(chǔ)設(shè)施輕松部署這一事實,這有助于建立平臺的過程,無需任何標(biāo)準(zhǔn)即可實現(xiàn)可移植性。關(guān)于隱私,提供了兩種處理敏感信息的方法:橫向身份服務(wù)僅允許訪問與特定組織相對應(yīng)的服務(wù)和數(shù)據(jù);組織可以在私有環(huán)境中部署平臺,與公共云通信,但僅共享交互所需的信息在CBP中,保留其自己的敏感數(shù)據(jù)和流程。一般來說,基本組的組件/服務(wù)允許處理基于微服務(wù)的平臺將面臨的所有困難。

3.3 平臺的實施

本次研究中給出了基于微服務(wù)的CBPs平臺的實現(xiàn)細節(jié)。如前所述,在基礎(chǔ)設(shè)施層面,有幾種方法可以用來實現(xiàn)它,試圖在云和可移植性、彈性、隱私和微服務(wù)要求微服務(wù)問題之間取得良好的平衡。例如,該平臺可以部署在IaaS基礎(chǔ)設(shè)施上,以支持公共云,其中的服務(wù)將可供所有組織使用。私有云可以由同一個或另一個IaaS提供商處理,甚至可以求助于私有IaaS基礎(chǔ)架構(gòu)。接下來,需要在這些基礎(chǔ)設(shè)施上配置對微服務(wù)更友好的適當(dāng)部署環(huán)境,例如Kubernetes作為Docker的編排器容器。另一種方法是直接使用容器服務(wù)/基礎(chǔ)設(shè)施,例如Amazon Elastic Container Service 8(Amazon ECS)、Amazon Elastic Kubernetes Service 9(Amazon EKS)、Azure Kubernetes Service 10(AKS)或Red Hat OpenShift Container Platform 11。這里選擇用于實驗的選項是Kubernetes,因為它具有適當(dāng)?shù)臄U展和負載平衡機制,以及基本組中剩余微服務(wù)的良好實現(xiàn)。Amazon EKS用于公共云服務(wù)和Red Hat OpenShift Container Platform對于私有云,因為兩者都基于Kubernetes并提供托管Kubernetes集群(在第一種情況下運行在Amazon Web Services —AWS上,在第二種情況下運行在Red Hat Enterprise Linux上,這是私有云實施的理想選擇)。這種基礎(chǔ)設(shè)施大大簡化了底層管理、配置和維護的各個方面,對于輕松快速地創(chuàng)建不同環(huán)境以以原型方式測試CBP平臺的組件非常有價值。

CBPs平臺的相關(guān)設(shè)計考慮主要是微服務(wù),特別是業(yè)務(wù)核心服務(wù)。為實現(xiàn)協(xié)同控制合作提出了一種編排方法。編排需要一個中央服務(wù),它將請求發(fā)送到其他服務(wù)并通過接收響應(yīng)來監(jiān)督流程。相反,編排假設(shè)沒有集中化,并使用事件和發(fā)布/訂閱機制來建立協(xié)作。幾乎所有服務(wù)都根據(jù)編排模式工作,除了CBP編排服務(wù)和CBP監(jiān)控服務(wù)。依賴于數(shù)據(jù)庫的服務(wù),如那些涉及存儲庫(CBP、IBP和PAIS)的服務(wù),需要一種機制來實現(xiàn)跨越多個服務(wù)實例的事務(wù)。此類服務(wù)的實例不能擁有不同的數(shù)據(jù)庫,因為整個平臺不能簡單地為每個實例使用本地ACID事務(wù)。每個本地事務(wù)更新數(shù)據(jù)庫并發(fā)布消息或事件以觸發(fā)下一個本地事務(wù)。

關(guān)于具體技術(shù),幾乎所有微服務(wù)的實現(xiàn)都使用了Spring Boot 12。前端服務(wù)需要一個具體的框架來與用戶進行適當(dāng)?shù)慕换ァpring Boot的一個優(yōu)點是它與內(nèi)置的嵌入式Apache Tomcat集成,因此前端是使用JavaServer Pages (JSP)開發(fā)的。存儲庫用于CBP、IBP和PAIS需要數(shù)據(jù)庫連接。Spring Boot很容易集成到MySQL數(shù)據(jù)庫中。用于實施CBPs編排服務(wù),需要一種允許異步發(fā)送/接收消息的技術(shù)來完成微服務(wù)編排模式,因為所有IBP都是自主和分散的。為此,Spring AMQP 13 API用于與RabbitMQ 14消息代理進行交互。IBPs編排服務(wù)還需要一種附加技術(shù)來制定整個IBP可執(zhí)行模型,并執(zhí)行與其他IBPs的交互(通過CBPs編排服務(wù)的消息交換)以及外部系統(tǒng)之間的交互。任何基于微服務(wù)的流程引擎都是合適的,但在這種情況下,用于微服務(wù)編排的工作流引擎稱為Zeebe 15用來。在Zeebe編排的工作流中,每個任務(wù)通常由不同的微服務(wù)執(zhí)行,發(fā)送/接收任務(wù)可以輕松地與CBP編排服務(wù)交互。

4 過程感知信息系統(tǒng)改進設(shè)計應(yīng)用

在過程感知信息系統(tǒng)協(xié)同業(yè)務(wù)流程改進設(shè)計中描述了基于微服務(wù)的平臺的組件和服務(wù)之間的功能、適用性和交互,用于執(zhí)行CBP。該分銷網(wǎng)絡(luò)是一個協(xié)作網(wǎng)絡(luò),包括電子產(chǎn)品零售商Megatronic和組裝商和供應(yīng)商Philkaw、Grundrive和Sanx。供應(yīng)商以單獨的點對點方式與零售商合作。每個供應(yīng)商都與零售商建立獨立的跨組織協(xié)作執(zhí)行具體的CBP模型。Megatronic同意與Philkaw和Grundrive執(zhí)行供應(yīng)商管理庫存(VMI)模型,以及與Sanx執(zhí)行協(xié)作計劃、預(yù)測和補貨(CPFR)模型。Megatronic和Philkaw共享一個公共云,Grundrive和Sanx獨立實施私有云。

為了使用該平臺,零售商訪問公共云的前端服務(wù),利用身份服務(wù)進行身份驗證,并使用CBPs管理服務(wù)創(chuàng)建協(xié)作網(wǎng)絡(luò)電子產(chǎn)品協(xié)同分銷,該服務(wù)通過CBPs存儲存儲庫服務(wù)。接下來,零售商在平臺中尋找供應(yīng)商并向他們發(fā)送加入該網(wǎng)絡(luò)的邀請。之后,供應(yīng)商加入?yún)f(xié)作網(wǎng)絡(luò)和零售商能夠與它們中的每一個創(chuàng)建三個組織間協(xié)作,全部通過CBPs管理服務(wù)。每一次合作都表明了所采用的商業(yè)模式和組織所扮演的角色。組織可以使用CBPs管理服務(wù)來管理CBP模型,該服務(wù)與CBPs存儲庫服務(wù)交互以檢索/存儲模型。例如,零售商將幾個CBP模型添加到CBP模型存儲庫中,作為與Sanx基于CPFR的協(xié)作的一部分,例如協(xié)作補貨計劃管理模型(CPFR流程)。圖2顯示了定義此CBP模型行為的BPMN中的編排圖。

圖2 Megatronic和Sanx之間的協(xié)同補貨計劃管理模型

在圖3中,(a)從CBP模型中為每個組織生成IBP模型(使用模板)。(b)從具有所需私有活動的模板完成IBP模型以獲得完整的IBP模型,一旦完成,獲得可執(zhí)行的IBP模型。(c)通過分散執(zhí)行各個IBP來執(zhí)行CBP。

該模型管理零售商和供應(yīng)商之間的簡單談判過程,以就短期內(nèi)幾種產(chǎn)品的補貨計劃達成一致。從向零售商提出供應(yīng)計劃的供應(yīng)商開始,零售商對其進行評估并決定拒絕、接受或提出反建議。決定發(fā)送給供應(yīng)商。在拒絕或接受的情況下,該過程結(jié)束。相反,對于反建議,供應(yīng)商對其進行評估并回復(fù)零售商接受或拒絕。在所有組織同意協(xié)作后,協(xié)作狀態(tài)會自動設(shè)置為“活動”,并且可以通過CBP監(jiān)控服務(wù)訪問。CBPs管理服務(wù)調(diào)用CBPs存儲服務(wù)以獲取最終的CBP模型,然后調(diào)用CBP-to-IBPs轉(zhuǎn)換服務(wù)從CBP生成每個組(Megatronic、Philkaw、Grundrive和Sanx)的IBPs的公共行為模型,作為不完整的IBP模型,最后使用IBPs存儲庫服務(wù)將它們保存在IBPs存儲庫中。CBP-to-IBPs轉(zhuǎn)換服務(wù)采用提出的方法和工具來執(zhí)行其操作。

從生成的不完整IBP模型中,通過前端服務(wù)和IBP管理服務(wù),組織完成它們并添加他們考慮的所有私有活動以正確執(zhí)行協(xié)作(圖3(a)完整的IBP模型交互)。這在公共云和/或私有云中以相同的方式完成,并且仍然是根據(jù)與技術(shù)無關(guān)的語言來實現(xiàn)的。完成的IBP模型也通過IBPs存儲庫服務(wù)保存到IBPs存儲庫中。組織現(xiàn)在能夠配置完整的IBP模型以生成可執(zhí)行規(guī)范。再次,在前端服務(wù)的幫助下和IBPs管理服務(wù),組織檢索其相應(yīng)的完整IBP模型并生成PAIS規(guī)范,以及與外部服務(wù)和/或遺留系統(tǒng)交互所需的所有信息和資源鏈接,吸引IBPs配置服務(wù)(圖3(b)生成可執(zhí)行的IBP模型交互)?？蓤?zhí)行的IBP模型通過PAISs管理服務(wù)和PAISs存儲庫服務(wù)保存到PAISs存儲庫中。當(dāng)可執(zhí)行的IBP模型可用時,每個組織都可以制定自己的IBP并開始去中心化執(zhí)行CBP(圖3(c))。同樣,這在公共云和/或私有云中以相同的方式完成。執(zhí)行意味著訪問PAIS存儲庫并檢索可執(zhí)行的IBP模型。這些可執(zhí)行模型可供IBP編排服務(wù)使用,該服務(wù)最終將執(zhí)行它們。在IBP執(zhí)行期間,IBP編排服務(wù)使用CBP編排服務(wù)根據(jù)CBP,在IBP之間交換消息,并且還使用Activity接口服務(wù)將IBP模型的每個活動與適當(dāng)?shù)耐獠糠?wù)和/或遺留系統(tǒng)進行通信。協(xié)作狀態(tài)現(xiàn)在設(shè)置為“執(zhí)行中”。一旦執(zhí)行所有IBP,每個組織都可以使用CBP監(jiān)控服務(wù)跟蹤協(xié)作狀態(tài)。

(a)

5 結(jié)束語

本次研究為CBPs管理平臺提出了一個基于微服務(wù)的架構(gòu)。通過微服務(wù)及系統(tǒng)環(huán)境部署,基于微服務(wù)的云架構(gòu)平臺系統(tǒng)有效解決了執(zhí)行CBPs的可移植性、彈性和隱私問題。該架構(gòu)還為微服務(wù)的部署帶來了更大的靈活性,支持IBP及其數(shù)據(jù)管理的微服務(wù),可以部署在公有云上,也可以部署在私有云上。所提出的云架構(gòu)滿足了組織執(zhí)行其IBP的自主性要求,同時也滿足了CBP分散執(zhí)行的要求,通過獨立部署的服務(wù)滿足了協(xié)同業(yè)務(wù)流程工作要求,并通過基于異步消息的微服務(wù)來支持CBP的執(zhí)行,以及對這些進程的監(jiān)控來提供CBP中消息交換的全局視圖,發(fā)揮了微服務(wù)的技術(shù)價值,改善了過程感知信息系統(tǒng)協(xié)同業(yè)務(wù)流程。