Java: Sockets or RMI?

Question

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-solution-client-server-or-rdp

Cheers.

Chlorohydrin

possible duplicate of #2605028 – Imaginative

I think you have answered the question yourself. If it is lightweight and single user and you are comfortable with RMI, then you should just go with it. – Cordie

@Imaginative possible duplicate? :) – Rah

Don't blame me, @oedo, that was auto-generated when I voted to close. Obviously a new feature of SO. – Imaginative

just another example of humans out-performing AI... :) – Rah

Closing this in favor of a question which is attracting no answers would seem to be poor. Better to close that one instead and edit in anything useful from there into this Q. – Smokeproof

Thanks for the answers folks. Stackoverflow is a great resource when you have no-one else in the office to answer these questions. All I got was 'what is RMI?'. Cheers. – Chlorohydrin

Answer 1

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

Rah

This was what I was thinking. Keep it simple, or use RMI and later take advantage of its other features. I'm still not sure, but I just wanted to make sure there were no other frameworks / API's I was unaware of. Cheers. – Chlorohydrin

Answer 2

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.

Fearnought

Answer 3

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).

Smokeproof

Answer 4

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

Mylohyoid

yes, takes care of marshalling and unmarshalling. Only drawback is , we need webserver. – Barbicel