我们是否真的需要导入Corda的RPC代码？ 将来如何？

我知道Corda正在移除它的Web服务器模块，并在文档中建议使用其他框架。

在一个示例（ “spring-observable-stream” ）中，他们使用Spring Boot作为服务器端API，并使用RPC调用实际运行的Corda节点。 这很好，可以和我所要做的相媲美。

在这个例子中，作者导入了特定的Corda的RPC代码，以及所需的实际流程（和状态）的代码。

我想问的是，如果可以通过使用一个通用的RPC库（任何建议？）来避免混乱，并使Web服务器API独立于实际的Corda / CordApp的代码，

如果我必须导入Corda特定的代码（这是有原因的？），我想问你：

1. 从Gradle角度来看，这样做的最低要求是多少？
2. 是否可以在CordApp上实现某种插件来减少这种纠结？

说实话，我感兴趣的是与CordApp交互的更一般的方法（例如Python），但是我知道由于AMQP集成尚未准备好，所以我们现在必须留在JVM上。 所以，请随时回答我们今天从Kotlin（我必须用于短期PoC）所要做的事情。

先谢谢你！

Answer 1

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

您的服务器还需要依赖于任何包含服务器将通过RPC启动的流或包含将通过RPC返回的types的CorDapps。 否则，您的服务器将无法启动流或反序列化返回的types。

如果你正在使用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的所有类都被包含在一个单独的模块中，并且只依赖于该模块。