Hello Wolrd!
听起来高大上，其实入手玩起来也可以很简单：
pragma solidity ^0.4.0;
contract HelloWorld{
function update(uint amount) returns (address, uint){
balance +=
return (msg.sender, balance);
通过读取参数输入的新值，并将之累加至合约的变量中，返回发送人的地址，和最终的累计值。
浏览器编译器Remix
使用无需安装的浏览器编译器可以立即看到效果。打开后，如下图所示：
输入上述代码，点击Create按钮，就能在浏览器中创建能调用函数的按钮。在update按钮旁输入入参，点击按钮，就能执行函数调用并打印出函数返回的结果了。
如果出现错误，可以等待浏览器资源加载完成，或强制刷新后再试。
Solidity的完整语法：
入门说明：
引用类型：
语言内置特性：
合约详解：查看: 245|回复: 0
区块链功能一定要智能合约来实现
主题帖子积分
中级会员, 积分 223, 距离下一级还需 277 积分
中级会员, 积分 223, 距离下一级还需 277 积分
智能合约是区块链的高级功能。大家现在在设计区块链相关的方案的时候，很容易的引入智能合约的概念，均希望通过智能合约构建自动化的业务逻辑。33 复杂美是超级账本成员之一，他们使用的底层技术主要基于以太坊、超级账本、以及各种开源代码进行改进。共识机制主要是PBFT，以搭建联盟链、许可链为主。节点分布在平台、银行、企业等多方。其中企业在区块链上累积的信用不可篡改，考虑到区块链平台的可扩展性，为将来信息流、资金流、物流融合做好准备
智能合约应该有两个特征，一个是分布式，一个是智能化。两个特征的结合才能称为智能合约。基于业务逻辑的特点，大家容易忽略了分布式，而追求智能化。或者大家对智能化要求更高些，而对分布式要求其实不是很高。按照这个思路，现在中心化的软件系统即可以实现大家对于智能化的需求。
同时，目前一部分的智能合约构建并不能令人满意，所以智能合约并不能较好的满足大家的智能化需求，而区块链的功能也并不一定需要智能合约来实现。
区块链发展现在还处于早期、不可使用区块链也是一样。区块链从2009年发展到现在，已经经历了8年的考验，对于区块链一些基础特征，包括透明性、公开性、不可篡改行等，已经可以产生对应的产品出来，这些特征我们归纳为区块层的特征；在区块层之上，我们定义了价值层的功能，价值层的功能目前也可以有比较好的支持，也有相应的一些产品和场景；在价值层之上，我们定义了合约层的功能，在本层，我们则与Gartner曲线观点一致，即合约层的概念是大家关注的热点，但是会有一段下降期，行业会有一段反思期，之后才是智能合约发展的黄金时期。
所以，基于分层来理解区块链，可以对区块链有个比较正确的理解方式。
, Processed in 0.078876 second(s), 38 queries
, Gzip On.通过业务规则让区块链智能合约更加智能
区块链对多方业务流程具有深远的影响。使用区块链的企业期望执行受信任的自动交易。区块链提供了一个信任框架，您可以使用该框架安全地自动化（至今）通常手动执行的流程。在传统业务交易中，当两方就价值进行交换时，他们需要共享交换值的共同表示法，以及交易的条款和条件。如果他们无法完全相互信任，那么每一方都要维护自己的交换记录
- 交易账本。他们还会保留各自的规则和流程的副本，以此副本来制约交换价值的合约。复制这些记录可能导致错误和欺诈。除此之外，还会复制交易流程，并手动且低效地执行交易。针对账本和合约副本差异的争议可能需要通过法庭来解决，这会产生大量的花费，并最终延误交易。区块链结合使用密码学、分布式计算和存储技术来解决传统流程中的固有问题，为交易双方提供一种方式，以共享他们的交易和资产的受信任的表示。价值交换遵循各方提前通过具有法律约束力的合约达成一致意见的规则，比如在买/卖交易中，各方交换已达成一致金额的资产的所有权。但是，规则往往更加复杂，包含来自对交易具有司法管辖权的有关部门的法律法规。借助区块链技术，各方能使用智能合约来编码和封装交易规则和流程，以此制约交易。处理交易时，智能合约会依据他们定义的规则，自动执行操作和合规性检查。集成决策管理平台如果使用受决策管理平台支持的规则引擎来实施智能合约，可以让这些合约变得更智能。借助 IBM® Operational
Decision Manager
(ODM)，可以在智能合约定义级别上增加信任。这种方法使业务干系人能参与智能合约决策逻辑的实施。它完全符合区块链的技术信任模型，而且插入到了
Hyperledger® Fabric™ 的分布式交易系统中。本文将介绍如何集成 IBM ODM 与 ，后者是在 （一个区块链平台）上运行的一个开源区块链开发框架。Hyperledger Composer 和 Fabric 是 The
Linux Foundation 主持的两个 Hyperledger 项目。了解如何在区块链解决方案中使用 IBM
ODM，给分布式业务网络中的所有参与者带来价值。Vehicle Lifecycle
样本为了演示 IBM ODM
如何给区块链网络带来价值，下面将以一辆车的生命周期作为样本。下图演示了车辆从制造到回收的过程，其中包括向车辆管理机构注册该车辆，并在出售车辆时转移所有权。该样本基于 Hyperledger Composer 中包含的样本。它将 IBM ODM 业务决策逻辑（规则）集成到在 Hyperledger
Fabric 上运行的智能合约中。Hyperledger Composer 样本和集成 IBM ODM 的样本都可以在 GitHub
上获得：一辆车的生命周期中涉及多方，包括制造商、车辆经销商、车辆管理机构、保险公司、所有者和废品商。如果业务网络是一个受信任、分布式的，且拥有车辆历史和所有权的事实来源，那么所有各方都会受益。车辆本身需要使用对每个参与方都很重要的特征来描述，比如它的技术和商业特征、所有者身份和保险状态。与车辆相关的交易包括初始购买订单、制造订单、注册申请和所有权转移。这些交易由车辆生命周期的不同阶段的不同规则来制约。当汽车最初从汽车经销商处购买时，业务规则可能适用于销售流程。所有权变更可能需要遵守特定于每个国家的车辆相关贸易法。参与者希望检测违规车辆的欺诈性交易或其他逃税模式。嵌入在智能合约中的一些交易处理工作从很大程度讲是技术性工作，涉及到调整和转换数据结构，以及创建、更新和销毁资产。
智能合约逻辑中的其他部分更接近于法律规则，这些规则规定了各方之间或政府监管机构之间的基础合约。本示例中的代码需要 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
的区块链网络的拓扑结构本节将探索如何将规则引擎插入到区块链网络架构中，以便向智能合约增添规则执行能力。要获得关于区块链网络的总架构的信息，请参阅 和 。 下图展示了一个典型的区块链业务网络架构。每个对等节点都有自己的 IBM ODM Rule Execution Server
实例，该实例为部署在它之上的所有区块链应用程序运行规则。区块链网络在一组节点上运行。每个节点都有交易账本和资产的副本，该副本存储在一个数据库中，这个数据库在 Hyperledeger Fabric
术语中称为世界状态（ world state）。 在一个节点内，通过多个流程实现区块链协议和功能。此拓扑结构中的一个对等节点是处理区块链节点上的交易所需的流程集合。业务网络中的每个 Hyperledger Composer 应用程序都用一个链代码流程表示。该链代码有一个 JavaScript
解释器，用于执行处理交易的逻辑。链代码是在 HyperLedger Fabric 区块链实现中定义智能合约的机制。对等节点流程可在不同机器上实际运行，以保证给定区块链节点的高可用性。如果对等节点的一个节点发生故障，另一个节点仍能验证传入的交易。必须通过强隔离安全模式来保护业务网络节点，所以需要为每个对等节点部署一个 IBM ODM Rule Execution Server
实例。多个对等节点可以实现应用程序和规则执行能力的高可用性。通过 Docker Compose，使用 Hyperledger Fabric 的 Docker 镜像和 Hyperledger Composer
来部署区块链节点。下图给出了一个服务于多种区块链应用的典型对等节点架构：部署 Hyperledger Fabric 和 Hyperledger Composer作为区块链应用程序开发框架，Hyperledger Composer 提供了必要的脚本来设置 Hyperledger Fabric 和
Hyperledger Composer 区块链基础架构。将该基础架构部署为一组 Docker
容器，这让您能够非常灵活地选择如何部署业务网络基础架构。要获得关于如何在自己的一个或一组机器上设置正常运行的区块链基础架构的信息，请参阅 。部署 IBM
ODM Rule Execution Server本文中的样本为 Hyperledger Fabric 和 Hyperledger Composer 基础架构补充了两个新组件：IBM ODM Rule
Execution Server 和 Deployer 流程。Rule Execution Server
在智能合约中执行决策（业务规则），Deployer 支持通过区块链部署业务规则。Deployer 与 Rule Execution Server 管理 API 进行交互。可以将它想象成 Rule Execution Server
中提供 API 供智能合约调用的专门的 facade。要在基于 Docker 的 Hyperledger Fabric 基础架构中运行 Rule Execution Server，可以将它打包为
Docker 镜像。请参阅 developerWorks 文章。Vehicle Lifecycle 样本的
组件包含用于构建 IBM ODM Docker 镜像的 Docker
文件，以及将 Rule Execution Server 部署到 Hyperledger Fabric 和 Hyperledger Composer
默认基础架构的指令。Vehicle Lifecycle 样本的
组件包含这个部署 facade 的 Node.js
实现。智能合约使用它来部署可供智能合约所引用的决策服务使用的 Java 可执行对象模型 (XOM) 和规则。在区块链业务网络中部署并运行 Rule Execution Server Docker 镜像和 Deployer Docker 镜像后，可以实现利用了
IBM ODM 功能的基于规则的智能合约。Hyperledger Composer 中的 Vehicle Lifecycle 数据模型Hyperledger Composer 有多个概念用于表示数据和定义交易处理逻辑：参与者表示通过交易与区块链应用程序交互的行动者。资产对要存储在区块链中的商品进行建模。它们通常表示交易处理的某个有价值的事物。交易表示在区块链账本上注册的，由一位参与者发起的与一个或多个资产相关的实际交易。交易处理器在区块链上发起交易时使用，而且区块链的所有节点都证实了该交易并承担副作用。在 Hyperledger
中，会在区块链的所有节点中都调用交易处理器回调。一致性算法通过检查来确认所有节点都以相同方式处理交易，这可以确保账本和世界状态数据库（the world state database）得到一致的更新。在 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
转移到另一个人，该转移操作是作为在区块链上注册的一个交易来执行的。 下面的屏幕截图中所示的 PrivateTransferTransaction 类表示了 Hyperledger
Composer 中的这个交易：下面的 JSON 文档表示此交易的一个示例：可以在 的 model 文件夹中找到此示例的数据模型，其中使用不同的
.cto 文件描述了该模型。IBM ODM
中的 Vehicle Lifecycle 数据模型还需要建模数据，以供 IBM ODM 中的业务规则使用。IBM ODM 中有 3 个数据表示层：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 的 XOM 开始，Java 开发人员可以在 Rule Designer 中与业务分析师合作创建 BOM
和词汇表。请注意，Hyperledger Composer 提供了一个工具来利用域模型的 cto 文件生成 Java
表示（这可能是一个构建 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、卖方和买方的所有信息发布到区块链。假设交易是通过规则进行制约的，这些规则会检查交易是否存在欺诈。这些规则的逻辑很复杂，并由专家定义。发现新的欺诈模式时，专家（业务干系人）希望快速更改规则，以便在欺诈性交易提交到区块链时自动识别它们。交易会经历下图中所示的历程：一个外部系统（可能是一个业务流程或应用程序）对这个区块链应用程序使用 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，可使用它在链代码外执行 POST REST
调用，传递当前交易，以及所需的任何其他资产或参与者数据。Hyperledger Composer 将资源作为 REST 调用的参数传递到 JSON
文档中。IBM ODM 将决策服务公开为 REST API，该 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 + "/" + currentRulesetV
// 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 vehicle
var url = 'http://odmruntime_odm-runtime_1:9060/DecisionService/rest/' + rulesetP
var dsCallObject = factory.newResource(NS_DECISION, 'IsSuspiciousTransferDecisionService', "isSuspiciousTransfer");
dsCallObject.transaction = privateVehicleT
print("Calling ODM Decision Service: " + url);
return post( url, dsCallObject, {permitResourcesForRelationships: true, deduplicateResources: true});可以在
中查看本示例的代码。这个回调所处理的交易包装在一个专用对象中，并传递给该调用。这里引入了包装器对象，是为了让 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#f1-e2",
"seller": {
"$class": "composer.base.Person",
"$id": "resource:composer.base.Person#dan",
"ssn": "dan",
"firstName": "Dan",
"lastName": "Selman",
"gender": "MALE",
"nationalities": [
"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": [
"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#",
"vin": "",
"vehicleDetails": {
"$class": "org.vda.VehicleDetails",
"make": "Arium",
"modelType": "Nova",
"colour": "white",
"vin": "",
"taxationClass": "PETROL_CAR"
"vehicleStatus": "ACTIVE",
"owner": "resource:composer.base.Person#dan",
"logEntries": [
"$class": "org.vda.VehicleTransferLogEntry",
"vehicle": "resource:org.vda.Vehicle#",
"buyer": "resource:composer.base.Person#dan",
"timestamp": "T13:57:13.652Z"
"transactionId": "f1-e2",
"timestamp": "T13:57:23.121Z"
}决策服务的 XOM 应支持此有效负载。Hyperledger Composer 首先序列化对象，然后通过 ID 引用已序列化的对象。XOM 中的具体
JSON 注释可用于处理对象图去序列化。参见 vehicle-lifecycle-xom 项目的代码。 确保调用了决策服务的正确版本，因为决策逻辑的演化可能独立于智能合约中的代码。区块链网络中的所有节点都必须使用决策逻辑的同一个版本。生命周期示意图中描述了一种管理决策逻辑版本的方式。决策服务返回一个描述决策操作的 JSON 文档。如果输入 JSON 文档的格式取决于 Hyperledger Composer
和区块链应用程序数据模型的格式，那么答案的格式是自由的，并受 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.
} else if (response.body.result.status === "SUSPICION") {
vehicle.suspiciousMessage = response.body.result.
}实现决策逻辑决策逻辑是作为常规 IBM ODM 决策服务来实现的。 可以为一个决策服务定义多个入口点，以适应需要在智能合约中委托给 IBM ODM
的不同业务决策。一个入口点（对应于 IBM ODM 中的一个决策操作）是一个专门的规则集，它拥有一个签名并包含表示为业务规则的决策逻辑。决策的输入参数通常是一个来自 Hyperledger Composer
的交易，引用了完成决策所需的资产、参与者或历史交易。如果要传递更多数据，则需要在 Hyperledger Composer
中建模一个专门的资源对象（一个资产或概念），并将它填充到 Transaction Processor 中，然后再调用决策服务。输出参数是一个对象，它包含需要返回给智能合约的决策和任何数据。在本文的样本中，决策操作按照下图中所示的方式来定义入口点：在调用 post API 时，通过这个决策操作创建的 REST API 支持由 Hyperledger Composer
序列化的 JSON 输入。输出参数是一个包含 status 和 message 的数据结构，由业务规则填充，并以 JSON
文档形式返回给调用方。样本中的决策逻辑很简单：一个规则流（包含一条业务规则）和一个决策表，如下面的 3 个屏幕截图所示。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 Console、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 transactionId
o String resDeployerURL
// ruleapp name should be of the form &ruleapp&/&ruleset&
o String ruleAppName
o String ruleapp_version
o String ruleset_version
o String archive
o String managedXomURI
}一个专用的交易处理器在每个区块链节点上处理交易。它执行以下 3 个操作：将归档的文件存储在由区块链控制的世界状态数据库中：
asset RuleApp identified by ruleAppId
o String ruleAppId
// ruleapp name should be of the form &ruleapp&/&ruleset&
o String ruleAppName
o String ruleapp_version
o String ruleset_version
o String archive
}将用于给定决策服务的 RuleApp 或规则集的当前版本写入特定的资产
(RuleAppCurrentVersion) 中： asset RuleAppCurrentVersion identified by ruleAppName
// ruleapp name should be of the form &ruleapp&/&ruleset&
o String ruleAppName
o String ruleapp_version
o String ruleset_version
}该代码通过 Deployer facade 将 RuleApp 或规则集部署到节点的 Rule Execution
Server，并传入 Archive 二进制文件及版本信息。为了知道使用了规则集的哪个版本，交易处理器利用这个特定资产来查找此信息，并在调用决策服务时使用它对 REST API 进行参数化。如果某处出错且 RuleAppUpdated 交易需要回滚，也会回滚
Current Version 资产，并仍然使用决策服务的上一个版本。然后，将规则集的最新版本部署到 Rule
Execution Server，但从不使用它。可以调整此机制，避免将大型 RuleApps 二进制文件直接存储在账本中。账本可以存储 Ruleapp
的引用和一个哈希代码签名，智能合约可以使用该签名来检查是否修改了二进制文件。请注意，决策逻辑高度依赖于支持业务规则的 XOM。样本中演示了一种将 XOM 部署到区块链中运行的各种 Rule Execution Server
的类似机制。决策逻辑管理和制约对智能合约使用 IBM ODM
的一个关键优势是，业务干系人可使用广泛的工具来管理和制约智能合约的决策逻辑。根据每周或者甚至每日的市场变化或其他因素，决策逻辑的演化速度通常比应用程序的剩余部分更快。重要的是各参与方的代表能控制智能合约中的逻辑。如果智能合约实现了一个规定各方如何交换资产和价值的具体合约，各方必须在规则和生命周期上达成一致。例如，各方可能决定一起评审规则，协商内容，并协商应部署这些规则的时间。此协议可能需要一个明确定义的制约流程，并由每方开展多级评审和批准。IBM ODM 通过
及其业务控制台在此领域取得了突出成绩，如下图所示：尽管对于区块链平台，必须分布式地执行规则，但可以将管理环境集中在一起，使每方的业务干系人能够更容易地协作定义和管理其区块链应用程序的决策逻辑。IBM ODM
的核心原则之一是将业务干系人（包括策略经理、分析师、律师、会计、审计员）集合在一起，为他们提供工具，以便按他们习惯的方式表达和制约应用程序的决策逻辑。很快将有一篇文章重点介绍如何使用 Decision Center（和一个特定的 DevOps 流程）来管理并部署用 IBM ODM
实现的智能合约逻辑，敬请期待。 结束语IBM ODM
非常适合表达和制约智能合约中的规则。定义智能合约时，业务干系人必须参与其中，而且通过将智能合约的规则与应用程序代码分离，来自双方的业务干系人都能使用
Decision Center 等工具协作定义和制约各种规则。他们也可以快速响应变化，避免耗时的代码库更新流程。Vehicle Lifecycle 样本演示了如何结合使用 IBM ODM 和 Hyperledger Fabric
“连锁”执行智能合约决策逻辑，并利用 IBM ODM 的企业级规则引擎。在下一个区块链项目中，可以考虑对您的智能合约使用 IBM ODM。它天生就适合 Hyperledger Composer
和区块链环境。随着让业务干系人参与该流程，并寻找快速响应变化的方式，IBM ODM 的优势将变得特别重要。我们渴望听到您的集成 IBM ODM 和区块链的体验，以及任何其他需求。致谢非常感谢 Hyperledger Composer 团队成员为这次集成提供极大的帮助和热情支持。尤其要感谢 IBM 区块链团队的 Simon
Stone 的持续支持。还要感谢 Laurent Grateau、Philippe Bonnard 和 Jeremy Pichon 贡献本文的样本，感谢 Peter
Gilliver 和 Nicolas Sauterey 对本文的细心评审。
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=Middleware, Cloud computingArticleID=1049661ArticleTitle=通过业务规则让区块链智能合约更加智能publish-date=