JMX可以用于两个远程Java进程之间的正常通信吗？
JMX可以用于两个远程Java进程之间的正常通信来来回传输一些数据吗？ 如果是这样，为什么在上述场景中 JMX 优于 RMI？
文档说JMX是用于管理/监控的，它可以用于调用和返回大对象集合吗？
Can JMX be used for normal communication between two remote Java processes to transfer some data back and forth?
If so why JMX is preferred over RMI for the above scenario?
Documentation says JMX is for management/monitoring, can it be used for calling and return huge object collections?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当然，您可以使用 JMX 形式进行普通通信，如果您将自己限制为 Open MBean，您甚至不需要每一侧的特殊类型信息（即用于反序列化的自定义 jar）。
JMX 通信的另一个优点是，您可以轻松地将协议栈从 RMI 切换出去。例如，您可以额外使用 JMX HTTP 桥，如 Jolokia 或作为替代品，并获得一些额外的优势（防火墙友好性、批量请求、无类型通信）
JMX 用作普通通信协议的缺点是，JMX 模糊了分层架构，因为 MBean 可以在任何层（表示层、服务、dao 等）注册。您可能只想远程导出服务层，使用 JSR-160，您可以访问在任何层中注册的每个 MBean，从体系结构的角度来看，这可能是不可取的。
Of course you can use JMX form plain communication and if you restrict yourself to Open MBeans you even don't require special type information on each side (i.e. custom jars used for deserialization).
Another advantage is of JMX communication is, that you can easily switch the protocol stack away from RMI. E.g. you can use a JMX HTTP-Bridge like Jolokia additionally or as replacement and gain some additional advantages (firewall friendliness, bulk requests, typeless communication)
The drawback of JMX used as a plain communication protocol is, that JMX blurs a layered architecture since MBeans can be registered in any layer (presentation, service, dao,...). Your probably only want to export your service layer remotely, with JSR-160 you have access to every MBean registered in any layer which might not be desirable from architectural point of view.
因为JMX不如RMI方便。
在 RMI 中，您可以通过接口使用远程对象，因此就像使用本地对象一样。
但是使用 JMX，您必须通过带有签名的字符串名称来调用方法。
Because JMX is not as convenient as RMI.
In RMI you can work with remote object via interface so it's like working with local object.
But with JMX you have to invoke methods by string name with signature.