Our client requires as part of their workflow that users upload supporting documents.  In order to streamline that workflow they requested that users be able to scan files directly in to the application from their desktop scanner.

This presents a problem that most web developers have faced at some point:  how do I interface with hardware using a browser?  The typical solution is to use ActiveX controls or other browser plugins.  Unfortunately, browser producers are actively moving away from plugins.  

Plugins have traditionally been very prone to security issues.  Ever noticed how many times Java needs to update?  Plugins are also made for a single platform which limits the accessibility of new features.  And of course there is always the issue of stability.  How many times has Adobe Flash player crashed on you right in the middle of watching something on YouTube?  So all of this being said, how do we provide a solution that will last in the ever evolving world of browser?

Our research brought us to the EMC Captiva Cloud Toolkit.  If you have a new scanner with an ISIS driver it is possible you have this service running on your machine already as it often is installed with the driver.  The Toolkit runs as a Windows Service that sends and receives HTTP calls.  Calls are sent from the web application to localhost (127.0.0.1 in most cases) with the relevant port number.  The service then interfaces with the scanner driver and does what we tell it to do.  

The service itself is pretty simple to use.  The calls are all asynchronous POST and GET calls with most of the important ones already laid out in the sample code from EMC. Scanned images are returned in the image format specified by the developer, usually as an encoded 64-bit string.  The one issue I had was adding pages.  Neither the scanner nor the scan service saved image data once it was done scanning.  Every new scan job removed the data from the prior one.  Since our application does not do partial file uploads (for a variety of reasons) this meant that I had to keep the document in browser memory.

So what do we get here compared to a plugin?  The service handles HTTP and HTTPS so we get the security of HTTPS without the many security holes that can come from plugins.  Since this a Windows Service we don’t have to worry about browser compatibility or other unforeseen circumstances which reduces our risk of crashes.  However, the fact that this is a Windows Service means that this is not a cross-platform solution.

As browsers advance the use of plugins will decrease significantly.  The long term hope is that the browsers themselves will offer the ability to interface with the OS.  As more and more we see users using the web as their primary solution for their application needs this seems inevitable.  In the meantime, services like the EMC Captiva Cloud Toolkit offer an interesting alternative that will last beyond the next evolution of browsers as we know them.