Hardware support from a web application

Question

I have a web application running with support for some specific pieces of hardware. This is achieved in the following steps:

1. User runs a small installer that places java files (and a couple others) on the client machine. The main piece is a jar called "hardwareManager"
2. User visits web app. The web app runs a java applet which, due to a .java.policy file placed during the install, has permission to interact with the client machine outside the browser sandbox.
3. The applet checks to make sure the hardwareManager is running, and if not runs a command to start it.
4. User interacts with the web app which sends commands to the applet via javascript. The applet then writes commands to a text file on the client machine. The text file is constantly monitored by the hardwareManager which runs any commands it reads in.

This works, but seems clunky. I have a couple ideas on how to improve it, but I don't know which, if any, are even worth trying.

Would it be better to set up the hardwareManager as a socketServer and have the applet connect directly to it, rather than going through text files? Is that even possible?

Is there a way to eliminate the applet altogether and have the javascript talk directly to the hardwareManager? Maybe by writing the hardwareManager to be a local http server? What port should it run on? Do javascript xss limitations fit in here somewhere?

Answer 1

It would be less clunky to start the Java application using Java Web Start. This would remove the need to daemonize or install the Java hardware manager.

Another alternative is to use a built-in browser inside Java. I supose this is not an option, since you depend heavily on Javascript (I suppose to provide a rich client experience).

If you already have to install something on the client machine, why did you make the choice to go with a web application?

Talking from experience: We had a Java EE application which needed to print to PoS printers at the client site. We installed a small "synchronizer" application that connects through SSH and synchronizes all clients files. Afterwards, it loads the JAR and executes the program. This program connects through RMI with the server and subscribes to a JMS queue to receive the print assignments.

Applied to your case: Why not let your Java application connect to the server directly? You can use HTTP, SOAP or even JMS over RMI. You can then launch the hardware command from the server (instead of from the limited JavaScript webbrowser environment). This way, you get tons of features: authentication, buffering of commands, and you can even share hardware between multiple clients.

Schematic:

                   <----AJAX------> Web browser
ApplicationServer                  
                   <---HTTP/SOAP--> Java hardware manager application

You can launch the Java application using Java Web Start, which allows you to update the application automatically (instead of needing to pass every client a new installer).