Hyperledger Fabric周周记：Composer

在上周周记的结尾，我曾经说过本周要介绍Fabric的开发和应用。按照最开始的写做计划，我打算讲讲两种开发模式：直接使用Fabric API和利用Composer框架。可在通读完Composer的文档以后，我当即取消了原定计划，直接介绍Composer。

选择工具A而不是B通常状况下理由都很直接：简单易上手。以我我的为例，在翻完Fabric的文档以后，虽然对于Fabric的架构和组件了然于胸，但对于如何开发，其实仍是很模糊的。

为何会这样？

有两个缘由：

• 文档自己给出的开发范例（fabric-samples）缺少一个系统性的介绍。所谓系统性，说白了就是教科书性质的介绍，由一个简单的例子开始，层层递进，最终让读者全盘掌握。就当前的文档来讲，这一任务显然没有达到。
• 缺少聚焦，正如这篇Composer幻灯片（第四页）介绍的，有太多东西要操心了，对于真正须要关心的东西（业务逻辑）反而没有突出。

Composer刚好很是好的弥补了Fabric文档中这两个缺陷，从其文档构成能够很明显的看出来：

1. 给出Composer的总体性介绍
2. 手把手教会你们如何完成安装
3. 给出一个Hello World级别的例子
4. 如何进行单元测试
5. 如何部署到真实的Fabric环境

这种方式是我最喜欢的，对于开发者来说，他能很快创建起总体印象，而且树立起信心。

固然，文档好并不足以吸引开发者成为粉丝。让其成为开发首选的理由只有一个：对开发者友好。

Composer的开发者友好性表如今如下几个方面。

1. 良好的抽象

Chaincode是Fabric开发的核心，但看过了例子以后，说真的，很容易让开发者打退堂鼓。由于太底层了！让人有一种回到用Servlet开发Java Web应用的感受。

Composer在这一点上作得很好，它的Runtime内置了通用的Chaincode。使用它开发根本不会感到Chaincode的存在。并且整个过程几乎跟你开发一个普通的CRUD Web应用无异！在开发者看来，他就是在写普通的JavaScript函数。

这篇文章给出了两种方式（Chaincode和Composer）的开发范例，在结尾处提到二者的代码行差别：

This ±10x reduction in the number of lines of code when Go and Composer solutions are compared is fairly consistent across several samples.

2. 统一的工程化体验

实际的开发不是书上的简单例子，并且涉及多人，若是没有良好的开发规范，很难产生好的结果。从Fabric文档中，你没法看出一个区块链应用的项目工程应该是什么样子，只能看到一个个零散的代码文件。显然没法知足工程上的要求。

就一个Fabric区块链项目来说，它包含：

• 存储于帐本上的Asset
• 操做Asset的Chaincode
• 访问Chaincode的Client App
• 应用相关的权限和成员

Composer很是完美地给出了解决方案，将整个开发过程分红3部分，每一部分都有对应的命令行工具，提供统一的开发体验：

1. Business Network，业务逻辑，其中包括如下组件：

   • asset model，存储于帐本上的Asset，其过程跟设计数据库的表没什么两样。
   • transaction function，对应Chaincode中的各个方法，但对于开发者来说彻底透明。
   • acl文件，权限定义。
   • query，命名查询，供transaction function调用。

2. Rest Server

   • 将发布到Fabric的Business Network暴露成Restful API，供外部调用，彻底语言中立。

3. Client App

   • 严格来说，这一步并不是必要，由于既然上面已经有了语言中立的API，理论上能够用任何框架来开发相应的Client APP。但Composer提供了一个基于Angular的模板帮助加速这一过程。

怎么样，这个过程是否是很是眼熟？经过开发框架固化的开发过程可让开发人员更快的上手，而且统一在相同的“big picture”之下。而且，上述的各个组件对于有经验的开发者并不陌生，有助于快速理解。

你们能够在文档中的这个例子中看到完整的过程。

3. 内建测试的支持

即使是水平再烂的开发，他也但愿能验证一下本身写的东西才好意思交出去。然而，对于Fabric应用来说，这可不是件容易的事情，由于部署太繁琐了。

Composer再次拯救了开发！

Composer内置的runtime为测试提供了良好的支持，因为良好的抽象，这个runtime既能够是实际的Fabric，也能够是一个内置的Node.js进程。然后者则是为测试而生的。更好的是，这一切彻底对开发者透明，开发的上层代码彻底不须要改动。

对于上进心更强，想要实现自动化测试的同窗，这里有一个例子能够参考。

4. 便捷的CLI工具

相比起Fabric零散的命令集合，Composer提供了便捷的CLI，统一了开发、管理和运营任务。开发者能够利用它方便的实现：

• 应用打包和部署
• 应用脚手架生成
• 环境管理

让开发更加聚焦于手头的任务，而不是为了准备工做而分散太多精力。

前面说了Composer的那么多好处，接下来讲说Composer的局限性。就目前的文档来看，我没有看到如何用它来开发System Chaincode的例子。并且，我怀疑当前的版本并不支持。所以，假如你像要开发的System Chaincode，Composer可能并不能知足你的须要。而这一任务应该算不上一个大众型任务。

或许你会奇怪，为何我没有展现一个实际的例子来证实我说的这些好处。这只能怪Composer的文档写得太好了，基本是傻瓜式教程，按照它的步骤，基本不会出现什么问题。既然是这样，干吗还要花时间在这个上面呢？

说到底，本文的目的只有一个：用Composer来开发将来的Fabric应用，不要再自虐了！同时，最新一期的Thoughtworks雷达也将其列为“TRIAL”并给出了下面的评语：

... However, the programming abstraction of chaincode is relatively low level given it manipulates the state of the ledger directly. Moreover, it always takes a lot of time to set up infrastructure before writing the first line of blockchain code. Hyperledger Composer, which builds on top of Fabric, accelerates the process of turning ideas into software. Composer provides DSLs to model business assets, define access control and build a business network. By using Composer you could quickly validate your idea through a browser without setting up any infrastructure.

最后，请你们记住：即便Composer下降了开发的门槛，但仍是要记得认真学习Fabric文档哟！