拒绝使用Hyperledger Composer的原因是什么？

Question

Hyperledger Composer是一个用于加速业务网络应用程序开发过程的平台。为什么不推荐使用BNA，而作曲家可以替代BNA？

Answer 1

Composer 的唯一问题是 IBM 等人放弃了它。Composer 是（在某种程度上仍然是）Fabric 用户为潜在客户提供概念验证 (POC) 业务解决方案的有效方式——以及希望证明内部预算合理以尝试在内部部署项目的用户。使用现实世界的业务逻辑。

Composer 应该是位于 Fabric 之上的业务逻辑堆栈，并允许用户无需深入研究即可进行部署。

我不需要知道每个组织都需要一个订购者或 CA——但我确实需要知道我有 6 个组织将参与我的网络，其中两个需要使用单独通道上的私有数据进行通信来自其他人，我确实需要知道我的业务用例规则是什么。自动化工具或脚本应该允许我在 **本地* 启动内部网络并从那里开始。是的，我需要知道结构细节或手头有人可以调整我的网络——但 Composer 让我 POC 这些。

没有——就像零一样——Fabric 的等价物——事实上，没有任何工具可以让人们轻松地克隆 Fabric 样本供他们自己使用，并轻松插入他们自己的网络/组织设置。

如果您想在不访问 IBM 云的情况下设置内部独立网络，那么 IBM VS Code 插件工具就是垃圾。真的吗？严重地？

如果没有 Composer —— 或类似的工具 —— 投资 Hyperledger Fabric 是一场巨大的财务和资源赌博以及时间消耗。时期。代码几乎每周更改一次，存在重大错误，社区不愿修复有时明显的文档问题并解决硬件大小问题。更不用说指派工程师和软件架构师来测试尚未准备就绪的软件的成本了。忘记熟悉文档和结构组件以构建企业级网络所需的时间。

关于上面答案中提出的观点：

应该有两种不同的编程模型，因为 BNA 方法是从业务部署的角度工作的。说在 Fabric 之上拥有一个带有 API 的 Composer 堆栈会“迷惑”用户，就像一句老话“如果客户太愚蠢不知道如何使用深度技术产品，那么客户就太愚蠢了”——这是根本错误的.

我不应该每次进入车辆并按下启动按钮时都必须刷​​新我对内燃机的了解——我知道我必须去哪里，我将如何到达那里，并且知道如何操作车辆来这样做。如果我想调整或以其他方式修改车辆、发动机、电气系统等，我会拿出相当于织物的文档并学习使用这些工具或聘请已经知道如何使用它们的机械师。

而且该设计并没有使采用和公开 Fabric 的最新功能变得更加困难——开发团队未能做到的是在 Composer 中与 Fabric 的发布同步实现这些功能。这是一个开发团队部署问题，而不是最终用户问题。并且说——不是暗示，说——社区没有站出来是一堆废话。如果 IBM 想要支持它，它可以拥有——它拥有这样做的人员、财务和全球资源。

在现实世界的环境中，企业应用程序的区块链/分布式账本可行性的商业前景并不乐观——事实上，充其量是值得怀疑的。我们从全球（北美、欧洲、中东和非洲）的潜在客户那里获得的排名第一的合规性是没有人能够充分证明这一点的。不开玩笑——通过终端窗口向潜在客户展示汽车所有权可以从一个用户转移到另一个用户是否能解决他们的业务需求？真的吗？通过终端窗口不少。

为了让我们对一个复杂的用例进行 POC 并能够支持餐巾纸演示，我们现在必须编写整个结构应用程序，或者希望我们可以修补一个结构示例示例——并在此过程中解决示例中的错误。

我们花费了数百小时来构建 POC 用例只是为了让 Composer 顺其自然，Fabric 版本 x 不适用于刚刚发布的 Fabric 版本 xx，先决条件软件版本发生变化或上帝禁止 Raft 或 Kafka 出现问题在“alpha”下一个最重要的 Fabric 发布之前尚未经过全面测试。等等等等等等。

对于上面的作者最后一点——Composer的价值绝对应该是让 Fabric 更容易用于基本的网络站立和 POC。没有人认为使用 Fabric 陷入困境是一件坏事——但从商业角度来看，在提交项目之前将 Composer 之类的东西用于 POC，这是必不可少的。

我们是否会继续与 Fabric 合作，并希望开发团队能够赶上现实世界的业务需求——很可能。我们为员工提供的大部分 IBM 和其他作曲家培训课程都是浪费。

所以，来自一个非常努力地证明 Hyperledger 和 Fabric 的优点的团队——请不要在未来解雇像 Composer这样的东西。因为如果这只是下一个被搁置的大事，我们不会投资于人员并培训他们。我有 15 个团队部署了潜在客户，他们在全球范围内工作的潜在用例和实现——试图调整和推送以客户为中心的用例演示给他们已经是 Hyperledger Fabric 的地狱。

一个人的意见比较小。GR

Answer 2

根据IBM的说法，Hyperledger Composer存在以下三个问题：

• Composer从一开始就被设计为支持多个区块链平台，而不仅仅是Fabric-但是这种设计需要付出一定的代价。这种设计意味着有两种完全不同的编程模型-Fabric编程模型（链码）和Composer编程模型（业务网络）。这给用户带来了极大的困惑，他们需要在两个编程模型之间做出“选择”，而两者之间的相似性很小。在这种特殊情况下，选择是一件坏事，许多用户选择在最初的探索或POC阶段之后不使用“可选”部分。

• 这种设计也使我们难以采用和公开最新的Fabric功能。例如，当前我们不断遇到的问题之一是“何时可以在Composer中使用Fabric v1.2私有数据功能？”。尽管我们已经采取了一些措施（getNativeAPI）来解决此问题，但是当我们试图保持使区块链平台保持独立的设计时，我们很难跟上Fabric的最新功能并与之保持一致。可以理解的是，这意味着用户已经停止使用Composer，而转而使用Fabric进行开发。

• 最后，使用Composer的人可能会喜欢我们简单，易于使用的API（JavaScript和REST），用于构建与区块链网络交互的应用程序。幕后有很多代码可以启用这些实际上不属于Composer的API。我们最终要做的是掩盖底层的底层Fabric API，而不是直接将改进推送到这些Fabric API中。如今，使用Fabric API提交事务需要约50行代码，而在Composer中则需要约5行代码，这是错误的-Composer的价值不应该来自于使Fabric易于使用。

有关详细信息，请阅读此内容。