JMX和RMI

key

RMI是一个RPC协议，如果要整合两个分散的应用程序，使之紧密结合在一起进行运行，
RMI是一个很好的选择。

SOAP也是一个RPC协议，但因为SOAP是基于XML，以及需要建立一个HTTP服务器，
如果要跑j2se而参与协作的各方没有Java以外的系统，则不应采用SOAP。

JMX是一个网管协议，由于考虑到网管终端的输入和显示能力，用JMX协议实现的接口
最好不要采用复杂的数据结构，以便能用最简单的jconsole来进行管理/测试。
同时，JMX没有一般RPC协议那种高度灵活、强悍的透明通信接口，一般而言不要考虑
采用JMX来整合两个系统。

我发神经，竟然打算用JMX来整合两个应用程序。。。。

yuba

原帖由 key 于 15-10-2009 20:21 发表

                               
登录/注册后可看大图

SOAP也是一个RPC协议，但因为SOAP是基于XML，以及需要建立一个HTTP服务器，
如果要跑j2se而参与协作的各方没有Java以外的系统，则不应采用SOAP。

Java 6 集成了 HTTP 服务器

bfox

rmi 是相对封闭的协议， 而soap 相对更通用。 系统间通讯，如果预算足够的话，我觉得还是soap更好点，毕竟http跨防火墙的能力可以在后期给你省下很多调试的时间。

mash

RMI,SOAP == RUBISH
XML-RPC JSON-RPC  are good...

key

你说的是这个吧？

http://blogs.sun.com/michaelmcm/entry/http_server_api_in_java

事实上如果真要用webservices，我还是会正而八经地apply一个web server，如tomcat, jetty之流。

原帖由 yuba 于 15-10-2009 21:03 发表

                               
登录/注册后可看大图

Java 6 集成了 HTTP 服务器

key

暂时来说没有看到用webservices的需要。
这个RPC是在我们各种服务器之间进行通信的，所有的服务器都是用java来实现，
其实直接用rmi应该就可以了。不过，网管功能在我们这个系统中显得非常重要，
这就是为什么我把jmx提出来的原因。不过，我似乎有点过份强调jmx的rpc能力，
导致系统设计时有很多限制。

这是一套很简单的系统，要实现的核心功能主要是数据的转换。系统的复杂性是来自我们要实现
1. High Availability
2. License管理
3. Cluster Monitoring

利用JMX，第3个问题基本上已经不是问题。现在就是怎样应付1和2两个问题。

对于问题一，就是实现Heartbeat和Failover两个东西就行了，在我看到，这个
High Availability只是尽人事而已。而License管理，其实只是License文件的发布和更新问题，
也不是什么大问题。

所以整套系统没有什么重要的通信任务，各个组件之间也不需要太多的rpc，使用jmx的好处是明显的。

原帖由 bfox 于 15-10-2009 22:31 发表

                               
登录/注册后可看大图

rmi 是相对封闭的协议， 而soap 相对更通用。 系统间通讯，如果预算足够的话，我觉得还是soap更好点，毕竟http跨防火墙的能力可以在后期给你省下很多调试的时间。

uniwg

通俗一点，不用整合之类的词。就用web service，异构平台的两个应用，一个client，一个服务暴露所有业务方法。现有的CXF框架，集成jetty，不用你apply什么。

key

thank u very much for the sharing.

原帖由 uniwg 于 30-10-2009 01:09 发表

                               
登录/注册后可看大图

通俗一点，不用整合之类的词。就用web service，异构平台的两个应用，一个client，一个服务暴露所有业务方法。现有的CXF框架，集成jetty，不用你apply什么。