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

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

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

1 技術發(fā)展背景

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

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

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

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

2 CBPs相關方法

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

2.1 微服務和容器

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

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

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

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

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

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

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

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

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

3 基于微服務的CBPs的架構原理

3.1 微服務平臺提供的主要服務

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

3.2 微服務平臺架構

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 平臺的實施

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

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

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

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

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

為了使用該平臺,零售商訪問公共云的前端服務,利用身份服務進行身份驗證,并使用CBPs管理服務創(chuàng)建協(xié)作網(wǎng)絡電子產(chǎn)品協(xié)同分銷,該服務通過CBPs存儲存儲庫服務。接下來,零售商在平臺中尋找供應商并向他們發(fā)送加入該網(wǎng)絡的邀請。之后,供應商加入?yún)f(xié)作網(wǎng)絡和零售商能夠與它們中的每一個創(chuàng)建三個組織間協(xié)作,全部通過CBPs管理服務。每一次合作都表明了所采用的商業(yè)模式和組織所扮演的角色。組織可以使用CBPs管理服務來管理CBP模型,該服務與CBPs存儲庫服務交互以檢索/存儲模型。例如,零售商將幾個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。

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

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

(a)

5 結束語

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