人工智能区块链智能合约

区块链已经对多方业务流程产生了深远的影响。 使用区块链的组织依靠可信的自动交易。 它提供了一个信任框架，您可以使用该框架来安全地自动化直到现在仍是手动的流程。

传统上，在商业交易中，当两方交换价值时，他们需要共享交换后的价值以及交易条款和条件的表示。 如果他们不能完全相互信任，则各方将维护自己的交换记录-交易分类帐。 他们还保留自己管理合同交换价值的规则和流程的副本。

复制这些记录可能会导致错误和欺诈。 最重要的是，交易过程也被复制，并且手动且低效地执行。 关于分类账副本和合同副本之间差异的争议可能需要在法庭上解决，从而导致大量成本，并最终导致交易延迟。

区块链通过将加密技术与分布式计算和存储技术一起使用来解决传统流程中固有的问题，从而为交易方提供一种共享交易和资产的可信表示的方式。

价值交换遵循交易双方事先通过具有法律约束力的合同达成的规则，例如在买卖交易中，交易双方将资产的所有权交换为约定的金额。 但是，规则通常更复杂，包括对交易具有管辖权的当局的法律和法规。

借助区块链技术，各方可以使用智能合约来编码和封装管理交易的交易规则和流程。 处理交易后，智能合约将根据其定义的规则自动执行操作和合规性检查。

整合决策管理平台

如果通过使用决策管理平台支持的规则引擎来实现智能合约，则可以使它们更加智能。 使用IBM®Operational Decision Manager（ODM），您可以在智能合约定义级别添加信任。 这种方法使业务涉众可以为智能合约决策逻辑的实施做出贡献。 通过将其插入Hyperledger®Fabric™的分布式交易系统中，它完全符合区块链的技术信任模型。

本文介绍了IBM ODM与Hyperledger Composer的集成， Hyperledger Composer是一个开源的区块链开发框架，该框架在Hyperledger Fabric （ 区块链平台）上运行。 Hyperledger Composer和Fabric是Linux Foundation托管的Hyperledger项目中的两个。 了解如何在区块链解决方案中使用IBM ODM，为不信任的业务网络中的所有参与者带来价值。

车辆生命周期样本

为了说明IBM ODM如何为区块链网络带来价值，以下示例考虑了车辆的生命周期。 插图说明了从生产到回收再利用的车辆，并已在车辆监管部门进行了注册，并在出售车辆时转移了所有权。

该示例基于Hyperledger Composer附带的示例。 该样本将IBM ODM业务决策逻辑（规则）集成到在Hyperledger Fabric上运行的智能合约中。 GitHub上提供了Hyperledger Composer示例和集成IBM ODM的示例：

• https://github.com/hyperledger/composer-sample-networks/tree/master/packages/vehicle-lifecycle-network
• https://github.com/ODMDev/sample-blockchain-vehicle-lifecycle

车辆的生命周期涉及多个方面，包括制造商，汽车经销商，车辆监管机构，保险公司，所有者和废品经销商。 业务网络中的所有各方都将从拥有关于车辆历史和所有权的可信的，分布式的真理源中受益。

必须使用对每个参与者都重要的特性来描述车辆本身，例如其技术和商业特性，所有者识别和保险状态。

与车辆有关的交易包括初始采购订单，制造订单，注册请求和所有权转让。 这些交易在车辆生命周期的不同阶段受不同规则的约束。 最初从汽车经销商处购买汽车时，业务规则可能适用于销售过程。 所有权变更可能需要遵守与车辆相关的贸易法律，具体针对每个国家/地区。 参与者希望检测不合规车辆或其他逃税方式上的欺诈交易。

嵌入在智能合约中的某些交易处理本质上是技术性的，可以调整和转换数据结构，以及创建，更新和销毁资产。 智能合约逻辑的其他部分与控制双方之间或政府监管机构之间的基础合约的法律规则更为接近。

本示例中的代码需要IBM ODM V8.9.x和Hyperleger Composer V0.11.1或更高版本。 有关所有其他要求，请参见README文件中的示例代码。

该示例代码包括下图所示的项目，提供示例应用程序和必要的基础结构代码，这些代码可启用区块链基础结构中的IBM ODM运行时组件。

要部署和运行示例，请参阅GitHub中的README文件。

智能合约

智能合约是区块链平台的基础。 使用智能合约，您可以在处理交易时安全地应用规则。 您可以使用它们来自动执行验证步骤并编码过去签订的有形合同上的条件。

为了建立智能合约，区块链平台的参与者就如何表示交易及其数据以及管理这些交易的规则达成共识。 该协议包括精确表达这些规则，探索所有可能的例外情况以及定义解决争端的框架。 它通常是一个涉及开发人员和业务利益相关者的迭代过程。

该过程还包括审查规则，在各方之间注册协议，测试交易数据规则，模拟方案以了解其业务影响并以安全透明的方式存储它们。 此外，必须同样注意数据模型及其代表的业务领域模型。 各方还必须定义规则的管理方式：谁可以定义规则，谁可以部署规则以及更改规则的过程。

智能合约可操纵价值，因此至关重要的是，您必须使用正确的工具和实践来开发可信任的安全，有保障，透明和逻辑–平台内部全部自动化以加快交易速度并实现自动化的承诺。

管理智能合约的流程类似于在诸如IBM ODM之类的决策管理平台中找到的流程，在该平台上，业务决策被表示，自动化并作为业务资产进行管理，并由业务涉众进行处理。

本文探讨了如何在IBM ODM中表示智能合约业务规则，如何通过广泛的IBM ODM工具集对其进行管理，以及如何在区块链平台内使用规则引擎来运行它们。

具有Hyperledger Fabric，Hyperledger Composer和IBM ODM的区块链网络的拓扑

本节探讨如何将规则引擎插入到区块链网络架构中，以向智能合约添加规则执行功能。

有关区块链网络的一般体系结构的信息，请参见Hyperledger Fabric文档和Hyperledger Composer文档 。

下图显示了区块链业务网络的典型架构。 每个对等节点都有其自己的IBM ODM Rule Execution Server实例，该实例为其上部署的所有区块链应用程序运行规则。

区块链网络运行在一组节点上。 每个节点都有一个事务分类帐和资产的副本，该副本存储在数据库中，在Hyperledeger Fabric术语中称为世界状态 。

在一个节点内，多个进程实现了区块链协议和功能。 此拓扑中的对等节点是处理区块链节点上的交易所需的一组过程。

商业网络中的每个Hyperledger Composer应用程序均由链码流程表示。 链码具有JavaScript解释器，该解释器执行用于处理事务的逻辑。 链码是在HyperLedger Fabric区块链实现中定义智能合约的机制。

对等节点进程可以物理上运行在不同的机器上，以确保给定区块链节点的高可用性。 如果对等节点之一发生故障，第二个对等节点仍可以验证传入的事务。

业务网络节点必须由强大的隔离安全性方案保护，因此您需要为每个对等节点部署一个IBM ODM Rule Execution Server实例。 多个对等节点使应用程序和规则执行功能都高度可用。

使用Hyperledger Fabric和Hyperledger Composer的Docker镜像，通过Docker Compose部署区块链节点。

下图显示了服务于多个区块链应用程序的对等节点的典型架构：

部署Hyperledger Fabric和Hyperledger Composer

作为区块链应用程序开发框架，Hyperledger Composer提供了必要的脚本来建立Hyperledger Fabric和Hyperledger Composer区块链基础架构。 该基础结构被部署为一组Docker容器，这为您部署业务网络基础结构提供了很多灵活性。

有关如何在您自己的机器或一组机器上设置正在运行的区块链基础结构的信息，请参见Hyperledger Composer文档 。

部署IBM ODM规则执行服务器

本文中的示例使用两个新组件补充了Hyperledger Fabric和Hyperledger Composer基础结构：IBM ODM Rule Execution Server和Deployer流程。 Rule Execution Server在智能合约中执行决策（业务规则），而Deployer支持通过区块链部署业务规则。

部署程序与Rule Execution Server管理API进行交互。 您可以将其视为Rule Execution Server的专用外观，它提供智能合约调用的A​​PI。

要在基于Docker的Hyperledger Fabric基础架构中运行Rule Execution Server，请将其打包为Docker映像。 请参阅使用Docker Compose部署IBM Operational Decision Manager拓扑 。

Vehicle Lifecycle示例的odm-runtime组件包含用于构建IBM ODM Docker映像的Docker文件，以及有关如何将Rule Execution Server部署到Hyperledger Fabric和Hyperledger Composer默认基础结构的说明。

Vehicle Lifecycle示例的odm-deployer组件包含此部署外观的Node.js实现。 智能合约使用它来部署Java可执行对象模型（XOM）和智能合约所引用的决策服务所使用的规则。

在区块链业务网络中部署并运行Rule Execution Server Docker映像和Deployer Docker映像之后，可以实施利用IBM ODM功能的基于规则的智能合约。

Hyperledger Composer中的车辆生命周期数据模型

Hyperledger Composer具有用于表示数据和定义事务处理逻辑的几个概念：

• 参与者代表通过交易与区块链应用程序进行交互的参与者 。
• 资产对要存储在区块链中的项目进行建模。 它们通常代表由交易操纵的有价值的东西。
• 交易代表从参与者发起的与一项或多项资产相关的在区块链分类账上注册的实际交易。
• 当在区块链上发起交易并且区块链的所有节点都对其进行验证并产生副作用时，将使用交易处理器 。 在Hyperledger Composer中，交易处理器回调在区块链的所有节点中被调用。 共识算法检查所有节点是否以相同的方式处理事务，从而确保分类账和世界状态数据库的更新一致。

Hyperledger Composer中使用专用的高级语言描述了参与者，资产和交易。 事务处理器被实现为可操纵资源JavaScript函数。

有关Hyperledger Composer应用程序的更多信息，请参阅Hyperledger Composer文档中的业务网络定义 。

Hyperledger Composer Playground Web用户界面使您可以浏览不同资源的数据模型以及事务处理器JavaScript代码。

参加者的例子

以下代码描述了Person的模型，在此示例中，该模型是可以购买或出售Vehicle 。

您可以使用REST API或通过特定交易在区块链数据库中创建Person实例。 它们存储为JavaScript Object Notation（JSON）文档。 例如，以下文档描述了一个名为Dan的Person ：

资产示例

此示例操作的主要资产是Vehicle ，如以下屏幕截图所示。 描述车辆的对象模型非常复杂，因为它需要考虑涉及车辆的各种交易范围中使用的所有属性。

Vehicle的实例表示为JSON文档。 Hyperledger Composer Playground的以下屏幕截图中对此进行了描述，其中显示了Vehicle注册表：

交易范例

Vehicle所有权从一个Person到另一个Person转移是作为在区块链上注册的交易执行的。

如以下屏幕截图所示， PrivateTransferTransaction类在Hyperledger Composer中表示此事务：

以下JSON文档表示此事务的一个示例：

您可以在车辆生命周期示例的model文件夹中找到此示例的数据模型，在不同的.cto文件中.cto进行了描述。

IBM ODM中的Vehicle Lifecycle数据模型

您还需要对数据建模，以便IBM ODM中的业务规则可以使用它。 IBM ODM表示三层数据：

• Java可执行对象模型（XOM），在此示例中作为一组Java类实现。 该模型表示规则引擎内部用于应用决策逻辑的数据。
• 业务对象模型（BOM），它以更抽象的级别表示数据模型。 通常，BOM反映XOM，但是您可以定义更多对业务友好的概念和方法，以支持业务涉众用来指定决策逻辑的自然语言。
• 商业词汇。 该特定于语言的层允许您定义业务术语以及引用业务规则中数据的短语。

您可以在IBM ODM Rule Designer中定义不同的层。 请参阅IBM ODM文档以获取更多信息。 设计业务对象模型描述了XOM，BOM和词汇表概念。

例如， Vehicle由XOM中的以下Java类表示：

Vehicle由以下BOM类及其英语语言表示：

通常，数据模型是在Hyperledger Composer中创建的，并且Java开发人员会创建基于Java的实现，并将其用作XOM。 Java开发人员与Rule Designer中的业务分析师合作，从基于Java的XOM开始创建BOM和词汇表。

请注意，Hyperledger Composer提供了一种从域模型的cto文件生成Java表示的工具（这可能是构建XOM的良好起点）。

有关此功能的更多信息，请参见示例的vehicle-lifecycle-xom目录中的README文件。

IBM ODM V8.9.x支持Jackson从JSON序列化和反序列化Java对象模型。 JSON用作HyperLedger Composer智能合约和IBM ODM决策服务之间的数据交换格式。

为了确保Hyperledger Composer事务处理器和IBM ODM决策服务可以轻松交换数据，在Hyperledger Composer中实现的数据模型必须与决策服务中使用的XOM相匹配，这一点至关重要。

请参阅vehicle-lifecycle-xom的Java实现以了解应如何实现XOM，以允许Hyperledger Composer与IBM ODM之间的数据平滑交换。

所有权转让交易的生命周期

为了说明区块链应用程序和IBM ODM如何协同工作，请考虑两个Person之间的买卖交易的情况。

要执行此业务交易，系统需要将VehicleTransferTransaction与关于Vehicle ，卖方和买方的所有信息一起发布到VehicleTransferTransaction链。

假定交易受检查交易是否欺诈的规则支配。 这些规则的逻辑很复杂，由专家定义。 当发现新的欺诈模式时，专家（业务利益相关者）希望快速更改规则，以在将欺诈性交易提交到区块链后立即自动识别。

交易过程如下图所示：

• 外部系统可以是业务流程或应用程序，它使用Hyperledger Composer为该区块链应用程序生成的REST API来推动PrivateVehicleTransfer事务。
• 交易由Hyperledger Fabric分发到区块链中的所有节点。
• 每个对等节点触发此区块链应用程序的链码（智能合约）以检查交易并应用由智能合约实现的逻辑。
• 链码触发在区块链应用程序中定义的Hyperledger Composer事务处理器回调。
• 事务处理器JavaScript代码对Rule Execution Server进行外部REST调用，该规则执行服务器将业务规则保存在决策服务中，并传递决策所需的数据。
• 业务规则将应用于事务并由规则引擎执行。
• 响应将发送回Hyperledger Composer回调。
• 回调根据响应执行操作，拒绝交易或验证交易，并在发生可疑交易时提供额外的信息。

请注意，本文重点介绍Hyperledger Composer JavaScript回调之间的交互，该回调将所有以业务为中心的逻辑委托给IBM ODM。 有关如何向Hyperledger Fabric提交事务或如何由区块链处理事务的信息，请参阅Hyperledger Composer和Hyperledger Fabric文档。

致电决策服务

Hyperledger Composer链代码与IBM ODM规则引擎不在同一进程中运行，因此这两个进程通过REST调用进行通信。

Hyperledger Composer提供了一个API，您可以使用该API在链代码外执行POST REST调用，传递当前事务以及所需的任何其他资产或参与者数据。 Hyperledger Composer将作为参数传递给REST调用的资源转换为JSON文档。

IBM ODM将决策服务作为REST API公开，可以采用描述请求有效负载的JSON有效负载。

例如，下面的Hyperledger Composer事务处理器使用决策服务来确定给定的事务是否是欺诈性的，如以下代码所示：

/*** Transfer a vehicle to another private owner* @param {org.vda.PrivateVehicleTransfer} privateVehicleTransfer - the PrivateVehicleTransfer transaction* @transaction*/
function privateVehicleTransfer(privateVehicleTransfer) {...
}

JavaScript代码知道哪个决策服务实现了需要执行的决策。 作为对等节点执行环境的一部分，Rule Execution Server正在运行，准备通过REST API接收请求。

在回调中使用以下代码来调用决策服务：

var rulesetPath = ruleappName + "/" + currentRuleappVersion + "/" + rulesetName + "/" + currentRulesetVersion;// this is where we're calling out to a Decision Service to determine of the transaction is suspicious or not// The Decision Service returns a 'status' and a 'message'. 'status' could be ACCEPTED, REJECTED, SUSPICION.// If REJECTED, the transaction should abort with the 'message' indicating why. If SUSPICION, the 'message'// should be assigned to the Vehicle.suspiciousMessage field// The Decision Service receives all the data about the current transaction: buyer, seller and the vehiclevar url = 'http://odmruntime_odm-runtime_1:9060/DecisionService/rest/' + rulesetPath;var dsCallObject = factory.newResource(NS_DECISION, 'IsSuspiciousTransferDecisionService', "isSuspiciousTransfer");dsCallObject.transaction = privateVehicleTransfer;print("Calling ODM Decision Service: " + url);return post( url, dsCallObject, {permitResourcesForRelationships: true, deduplicateResources: true});

您可以在vda.js看到此示例的代码。

此回调处理的事务包装在专用对象中，并传递给调用。 引入包装器对象是为了使Hyperledger Composer发送的JSON有效负载与决策服务期望的请求有效负载匹配，这取决于IBM ODM中指定的决策服务签名。 例如，决策服务签名可以具有多个输入参数，所有输入参数都必须是请求有效负载中的条目。

以下有效负载中的transaction条目与IBM ODM的决策操作中指定的transaction输入参数匹配。

当PrivateVehicleTransfer交易指向买方，卖方和车辆时，整个对象图被序列化为JSON文档。 调用Hyperledger Composer post() API时，它将发送到决策服务。 对于此事务，将生成以下JSON代码：

{"$class": "org.acme.vehicle.lifecycle.decision.IsSuspiciousTransferDecisionService","$id": "resource:org.acme.vehicle.lifecycle.decision.IsSuspiciousTransferDecisionService#isSuspiciousTransfer","dsId": "isSuspiciousTransfer","transaction": {"$class": "org.vda.PrivateVehicleTransfer","$id": "resource:org.vda.PrivateVehicleTransfer#4302c409-96f1-4660-9772-400875e5e2e2","seller": {"$class": "composer.base.Person","$id": "resource:composer.base.Person#dan","ssn": "dan","firstName": "Dan","lastName": "Selman","gender": "MALE","nationalities": ["French","UK"],"contactDetails": {"$class": "composer.base.ContactDetails","email": "dan@acme.org","address": {"$class": "composer.base.Address","city": "Winchester","country": "UK","region": "England"}}},"buyer": {"$class": "composer.base.Person","$id": "resource:composer.base.Person#anthony","ssn": "anthony","firstName": "Anthony","lastName": "Smith","gender": "MALE","nationalities": ["French"],"contactDetails": {"$class": "composer.base.ContactDetails","email": "anthony@acme.org","address": {"$class": "composer.base.Address","city": "Paris","country": "France","region": "IDF"}}},"specialNotes": "Dan selling a car to Anthony Smith","vehicle": {"$class": "org.vda.Vehicle","$id": "resource:org.vda.Vehicle#156478954","vin": "156478954","vehicleDetails": {"$class": "org.vda.VehicleDetails","make": "Arium","modelType": "Nova","colour": "white","vin": "156478954","taxationClass": "PETROL_CAR"},"vehicleStatus": "ACTIVE","owner": "resource:composer.base.Person#dan","logEntries": [{"$class": "org.vda.VehicleTransferLogEntry","vehicle": "resource:org.vda.Vehicle#156478954","buyer": "resource:composer.base.Person#dan","timestamp": "2017-07-30T13:57:13.652Z"}]},"transactionId": "4302c409-96f1-4660-9772-400875e5e2e2","timestamp": "2017-07-30T13:57:23.121Z"}
}

决策服务的XOM应该支持此有效负载。 Hyperledger Composer首先对对象进行序列化，然后引用已通过ID序列化的对象。 XOM中的特定JSON批注允许处理对象图反序列化。 请参阅vehicle-lifecycle-xom项目的代码。

确保您调用正确版本的决策服务，因为决策逻辑可能会独立于智能合约中的代码而发展。 区块链网络的所有节点必须使用相同版本的决策逻辑。 生命周期说明中介绍了一种管理决策逻辑版本的方法。

决策服务返回描述该决策操作的JSON文档。 如果输入的JSON文档的格式由Hyperledger Composer驱动，并且由Blockchain应用程序的数据模型的形式驱动，则答案的格式是免费的，并由IBM ODM决策服务控制。 在本文的示例中，如果存在可疑事务，则决策服务将返回JSON有效负载，如以下代码所示：

{"status": "SUSPICION","message": "Cross Border Suspicious Transfer: please double check buyer regulation"
}

交易处理器使用该响应来根据决策服务已采取的业务决策对交易进行处理。 在以下示例中，决策结果被写入Vehicle资产。

.then(function (response) {if (response.body.result['status'] != null) {if (response.body.result.status === "REJECTED") {
vehicle.suspiciousMessage = "REJECTED: " + response.body.result.message;} else if (response.body.result.status === "SUSPICION") {vehicle.suspiciousMessage = response.body.result.message;}}
}

实施决策逻辑

决策逻辑被实现为常规的IBM ODM决策服务。 您可以为决策服务定义多个入口点，以适应需要在智能合约中委派给IBM ODM的不同业务决策。 入口点（对应于IBM ODM中的决策操作）是专用规则集，它具有签名并包含表示为业务规则的决策逻辑。

决策的输入参数通常是Hyperledger Composer的事务，指的是您需要为决策完成的资产，参与者或历史事务。 如果需要传递更多数据，则需要在Hyperledger Composer（资产或概念）中为专用资源对象建模，然后在调用决策服务之前将其填充在事务处理器中。

输出参数是一个对象，用于保存决策和返回智能合约所需的所有数据。

在本文的示例中，入口点由以下屏幕截图中的决策操作定义：

通过此决策操作创建的REST API在调用post API时支持Hyperledger Composer序列化的JSON输入。

输出参数是具有status和message的数据结构，该数据结构由业务规则填充，并作为JSON文档返回给调用方。

该示例中的决策逻辑很简单：规则流，业务规则和决策表，如以下三个屏幕截图所示。

IBM ODM Rule Designer中的规则流：

IBM ODM Rule Designer中的业务规则：

IBM ODM Rule Designer中的决策表：

IBM ODM允许您所需的复杂决策逻辑。 由成千上万个规则组成的决策逻辑是常见的，并且IBM ODM易于支持。 本文中的示例主要使用Rule Designer编写决策逻辑，但是您也可以使用Decision Center定义和管理业务逻辑。 寻找有关利用Decision Composer实施决策逻辑和协作管理业务规则生命周期的未来内容。

注意，可以在IBM ODM BOM编辑器中完全指定规则中使用的业务词汇。 例如，在此示例中，Hyperledger Composer提供的数据模型非常冗长，具有多个嵌套级别。 BOM适用于实施快捷短语以隐藏这种复杂性。 在示例中， Person概念具有一个额外的getCountry()方法，该方法隐藏了查找国家/地区信息的潜在复杂性，如以下屏幕截图所示：

决策逻辑生命周期

区块链是一种运行时环境，在这种环境中，通过设计，分配和控制机制来确保通过智能合约进行的交易处理能够确保账本的一致性和安全性。

当交易提交到Hyperledger Fabric时，它被分派到区块链网络的所有节点，并且智能合约的多个实例适用于处理交易。 这些智能合约的所有实例必须返回其控制的资产的相同更新集，并且它们必须对交易的有效性做出相同的决定。 因此，所有节点都必须具有委派给IBM ODM的相同版本的决策逻辑，这一点很重要。 同样，就像智能​​合约代码在区块链内部是防篡改一样，重要的是没有人可以篡改业务规则。

由于这两个原因，无法通过通常与IBM ODM一起使用的典型部署过程来处理部署决策逻辑的新版本。 由于所有节点都有自己的Rule Execution Server的隐藏实例和私有实例，因此从Rule Execution Server控制台，Rule Designer或Decision Center（或通过IBM ODM API中的任何其他集中管理的API）进行的部署不适用于区块链案件。

vehicle-lifecycle示例具有专用的部署机制，该机制使用区块链的功能来确保所有节点具有相同版本的逻辑。

特定资产和交易将添加到应用程序中以存储和管理规则集。 您可以在vehicle-lifecycle项目的odm.cto和odm.js中看到它们的实现。

决策逻辑的更新被视为区块链交易。 当决策逻辑更改时，IBM ODM会生成新版本的规则集归档文件。 该归档文件的二进制文件及其版本号通过事务提交到区块链，如以下代码所示：

transaction RuleAppUpdated identified by transactionId
{o String transactionIdo String resDeployerURL// ruleapp name should be of the form <ruleapp>/<ruleset>o String ruleAppNameo String ruleapp_versiono String ruleset_versiono String archiveo String managedXomURI
}

专用交易处理器处理每个区块链节点上的交易。 它执行以下三个操作：

• 它将档案存储在由区块链控制的世界状态数据库中：

asset RuleApp identified by ruleAppId{o String ruleAppId// ruleapp name should be of the form <ruleapp>/<ruleset>o String ruleAppNameo String ruleapp_versiono String ruleset_versiono String archive}

• 它编写用于特定资产中特定决策服务的RuleApp或规则集的当前版本（ RuleAppCurrentVersion ）：

asset RuleAppCurrentVersion identified by ruleAppName{// ruleapp name should be of the form <ruleapp>/<ruleset>o String ruleAppNameo String ruleapp_versiono String ruleset_version}

• 它通过Deployer外观将RuleApp或规则集部署到该节点的Rule Execution Server中，同时传递Archive二进制文件和版本信息。

为了知道要使用哪个版本的规则集，事务处理器在调用决策服务时会从该特定资产中查找此信息，并使用它来对REST API进行参数化。

如果出了什么问题，并且需要回滚RuleAppUpdated事务，则还会回滚“ Current Version资产，并且仍使用决策服务的先前版本。 然后，将最新版本的规则集部署到Rule Execution Server，但从不使用它。

该机制可以避免在分类帐中直接存储大型二进制RuleApp。 分类帐可以使用哈希码签名存储对Ruleapp的引用，智能合约可以使用哈希码签名来检查二进制文件是否被修改。

请注意，决策逻辑高度依赖于支持业务规则的XOM。 该示例中说明了一种类似的机制，用于将XOM部署到在区块链中运行的各种Rule Execution Server。

决策逻辑管理与治理

使用IBM ODM进行智能合约的一个主要优势是广泛的工具，业务涉众可以使用这些工具来管理和管理智能合约的决策逻辑。 根据市场每周甚至每天的变化或其他因素，决策逻辑通常比应用程序的其余部分发展得更快。

重要的是，有关各方的代表可以控制智能合约中的逻辑。 如果智能合约执行具体的合同来规范当事方如何交换资产和价值，则他们必须就规则和生命周期达成共识。

例如，当事方可能决定一起审查规则，协商内容，并商定何时应部署这些规则。 该协议可能需要一个定义明确的治理流程，并需要各方进行不同级别的审查和批准。

IBM ODM excels in this area with the Decision Center and its business console, shown in the following screen capture:

Even though rule execution is necessarily distributed for a blockchain platform, you can centralize the management environment, which makes it easier for the business stakeholders of each party to collaborate on defining and managing the decision logic of their blockchain application.

One of the core principles of IBM ODM is bringing together business stakeholders (including policy managers, analysts, lawyers, accountants, auditors) by giving them tools to express and govern the decision logic of their applications in terms they are comfortable with.

Look for an upcoming article that focuses on how you can use Decision Center, coupled with a specific DevOps process, to manage and deploy the logic of smart contracts implemented with IBM ODM.

结论

IBM ODM is ideal for expressing and governing the rules in a smart contract. When you define a smart contract, the business stakeholders are necessarily involved, and by separating the rules of the smart contract from the application code, the business stakeholders from both parties can use tools like Decision Center to collaborate to define and govern them. They can also respond quickly to change and avoid the time-consuming processes of updating code bases.

The Vehicle Lifecycle sample illustrates how you can use IBM ODM with Hyperledger Fabric to execute the smart contract decision logic "in-chain" and take advantage of the enterprise-class rule engine of IBM ODM.

For your next blockchain project, consider IBM ODM for your smart contracts. It is a natural fit with Hyperledger Composer and the blockchain environment. The strengths of IBM ODM become particularly important as you bring the business stakeholders closer to the process, and look for ways to quickly respond to change.

We are eager to hear about your experiences and any additional requirements you might have for integrating IBM ODM and blockchain. You can connect with us on Twitter or email, or add a comment at the bottom of this article.

致谢

Many thanks to the Hyperledger Composer team members for their extraordinary help and responsiveness in supporting this integration. Special thanks to Simon Stone on the IBM Blockchain team for his continuous support.

We also would like to thank Laurent Grateau, Philippe Bonnard, and Jeremy Pichon for their contribution to the sample supporting this article, and Peter Gilliver and Nicolas Sauterey for their attentive reviewing of this article.

翻译自: https://www.ibm.com/developerworks/library/mw-1708-mery-blockchain/1708-mery.html

人工智能区块链智能合约