access scanner, barcode, camera with asp.net application

I have this weird requirement to access scanner, barcode reader, camera etc. from an asp.net application. Since these are local resources, i know its not possible to do that. I was wondering if there is some other solution to this problem.

I was thinking of creating an windows service that will run on local system and will open a port and listen to it and does the required job. I was wondering if there is a way to send some kind of message to the local port from an asp.net page using JS or some other library or activex.

If you have totally different solution, i am all ears.

Solution

We solved an analogous problem (ticket printer attached to serial port) by creating a tiny app (TCL/TK original, as it runs nicely on Win/Mac/Lin, but C#/.NET now since mono grew up), that

takes the user/password
creates the session with a web request.
opens the browser,
giving the session token in the URL as an anchor (http[s]://foo.bar/baz?x=y#sessiontoken)

This way it is never transmitted over the wire, but is available to the JS code in the client.

After the helper app has started the browser, it uses long polling and the session token (known to the browser and the helper app) to communicate with the webserver - as a client-sided app it can communicate with the peripherial quite naturally.

100's of 1000's of tickets printed this way ...

Edit: Yes, I know this gets longer and longer, but I need (and was asked to) to elaborate.

If you want to avoid going the ActiveX/Silverlight/whatever route, which I strongly suggest, you need 4 players:

Webserver
Browser
Helper application ("Agent")
Device (Ticket printer, Barcode scanner, whatever)

Your basic problem is, that 1. needs to talk to 4., but can't. So you choose two parallell paths: Communication meant for the user is exchanged between server and browser, while communication meant for the device is exchanged between server and agent, the latter relaying it to the device (and ofcourse the other way round).

The agent is a quite simple application, that talks to the device via the OS facilities (how exactly this is done ofcourse depends on the device), and talks to the webserver via HTTP requests.

Depending, on which direction of information flow you need:

To facilitate information flow from the device to the server, simply have activity on the device trigger a webrequest. (Input device, e.g. barcode scanner)
To facilitate information flow from the server to the devide, use long polling. (Output device, e.g. ticket printer)
For both directions do both (Server-triggered input device, e.g. camera)

Now the remaining problem is, how to correlate a human action in the browser with a device action - in short: How can the server send the ticket you chose in your browser to your ticket printer, not to whatever printer long-polls next.

To solve this, using the session ID is a natural fit - but it requires to have the browser and the agent both know the same session ID. For this to happen, you need to communicate it from one to the other. Since you can't communicate it from the browser to the agent (or this discussion would be moot), you need to communicate it the other way round - and the anchor in the URL is the vehicle to achieve this. You do the following:

User starts the agent (not the browser!) and enters his credentials
Agent calls sends a web request for a login to the server, and gets back a session token (please use some basic cryptography or go for HTTPS)
Agent then starts the browser (e.g. by executing cmd.exe /c start "http[s]://domain.tld/start.aspx?x=y#sessiontoken")
Since the session token is an anchor, it will not be sent over the wire, but will be available to the browser-sided code ... Bingo!
Now the two parallell paths are open: The browser for the human requests, knowing the session token, and the agent now going into the modes described above,