How a web app can talk to client hardware?

Question

0.00/5 (No votes)

See more:

Hello world! :)

I have a situation which I can't figure what it will be the "cleanest" way to solve it Thanks for any ideas in advance.

Problem:
I need to build a web application in which the client forms need to get input from hardware that is driven by C# DLLs. Some of these DLLs have an application / session scope for which they need to be active.

Workarounds:
- The easiest way will be to use a hidden-frame which uses JavaScript ActiveXObject() to control the Hw DLL activity and readings.
- Another option will be to somehow make my Hw controller as an IE browser "addon" and call it from JavaScript. I think this is doable through Browser Helper Objects and some how make calls in JavaScript as: navigator.MyController.
- Make a background service which start / stop the Hw communication and separate the controller to be what is call from JavaScript.

Any help / opinions?
Please avoid a flame war of not being a recommend approach. :)

Posted 18-Apr-11 8:17am

hyperplus

Updated 18-Apr-11 12:09pm

v2

Add a Solution

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2011-04-18T08:26:00

Solution 1

First thing you need to know: DLL's have no sessions. You should better talk about Assemblies and class libraries, as "DLL" in .NET is just "extension", a part of file name, no more; it can be anything, you can even use .EXE file as a library: reference it, load it, etc.

The scope and life time of any objects of .NET class library is totally defined by the process where the library is loaded, more exactly, by the Application Domain, See System.AppDomain, http://msdn.microsoft.com/en-us/library/system.appdomain.aspx[^].

Keeping it in mind, I trust you can figure out your remaining questions by yourself.

Good luck,

—SA

Posted 18-Apr-11 8:26am

Sergey Alexandrovich Kryukov

Comments

hyperplus 18-Apr-11 16:40pm

SAKryukov, thanks for the prompt response. I have read some about this topic, but a little more pointers will be appreciated. Below is what I understand how I could use this and a little more detail about the problem.

Possible scenario flow:
When user enters the page to start the "Test Routine" a "calibration" process is started with the hardware which needs to keep the communication active. When calibration is complete, the user will move to the next page which is to get "Actual Readings". During this flow I can't loose my active communication...

What I understand can be done:
Create an AppDomain which will host the active communication. Get the active instance from this AppDomain in the next page.

Questions?
Is this what you had in mind? :)
So this means I have to startup my AppDomain Main() to be running in the background to perform this activities?
I don't think I can just use the IE AppDomain to plug my functionality in.

Thanks for any advise

Sergey Alexandrovich Kryukov 18-Apr-11 16:53pm

No, you usually do not have to create AppDomain, you already have one, the default one, this is enough. I mentioned AppDomain to make my statement formally correct, because if you ***would*** have extra domain, your scope in question could be less then a scope of whole process. Basically, you need to create AppDomain for complete data isolation; one convincing reason is re-loadable plug-in Assembly, because if is not possible to unload Assembly from the process, you can unload only a whole domain. If you need a design like that, I'll give you the reference. I don't see where you need an extra domain right now.

You major problem is that a lifetime in you process is limited by a single HTTP request. This is a major limitation of ASP.NET stemmed from the state-less nature of HTTP. As a result, you need to consider a process of the next request as a completely different process. To keep application integrity, you need to persist the all the states you need in a next instance of the process after new request/post-back. That should be a basis from your session support.

--SA

hyperplus 18-Apr-11 17:12pm

Thanks for your help. This is not a trivial problem for me about how to address the requirements. I am getting a little lost in trying to get your idea...

What will be considered the default AppDomain? The one in the web server or the one running the browser? Or actually both? I think it will be the one in the browser, but I will not have access to play there. That's why I was thinking I need my own AppDomain.

What will I really gain by persisting the Hw object & connection? From my understanding, this will serialize the object instance, send it to the server and restore it back in the client when the next page is loaded. Am I missing something?

Another quick note: The web app is not .Net oriented, and actually it will use a Websphere server with Facelets.

Sergey Alexandrovich Kryukov 18-Apr-11 17:29pm

No, I did not mean browser. Yes, browser is another one, pretty much irrelevant as it reflects the session as it understood at the server. I mean each time your Web application gets a HTTP request your APS.NET code-behind code is run over again (previous instance of the process gets terminated, the new one started). From your standpoint, you do not communicate between the instances through memory or other objects, only through persistence.

--SA

Sergey Alexandrovich Kryukov 18-Apr-11 17:31pm

If you Web application is not .NET oriented, I have not idea what hosts/loads your .NET code (you should have explained that from the very beginning), but my general considerations remain valid.
I was keeping in mind a normal ASP.NET application. I'm not even familiar with WebSphere (but have some minor experience with other Server-side models).
--SA

hyperplus 18-Apr-11 17:39pm

Sorry for the confusion there.

Going back to step #1.5 :) So the web page is serve from Websphere server and all that is ok. But what I need to figure out is hardware control on the client machines. For that we will use Internet Explorer ability to load ActiveXObjects from JavaScript. The problem I still have is how to keep the connection activity across the pages navigation.

Back to possible solutions:
Option #1: Hidden frame which hosts the references to the active connection. But now that I think about it, it probably wont work as the object in page_A might not be accessible by page_B.
Option #2: Implement an IE - Browser Helper Object (BHO) which will make the browser the container of my objects for the hardware and some how access that from JavaScript. I seen some tutorials in C, but nothing in C#. And I haven't got it working neither.

Espen Harlinn 18-Apr-11 17:43pm

Good effort, my 5

Sergey Alexandrovich Kryukov 18-Apr-11 22:12pm

Thank you, Espen.
--SA

BobJanova · Answer 2 · 2011-04-19T00:15:00

Not the recommended solution! ;)

But seriously, I don't think it is. You can't communicate with hardware on the client machine without them installing an ActiveX and permitting you to run it when they visit your website, so why not have them install a WinForms (or WPF) desktop app to manage the hardware instead? The usual reason to make things browser-based is to avoid the user having to install anything, which isn't possible in this case – you are already making them install an ActiveX and the assemblies which talk to the hardware. That app can talk to your server (via HTTP(S) or other protocols) if you need to synchronise things.

As some others have mentioned, running a persistent communication from a web app is hard because as soon as the user navigates off your page, everything within it is lost. You would have to fake it by storing some sort of session token (not to be confused with the server-side web session) and reconnecting when the new page is loaded.

Can you explain why you want to use a web application? It is (probably) technically possible to do what you say you want, but it is definitely a square peg and a round hole, and I don't currently understand why you are taking that route.

hyperplus · Answer 3 · 2011-06-10T07:21:00

Reviving an old post to give a final status to this subject...

So after playing with technologies, we were able to develop a small framework which will accomplish our needs. We had to mix: IE9, ActiveX, BHO, C#, JavaScript, JSF2, and a couples of tricks to get all this working based on customer requirements.

Finally it was decided it will be too unreliable and unmaintainable. And now they are happy we are going full .Net forms which implements web services to manage part of the business logic.

How a web app can talk to client hardware?

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0