我们真的需要为RPC导入Corda的代码吗?未来怎么样?

时间:2017-11-28 15:22:54

标签: rpc corda

我知道 Corda 正在删除其 Web服务器模块,在documentation中他们建议使用其他框架。

在一个示例("spring-observable-stream")中,他们使用 Spring Boot 作为服务器端API,并使用RPC调用实际运行的Corda节点。这很好,可以与我的工作相媲美。

在该示例中,作者导入特定的Corda的RPC代码,以及所需的实际流程(和状态)的代码。

我想在这里问的是,是否可以通过使用通用RPC库(任何建议?)来避免纠结并保持Web服务器API独立于实际的Corda / CordApp代码。

相反,如果我必须导入特定于Corda的代码(有原因吗?),我想问你:

  1. 从Gradle角度来看,最低要求是什么?
  2. 是否可以在CordApp上实现某种插件以减少纠结?
  3. 老实说,我对与CordApp交互的更通用的方式感兴趣(例如来自Python),但我知道由于 AMQP 集成还没有准备好,我们现在必须留在JVM上。因此,我们可以随时回答Kotlin今天需要做的事情(我必须将其用于短期PoC)......

    提前谢谢!

1 个答案:

答案 0 :(得分:2)

目前,您的服务器必须依赖Corda RPC库通过RPC与节点进行交互。 Corda尚未公开通过RPC发送和接收消息的独立格式。

您的服务器还需要依赖任何包含服务器将通过RPC启动的流的CorDapp,或者包含将通过RPC返回的类型的CorDapp。否则,您的服务器将无法启动流程或反序列化返回的类型。

如果您正在使用Gradle,那么最小依赖项块可能是这样的:

dependencies {
    compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version"

    cordaCompile "net.corda:corda-rpc:$corda_release_version"

    compile "com.github.corda:cordapp-example:release-V1-SNAPSHOT"
}

在这里,我们依赖于corda-rpc库,并且还使用JitPack依赖于CorDapp,我们在那里定义了我们想要通过RPC启动/返回的流和状态。

如果需要,可以将CorDapp模块化,以便所有依赖于RPC的类都包含在一个单独的模块中,并且只依赖于该模块。