第5章HyperledgerComposer入門5.1HyperledgerComposer簡介5.2環(huán)境搭建5.3

HyperledgerComposer的建模語言5.4開發(fā)你的第一個業(yè)務網(wǎng)絡5.5部署和測試本章小結(jié)

5.1

HyperledgerComposer簡介

1.工作流步驟1——搭建并啟動Fabric網(wǎng)絡首先，要明確HyperledgerComposer只是我們開發(fā)業(yè)務網(wǎng)絡的助手，而不是區(qū)塊鏈網(wǎng)絡本身的模塊。HyperledgerComposer僅僅為我們提供了應用打包、安裝部署、可視化測試等功能，但由于應用包最終將部署在Fabric區(qū)塊鏈網(wǎng)絡上，因此啟動Fabric網(wǎng)絡以及HyperledgerComposer框架的安裝是一切開發(fā)工作的基礎。搭建并啟動Fabric網(wǎng)絡分為安裝依賴、編寫網(wǎng)絡配置文件和啟動三個步驟，如圖5-1所示。

圖5-1

HyperledgerComposer工作流步驟1

2.工作流步驟2——部署和測試業(yè)務網(wǎng)絡

借助HyperledgerComposer獨特的建模語言和工程結(jié)構(gòu)，能夠輕松地進行應用程序的開發(fā)。

開發(fā)完成后，首先需要使用HyperledgerComposer命令將工程代碼打包成一個BNA(BusinessNetworkApplication，業(yè)務網(wǎng)絡應用包)；接著將該網(wǎng)絡包(BNA)安裝部署到Fabric網(wǎng)絡的Peer節(jié)點上，然后啟動該網(wǎng)絡；最后可通過HyperledgerComposer的RestServer工具生成RestfulAPI進行可視化測試。為了讓用戶可以方便調(diào)試，HyperledgerComposer提供了日志功能，用戶可以通過查看交易日志來分析測試結(jié)果，如圖5-2所示。圖5-2

HyperledgerComposer工作流步驟2

5.2環(huán)

境

搭

建

使用HyperledgerComposer之前，必須先搭建好FabricRuntime(運行時環(huán)境)。官網(wǎng)已經(jīng)提供了一鍵安裝并搭建環(huán)境的腳本，所有的依賴都會自動安裝，免除了從Github上克隆項目再手動安裝的麻煩。

安裝步驟如下：

(1)使用Cd命令切換至想要安裝HyperledgerComposer框架的目錄，命令行如下：

(2)用Curl命令遠程下載自動安裝腳本，命令行如下：

(3)下載完畢后執(zhí)行腳本。如遇到無法執(zhí)行的問題，可先使用Chmod命令修改腳本權(quán)限為可執(zhí)行，然后再執(zhí)行該腳本，命令行如下：

(4)退出系統(tǒng)當前用戶并重新登錄，使系統(tǒng)設置生效，命令行如下：

(5)安裝HyperledgerComposer相關工具所需的Linux指令如下：

(6)安裝Fabric運行時環(huán)境：

①

創(chuàng)建并切換至fabric工作目錄，稍后要將Fabric工具下載到該目錄中，命令行如下：

②

下載并解壓Fabric測試服務器壓縮包，命令行如下：

③

運行解壓后的腳本并安裝Docker鏡像文件，命令行如下：

(7)啟動Fabric測試網(wǎng)絡并創(chuàng)建網(wǎng)絡節(jié)點訪問卡(證書)，命令行如下：

5.3

HyperledgerComposer的建模語言

1.?CTO建模語言的特點

(1)簡單易懂：其語法類似于面向?qū)ο笳Z言中的Class和SQL中的建表。開發(fā)人員編寫CTO的過程就像編寫數(shù)據(jù)庫實體類和建表一樣，大大降低了開發(fā)復雜度。

(2)語法靈活：定義對象的屬性時可指定多個特殊字段，如“可選的”、指定范圍和校驗等。

2.?CTO文件的內(nèi)容

CTO文件后綴為?.CTO。一個完整的CTO模型文件包含下面幾個方面：

(1)命名空間。

(2)資源定義(資產(chǎn)、參與者、交易等)。

(3)從其他命名空間導入(按需)。

5.3.1命名空間

CTO中命名空間的概念和其他語言的概念基本一致，類似于文件系統(tǒng)中的文件目錄或Java中的包，主要作用是對代碼文件進行合理的劃分。

在Composer開發(fā)中，業(yè)務網(wǎng)絡可能會有一個或多個.CTO模型文件。通常，每個模型文件以命名空間作為文件名，用于對不同資源進行劃分。

一個CTO文件必須在文件開頭指定一個命名空間。該文件中定義的資源只屬于該命名空間，不同命名空間的資源相互獨立。

5.3.2資源

資源可以理解為區(qū)塊鏈業(yè)務網(wǎng)絡中出現(xiàn)的對象，是Composer的重要概念。

1.資源的種類

資源對象包含以下種類：

(1)資產(chǎn)(Asset)：即有價值的、可被交易的物品。

(2)參與者(Participant)：參與業(yè)務網(wǎng)絡的角色。

(3)交易(Transaction)：業(yè)務網(wǎng)絡中的資產(chǎn)轉(zhuǎn)移。

(4)事件(Event)：業(yè)務網(wǎng)絡中觸發(fā)的某種通知。

(5)枚舉(Enum)：一組同類型的值的集合。

(6)概念(Concept)：資源中的通用屬性集。

2.資源的特點

資源的特點如下：

(1)資源屬于某命名空間。

(2)資源名在命名空間內(nèi)唯一。

(3)資源類型為Asset和Participant時，必須指定主鍵(Identifiedby)。

(4)資源類型為Transaction時，會自動生成ID和交易時間，因此不能顯式地指定主鍵。

(5)資源具有屬性(o表示屬性)。

(6)資源可互相依賴(-->表示依賴)。

(7)資源支持單繼承(Extends關鍵字)。

(8)資源支持抽象類(Abstract關鍵字)。

資源定義格式如下：

5.3.3屬性

每種資源都可能具有屬性，用“o+屬性類型+屬性名”表示。如電腦可能有名稱、生產(chǎn)數(shù)量、價格、功能、生產(chǎn)日期等屬性。

1.屬性的樣例代碼

2.屬性的基本類型

屬性包括如下基本類型：

(1)?String(UTF-8字符串)；

(2)?Double(64位帶符號浮點數(shù))；

(3)?Integer(32位帶符號整數(shù))；

(4)?Long(64位帶符號整數(shù))；

(5)?Boolean(布爾類型：true/false)；

(6)?DataTime(與ISO-8601兼容的時間，具有可選的時區(qū)和UTZ偏移)。

3.屬性的引用類型

屬性包括如下引用類型：

(1)?Array(數(shù)組，基本類型或引用類型后加中括號)；

(2)?Concept；

(3)?Enum；

(4)?依賴類型。

5.3.4依賴

資源之前可能存在依賴(引用)關系(依賴也是一種屬性)，用“-->+依賴資源名+屬性名”表示。如電腦和生產(chǎn)者存在依賴關系。

依賴樣例代碼如下：

5.3.5枚舉

枚舉通常是一組相關值的集合，無法被實例化，其中定義的屬性最好全大寫；多單詞間用下劃線分隔。比如表示訂單的狀態(tài)。

枚舉樣例代碼如下：

5.3.6概念

概念表示多個資源中通用的屬性，無法被實例化。比如參與者類型很多時，我們可以將所有參與者共有的屬性用概念來表示(也可以使用抽象類和繼承)。

概念樣例代碼如下：

5.3.7

CTO語言特性

CTO建模語言和SQL建表語句——指定名稱、標識主鍵、列舉字段——十分相似。此外，CTO語法還包括屬性默認值以及可選屬性。

屬性默認值和可選屬性樣例代碼如下：

1.正則表達式

Composer還可以限制屬性取值范圍，支持正則表達式。

正則表達式為用戶姓名和年齡屬性定制了規(guī)則，其樣例代碼如下。

2.繼承樣例代碼

CTO建模語言使用面向?qū)ο蟮乃枷耄С仲Y源之間的繼承(Extends)以及抽象類(Abstract)。

繼承樣例代碼如下：

3.CTO建模語言須遵循的規(guī)范

CTO建模語言還有一些高級特性，如注解，但須遵循以下規(guī)范：

(1)注解可以定義在除概念和枚舉外的所有資源上。

(2)注解可以定義在除概念之外的所有屬性和依賴上。

(3)同一資源和屬性上可定義多個注解，但不能同名。

(4)每條注解可定義多個參數(shù)。

下面樣例的注解是合法的：

4.導入其他命名空間

CTO建模語言還支持導入其他命名空間。

通過Import語句，可以使用其他命名空間中定義的資源，但注意資源名稱不能沖突。

導入命名空間樣例代碼如下：

5.4開發(fā)你的第一個業(yè)務網(wǎng)絡

5.4.1網(wǎng)絡定義卡牌交易網(wǎng)絡是一個簡單的網(wǎng)絡。在卡牌交易網(wǎng)絡中，卡牌商人可以生產(chǎn)卡牌，玩家可以從商人手里購買卡牌。該網(wǎng)絡由如下資源組成：

(1)資產(chǎn)：卡牌。

(2)參與者：卡牌商人，玩家。

(3)交易：卡牌商人生產(chǎn)卡牌，玩家購買卡牌。

開發(fā)流程如下：

(1)生成工程目錄模板。

(2)資源建模：編寫CTO文件。

(3)業(yè)務邏輯：編寫交易JS腳本。

(4)訪問控制：編寫ACL。

5.4.2生成工程目錄模板

(1)進入到配置環(huán)境時指定的Fabric工作目錄文件夾，命令行如下：

(2)通過Yeoman自動生成工程目錄結(jié)構(gòu)模板(搭建環(huán)境時已安裝Yoeman和模板)，如圖5-3所示。圖5-3使用Yeoman生成工程目錄結(jié)構(gòu)模板

(3)選擇生成空模板，將創(chuàng)建模板文件，如圖5-4所示。圖5-4使用Yeoman生成模板文件成功

5.4.3資源建模

資源建模是指在CTO文件中定義卡片交易網(wǎng)絡中的資源。Yeoman已經(jīng)自動生成了models文件夾和一個CTO文件，在該CTO文件開頭指定了命名空間(與文件名相同)，代碼如下：

1.資產(chǎn)定義

卡片屬于資產(chǎn)。定義卡片的代碼如下：

2.參與者定義

定義參與者時有一個小技巧，由于卡片商人和玩家有很多共同的屬性，如ID、姓名和資金，因此可以定義一個抽象類，讓二者去繼承。

卡片商人和玩家的定義代碼如下：

3.定義交易

在定義交易時，交易的屬性和后面要編寫的交易函數(shù)的傳入?yún)?shù)相對應。當通過交易創(chuàng)建資產(chǎn)時，屬性通常包含要被創(chuàng)建的資產(chǎn)的屬性。類似于創(chuàng)建一個對象時，要通過傳參來對其屬性進行初始化。

生產(chǎn)卡片交易Transaction的定義代碼如下：

購買卡片交易Transaction的定義代碼如下：

注意：在該交易中只包含了buyer和card兩個依賴，因為卡片的主人(即商人)可以在Card的owner屬性中獲取。交易傳遞參數(shù)時將會遞歸地傳遞依賴及依賴的依賴。

5.4.4業(yè)務邏輯

HyperledgerComposer中的業(yè)務邏輯是寫在js函數(shù)中的，CTO中定義的每個交易都必須對應著一個js中的函數(shù)。

通過Yeoman生成的空項目模板并不包含lib文件夾和js文件，需要開發(fā)者手動創(chuàng)建。現(xiàn)在的工程目錄如圖5-5所示。圖5-5

card-network工程目錄

接下來依次編寫CTO中定義好的交易。注意：不是所有js中的函數(shù)都會被識別為交易函數(shù)，必須使用doc注釋和注解來聲明一個函數(shù)為交易函數(shù)，代碼如下：

代碼說明如下：

@param注解用于指定在CTO中定義的交易，tx表示向js函數(shù)中傳入的參數(shù)名。

@transaction注解用于聲明該函數(shù)為交易函數(shù)。

二者缺一不可。

編寫交易函數(shù)非常簡單，代碼如下(建議在logic.js開頭先定義一些常量)：

此處定義的命名空間名稱(NS)能夠方便后續(xù)獲取資源實例和注冊器。logic.js中所有的新實例和關系都需要通過factory對象去創(chuàng)建(factory對象的實現(xiàn)基于設計模式中的工廠模式)。

生產(chǎn)卡片交易的實現(xiàn)代碼如下：

這段代碼包含最簡單的業(yè)務邏輯判斷，即商人有足夠的錢即可生產(chǎn)卡片。其整體業(yè)務邏輯可被簡述為檢查商人的參與者信息，判斷金額是否足夠→產(chǎn)生新的卡片實例并對其屬性進行賦值操作→與注冊器交互，更新相關資源的狀態(tài)。注釋已經(jīng)足夠詳細，相信大家都能讀懂。但是注意這段代碼有幾個要點：

(1)函數(shù)前加async，這是ES7的異步關鍵字。獲取注冊器和CRUD操作都是異步的，因此需要進行同步控制，否則將會獲取不到注冊器或是在多個CRUD時代碼提前返回時導致調(diào)用失敗。開發(fā)者只需在函數(shù)調(diào)用前加await即可使異步函數(shù)同步執(zhí)行，省略了定義promise的麻煩。

(2)獲取新實例時需傳入ID，這個ID要由自行拼接或參數(shù)傳入。

(3)使用注冊器的方法進行CRUD操作，注意要加await關鍵字來同步。

(4)通過拋出異常的方式來使交易失敗。

第一個交易函數(shù)實現(xiàn)了新建資產(chǎn)，下面編寫轉(zhuǎn)移資產(chǎn)的代碼。

購買卡片交易代碼如下：

5.4.5訪問控制

通過訪問控制，可以限制哪些參與者能夠?qū)δ男┵Y源進行何種權(quán)限的訪問。訪問控制列表文件后綴為.acl。

雖然本示例中不需要使用ACL，但是默認不配置ACL會使所有資源禁止被任何參與者訪問，因此必須在permissions.acl中配置開放管理員的訪問權(quán)限。訪問權(quán)限包含訪問網(wǎng)絡和訪問系統(tǒng)資源兩部分。

Yeoman已經(jīng)自動生成了默認配置文件permissions.acl，可直接查看。

配置文件permissions.acl代碼如下：

5.5部

署

和

測

試

5.5.1打包進入終端，使用cd命令切換當前目錄至card-network目錄，通過Composer命令打包全部代碼，命令行如下：

card-network目錄下生成了card-network@0.0.1.bna文件，即業(yè)務網(wǎng)絡包，如圖5-6所示。圖5-6項目目錄結(jié)構(gòu)及生成的bna包

5.5.2手動部署

手動部署方式需要經(jīng)歷如下步驟：啟動Fabric網(wǎng)絡、創(chuàng)建節(jié)點管理員、安裝網(wǎng)絡包、啟動網(wǎng)絡包、生成業(yè)務網(wǎng)絡管理員卡等，較為復雜。

1.啟動FabricRuntime

通過Composer提供的一鍵啟動腳本啟動網(wǎng)絡，方便快捷，命令行如下：

2.創(chuàng)建節(jié)點管理員

啟動網(wǎng)絡之后要創(chuàng)建節(jié)點管理員Card。由于業(yè)務網(wǎng)絡是部署在Peer節(jié)點上的，因此必須要擁有管理權(quán)限，使Composer能夠訪問Fabric網(wǎng)絡并在節(jié)點上部署應用。創(chuàng)建節(jié)點管理員命令行如下：

3.安裝網(wǎng)絡包

使用composernetworkinstall命令安裝網(wǎng)絡包，命令行如下：

4.啟動網(wǎng)絡包

使用composernetworkstart命令啟動網(wǎng)絡包，命令如下：

5.訪問網(wǎng)絡

使用composercardimport命令將剛生成的業(yè)務網(wǎng)絡管理員卡導入錢包，之后就可以通過管理員身份訪問網(wǎng)絡，命令行如下：

6.查看card文件列表

使用composercardlist命令查看Card文件列表，命令行如下：

7.網(wǎng)絡測試

使用composernetworkping命令測試網(wǎng)絡是否啟動成功，命令行如下：

8.啟動rest-server

指定以網(wǎng)絡管理員身份啟動rest-server，-n參數(shù)表示不使用命名空間，命令行如下：

5.5.3自動部署

采用自動部署時，推薦使用HyperledgerPlayground可視化界面自動部署項目。

ComposerPlayground的Web界面會調(diào)用ComposerRestServer提供的接口來訪問業(yè)務網(wǎng)絡，如圖5-7所示。圖5-7

ComposerPlayground工作流

使用ComposerPlayground部署業(yè)務網(wǎng)絡非常簡單，下面介紹詳細步驟。

1.啟動ComposerPlayground

直接執(zhí)行下列命令即可啟動ComposerPlayground：

ComposerPlayground支持連接實際業(yè)務網(wǎng)絡(即本地FabricRuntime)和Web模擬業(yè)務網(wǎng)絡(利用localStorage)。我們使用Web方式即可，省去了啟動Fabric的麻煩，如圖5-8所示。圖5-8

Web方式部署業(yè)務網(wǎng)絡包

2.導入業(yè)務網(wǎng)絡包

如圖5-9所示，在可視化界面導入文件即可導入業(yè)務網(wǎng)絡包。圖5-9可視化導入業(yè)務網(wǎng)絡包

3.部署

點擊Deploy即可確認部署，如圖5-10所示。圖5-10確認部署

4.連接業(yè)務網(wǎng)絡

完成上述步驟，回到主頁，可以看到關于Card-Network業(yè)務網(wǎng)絡的訪問框。點擊Connectnow即可連接網(wǎng)絡，如圖5-11所示。圖5-11連接業(yè)務網(wǎng)絡

5.測試

切換至test界面，進行測試，如圖5-12所示。圖5-12切換至測試界面

1)創(chuàng)建卡片商人

左邊列表可以切換資源，方法為：選中CardSeller，點擊最右邊按鈕，添加一個CardSeller；然后點擊彈窗下方GenerateRandomData生成隨機數(shù)據(jù)；最后創(chuàng)建一個ID為1、擁有10塊錢的卡片商人即可，如圖5-13所示。圖5-13創(chuàng)建ID為1、資金為10的卡片商人

卡片商人創(chuàng)建成功后會看到如圖5-14所示的信息。圖5-14創(chuàng)建卡片商人成功

2)創(chuàng)建玩家

按照上述方法繼續(xù)創(chuàng)建一個ID為1、有100塊錢的玩家，如圖5-15所示。圖5-15創(chuàng)建ID為1、資金為100的玩家

3)執(zhí)行交易

下面執(zhí)行交易，點擊左下方按鈕，如圖5-16所示。

圖5-16執(zhí)行交易按鈕

4)制造卡片

選擇制造卡片交易，修改參數(shù)，由ID為1的卡片商人制造一張50塊錢的卡，如圖5-17所示。圖5-17執(zhí)行制造卡片交易

5)生成卡片

制造成功，生成了一張Card，同時卡片商人的資金減少10，如圖5-18所示。圖5-18制造卡片交易執(zhí)行成功

6)購買卡片

接下來測試購買卡片交易，修改Card和玩家的ID值，如圖5-19所示。圖5-19執(zhí)行購買卡片交易

執(zhí)行交易后，Card的owner變?yōu)镻layer#1，同時ID為1的玩家資金減少50，ID為1的商人資金增加50。通過左邊列表AllTransactions可以查看所有歷史交易，如圖5-20所示。圖2-2

7)修改文件和升級網(wǎng)絡

當我們需要修改文件和升級網(wǎng)絡時，選擇頂部define選項卡，點擊左邊f(xié)iles修改文件，然后點擊左下方部署按鈕即可，如圖5-21所示。圖5-21修改代碼界面

本

章

小

結(jié)

本章帶領讀者從零開始學習HyperledgerComposer，先給出開發(fā)業(yè)務網(wǎng)絡的整體思路，然后依次講解了搭建環(huán)境、CTO建模語言、業(yè)務邏輯代碼編寫、部署和測試的方法，并且完成了一個簡單的卡片交易業(yè)務網(wǎng)絡。讀者此時應對HyperledgerComposer的開發(fā)流程有了基本的了解，并且感受到通過Composer開發(fā)區(qū)塊鏈應用的方便。

本章重點掌握知識如下：

(1)什么是HyperledgerComposer。

(2)CTO建模語言。

(3)如何編寫業(yè)務邏輯代碼。

(4)如何手動安裝部署一個業(yè)務網(wǎng)絡。

(5)如何利用ComposerPlayground進行測試。

實際上，HyperledgerComposer的功能還遠不止這些。

在接下來的章節(jié)中，讀者會正式投入到業(yè)務網(wǎng)絡的開發(fā)中，學習和探索HyperledgerComposer更多強大的功能，了解更多設計原則和網(wǎng)絡擴展思路。第6章HyperledgerComposer業(yè)務

網(wǎng)絡實戰(zhàn)——基礎篇6.1易腐貨物網(wǎng)絡案例分析6.2共享單車網(wǎng)絡案例分析本章小結(jié)

6.1易腐貨物網(wǎng)絡案例分析6.1.1網(wǎng)絡建模分析業(yè)務需求后，首先要對需求中涉及的對象和交易建模。該業(yè)務網(wǎng)絡涉及如下內(nèi)容：

·易腐貨物；

·業(yè)務合作伙伴，比如種植者、運輸者和進口商；

·三方簽訂的交易合同；

·易腐貨物的生產(chǎn)、裝運；

·貨物腐爛；

·貨物送達。

1)資產(chǎn)

資產(chǎn)是指在業(yè)務網(wǎng)絡中具有一定價值、可被交易或修改狀態(tài)的物品，通常為某個參與者所擁有。

在易腐貨物網(wǎng)絡中，資產(chǎn)包括如下內(nèi)容：

·易腐貨物(蘋果、香蕉和咖啡)；

·三方共同簽訂的交易合同。

2)參與者

加入業(yè)務網(wǎng)絡的成員叫做參與者。在易腐貨物網(wǎng)絡中，將模擬易腐貨物從生產(chǎn)到運輸?shù)阶罱K成功出售所經(jīng)過的流程，因此需要如下參與者：

·種植易腐貨物的種植者；

·運輸易腐貨物的運輸者；

·購置易腐貨物的進口商。

3)訪問控制

在業(yè)務網(wǎng)絡中，訪問控制通常是不可或缺的。它能夠控制哪些人能夠?qū)δ男┵Y源進行哪種權(quán)限的訪問，即隱私保護和權(quán)限控制。

在易腐貨物網(wǎng)絡中，暫時不需要進行訪問控制，使用默認的開放規(guī)則即可。

4)交易

區(qū)塊鏈是一個分布式賬本，賬本上記錄的便是交易。交易通常涉及資產(chǎn)的改變或轉(zhuǎn)移，會影響到區(qū)塊鏈賬本的狀態(tài)，類似于區(qū)塊鏈中的“智能合約”。

在業(yè)務網(wǎng)絡中，通過發(fā)起交易來執(zhí)行對應的業(yè)務邏輯。

易腐貨物網(wǎng)絡將會產(chǎn)生如下交易：

(1)種植出易腐貨物；

(2)種植者、進口商、運輸者三方簽訂交易合同；

(3)貨物送達；

(4)貨物中途腐爛。

5)事件

若開發(fā)者希望區(qū)塊鏈中產(chǎn)生交易或某資產(chǎn)發(fā)生改變時能夠收到相應的通知提醒或執(zhí)行相關后續(xù)操作，則可以使用事件機制。

事件采用的是發(fā)布/訂閱方式，區(qū)別于發(fā)送/接收方式。所有訂閱了事件的用戶(應用程序)在該事件發(fā)生時都會收到相應的通知，以進行相應的處理。

易腐貨物網(wǎng)絡的事件是當貨物腐爛時發(fā)出警報。

確認上述模型后，開始編寫代碼實現(xiàn)模型和交易。

6.1.2代碼實現(xiàn)

在第5章中，讀者應已熟悉工程模板的生成、基本的CTO建模語法以及簡單業(yè)務邏輯代碼的編寫。

代碼編寫包括CTO建模、業(yè)務邏輯、訪問控制列表三個部分。首先，使用Yeoman生成工程目錄結(jié)構(gòu)，并新建lib文件夾和logic.js，工程目錄結(jié)構(gòu)如圖6-1所示。圖6-1工程目錄結(jié)構(gòu)

1.CTO建模

CTO建模就是編寫.cto文件，將業(yè)務網(wǎng)絡涉及的資源用面向?qū)ο笳Z法來表示。

模板自動在cto文件開頭生成了命名空間，代碼如下：

1)枚舉

由于易腐貨物具有相同的屬性(如名稱)，因此無需把每種貨物都定義一個資產(chǎn)，只需定義一個枚舉來表示貨物類別即可。

假設貨物類別有蘋果、香蕉和咖啡，則該貨物類別的枚舉代碼如下：

本例中的貨物狀態(tài)包括已創(chuàng)建、運輸中、已送達和已腐爛，該貨物狀態(tài)的枚舉代碼如下：

2)資產(chǎn)

對于擁有相同屬性(如id)的資產(chǎn)或參與者，可以使用抽象類來節(jié)約代碼量。抽象類無法被實例化，但它可被用作該類型的其他資產(chǎn)的超類型(super-type)。資產(chǎn)將擁有所指定的超類型所擁有的屬性，并且能夠根據(jù)定義追加新的屬性。

資產(chǎn)抽象類定義代碼如下：

易腐貨物定義代碼如下：

注意：資產(chǎn)類“Goods”的超類型“BaseAsset”的抽象屬性不會被其繼承。

由于易腐貨物剛產(chǎn)生時還無法確定運輸者和進口商，因此要為這兩個屬性添加optional(可選的)關鍵字，使得該屬性接受空值，否則在創(chuàng)建實例時會報錯。

交易合同定義代碼如下：

3)參與者

參與者抽象類定義代碼如下：

該抽象類定義了業(yè)務網(wǎng)絡參與者的通用屬性，其他參與者只需繼承該抽象類即可。

4)交易

交易中的屬性和依賴對應于業(yè)務邏輯交易函數(shù)的參數(shù)。調(diào)用交易函數(shù)時，會傳入一個交易實例，從交易實例中可獲取到輸入?yún)?shù)，因此，在定義交易模型時也要考慮交易函數(shù)的參數(shù)，類似編寫面向?qū)ο缶幊陶Z言中的接口。

定義交易模型的屬性和依賴的三個原則如下：

·全面：保證參數(shù)滿足業(yè)務需求；

·精準：避免無用的參數(shù)；

·易讀：屬性名稱和類型對應，并適當添加注釋。

接下來講述易腐貨物網(wǎng)絡中的交易定義。

生產(chǎn)易腐貨物交易結(jié)構(gòu)體代碼如下：

簽訂合同交易結(jié)構(gòu)體代碼如下：

貨物送達交易結(jié)構(gòu)體代碼如下：

此處通過一個合同依賴即可獲取到所有參與合同簽訂的參與者，因此無需顯式定義它們，以便代碼更加精簡，避免屬性冗余。在該階段中，若交易雙方確認貨物運輸行為已完成，則可對所引用合約進行相應的履約操作。

貨物腐爛結(jié)構(gòu)體代碼如下：

5)事件

如何在貨物腐爛時，向客戶端發(fā)送一個通知呢？可以通過定義事件來實現(xiàn)。

貨物腐爛事件代碼如下：

2.業(yè)務邏輯

HyperledgerComposer的業(yè)務邏輯代碼寫在lib目錄下的js文件中。Yeoman已經(jīng)默認生成了logic.js，直接編寫該文件即可。

1)常量定義

在交易函數(shù)前，可以定義一些在函數(shù)中經(jīng)常使用的對象、變量、枚舉等。

上述代碼中，getFactory是HyperledgerComposer提供的API，用于獲取工廠對象；工廠用于創(chuàng)建新的資源實例。

由于命名空間將多次出現(xiàn)在交易函數(shù)中，因此在開頭將其定義成常量。

在CTO建模時定義的枚舉在js中推薦轉(zhuǎn)換為定義一個屬性名全部大寫的對象，屬性值定義成對應的大寫字符串。

2)種植易腐貨物

編寫交易函數(shù)的一般流程如圖6-2所示。圖6-2編寫交易函數(shù)的流程

種植者須消耗一定金錢去種植貨物，即創(chuàng)建易腐貨物實例。如果金錢不足，則不能種植。

交易函數(shù)的詳細代碼如下：

上述代碼對應的業(yè)務邏輯可被概括為：獲取交易發(fā)起者的參與者信息→檢查余額是否充足并扣除指定數(shù)目余額→創(chuàng)建新的貨物實例并賦值→與注冊器交互，更新相關資源的狀態(tài)。每個交易函數(shù)在定義前都要添加async關鍵字，獲取及使用注冊器時必須添加await關鍵字。

3)簽訂合同

下面的代碼看似比較復雜，其實大多是給新對象賦值的冗余代碼。讀者可自行使用lodash.js等工具庫來簡化對象賦值操作。交易代碼如下：

上述代碼對應的業(yè)務邏輯可被概括為：創(chuàng)建合同并根據(jù)傳入?yún)?shù)對合同屬性進行賦值→更新貨物(Goods)資產(chǎn)實例中對進口商(importer)、運輸者(shipper)的引用并更新貨物狀態(tài)→與注冊器交互，更新相關資源的狀態(tài)。

4)貨物到達

貨物到達后，要修改貨物狀態(tài)并判斷貨物是否腐爛。若腐爛，則運輸者進行賠償；否則進口商支付運輸者和種植者一定費用。函數(shù)中須獲取三個參與者和貨物的注冊器，對它們進行更新操作。

上述代碼對應的業(yè)務邏輯可被概括為：調(diào)取合約中各個參與者以及貨物的狀態(tài)信息→檢查貨物狀態(tài)(是否腐爛)→根據(jù)貨物狀態(tài)分配參與者資金→與注冊器交互，更新相關資源的狀態(tài)。

5)貨物腐爛

貨物腐爛(在業(yè)務網(wǎng)絡中具體表現(xiàn)為一個“貨物腐爛”(GoodsBlet)交易被發(fā)起)時，會觸發(fā)通知事件。事件可被外部應用監(jiān)聽并接收。

事件的觸發(fā)流程如圖6-3所示。圖6-3事件觸發(fā)流程

上述代碼對應的業(yè)務邏輯可被概括為：調(diào)取交易中引用的貨物實例→更新貨物狀態(tài)為“已腐爛”→與注冊器交互，更新相關資源的狀態(tài)→創(chuàng)建新事件，定義事件類型和事件屬性→觸發(fā)事件。

3.訪問控制列表

目前無需對該網(wǎng)絡進行訪問控制，因此使用模板生成的默認訪問控制列表文件permissions.acl即可，所有用戶資源和系統(tǒng)資源都會開放訪問。該文件內(nèi)容如下：

4.代碼測試

代碼編寫完成，接下來使用命令將其打包并部署到ComposerPlayground上進行測試。

1)打包

打包命令如下：

2)啟動

啟動ComposerPlayground命令如下：

3)部署

以web方式部署，如圖6-4和圖6-5所示。圖6-4點擊部署一個業(yè)務網(wǎng)絡圖6-5點擊Drophere上傳本地網(wǎng)絡包

6.1.3情景測試

1.貨物交易成功

種植者種出一批香蕉，要賣給進口商，由運輸者負責這批香蕉的運輸，三方之間簽訂了一份交易合同。

合同簽訂后，運輸者開始運輸貨物。

風和日麗，貨物在腐爛之前成功送達給進口商。進口商將按合同支付種植者貨物金額和運輸者的運輸費用。

(1)創(chuàng)建種植者，代碼如下：

(2)創(chuàng)建進口商，代碼如下：

(3)創(chuàng)建運輸者，代碼如下：

(4)種植者種植香蕉。要通過ComposerPlayground執(zhí)行一個交易，須先選擇對應的交易類型，添加請求參數(shù)并提交。

請求數(shù)據(jù)如下：

執(zhí)行交易后，種植者花費10金錢來種植香蕉，結(jié)果數(shù)據(jù)如下：

產(chǎn)生了一個香蕉實例，其id由種植者id和當前時間(毫秒數(shù))拼接而成。

(5)三方簽訂合同。發(fā)起一個簽訂合同交易，請求數(shù)據(jù)如下：

創(chuàng)建了一份合同，結(jié)果數(shù)據(jù)如下：

同時，運輸?shù)呢浳锏膕hipper和importer依賴都和相應參與者關聯(lián)，且狀態(tài)改為“運輸中”，結(jié)果數(shù)據(jù)如下：

(6)貨物送達。發(fā)起貨物送達交易，請求數(shù)據(jù)如下：

貨物狀態(tài)修改為“已送達”，結(jié)果數(shù)據(jù)如下：

種植者金錢增加20，結(jié)果數(shù)據(jù)如下：

進口商金錢減少40(運輸費+貨物價格)，結(jié)果數(shù)據(jù)如下：

運輸者金錢增加20(運輸費)，結(jié)果代碼如下：

2.貨物中途腐爛

種植者又種出一批蘋果，要賣給進口商，由運輸者負責運輸，三方之間再次簽訂了一份交易合同。

合同簽訂后，運輸者開始運輸。

可惜，風浪導致貨物在中途腐爛，運輸者不得不按合同賠償種植者和進口商。

(1)種植者種植蘋果。按上述步驟執(zhí)行種植蘋果交易，結(jié)果數(shù)據(jù)如下：

種植者金錢減少10(種植費)，結(jié)果數(shù)據(jù)如下：

(2)三方簽訂合同。執(zhí)行簽訂合同交易，請求數(shù)據(jù)如下：

創(chuàng)建了一個新的合同，結(jié)果數(shù)據(jù)如下：

(3)貨物腐爛。執(zhí)行貨物腐爛交易，請求數(shù)據(jù)如下：

蘋果的狀態(tài)改變?yōu)椤耙迅癄€”，結(jié)果數(shù)據(jù)如下：

該交易函數(shù)觸發(fā)了一個事件，可以在Playground左側(cè)的歷史記錄中查看，如圖6-6所示。圖6-6貨物腐爛事件

(4)貨物到達。執(zhí)行貨物到達交易，請求數(shù)據(jù)如下：

由于貨物腐爛，屬于運輸者違約，因此種植者和進口商都將獲得賠償。種植者金錢增加20，結(jié)果數(shù)據(jù)如下：

運輸者金錢減少50，結(jié)果數(shù)據(jù)如下：

6.1.4網(wǎng)絡擴展

1.合理性擴展

細心的讀者會發(fā)現(xiàn)，前述章節(jié)在業(yè)務邏輯代碼中添加了一些校驗。如只有當種植者金錢足夠時才能種植，否則將拋出異常。這就是合理性的體現(xiàn)。

編寫好基礎的邏輯代碼后，在進行網(wǎng)絡擴展時，首先應考慮合理性擴展。有時，一個不合理的交易就會導致整個賬本數(shù)據(jù)合理性的雪崩！

在考慮合理性時，要綜合考慮多種情況，尤其是并發(fā)時的合理性。如要防止一箱易腐貨物同時被多個進口商購買。

在易腐貨物網(wǎng)絡中，可進行如下合理性擴展：

(1)簽訂合同時判斷進口商是否有足夠的金錢進貨，同時判斷運輸者是否有空余的運力。

(2)貨物送達時，再次判斷進口商是否有足夠的金錢購買貨物，因為運送期間其資金狀況有可能改變。

(3)一批貨物只能對應一個合同。

2.安全性擴展

安全性擴展通常是指訪問控制。雖然易腐貨物網(wǎng)絡中暫未添加禁止訪問策略，但在實際應用場景中，訪問控制不可或缺。

在易腐貨物網(wǎng)絡中，可進行如下安全性擴展：

將三方合同分為兩兩之間的合同，只有合同的簽訂者可以查看該合同。

3.模型擴展

模型擴展是指為業(yè)務網(wǎng)絡添加更多的資源，可以是資產(chǎn)、參與者、事件等類型，也可以為已有資源添加屬性和依賴，從而為功能擴展打下基礎。

通常模型擴展要做到OOP(ObjectOrientedProgramming，面向?qū)ο缶幊?的“開閉原則”，即對擴展開放，對修改關閉。同時應盡量使模型的擴展不影響到已有代碼，尤其是在區(qū)塊鏈環(huán)境中，這種修改可能對賬本來說是破壞性的。因此對于模型最初的設計和每一步的擴展都要謹慎考慮。

在易腐貨物網(wǎng)絡中，可進行如下模型擴展：

·添加資產(chǎn)——船，來表示運輸者的運力。

·添加參與者——公證人，來證明合同的有效性。

·添加事件——貨物送達。

4.功能擴展

功能擴展通常依賴于模型擴展。每當新增模型時，通常都要為該模型添加一定功能。此處的功能即定義新的交易或擴展現(xiàn)有交易邏輯。

注意：不要讓單個js文件太過龐大。當交易類型很多時，可對交易進行垂直業(yè)務劃分，僅將同類的交易函數(shù)寫入同一js文件中，以此來提高代碼的可讀性和可維護性。

當單一業(yè)務邏輯函數(shù)很復雜、行數(shù)很多時，可以采用“微服務”的思想，將其中的部分邏輯單獨封裝成一個通用函數(shù)，供其他交易函數(shù)調(diào)用，這大大提高了代碼的可復用性和可維護性。

在易腐貨物網(wǎng)絡中，可進行如下功能擴展：

·周期性地記錄易腐貨物的溫度，動態(tài)判斷貨物是否腐爛。

·公證人證明合同生效。

·合同違約。

6.2共享單車網(wǎng)絡案例分析

6.2.1網(wǎng)絡建模該業(yè)務網(wǎng)絡涉及共享單車，單車生產(chǎn)者、用戶，生產(chǎn)單車，租用單車，歸還單車。真實的場景十分復雜。此處的業(yè)務網(wǎng)絡用作入門，將真實場景簡化，僅涉及最核心的交易部分。

1.資產(chǎn)

在共享單車網(wǎng)絡中，資產(chǎn)為共享單車。

2.參與者

加入業(yè)務網(wǎng)絡的成員叫做參與者。在共享單車網(wǎng)絡中，將模擬一輛共享單車從被生產(chǎn)到被租用再到被歸還的過程，因此需要如下參與者：

生產(chǎn)共享單車的生產(chǎn)商；

租用共享單車的用戶。

3.訪問控制

在共享單車網(wǎng)絡中，暫時不需要進行訪問控制，使用默認開放規(guī)則即可。

4.交易

共享單車網(wǎng)絡將會產(chǎn)生如下交易：

生產(chǎn)商生產(chǎn)一輛單車；

用戶租用一輛單車；

用戶歸還單車。

5.事件

共享單車網(wǎng)絡會觸發(fā)如下事件：

單車被租用時進行通知；

單車被歸還時進行通知。

確定網(wǎng)絡模型后，開始編寫代碼。

6.2.2代碼實現(xiàn)

代碼編寫包括CTO建模、業(yè)務邏輯、訪問控制列表三個部分。首先，使用Yeoman生成工程目錄結(jié)構(gòu)，并新建lib文件夾和logic.js，如圖6-7所示。圖6-7工程目錄結(jié)構(gòu)

1.CTO建模

模板自動在cto文件開頭生成了命名空間代碼：

1)枚舉

共享單車狀態(tài)枚舉代碼如下：

2)概念

因為用戶、生產(chǎn)商和單車都需要有地址屬性，所以將其定義為概念(concept)，即一組多資源通用的屬性組合。概念具有與資產(chǎn)、參與者、交易相似的類結(jié)構(gòu)，但它們的存在更為“抽象”，通常被作為一個屬性包含于資產(chǎn)、參與者或交易類中。

地址定義代碼如下：

3)資產(chǎn)

共享單車定義代碼如下：

4)參與者

抽象參與者定義代碼如下：

5)交易

在此交易中，生產(chǎn)共享單車，會創(chuàng)建一輛單車，因此須定義一些單車的屬性。

生產(chǎn)單車交易定義代碼如下：

使用單車交易定義代碼如下：

歸還共享單車交易定義代碼如下：

6)事件

用戶租用單車事件(使用name屬性來傳遞其中一些事件內(nèi)容)代碼如下：

單車被歸還事件代碼如下：

2.業(yè)務邏輯

該步驟的任務是編寫交易函數(shù)到lib目錄下的logic.js文件中。

1)常量定義

有關常量定義的作用在5.4.4中已作解釋，代碼如下：

2)生產(chǎn)共享單車

生產(chǎn)共享單車交易的代碼如下：

第25行使用了js內(nèi)置的向數(shù)組添加元素的函數(shù)push。上述代碼對應的業(yè)務邏輯可被概括為：獲取相關單車生產(chǎn)商的參與者信息→檢查余額是否充足并扣除指定數(shù)目的余額→創(chuàng)建新的單車實例并賦值→與注冊器交互，更新相關資源的狀態(tài)。

3)使用共享單車

使用共享單車函數(shù)觸發(fā)了一個事件，該事件訂閱者將在用戶使用單車時收到消息。該交易的完整代碼如下：

上述代碼對應的業(yè)務邏輯可被概括為：獲取交易雙方的參與者信息→檢查單車狀態(tài)是否為“可用”→檢查消費者余額是否充足并扣除指定數(shù)目的余額轉(zhuǎn)至單車供應商的賬戶→修改單車的使用狀態(tài)與當前使用者→與注冊器交互，更新相關資源的狀態(tài)→發(fā)布“租用單車”事件。

4)歸還共享單車

歸還共享單車函數(shù)觸發(fā)了一個事件，該事件訂閱者將在用戶使用單車時收到消息。該交易的完整代碼如下：

3.測試

代碼編寫完成，接下來將其打包并部署到ComposerPlayground上進行測試。

(1)打包命令如下：

(2)啟動ComposerPlayground命令如下：