Java Desktop Application Requirement - Is sockets the preferred choice ?

Question

I'm currently working on a requirement for a desktop application - using Java

If for some reason the GUI crashes, it shouldn't affect the background process. Once the GUI is restarted - the execution status along with the log messages should be given back to GUI.

Desktop application is built for both windows & ubuntu 12.04.

As per my knowledge in Java, this could be achieved using Sockets. Keeping GUI as client, and executing background code in a Server.( But again i'm still trying to understand how the server stays alive if the GUI crashes, - I mean if server is started from the GUI instance @ any point, and if the GUI crashes, the server is dead too, bcz it still belongs to the same JVM instance, right ? )

The question really comes down to - how to start a server(tcp) in a new process from the gui instance. Can someone throw some light on - how to implement this requirement?

Answer 1

Sockets, RMI, Protocol Buffers, Thrift, CORBA, DCOM, ... the number of RPC systems is long and extensive. They all have a similar goal though: provide a system to allow a client process and another server process talk to each other.

Today the possible best practice is to use a standard communication system, one where you can change the client to a different technology and the server will not need any modification. The system used by a lot of people is web services. Its still another form of remote communication, but if you implement the server using it, you'll be able to write a web-based client very easily, or open your server to other clients using a standard API.

If you need raw speed though, a socket is best, but its low-level. You'll have to make the protocol (ie the messages) you send yourself. I never found that to be a problem TBH, but many people prefer a framework that does that for you - protocol buffers can do this, or you can go even higher level and use something like RMI which will tie you into Java and will make it slightly easier.

Answer 2

Your problem can be solved if you use RMI in java.

RMI is Remote Method Invocation.

In this what you can do is , you can create two applications.one for GUI and another Server(where your actual process(functions) is existed). GUI can communicate with server via method calling with parameter pacing if necessary.But both application independent from each other. For your case this will work. Because if GUI(client) crash nothing happen to Server since it is independent from client execution. once you restart the client you can find the server and continue the works. But in case if server crashed then you have to restart both client and server. These application can be run in same JVM or separate JVMs . Anyway you have to use IP addresses to configure communication. I can give you small executable app(both apps client and server) if you want.

thanks.