Java: Sockets or RMI?

I need to separate our application into a light-weight gui application and a business logic application. This won't be a client/server setup as such, as the 'server' component will only have one client.

The other limitation in the application is that it has only one entry/exit point. Therefore if we were to use RMI, it would only ever be on one function. All form data is already wrapped up into a string and passed through one transport area.

Should I just use Java Sockets to enhance this application, or go with RMI? Or some other Java technology?

I made a previous post outlining the requirements of our application, however it went unanswered. https://stackoverflow.com/questions/2604528/terminal-panel-pc-single-server-sol开发者_如何学JAVAution-client-server-or-rdp

Cheers.

personally, RMI seems like a bit of overkill if you've just got one method to call, and all your data is already wrapped in a string. i imagine a simple socket server would suffice very well for your needs. however, RMI does give you a bunch of stuff for free, like multithreading, distributed garbage collection, object marshalling, etc etc. however if you only have 1 client then multithreading might not be useful and since you're doing your own object marshalling then these benefits might not gain you anything.

there's a good page on rmi's capabilities here : http://java.sun.com/javase/technologies/core/basic/rmi/whitepaper/index.jsp

since your protocol is already very simple (you just pass a string) I suggest that you just go with sockets. the advantage would be that you will not be tied up to Java on both ends, for example - it will be possible to switch the UI to another language easily.

Having done apps that used raw sockets to communicate, that used RMI, and that used SOAP, it's easiest (by a thin hair) to use RMI but then you're strongly bound to using Java for everything. The key to why RMI is easiest is that it ensures that whole messages are sent and includes a basic discovery framework, and yet it doesn't have the complexity of SOAP (which is a lot more complicated than everything else listed above).

You may consider wrapping your server entry point as a servlet and doing a POST from a client.