The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Server to Server communication

In Java / J2EE environment, what are some good ways to communicate with other processes.  It is normally best practice to use an existing framework.  For example, SOAP, XML-RPC, REST.  These seem great for distributed objects.  But, for simple passing of messages, it seems a little rich?

And, how do approach communication from a web server(servlet container), for example Tomcat sending a message to a remote process.

And, here is a continuation of a thread on the main forum on Threads.  Is the best approach to use a thread per connection, or use the new io(NIO) functionality.

"...In general I use threads when I need to wait for something efficiently. Socket connections. Web service calls. Windows message loop.

Each thread is dedicated to one waitable thing, with possibly other threads to do processing that doesn't need to wait for anything. It works out pretty well..."

My question: is socket and thread communication still ok for simple remote messaging? especially if you are communicating from a J2EE system to a non-J2EE system.
Berlin Brown Send private email
Friday, July 15, 2005
 
 
I've switched from RPC to basic socket message passing. RPC turned out to be a nightmare, especially the synchronous nature of it. (Sure, you can do asynchronous message calls, but the whole thing ends up being really ugly.)

I'll never again use RPC if I have a choice, so my suggestion would be to use NIO sockets. The result will end up being a LOT more flexible, as well as more efficient.
sloop
Friday, July 15, 2005
 
 
Technically, you're not supposed to do I/O (including sockets) from J2EE code. The J2EE correct thing to do is use RMI, JMS, or if it's not J2EE on the other side of the wire, JCA.

The thread per request vs. non-blocking I/O decision should probably be based on your acceptable throughput/latency and expertise in the area (nio tends to be harder).
matt.
Friday, July 15, 2005
 
 
The main thing, I have a server(possibly) several that don't speak RMI.

Sockets would have to work?
Berlin Brown Send private email
Friday, July 15, 2005
 
 
===========================
Technically, you're not supposed to do I/O (including sockets) from J2EE code. The J2EE correct thing to do is use RMI, JMS, or if it's not J2EE on the other side of the wire, JCA.
===========================


That's very wrong and a very common misunderstanding. Nothing keeps you from performing IO operations from within "j2ee" code. This is what the j2ee crowd recommends (without explaining why):

1) not to perform file io operations from ejb or servlet code - they recommend this because for them, any j2ee application should work in a cluster. since in a cluster configuration you can't control to which machine a remote EJB call will go (or to which servlet), you'll end up with two different files on two different machines. Then, when you'll need to read data, some calls might go to machine A and fetch data from the file there, others to machine B and  fetch data from the file over there. Since the two files are not identical, it's very likely you get inconsistent results.

However, there are workarounds (place your file on shared network volume) and situations when this can be acceptable . For example, your file may be a write only operation log. When analyzing the log afterwards all you'll need to do is to merge the two files to get the full content. If

If your application will never be deployed in a cluster, then forget about any file IO restrictions, you'll be able to do whatever you want.

2) not to use socket io operations from ejb and servlet code. This should be translated in "do not use server sockets in EJB methods or in doPost/ doGet methods in servlets". There a good reason because you shouldn't do this, and that because the servlet and EJB containers are managed environments, and the threads in which your code runs are managed by the application server. if you start accepting connections on server sockets the thread will block and the app server will not be able to manage it any more. this can cause serious problems for the app server and your code can be broken, as certain app servers kill threads that don't return after a while.

There is absolutely nothing that keeps you from using client sockets in j2ee. How do you think JMS or RMI works? These  IPC communication methods use TCP for transport.

Regards,
Emil.
emil kirschner
Wednesday, July 27, 2005
 
 
===============
And, here is a continuation of a thread on the main forum on Threads.  Is the best approach to use a thread per connection, or use the new io(NIO) functionality.
===============

I assume your questions is about writing a server. In this case the answer is: it depends on the number of connections you expect. If you have a small number of simultaneous connections  a thread per connection would do the trick because the server logic is easy to implement and performs well for not so many simultaneous connections. If you expect a high number of simultaneous connections, having one connection per thread become too expensive, because of the context switching that happens each time a thread takes control. This ends up using an amount of computing power comparable to the one used by the server logic itself, and that's not good. In this case, you should go for an async tcp server approach (and nio let's you do this). Implementing async protocol handlers is a little bit more tricky, though.

If you feel you have to go for the async approach, this is an excellent article that can help you through it: http://www.onjava.com/pub/a/onjava/2004/09/01/nio.html
emil kirschner
Wednesday, July 27, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz