One good use of this style of architecture is when a web application needs to interact with connected devices on the client's machine such as paper/check scanners, portable devices etc. Since an ActiveX control can access local resources, interaction with such devices in a web app through the control allows you to post information back to your backend systems for processing. This makes a whole lot of sense, especially since it avoids you to write web services for communication with a backend systems written on a different platform or language (say JEE).
A list of things that one has to remember while writing an ActiveX .NET control:
- The control has to be coded as a Windows Form control with "Make Assembly COM visible"checked in the Assembly information of the Project's properties.
- Your OBJECT tag in the HTML page points to the .NET DLL, like so -
<OBJECT id=”myControl” CLASSID=”http://server:port/MyApp.DLL#MyControl”/>
- You should load the control with a javascript function for the Eolas Lawsuit workaround that prevents controls from being active on page load. In short the OBJECT tag mentioned above should be written out (using document.write) by a javascript function on a page load.
- You need to create a security policy that needs to be pushed to the client's machine that is going to run the ActiveX component. Note here that if this is an Intranet application, rights to the control have to be defined under the LocalIntranet_Zone in the .NET Configuration management console.
- And finally make sure your Internet Explorer policy settings allow for running "ActiveX controls and plugins".
Still have questions on this - just ask here.....:). But this type of system architecture will help you leverage the best of both platforms - mainly .NET(on the frontend) and Java(on the backend).
No comments:
Post a Comment