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?
Best Answer
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.