1

I need to create a web-controlled application (that lives in the browser) that can connect to and read data from devices connected via USB or the serial port.

At the moment, I'm using an ActiveX control to do this. However, I'm like to re-write this system to make it cross-browser (support Firefox) and eventually cross-platform (support Safari on Mac). ActiveX is neither cross-browser or cross-platform, so I'm looking for an alternative technology.

My first inclination would have been to use Silverlight, because Silverlight 4 grants access to COM Automation. Unfortunately, this only works with OOB (Out of browser) Silverlight applications - in-browser systems are still bound in a sandbox and do not have access.

So, what technologies exist (frameworks, browser plug-ins, etc) that will allow me to interface with a USB/Serial device from within a browser-based web application? What are the pros/cons of each?

EAMann
  • 4,128
  • 2
  • 29
  • 48
  • 2
    Your title is not really appropriate here. You should not be trying to "break" the browser's sandbox. You should be using the appropriate APIs to grant trust to your application (the JVM/java if you want x-platform) – x0n Nov 18 '10 at 19:22

3 Answers3

1

I think your best bet is probably Java in this case. USB, though an industry standard in terms of protocol is definitely not standardised in terms of bare-metal implementation. For this reason, you will still need a different Java USB implementation for each distinct platform (windows, linux, osx, bsd) that you intend to support. Of course you will also have to pay for code-signing certificates so you can try to convince people to grant your application the kind of access it requires; something that browsers try very hard to deny access to and most people in this day and age are very unwilling to grant. That said, there's an old IBM article here on the various Java USB projects that makes a good read. Good luck.

http://www.ibm.com/developerworks/library/j-usb.html

-Oisin

x0n
  • 51,312
  • 7
  • 89
  • 111
1

It might be painful, but you could use a signed Java applet. Signed Java applets can have full access to the user's system.

Java does not have built in USB support, so you would probably need to roll your own JNI interface to native USB APIs.

Using JNI in an applet can be tricky. I've done it before. If you Google the topic, most results say "don't do it" or "you can't do it." Well, you can do it.

This is how I did: I packaged the native libraries (DLL, so, etc) inside the applet's JAR, and then read the native libraries out of the JAR using e.g. getResourceAsStream. I then wrote the libraries out to an appropriate location on disk (e.g. ${user.home}/.myapp/.) I then used System.load to load the JNI DLL.

There can be some ClassLoader issues with JNI libraries and applets. The issues are subtle and difficult to explain. They basically have to do with the fact that a JVM can only load and bind a given JNI library once per VM instance, but applets get instantiated a lot, often with their own new ClassLoader, which can be problematic. The work that Sun did on process separation in the Next Generation Browser Plugin may have relieved some of these issues, but your users will only have this if they are using Java 1.6.0_10 or later.

It is also possible to use JNA within a signed applet. I would not recommend using JNA to access USB APIs directly. But JNA can sometimes be a big time saver for accessing simple native functions. Although once you've set up your JNI infrastructure, JNA probably has less value.

Here are a few other random thoughts:

  1. Java WebStart - Can be launched from browser, but runs outside the browser
  2. Microsoft ClickOnce - Can be launched from browser, but runs outside the browser
  3. Flash / AIR - Can't escape its sandbox
Mike Clark
  • 10,027
  • 3
  • 40
  • 54
0

The best solution I've come across thus far is the cross-browser/cross-platform plug-in system called FireBreath. This is a framework built in C++ that allows you to generate plug-ins for both ActiveX and NPAPI from the same codebase.

So build it once, make it work, and it compiles to one DLL that you can deploy in either environment: ActiveX for IE, NPAPI for everyone else.

EAMann
  • 4,128
  • 2
  • 29
  • 48