1

I'm currently developing a GUI for a Java-application that I've created. I would like to keep the GUI in a separate process from the rest of the client. The rationale behind this is:

  • Reduced risk of crashing. E.g. a OutOfMemoryError in the GUI won't crash the rest of the client.
  • I get an API "for free". If I later on want to allow other people to programmatically access the client I can just let them use the same API that the GUI is using.
  • I'm writing the GUI in SWT and the client is created using IntelliJ. Since Eclipse has a lot better SWT-support it makes sense to keep them separate, so that I can use Eclipse for the GUI-code and IntelliJ for the rest.

My question is now: what technology should I use to expose the client's interface to the GUI? RMI is what came to mind first. However, that has the disadvantages of restricting the API to be Java only. I'm also not sure about how well suited RMI is for large scale deployment (e.g. how does it handle local firewalls?). However, I don't want to rule it out just yet.

I should also mention that I have some deployment-requirements as well:

  • Must be able to run as non-admin.
  • Must be able to handle restrictive local firewall-restrictions.
  • Deployment must be automatic (it's a large scale consumer-app) and work on Windows, Mac OS X and Linux.

Given these restriction what solution would you use?

Yrlec
  • 3,401
  • 6
  • 39
  • 75
  • *"what technology should I use to expose the client's interface to the GUI?"* I probably misunderstand the question, but I'd tend to simply add it to the run-time class-path of the GUI. Directly instantiating classes and using their methods is much simpler than using RMI or similar technologies. I also don't quite understand the GUI crashing and wanting to keep the client running. What is the point of keeping the client running? – Andrew Thompson Nov 26 '11 at 13:39
  • The client is a backup program. If the GUI crashes I still want to keep the backup running. Also I want to be able to access the client's instances of the classes. AFAIK, that's no possible by just setting the run-time class-path. – Yrlec Nov 26 '11 at 13:43
  • *"The client is a backup program. If the GUI crashes I still want to keep the backup running."* Wouldn't it be better to make the back-up resumable? What if someone trips over the power cable to the PC? Running the B/U API in a separate process (on the same machine) is not going to help with that. ;) – Andrew Thompson Nov 26 '11 at 13:47
  • It is resumable. However, I still prefer to minimize the chances of it crashing. E.g. it can crash in the middle of a fsync and corrupts some file. Just because it doesn't provide 100% protection doesn't mean it's worthless. – Yrlec Nov 26 '11 at 13:50
  • Related http://stackoverflow.com/questions/12815907/design-for-separating-code-and-gui – andersoj Nov 29 '13 at 17:37

1 Answers1

2

I faced this same situation a while back, except that the back-end was in Python, and the GUI was in java.

Important points to consider:

  • how flexible and granular the interface between the GUI and the back-end needs to be. Do you want to be able to do one thing from the GUI? 5 different things? 10? 50? How tightly coupled is the GUI -- will it know about/be calling individual methods in the back-end?
  • how the output gets from the back-end to the GUI. Can it simply write to STDOUT or to temp files? Does it need something more elaborate?
  • the format of the output. Ideally, it should be easily parseable, which indicates XML or JSON may be your best bet.

You might find JSON-RPC useful: it's a standard for remote method calls to separate programs.

All in all, it's hard for me to say what would be best for you. I ended up avoiding RPC, and gave the back-end a simple command-line interface; output was written to temp files and STDERR, as JSON objects. I feel that this was a good decision because it kept the interface between the programs very simple and uncoupled.

Matt Fenwick
  • 48,199
  • 22
  • 128
  • 192