Socket-based The socket-based implementation enforces strict lock-step among the clients by relaying all updates to the central display through the server. The advantage of this technique is that updates to the list are displayed in real-time by the clients. The disadvantage is that all clients require a direct TCP/IP connection to the server, which may not be possible in an environment with firewalls and other constraints. Our use of object streams to encapsulate messages provides us with a much cleaner interface than using raw bits and bytes; however, there is still some effort required to implement a multithreaded server that can handle network failures, among other potential disasters. RMI-based The RMI-based environment, on the other hand, allows clients to proceed on their merry way independent of the central list. If a client makes an update to the list, the server will inform it whether or not the update was approved; however, the server will not tell the client what other changes have been made (although it could). Instead, it is up to each client to regularly poll the server -- either manually or automatically -- for updates from other clients. RMI usually requires a direct socket connection to the central server, but it also has support for HTTP proxying of requests should that be necessary. As a result, our RMI-networked whiteboard can operate behind a firewall where HTTP traffic is permitted or proxied. For this particular application, the socket-based solution is, in general, superior. RMI, however, has the advantage of being fairly simple, and in an environment where real-time update is not a necessity, an RMI-based distributed list is far more elegant than the socket-based approach. Note that our RMI list has no knowledge of when clients connect or disconnect, of threads, or of network failures; it must simply respond to method calls that are made by the RMI substructure. For real-time updates, however, the overhead of clients constantly setting up network connections to poll the server is most undesirable. An alternative to RMI with polling would be to implement a thoroughly RMI-based ObservableList. Updates from clients would be made through RMI calls to the server, and these updates would then result in the server making RMI calls back to all the registered listeners -- no matter where on the network they are. Although interesting in concept, this approach has a few failings: Unlike our current RListImpl, the RMI-based server would have to maintain a list of all active clients, making the solution less elegant. Furthermore, and this is what makes this approach useless to our applet-based whiteboard, the clients would then have to expose themselves as remote objects that could be accessed by the server. This goes against the security model imposed by most browsers, and, thus, would require that the clients be digitally signed and trusted by the users -- an undesirable burden.
其他的我也不太了解
2种方式各有优点和缺点
远程访问ejb就是非常耗时得一件工程。
^_^
http://www.javaworld.com/javaworld/jw-12-1997/jw-12-step.html
这篇文章。里面讲了2种方式的特点和实现方式及相关代码。
The socket-based implementation enforces strict lock-step among the clients by relaying all updates to the central display through the server. The advantage of this technique is that updates to the list are displayed in real-time by the clients. The disadvantage is that all clients require a direct TCP/IP connection to the server, which may not be possible in an environment with firewalls and other constraints. Our use of object streams to encapsulate messages provides us with a much cleaner interface than using raw bits and bytes; however, there is still some effort required to implement a multithreaded server that can handle network failures, among other potential disasters. RMI-based
The RMI-based environment, on the other hand, allows clients to proceed on their merry way independent of the central list. If a client makes an update to the list, the server will inform it whether or not the update was approved; however, the server will not tell the client what other changes have been made (although it could). Instead, it is up to each client to regularly poll the server -- either manually or automatically -- for updates from other clients. RMI usually requires a direct socket connection to the central server, but it also has support for HTTP proxying of requests should that be necessary. As a result, our RMI-networked whiteboard can operate behind a firewall where HTTP traffic is permitted or proxied. For this particular application, the socket-based solution is, in general, superior. RMI, however, has the advantage of being fairly simple, and in an environment where real-time update is not a necessity, an RMI-based distributed list is far more elegant than the socket-based approach. Note that our RMI list has no knowledge of when clients connect or disconnect, of threads, or of network failures; it must simply respond to method calls that are made by the RMI substructure. For real-time updates, however, the overhead of clients constantly setting up network connections to poll the server is most undesirable. An alternative to RMI with polling would be to implement a thoroughly RMI-based ObservableList. Updates from clients would be made through RMI calls to the server, and these updates would then result in the server making RMI calls back to all the registered listeners -- no matter where on the network they are. Although interesting in concept, this approach has a few failings: Unlike our current RListImpl, the RMI-based server would have to maintain a list of all active clients, making the solution less elegant. Furthermore, and this is what makes this approach useless to our applet-based whiteboard, the clients would then have to expose themselves as remote objects that could be accessed by the server. This goes against the security model imposed by most browsers, and, thus, would require that the clients be digitally signed and trusted by the users -- an undesirable burden.
其实现在用j2ee，大多是做BS的程序，很多底层的实现都已经有人做好了，包括通过防火墙，向客户端发消息等，都有固定的模式或者类库。但我现在做的因为是面向电信的告警系统，很多东西还不能在web上灵活表示，当然我会考虑移植到web上，但就程序来说，很多都已经实现了，就是复杂了些，效果不是很好。rmi的调用是非连接的（我认为），每次方法的调用都要创建连接，类似webservice,如果做北向接口，倒是很合适，对于我的程序来说，肯定要有稳定的连接，包括断线重联机制，所以考虑还是要原始的socket.其实rmi也是基于socket之上的类库，就不能说rmi能过防火墙，socket不能的。其实现在能通过防火墙，一般都是使用http协议，http也是基于tcpip的，也是socket通讯。如果我把socket写成http隧道，还是可以实现这个功能的，这个我不说了。
搞这么多东东干啥，用http＋xml＋servlet＋javabean＋jdbc不就行了。至于server向client发消息。在client搞个httpServer就行了。
＝＝＝＝＝＝＝＝＝
老兄，我的是应用程序，这样也太麻烦了把。再次感谢以上各位，再看看还有高见
防火墙，根本不是我考虑的重点，或者根本不是问题，因为我的程序肯定是通过用户的校验的，不是偷偷运行的，如上面一位老兄说的，“我觉得如果担心防火墙的问题，那通讯的东东都不要做了吧”。
不过还是很感谢这位老兄，有机会的话，可以和你探讨探讨。
如果楼主觉得传输xml和解析xml太消耗资源的话，再如果只是传输一些简单的文本数据，那就可以自己定义一个数据格式，这样不用xml，解析也会更容易
application实现socketServer，然后用它去调用同一个jvm的ejb,通过session bean来调entity bean来实现整个客户端与服务器的通讯。上面一位兄弟说到，在客户端使用servlet，那就必须需一个固定IP地址，这对大量的c/s开发，是不可取的。个人愚见：）
不过，怎么在一个虚拟机里调用ejb，还是有点疑惑。比如weblogic,在startup里实现。我不是不想这样做，我是怕真正运行的时候可能会有一些问题。我现在是单独一个应用程序，调用ejb的接口，其实好像就是个客户端的代理。谢了sjcode(愚者)。