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?

Renunciation

If you make the hardwareManager accept HTTP requests he can definitely be accessed directly by the JS, even better you can design it to implement commands as a REST web service. XSS: not a problem here. You would need of course to have the hardwareManager running for it to accept the commands, and a way to know on which port. – Analyzer

adding to @Viruzzu 's answer, you can use Jetty which allows to easily embed an http server inside a java application. then you simply direct the javascript code to localhost in order to interact with the hardwareManager – Merylmes

Viruzzo, please make that an answer so I can vote for it. – Curricle

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

Folks

If you already have to install something on the client machine, why did you make the choice to go with a web application? It primarily a web application and now has a need to have optional hardware support for some users. – Renunciation