Java 和 C 中最简单的 RPC++
我正在寻找一种非常简单的方法来允许 Java 和 C++ 应用程序之间进行 RPC。
我的系统包含多个 Java 模块和一个 C++ 模块。 我没有太多不同的程序要调用（每个模块大约 2-3 个），并且它们不会改变太多（除了一些小的调整，例如添加新程序或更改原型）。我正在编写所有模块，这样我就可以使用我想要的任何模块。此外，除了一个之外，所有模块都将在同一台机器上执行，但是在另一台机器上执行其中一些模块而不会造成太多麻烦（基本上，只需更改配置文件）的可能性将是一个优势。
用于此应用程序的所有模块、机器和网络都是可信的，但我不希望 RPC 协议出现任何安全缺陷，并且我希望性能开销最小，因此 RPC 协议越简单越好。此外，每个调用的方法都只有一个原型。
目前我正在尝试通过 TCP 套接字使用 RPC，因为我不想使用 RMI 或 Unix 原语（Java 上没有标准实现，也没有网络功能）。我编写了一个非常简单的 RPC 协议：通过 TCP 帧给出所调用方法的序列化名称，后跟参数的序列化列表。在服务器端，它监听一个对象并使用反射来执行给定的方法。如果发生错误，返回的对象是封装错误的 DistantRPCError。
代码非常简单（只有大约 100 个 loc），并且可以在多种情况下使用（我使用 Streams，所以我什至不依赖于 Sockets）。 我面临的问题是我无法静态测试我的代码（本地测试的简单初始化比测试的代码长）并且我无法真正看到在 C++ 中实现它有多难（使用 JNI 进行序列化） ， 我想）。
所以我的问题是：你知道在 Java 和 C++ 中进行 RPC 调用的不同方法吗？这种方法非常简单（所以没有 RMI）并且可以信任（我不是在寻找一种闪亮的技术，我想要一些东西标准和行业验证）。另外，我在性能上有一些限制（该机器是一台低成本计算机，我有很多密码学需要在本地完成）。正如我所说，大多数模块（除了一两个）都是在本地执行的，因此我也对 IPC 机制感兴趣（即使我的所有模块只有一种 RPC 机制会很好）。
如果您愿意，我可以给您我的实际 RPC 代码，但正如我所说，它甚至没有经过测试，所以我不确定它是否有效。
编辑：我可能会使用 SOAP，因为我对使用 ORB 来解决我的特定问题没有太大兴趣。谢谢你的主意！
I'm looking for a very simple way to allow RPC between Java and C++ applications.
My system contains several Java modules and one C++ module.
I have not too much different procedures to call (about 2-3 per module), and they will not change much (except some minor adaptations like adding a new procedure or changing one's prototype). I am writing all the modules so I can use whatever I want. Also, the modules are to be all executed on the same machine, except for one, but the possibility of executing some of them on another machine without to much harass (basically, just changing a configuration file) would be a plus.
All the modules, the machines and the networks used for this application are trusted but I don't want any security flaw on the RPC protocol and I want a minimal performance overhead, so the simpliest the RPC protocol is, the better. Also, each method called has one prototype only.
At the moment I'm trying to use RPC through TCP sockets, as I don't want to use RMI nor Unix primitives (no standard implementation on Java and no network capabilities). I have written a very simple RPC protocol: through a TCP frame you give the serialized name of the method called, followed by the serialized list of arguments. On the server side, it listens on an object and uses reflection to execute the method given. In case of error, the returned object is a DistantRPCError encapsulating the error.
The code is very simple (only about 100 loc) and can be used in a large variety of situations (I work with Streams, so I'm not even depending on Sockets).
The problem I am facing is that I can not test my code statically (The simple initialization of a local test is longer than the tested code) and I can not really see how hard this would be to implement it in C++ (using JNI for serialization, I suppose).
So my question is: do you know of a different way of making RPC calls in both Java and C++ that is really simple (so no RMI) and can be trusted (I'm not looking for a shinny piece of technology, I want something standard and industry-proofed). Also, I have some limitations on the performances (the machine is a low-cost computer and I have a lot of cryptology to do locally). And as I said, the majority of the modules (except for one or two) are executed locally, so I'm also interested in IPC mechanisms (even if it would be nice to have only one RPC mechanism for all my modules).
I can give you my actual RPC code if you want, but as I said it is not even tested, so I am not sure it works at all.
Edit: I will probably use SOAP, as I don't see much interest in using an ORB for my specific problem. Thanks for the idea !
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不知道其中任何一个是否符合您的简单性标准，但我想说您最好的两个选择是旧的 - CORBA - 和新的 - Web 服务。
我想到了 CORBA，因为用不同语言编写的分布式组件的互操作是其灵感的一部分，但这并不简单。市场也投票反对 CORBA。我想说它在 90 年代初到中期达到顶峰，此后一直在下降。我不太了解 CORBA，也不知道它的价值。
Web 服务，特别是如果您避开 SOAP 并使用 REST，则通过 HTTP 工作并且相对简单。我认为开发和维护自己的有线协议没有任何优势。我会使用 HTTP 并坚持使用 REST。
I don't know if either one would meet your criteria for simplicity, but I'd say your two best bets are something old - CORBA - and something new - web services.
CORBA comes to mind because interoperation of distributed components written in different languages was part of its inspiration, but it's not simple. The marketplace has also voted against CORBA. I would say it hit its peak in the early to mid 90s and has declined since. I don't hear much about CORBA, for what it's worth.
Web services, especially if you eschew SOAP and go with REST, work over HTTP and are relatively simple. I don't see any advantage in developing and maintaining your own wire protocol. I'd use HTTP and stick with REST.
想让你知道，我最终选择对我所有的 RPC 使用 MessagePack ，重点是：它非常简单使用起来，开源（具有小型代码库）并且效果非常好。
缺点是：java 库完全没有注释，但正如我所说，它是开源的，代码库很小，架构也很简单，所以理解它的工作原理是没有问题的。
另外，java 库有很多不同的开发版本（这可能意味着 API 不稳定，但系统完成后我不会更新库，所以这不是问题），而且我无法编译 C++ Windows 上的 lib（这对我来说并不是真正的问题，因为我在 Linux 上使用它）。
Just so you know, I finally choose to use MessagePack for all my RPC, the point is: it is very simple to use, open-source (with a small code base) and it works wonderfully.
The downsides are: there is no comments at all for the java lib, but as I said it is open source with a small code base and a simple architecture so there is no problem understanding how it works.
Also there is a lot of different developpement versions for the java libs (which can mean an unstable API, but I won't update the lib once the system will be finished, so it is not a problem) and I could not compile the C++ lib on windows (which is not really a problem for me, since I use it on Linux).