SOAP RMI C++ - Java 和C++沟通
您能否提供一个使用 SoapRMI-C++ 在应用程序的 C++（顶层）和 Java（底层）层之间发送/接收对象的示例提供建议。
请让我了解其可行性和实施复杂性。
谢谢， 格特克
Can you please advice with an example of using SoapRMI-C++ to send/receive objects between C++(top) and Java(bottom) layers of an application.
Please let me know its feasibility and implementation complexities.
Thanks,
Gtk
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不。使用协议缓冲区之类的内容。
肥皂冗长且缓慢。当需要纳秒发送的消息变成需要微秒（如果两个程序位于同一个盒子上，或者可能在同一个 LAN 上）甚至毫秒发送的消息时，RMI 会导致糟糕的程序设计。它的命令式性质也倾向于鼓励客户端和服务器以相当交织的方式依赖彼此状态的设计，就像调用者和被调用者在进行普通方法调用时所做的那样。它鼓励状态范围的大小包含客户端与服务器通信的端到端延迟，这会大大减慢速度并导致错误。
使用显式消息传递的技术，鼓励您关注通过远程端执行的操作传递的数据。同样，这指向了像 Protocol Buffers 这样的解决方案。
我很久以前写过一篇论文，解释为什么 RPC（以及扩展的 RMI）是一个坏主意。在其中我单独提到了 CORBA，但我的大部分论点几乎适用于任何形式的 RPC。
此外，Erlang 等语言的存在和流行表明，即使对于同一 CPU 上不同线程之间的通信（延迟和网络延迟不成问题），显式消息传递也很有用。这是因为它大大降低了线程之间的耦合度。线程不再需要同意在执行某些操作或类似操作之前始终获取互斥体。单个线程的状态范围不再包含系统上其他线程的状态范围。它还减少了多个线程想要控制同一互斥锁或共享状态的同步行为。
Don't. Use something like Protocol Buffers.
Soap is verbose and slow. And RMI leads to poor program design when messages that would've taken nanoseconds to send instead become messages that take microseconds (if the two programs are on the same box, or maybe on the same LAN) or even milliseconds to send. And it's imperative nature also tends to encourage designs in which the client and server depend on each other's state in a fairly intertwined way, just like the caller and callee do when making an ordinary method call. It encourages the size of the state horizon to encompass the end-to-end latency of the client talking to the server which can greatly slow it down and lead to errors.
Use techniques in which the message passing is explicit and that encourage you to focus on the data being passed over the operation that is to be performed by the remote side. Again, this points to a solution like Protocol Buffers.
I wrote a paper a long time ago on why RPC (and by extension RMI) was a bad idea. In it I single out CORBA, but most of my arguments apply to almost any form of RPC.
Additionally, the existence and popularity of languages like Erlang show that explicit message passing is good even for communications between different threads on the same CPU where latency and network delays are not an issue. This is because it greatly decreases the coupling between threads. Threads no longer have to agree to always acquire a mutex before doing certain things or anything like that. An individual thread's state horizon no longer encompasses that of the other threads on the system. It also reduces synchronous behavior in which several threads want control over the same mutex or piece of shared state.