汉口企业制作网站的,网站建设公司怎样布局,学校网站建设配套制度,f1意大利站最新排名pbfunc外部扩展函数Corda 4于上周#xff08;2月21日#xff09;发布#xff0c;带来了大量的新功能#xff0c;使Corda更加令人愉快。 老实说#xff0c;我有点假设有很多新功能。 我快速浏览了变更日志#xff0c;主要是看到我的贡献被引用#xff0c;但是我记得看到很… pbfunc外部扩展函数 Corda 4于上周2月21日发布带来了大量的新功能使Corda更加令人愉快。 老实说我有点假设有很多新功能。 我快速浏览了变更日志主要是看到我的贡献被引用但是我记得看到很多文本行。 那一定是一件好事吧 无论如何这些功能之一就是能够扩展和覆盖流程。 当您意识到Corda用Kotlin编写并完全继承了继承性时听起来并不是很花哨对于Java也是如此。 但是不仅如此。 Corda需要将“发起流程”映射到与其响应的交易对手流程。 当两方使用相同的CorDapp时这很好。 在这种情况下不会增加任何额外的复杂性。 另一方面如果交易对手希望在收到交易后将一些数据发送到外部系统他们该怎么做 原始的CorDapp不了解或不关心此系统因此无法满足这些需求。 能够解决这类问题使开发人员可以在现有的CorDapps的基础上进行构建并使它们适应于其用例。 此外一旦制定了良好的实践扩展第三方CorDapps将变得更加容易并且在其他人已经解决了部分问题的同时不再需要开发团队不断重新发明轮子。 显然这假定可以访问这些外部CorDapp但这完全是可能的。 特别是在R3 Marketplace已经展示了一个集合的情况下。 在本文中我们将专注于扩展和覆盖流程。 此外我们将采用两种不同观点的观点。 CorDapp的开发人员/维护人员 想要使用和改编现有CorDapp的开发人员 为了使该过程正常进行双方都必须努力以适当的方式编写其应用程序以便可以利用其收益。 我们将首先查看原始CorDapp必须包含的内容然后是开发人员必须进行扩展的内容。 在我们进行下一步之前这里是指向有关扩展和覆盖流程的官方文档的链接。 编写基本流程以允许扩展 以一种易于扩展的方式编写CorDapp可能需要进行大量思考。 这在很大程度上取决于CorDapp维护人员要实现的目标。 为开发人员提供一种扩展CorDapp的方式以便他们可以将数据发送到外部系统或添加自己的日志记录这不会造成任何问题。 另一方面允许更改事务的内容或将事务的内容发送给谁将需要更多的考虑以确保不滥用CorDapp。 我希望在以后的帖子中进一步探讨这个主题。 出于本文的目的我们将介绍更简单的选项。 让我们直接进入因为到目前为止有很多文本没有代码。 下面是将充当“基本”流的SendMessageFlow 它将在后面的部分中进行扩展 InitiatingFlow
open class SendMessageFlow(private val message: MessageState) :FlowLogicSignedTransaction() {open fun preTransactionBuild() {// to be implemented by sub type flows - otherwise do nothing}open fun preSignaturesCollected(transaction: SignedTransaction) {// to be implemented by sub type flows - otherwise do nothing}open fun postSignaturesCollected(transaction: SignedTransaction) {// to be implemented by sub type flows - otherwise do nothing}open fun postTransactionCommitted(transaction: SignedTransaction) {// to be implemented by sub type flows - otherwise do nothing}Suspendablefinal override fun call(): SignedTransaction {logger.info(Started sending message ${message.contents})preTransactionBuild()val tx verifyAndSign(transaction())preSignaturesCollected(tx)val sessions listOf(initiateFlow(message.recipient))val stx collectSignature(tx, sessions)postSignaturesCollected(stx)return subFlow(FinalityFlow(stx, sessions)).also {logger.info(Finished sending message ${message.contents})postTransactionCommitted(it)}}// collectSignature// verifyAndSign// transaction
} 我删除了一些功能因此我们可以专注于重要的事情。 允许扩展此类的第一步甚至有时很重要的步骤是它是open 。 这更像是Kotlin而不是Java因为Kotlin中的所有类默认都是final 。 如果您使用Java编写此代码则只需忽略最后几句话 接下来有一系列可以被覆盖的功能。 每个功能已放置在Flow主要执行程序内的适当位置。 Flow运行时将调用它们。 目前由于没有为CorDapp开发人员提供任何使用因此为他们提供了空的实现。 关于open功能。 您可以命名它们或将它们放置在任何需要的位置。 我认为这些功能对于希望在基本应用程序提供的内容上增加额外可追溯性的开发人员很有用。 深入了解更多细节。 call函数已被final 与Java中相同以防止覆盖Flow的全部内容。 如果有人想采用您的Flow并完全取代其“主要”功能那有什么意义呢 对我来说这似乎有点狡猾。 为了消除这种可能性将其final是明智之举。 稍后我们将研究如何将此Flow子类化。 下面是与SendMessageResponder交互的SendMessageFlow 。 它遵循与上述相同的概念因此在以后我仅将其作为参考 InitiatedBy(SendMessageFlow::class)
open class SendMessageResponder(private val session: FlowSession) : FlowLogicUnit() {open fun postTransactionSigned(transaction: SignedTransaction) {// to be implemented by sub type flows - otherwise do nothing}open fun postTransactionCommitted(transaction: SignedTransaction) {// to be implemented by sub type flows - otherwise do nothing}Suspendablefinal override fun call() {val stx subFlow(object : SignTransactionFlow(session) {override fun checkTransaction(stx: SignedTransaction) {}})postTransactionSigned(stx)val committed subFlow(ReceiveFinalityFlow(otherSideSession session,expectedTxId stx.id))postTransactionCommitted(committed)}
}扩展现有的启动流 在本节中我们将看到开发人员如何利用在上一个Flow上完成的工作。 它已经具有所有必需的功能。 唯一缺少的是开发人员想要添加的少量额外的可跟踪性。这要归功于基本Flow所添加的功能。 这不会造成任何问题。 让我们从扩展启动流开始。 这样做的要求如下 扩展基础InitiatingFlow 不要添加InitiatingFlow到新的流程错误会发生如果你这样做 引用基本Flow的构造函数Java中的super 覆盖任何所需的功能 调用新流程而不是基本流程 阅读该列表后您可能已经意识到这几乎是对面向对象语言例如Kotlin和Java中继承的描述。 Corda内可能还有更多事情要做但是从您的角度来看您只是像往常一样编写普通的面向对象代码。 遵循这些要求我们可以看到扩展的Flow可能是什么样的 StartableByRPC
class CassandraSendMessageFlow(private val message: MessageState) :SendMessageFlow(message) {override fun preTransactionBuild() {serviceHub.cordaService(MessageRepository::class.java).save(message,sender true,committed false)logger.info(Starting transaction for message: $message)}override fun preSignaturesCollected(transaction: SignedTransaction) {val keys transaction.requiredSigningKeys - ourIdentity.owningKeylogger.info(Collecting signatures from $keys for transaction for message: $message)}override fun postSignaturesCollected(transaction: SignedTransaction) {logger.info(Collected signatures for transaction for message: $message)}override fun postTransactionCommitted(transaction: SignedTransaction) {serviceHub.cordaService(MessageRepository::class.java).save(message,sender true,committed true)logger.info(Committed transaction for message: $message)}
} 我留下了实现我所谈论的额外可追溯性的所有嘈杂函数但这是由于没有它们的类将有多么空。 由于不需要call 。 此流程仅需要覆盖open功能。 老实说根本不需要覆盖它们它们是可选的。 如果需要此流可以覆盖单个函数然后将其保留为空。 是否满足上述所有要求 CassandraSendMessageFlow扩展了SendMessageFlow 看不到InitiatingFlow 在Kotlin中无论如何都必须调用super构造函数这样就完成了 在这种情况下所有功能都被覆盖 我们还没有走这么远 好的到目前为止是4/5。 那是一个很好的开始。 要划掉列表中的最后一项我们需要查看其调用方式。 以下是调用基本SendMessageFlow和CassandraSendMessageFlow扩展Flow的代码片段。 从SendMessageFlow开始 proxy.startFlow(::SendMessageFlow, messageState) 其次是CassandraSendMessageFlow proxy.startFlow(::CassandraSendMessageFlow, messageState) 注意区别吗 在这种情况下仅流的名称已更改。 没有其他的。 这两个代码段都是完全有效的。 仍然允许调用原始的SendMessageFlow 。 请记住从我们的角度来看它只是普通的面向对象代码。 它不会在扩展的Flow中添加多余的代码但是它仍然可以执行而不会出现问题。 完成此步骤符合扩展InitiatingFlow的最后要求。 在结束本节之前这里是Corda文档中需要记住的重要信息 “您必须确保子类中的发送/接收/子流的顺序与父类兼容。” 我将把它放在以下所有部分中因为不遵循这将导致您的流程失败。 扩展响应者流程 扩展响应者流的方式与扩展InitiatingFlow流的方式非常相似。 唯一的区别是它的调用方式。 如文档中所述 “ Corda会检测到 BaseResponder 和 SubResponder 都已配置为响应发起方。 然后Corda将计算到 FlowLogic 的跃点 并选择距离最远的实现即子类化最多的实现。” “最子类化”的陈述是本文的重要内容。 因此从开发人员的角度来看他们所需要做的就是扩展外部基本响应程序流仅此而已。 我非常喜欢之前的需求列表因此让我们再看一遍扩展响应者流程 扩展基础InitiatedBy /响应者流 将InitiatedBy添加到新流程 引用基本Flow的构造函数Java中的super 覆盖任何所需的功能 如果您保持警惕您可能已经注意到没有提到如何调用它。 扩展的“响应者流”不需要在其他任何地方调用或引用。 Corda将尽一切努力将所有物品路由到正确的位置。 可以肯定的是让我们快速看一个例子 InitiatedBy(SendMessageFlow::class)
class CassandraSendMessageResponder(session: FlowSession) :SendMessageResponder(session) {override fun postTransactionSigned(transaction: SignedTransaction) {val message transaction.coreTransaction.outputsOfTypeMessageState().single()logger.info(Signed transaction for message: $message)}override fun postTransactionCommitted(transaction: SignedTransaction) {val message transaction.coreTransaction.outputsOfTypeMessageState().single()serviceHub.cordaService(MessageRepository::class.java).save(message,sender false,committed true)logger.info(Committed transaction for message: $message)}
} 此外让我们再次回顾“最子类化”的说法。 CassandraSendMessageResponder是SendMessageResponder的子类因此由Corda选择以处理来自启动流的请求。 但是这可以采取进一步的措施。 如果还有另一个类例如说SuperSpecialCassandraSendMessageResponder 那么此流程现在就是Corda将开始使用的流程。 尽管我确实发现这种情况目前不太可能但绝对值得了解。 再次复制并粘贴此语句这样您就不会忘记 “您必须确保子类中的发送/接收/子流的顺序与父类兼容。” 覆盖响应者流程 这是故意的一个单独的部分。 在这里我们将专门讨论覆盖响应程序流而不是扩展响应流。 您为什么要这样做有什么区别 回答第一个问题开发人员可能想要编写一个与原始基本流程大不相同的Responder Flow但仍需要与外部CorDapp提供的特定启动流程进行交互。 为此他们可以覆盖Flow。 另一个描述这个的词可以是“替换”。 原始基本流程完全被覆盖流程取代。 在这种情况下不涉及扩展。 我认为Corda文档在此主题上的措辞非常好 “虽然子类化方法可能对大多数应用程序有用但是还有另一种机制可以覆盖这种行为。 例如如果特定的CordApp用户需要这样一个不同的响应者以子类化现有流将不是一个好的解决方案那么这将很有用。” 希望此摘录以及我之前的描述将阐明扩展和覆盖响应程序流之间的区别。 那么最重要的Flow会是什么样子 好吧在合理范围内您真正想要的任何东西。 也许看起来像下面尽管我对此表示怀疑 InitiatedBy(SendMessageFlow::class)
class OverridingResponder(private val session: FlowSession) :FlowLogicUnit() {Suspendableoverride fun call() {val stx subFlow(object : SignTransactionFlow(session) {override fun checkTransaction(stx: SignedTransaction) {}})logger.info(Screw the original responder. Ill build my own responder... with blackjack and hookers!)subFlow(ReceiveFinalityFlow(otherSideSession session,expectedTxId stx.id))}
} 由于此流程完全替代了原始基本流程因此它看起来就像普通的响应者流程。 既然是这样那就好了。 这意味着它有InitiatedBy引用了Initiating Flow扩展了FlowLogic并实现了call函数。 最后一次将它放在这里 “您必须确保子类中的发送/接收/子流的顺序与父类兼容。” 与上一节相比这在这里更为普遍。 由于整个call函数都已被覆盖因此您必须确保每个send和receive都在正确的位置以便与启动流的交互运行不会出错。 在配置方面要做更多的事情而不是扩展Flow。 在这种情况下我们正在尝试将响应者完全替换为另一个。 为此我们需要一种方法来告诉节点将交互从“发起流”重定向到新的优先响应器流。 Corda提供了一种做到这一点的方法。 要指定重定向请将以下内容添加到您的node.conf flowOverrides {overrides[{initiatorcom.lankydanblog.tutorial.base.flows.SendMessageFlowrespondercom.lankydanblog.tutorial.cassandra.flows.OverridingResponder}]
} 显然更改您自己引用的类… 那么这是怎么回事 这个配置说 SendMessageFlow通常与之交互SendMessageResponder现在将路线OverridingResponder代替。 为了使一切都变得更简单 Cordform插件提供了flowOverride方法作为deployNodes一部分。 然后将为您生成上面的配置块。 对于上面的示例使用了以下代码 node {name OPartyA,LLondon,CGBp2pPort 10002rpcSettings {address(localhost:10006)adminAddress(localhost:10046)}rpcUsers [[user: user1, password: test, permissions: [ALL]]]cordapp(project(:cordapp-contracts-states))cordapp(project(:cordapp))cordapp(project(:cordapp-extended-cassandra))// the important partflowOverride(com.lankydanblog.tutorial.base.flows.SendMessageFlow,com.lankydanblog.tutorial.cassandra.flows.OverridingResponder)
} 现在在deployNodes运行并启动了节点之后来自SendMessageFlow或其任何子类的任何请求现在都将通信路由到OverridingResponder 。 结论 Corda 4提供的便捷功能之一就是能够从第三方CorDapps或您自己的自定义Flows。 这可以通过两种方法来完成即扩展或覆盖。 扩展将是我在这两者之间的第一选择但确实需要CorDapp开发人员付出更多的努力。 他们必须提供足够的自定义渠道而不能放弃对Flows原始功能的控制。 提供很少的自定义可能不会阻止其他开发人员使用他们的CorDapp。 但是开发人员可能会对缺乏对自己的应用程序的控制感到不满。 这是一个湿滑的坡道可通过自定义路线来控制原始意图。 另一方面实际上扩展Flow并不需要太多工作这使开发人员更容易采用和适应外部Flow。 另一方面对于CorDapp开发人员而言覆盖不需要任何工作而是可以利用外部“响应程序流”将所有内容放入开发人员。 那是因为现有的Flow几乎被丢弃了并且回溯到原始实现的唯一参考就是指向Initiating Flow的链接。 通过拥抱Flow的扩展和覆盖CorDapp开发人员将能够利用外部CorDapp同时仍提供足够的自定义功能来满足他们可能拥有的所有业务需求。 随着时间的流逝开发人员将推动重用现有CorDapps的使用因为它们提供了对其他自定义的访问权限很快将与我们在任何工作中已经利用的开源库的地位相同。 这篇文章中使用的代码可以在我的GitHub上找到 。 它包含CassandraSendMessageFlow的代码该代码建立与外部Cassandra数据库的连接以保存跟踪样式数据。 它还包含另一个模块该模块发送HTTP请求作为其基本流扩展的一部分。 如果您在阅读本文后仍然感到好奇则此存储库可能会有所帮助。 如果您喜欢这篇文章或发现它有帮助或两者都有请随时在Twitter上LankyDanDev关注我并记住与可能对您有用的任何人分享 翻译自: https://www.javacodegeeks.com/2019/03/extending-overriding-flows-cordapps.htmlpbfunc外部扩展函数
