12.3　票据背书架构设计

根据票据背书的需求分析，本节设计一个简单的架构，再定义票据背书的数据模型。

12.3.1　票据背书的分层架构

我们利用图10.1所示Hyperledger Fabric 1.0的应用开发模型来实现票据背书的应用场景。我们将基于区块链的数字票据进行分层设计，包括Hyperledger Fabric 1.0底层平台、智能合约、业务层和应用层，如图12-2所示。

图12-2　票据背书的分层架构

每个层的主要功能如下。

1）区块链底层平台：提供分布式共享账本的维护、状态数据库维护、智能合约的全生命周期管理等区块链功能，实现数据的不可篡改和智能合约的业务逻辑。根据第11章的内容搭建区块链网络以后，默认就提供了这部分功能。另外，通过fabric-ca提供成员注册和注销等功能。

2）智能合约：智能合约通过链码来实现，包括票据发布、 票据背书、票据背书签收、票据背书拒绝等链码调用功能，链码查询包括查询持票人票据、查询待签收票据、根据链码号码查询票据信息等。票据系统的其他功能 （比如贴现、转贴现、再贴现、回购等一系列业务类型）都可以在智能合约里实现，这部分功能留给读者继续完善。

3）业务层：业务层是应用程序的后端服务，给Web应用 提供RESTful的接口，处理前端的业务请求。后端服务的基本功能包括用户管理和票据管理，通过Hyperledger Fabric 1.0提供的Node.js SDK和区块链网络进行通信。业务层也可以和其他的业务系统进行交互。

4）应用层：Web应用采用 Angular.js+HTML+CSS的前端架构编写具有MVC、模块化、自动数据绑定等特点的单页面应用，提供用户交互的界面操作，包括用户操作的功 能和业务操作的功能。用户是内置的，只提供用户登录和用户退出操作。业务操作包括发布票据、查询持票人持有的票据、发起票据背书、查询待签收票据、签收票 据背书、拒绝票据背书等功能。

各个层之间采用不同的接口，业务层的Node.js SDK、智能合约和区块链底层平台之间采用gRPC的接口，业务层和Web应用之间采用RESTful的接口。

12.3.2　票据背书的数据模型

本节看一下链码设计的数据模型，包括票据数据结构定义和票据状态定义。

1.票据数据结构

票据信息包括票据基本信息、出票人信息、承兑人信息、收款人信息、持票人信息、待背书人信息、拒绝背书人信息、票据状态和票据背书历史等，数据结构定义如下：

// 票据数据结构
type Bill struct {
        BillInfoID string `json:BillInfoID`                     //票据号码
        BillInfoAmt string `json:BillInfoAmt`                   //票据金额
        BillInfoType string `json:BillInfoType`                 //票据类型
        BillInfoIsseDate string `json:BillInfoIsseDate`         //票据出票日期
        BillInfoDueDate string `json:BillInfoDueDate`           //票据到期日期
        DrwrCmID string `json:DrwrCmID`                         //出票人证件号码
        DrwrAcct string `json:DrwrAcct`                         //出票人名称
        AccptrCmID string `json:AccptrCmID`                     //承兑人证件号码
        AccptrAcct string `json:AccptrAcct`                     //承兑人名称
        PyeeCmID string `json:PyeeCmID`                         //收款人证件号码
        PyeeAcct string `json:PyeeAcct`                         //收款人名称
        HodrCmID string `json:HodrCmID`                         //持票人证件号码
        HodrAcct string `json:HodrAcct`                         //持票人名称
        WaitEndorserCmID string `json:WaitEndorserCmID`         //待背书人证件号码
        WaitEndorserAcct string `json:WaitEndorserAcct`         //待背书人名称
        RejectEndorserCmID string `json:RejectEndorserCmID`     //拒绝背书人证件号码
        RejectEndorserAcct string `json:RejectEndorserAcct`     //拒绝背书人名称
        State string `json:State`                               //票据状态
        History []HistoryItem `json:History`                    //票据背书历史
}

票据历史信息包含了票据的流转信息，比如票据发布、票据签收、票据拒绝等都会记录到历史信息中，数据结构定义如下：

// 背书历史item结构
type HistoryItem struct {
        TxId  string `json:"txId"`
        Bill Bill `json:"bill"`
}

票据历史信息是智能合约自动完成的。

2.票据状态模型

票据状态定义如表12-2所示。

表12-2　票据状态定义

票据背书的状态转移图如图12-3所示。

图12-3　票据背书的状态转移图

票据发布以后进入票据新发布状态NewPublish，票据持票人可以提交票据背书的操作进行票据权利转移，进入 票据等待签收的状态EndrWaitSign。票据被背书人接收到票据背书请求后，可以选择签收票据或者拒绝签收，票据签收成功进入状态 EndrSigned，持票人转移为被背书人；拒绝签收进入状态EndrReject，持票人保持不变还是原有的持票人。处于EndrSigned和 EndrReject状态的持票人都可以再次发起票据背书的请求，进入下一轮的操作。

来源：我是码农，转载请保留出处和链接！

本文链接：http://www.54manong.com/?id=1045