Hyperledger Composer 被弃用的原因是什么？
What are reasons for the deprecation of Hyperledger Composer?
Hyperledger Composer 是一个用于加速业务网络应用程序开发过程的平台。为什么它被弃用，用于开发 BNA 的 composer 有哪些替代方案？
根据 IBM 的说法，Hyperledger Composer 存在以下三个问题：
Composer 从一开始就被设计为支持多个区块链平台，而不仅仅是 Fabric - 但这种设计是有代价的。这种设计意味着存在两种完全不同的编程模型——Fabric 编程模型（链码）和 Composer 编程模型（业务网络）。这给用户造成了很大的困惑，他们需要在这两种编程模型之间做一个 "choice"，两者之间几乎没有相似之处。在这种特殊情况下，选择是一件坏事，许多用户在初始探索或 POC 阶段后选择不使用 "optional" 部分。
这种设计也让我们更难采用和公开最新的 Fabric 功能。例如，我们目前不断收到的问题之一是 "when can I use the Fabric v1.2 private data feature with Composer?"。虽然我们已经采取了一些步骤 (getNativeAPI) 来帮助解决这个问题，但是当我们试图维护一个使我们的区块链平台独立的设计时，我们很难跟上并与 Fabric 中的最新功能保持一致。这意味着用户可以理解地停止使用 Composer，转而使用 Fabric 进行开发。
最后，那些使用过 Composer 的人可能会喜欢我们简单易用的 API（JavaScript 和 REST）来构建与区块链交互的应用程序网络。幕后有很多代码来启用这些实际上不属于 Composer 的 API。我们最终所做的是掩饰底层的低级 Fabric API，而不是将改进直接推入这些 Fabric API。今天使用 Fabric API 提交交易需要大约 50 行代码，而在 Composer 中需要大约 5 行代码，这是错误的——Composer 的价值不应该仅仅来自于让 Fabric 更易于使用。
详情请阅读this。
Composer 的唯一问题是 IBM 等放弃了它。 Composer 是（在某种程度上仍然是）Fabric 用户为潜在客户提供概念验证 (POC) 业务解决方案的有效方式——对于想要证明内部预算合理以尝试在内部部署项目的用户而言。使用真实世界的业务逻辑。
Composer 应该是位于 Fabric 之上的业务逻辑堆栈，允许用户进行部署而无需深入研究杂草。
我不需要知道我需要每个组织的订购者或 CA -- 但我需要知道我有 6 个组织将参与我的网络，其中两个需要使用私有进行通信数据与其他渠道分开，我确实需要知道我的业务用例规则是什么。自动化工具或脚本应该允许我在**本地*启动内部网络并从那里开始。是的，我需要了解结构细节或手头有人能够调整我的网络——但 Composer 让我 POC 这些。
没有——零——相当于 Fabric——事实上，没有工具可以让人们轻松地克隆 fabric 样本供自己使用，并轻松地插入他们自己的网络/组织设置。
如果您想在不进入 IBM 云的情况下设置内部独立网络，那么 IBM VS Code 插件工具就是垃圾。真的吗？认真的吗？
如果没有 Composer——或类似的工具——投资 Hyperledger Fabric 是一场巨大的财务和资源赌博，也是一场时间浪费。时期。代码几乎每周都会更改，存在重大错误，社区不愿修复有时明显的文档问题和解决硬件大小问题。更不用说指派工程师和软件架构师 测试 尚未准备就绪的软件的成本了。忘记只需要花多少时间来熟悉文档和结构组件就能够构建企业级网络。
关于上述回答的要点：
应该有两种不同的编程模型，因为从业务部署的角度来看，BNA 方法有效。说在 Fabric "confuses" 用户之上有一个 Composer 堆栈 API 就像那句老话 "if the customer is too stupid to know how to use the deeply technical product the customer is too stupid" —— 这从根本上是错误的。
我不应该每次上车并按下启动按钮时都更新我对内燃机的了解——我知道我必须去哪里，我将如何到达那里并知道如何操作发动机车辆这样做。如果我想调整或以其他方式修改车辆、它的发动机、电气系统等。我会拿出相当于织物文档的文件并学习使用这些工具或聘请已经知道如何使用它们的机械师。
并且设计没有使采用和公开 Fabric 的最新功能变得更加困难——开发团队未能做到的是在 Composer 中锁定实现这些功能发布 Fabric。这是开发团队部署问题，而不是最终用户问题。并且说 - 不是暗示，说 - 社区没有站出来是一堆废话。如果 IBM 想要支持它，它本来可以——它拥有这样做的人员、财务和全球资源。
在现实世界中，企业应用程序的区块链/分布式账本可行性的商业观点并不热情——事实上，充其量是值得怀疑的。我们从全球（北美、欧洲、中东和非洲）的潜在客户那里获得的第一顺从性是没有人能够充分证明这一点的。不是开玩笑——通过终端 window 向潜在客户展示汽车所有权可以从一个用户转移到另一个用户是否可以解决他们的业务需求？真的吗？通过终端 window 不少于。
为了让我们 POC 一个复杂的用例并能够支持餐巾纸演示，我们现在必须编写整个织物应用程序，或者希望我们可以通过修复织物样本示例来拼凑——并在此过程中完成示例中的错误。
我们已经花费了数百小时构建 POC 用例，只是为了让 Composer 靠边站，Fabric 版本 x 不适用于刚刚发布的 Fabric 版本 xx，必备软件版本发生变化或出现问题上帝保佑 Raft 或 Kafka 在 "alpha" 下一个最伟大的 Fabric 发布之前还没有经过全面测试。等等等等等等
对于上面最后一点的作者——Composer 的价值绝对应该是让 Fabric 更易于使用 用于基本网络站和 POC。没有人认为使用 Fabric 涉足杂草是一件坏事——但从 BUSINESS 的角度来看，在提交项目之前拥有像 Composer 到 POC 这样的东西是必不可少的。
我们会继续使用 Fabric 并希望开发团队赶上现实世界的业务需求 - 可能。我们为员工安排的所有 IBM 和其他作曲家培训课程大部分都是浪费。
所以，来自一个非常努力地证明 Hyperledger 和 Fabric 的优点的团队——请不要在将来解雇 像 Composer 这样的东西。因为如果这只是下一件被搁置的大事，我们就不会投资于人员和培训他们。我部署了 15 个团队，在全球范围内处理潜在的用例和实现——试图调整并向他们推送以客户为中心的用例演示，这一直是 Hyperledger Fabric 的地狱。
个人意见比较小。 GR
我认为前面的评论中的原因很清楚，但对于你的最后一个问题，数百名开发人员正在采取的一个选择是使用 Convector。 Convector 是一个 Hyperledger Labs 项目，它是在 Hyperledger Composer 被弃用之前创建的，但看起来与开发人员相似。它遵循模型控制器模式（类似于 Composer 资产和交易），但它会本地编译为 Fabric 代码，并且不会创建 运行time。
使用 Convector 创建的代码可以用于生产，包括各种帮助程序，如 API 生成器、开发环境引导程序（创建本地网络的一个命令）、使模型更可预测的装饰器，默认单元测试（CI/CD 友好），数十个代码示例和实际项目供参考。
Convector 拥有 community 数百名开发人员，其中一些人很容易从 Composer 迁移过来，其他人则是他们了解 Fabric 的第一个工具。为什么 Convector 不会很快消失，即使它看起来和感觉上与 Composer 相似，主要区别在于它的解耦架构和使用能力以及 运行 原生与 Fabric 的使用。
如果您想加入社区，人们会帮助您从 Composer 迁移到 Convector。你可以 join here.
Here's a blog post mapping concepts from Hyperledger Composer to Convector.
关于 Convector 的小回顾：
- Hyperledger Composer 看起来很熟悉。
- 可以将相同的代码投入生产。
- 运行 本机并使用 Fabric 本机扩展。
- 工具生态系统：单元测试、开发人员环境、API 生成器等
- Discord 中伟大而友好的社区。
--
免责声明：我与 Convector 的开发者 Covalent 一起工作。 Convector 是一个免费的开源 Apache 2.0 项目组。
Hyperledger Composer 是一个用于加速业务网络应用程序开发过程的平台。为什么它被弃用，用于开发 BNA 的 composer 有哪些替代方案？
根据 IBM 的说法，Hyperledger Composer 存在以下三个问题：
Composer 从一开始就被设计为支持多个区块链平台，而不仅仅是 Fabric - 但这种设计是有代价的。这种设计意味着存在两种完全不同的编程模型——Fabric 编程模型（链码）和 Composer 编程模型（业务网络）。这给用户造成了很大的困惑，他们需要在这两种编程模型之间做一个 "choice"，两者之间几乎没有相似之处。在这种特殊情况下，选择是一件坏事，许多用户在初始探索或 POC 阶段后选择不使用 "optional" 部分。
这种设计也让我们更难采用和公开最新的 Fabric 功能。例如，我们目前不断收到的问题之一是 "when can I use the Fabric v1.2 private data feature with Composer?"。虽然我们已经采取了一些步骤 (getNativeAPI) 来帮助解决这个问题，但是当我们试图维护一个使我们的区块链平台独立的设计时，我们很难跟上并与 Fabric 中的最新功能保持一致。这意味着用户可以理解地停止使用 Composer，转而使用 Fabric 进行开发。
最后，那些使用过 Composer 的人可能会喜欢我们简单易用的 API（JavaScript 和 REST）来构建与区块链交互的应用程序网络。幕后有很多代码来启用这些实际上不属于 Composer 的 API。我们最终所做的是掩饰底层的低级 Fabric API，而不是将改进直接推入这些 Fabric API。今天使用 Fabric API 提交交易需要大约 50 行代码，而在 Composer 中需要大约 5 行代码，这是错误的——Composer 的价值不应该仅仅来自于让 Fabric 更易于使用。
详情请阅读this。
Composer 的唯一问题是 IBM 等放弃了它。 Composer 是（在某种程度上仍然是）Fabric 用户为潜在客户提供概念验证 (POC) 业务解决方案的有效方式——对于想要证明内部预算合理以尝试在内部部署项目的用户而言。使用真实世界的业务逻辑。
Composer 应该是位于 Fabric 之上的业务逻辑堆栈，允许用户进行部署而无需深入研究杂草。
我不需要知道我需要每个组织的订购者或 CA -- 但我需要知道我有 6 个组织将参与我的网络，其中两个需要使用私有进行通信数据与其他渠道分开，我确实需要知道我的业务用例规则是什么。自动化工具或脚本应该允许我在**本地*启动内部网络并从那里开始。是的，我需要了解结构细节或手头有人能够调整我的网络——但 Composer 让我 POC 这些。
没有——零——相当于 Fabric——事实上，没有工具可以让人们轻松地克隆 fabric 样本供自己使用，并轻松地插入他们自己的网络/组织设置。
如果您想在不进入 IBM 云的情况下设置内部独立网络，那么 IBM VS Code 插件工具就是垃圾。真的吗？认真的吗？
如果没有 Composer——或类似的工具——投资 Hyperledger Fabric 是一场巨大的财务和资源赌博，也是一场时间浪费。时期。代码几乎每周都会更改，存在重大错误，社区不愿修复有时明显的文档问题和解决硬件大小问题。更不用说指派工程师和软件架构师 测试 尚未准备就绪的软件的成本了。忘记只需要花多少时间来熟悉文档和结构组件就能够构建企业级网络。
关于上述回答的要点：
应该有两种不同的编程模型，因为从业务部署的角度来看，BNA 方法有效。说在 Fabric "confuses" 用户之上有一个 Composer 堆栈 API 就像那句老话 "if the customer is too stupid to know how to use the deeply technical product the customer is too stupid" —— 这从根本上是错误的。
我不应该每次上车并按下启动按钮时都更新我对内燃机的了解——我知道我必须去哪里，我将如何到达那里并知道如何操作发动机车辆这样做。如果我想调整或以其他方式修改车辆、它的发动机、电气系统等。我会拿出相当于织物文档的文件并学习使用这些工具或聘请已经知道如何使用它们的机械师。
并且设计没有使采用和公开 Fabric 的最新功能变得更加困难——开发团队未能做到的是在 Composer 中锁定实现这些功能发布 Fabric。这是开发团队部署问题，而不是最终用户问题。并且说 - 不是暗示，说 - 社区没有站出来是一堆废话。如果 IBM 想要支持它，它本来可以——它拥有这样做的人员、财务和全球资源。
在现实世界中，企业应用程序的区块链/分布式账本可行性的商业观点并不热情——事实上，充其量是值得怀疑的。我们从全球（北美、欧洲、中东和非洲）的潜在客户那里获得的第一顺从性是没有人能够充分证明这一点的。不是开玩笑——通过终端 window 向潜在客户展示汽车所有权可以从一个用户转移到另一个用户是否可以解决他们的业务需求？真的吗？通过终端 window 不少于。
为了让我们 POC 一个复杂的用例并能够支持餐巾纸演示，我们现在必须编写整个织物应用程序，或者希望我们可以通过修复织物样本示例来拼凑——并在此过程中完成示例中的错误。
我们已经花费了数百小时构建 POC 用例，只是为了让 Composer 靠边站，Fabric 版本 x 不适用于刚刚发布的 Fabric 版本 xx，必备软件版本发生变化或出现问题上帝保佑 Raft 或 Kafka 在 "alpha" 下一个最伟大的 Fabric 发布之前还没有经过全面测试。等等等等等等
对于上面最后一点的作者——Composer 的价值绝对应该是让 Fabric 更易于使用 用于基本网络站和 POC。没有人认为使用 Fabric 涉足杂草是一件坏事——但从 BUSINESS 的角度来看，在提交项目之前拥有像 Composer 到 POC 这样的东西是必不可少的。
我们会继续使用 Fabric 并希望开发团队赶上现实世界的业务需求 - 可能。我们为员工安排的所有 IBM 和其他作曲家培训课程大部分都是浪费。
所以，来自一个非常努力地证明 Hyperledger 和 Fabric 的优点的团队——请不要在将来解雇 像 Composer 这样的东西。因为如果这只是下一件被搁置的大事，我们就不会投资于人员和培训他们。我部署了 15 个团队，在全球范围内处理潜在的用例和实现——试图调整并向他们推送以客户为中心的用例演示，这一直是 Hyperledger Fabric 的地狱。
个人意见比较小。 GR
我认为前面的评论中的原因很清楚，但对于你的最后一个问题，数百名开发人员正在采取的一个选择是使用 Convector。 Convector 是一个 Hyperledger Labs 项目，它是在 Hyperledger Composer 被弃用之前创建的，但看起来与开发人员相似。它遵循模型控制器模式（类似于 Composer 资产和交易），但它会本地编译为 Fabric 代码，并且不会创建 运行time。
使用 Convector 创建的代码可以用于生产，包括各种帮助程序，如 API 生成器、开发环境引导程序（创建本地网络的一个命令）、使模型更可预测的装饰器，默认单元测试（CI/CD 友好），数十个代码示例和实际项目供参考。
Convector 拥有 community 数百名开发人员，其中一些人很容易从 Composer 迁移过来，其他人则是他们了解 Fabric 的第一个工具。为什么 Convector 不会很快消失，即使它看起来和感觉上与 Composer 相似，主要区别在于它的解耦架构和使用能力以及 运行 原生与 Fabric 的使用。
如果您想加入社区，人们会帮助您从 Composer 迁移到 Convector。你可以 join here.
Here's a blog post mapping concepts from Hyperledger Composer to Convector.
关于 Convector 的小回顾：
- Hyperledger Composer 看起来很熟悉。
- 可以将相同的代码投入生产。
- 运行 本机并使用 Fabric 本机扩展。
- 工具生态系统：单元测试、开发人员环境、API 生成器等
- Discord 中伟大而友好的社区。
--
免责声明：我与 Convector 的开发者 Covalent 一起工作。 Convector 是一个免费的开源 Apache 2.0 项目组。