ActiveX
Keywords:
ActiveX, ActiveX controls, ActiveX Documents, ActiveX object model, ActiveX containers.
Software Component technology, dispatch intefaces, Component Object Model
Other Keywords:
Java, VJ++, DCOM,
Definitions:
ActiveX controls are reusable code in binary form.
Reusable Code: Binary so no source code required. Cannot extend it though.
ActiveX are self-contained programs that live inside the web.
ActiveX, a convention of coding and API.
Some more Definitions:
ActiveX containers: The programs that use ActiveX controls are called containers. A Web Browser is an ActiveX container.
Hype Words:
ActiveX technology is modular in design, programs can be written in such a way that they can work as standalone applications, embedded "smart" objects within Visual Basic programs or Web pages, or as traditional OLE objects within business documents, all with the potential to communicate with the Internet, should you choose.
ActiveX Contorls Vs. Java Applets
ActiveX controls have methods and properties.
Both used for supercharging the Web.
|
ActiveX |
Java Applet |
Port |
No |
Yes |
File access |
Yes |
No |
OLE support |
Yes |
No |
Legacy Code |
Yes |
No |
Fast compilation |
No |
Yes |
Fast execution |
Yes |
No |
only browser |
No |
Yes |
ActiveX controls are Persistent, Applet is not.
Strengths:
ActiveX controls are more powerful that their Java Counterparts. They can access files on the client machine; they run faster; and they have better support for legacy code.
Weakness:
Insecure (Use digital Signature, code-signing). Checks - license, version, and signature - to protect copyrights and ensure security.
Tools:
VC++, VB, VJ++
Portability:
Windows platform only. On the Intranet, portability in not a problem. Companies usually standardized to a single platform, therefore ActiveX has
capability to churn out Enterprise Solutions.
Integration:
ActiveX is an architecture, Java is a language. Java helps programmers write software components, ActiveX allows those components to interact with each other.
Learning Curve:
ActiveX component can be written with any language; C++, VB, even Java.
ActiveX vs JNI:
JNI ruins portabilty. A better solution is to encapsulate an ActiveX control inside a Java Applet. Component Object Model .. COM allows hardware access and is compatible with web browsers
Communicate with other programs:
Java can call OLE interfaces and thus communicate with OLE-enabled software.
Access databases:
ActiveX can link Java code to a database including remote databases anywhere on the internet.
VJ++:
Today on VJ++ allows this integration between ActiveX and Java.
Windows VM:
Windows VM is just an ActiveX control which understands and executes Java Code. It also provides a bridge between Java Applets and ActiveX applications. Appletsa can also talk to non-Java programs. So one can access any third party tool, they just need to support the ActiveX controls achitecture.
DCOM is available to ActiveX controls, so now the protocol is also accessible from Java. It allows you to divide your code into multiple parts and run them on separate computer systems for increased speed.
Other Stuff:
Microsoft donated ActiveX technology to independent council of consumer representatives. Java Beans, (OLE like implementation) wraps Java code in an OLE shell to make it look like an OLE object.
ActiveX controls are Persistent, Applet is not.
With ActiveX Control Pad, you can easily put ActiveX controls on a Web page.
ActiveX Pluging of Netscape - NCompass Labs Inc:
The <OBJECT> Tag:
< OBJECT
CLASSID = URL
DATA = URL
ID = string >
<PARAM NAME = "name" VALUE = "value">
</OBJECT>
CLASSID=16 byte identifier.
Searches users system registry for ID. If found, ActiveX control already installed, and knows where on disk to find it. Otherwise, checks the CODEBASE to obtain and install.
SIMPLEST Example:
<HTML>
<HEAD>
<TITLE>Simplest ActiveX Example Page</TITLE>
</HEAD>
<BODY>
<H1>It Looks Good</H1>
<H3>Calender</H3>
<HR>
<OBJECT ID="Calendar1" WIDTH=288 HEIGHT=192
CLASSID="CLSID:8E27C92B-1264-101C-8A2F-040224009C02"
</OBJECT>
<HR>
</BODY>
</HTML>
Output of Simplest:
SIMPLE:
<HTML>
<HEAD>
<TITLE>Simple ActiveX and Javascript Example Page</TITLE>
</HEAD>
<BODY>
<OBJECT ID="SpinButton1" WIDTH=16 HEIGHT=39
CLASSID="CLSID:79176FB0-B7F2-11CE-97EF-00AA006D2776">
<PARAM NAME="Size" VALUE="418;1000">
</OBJECT>
<BR>
<HR>
<OBJECT ID="TextBox1" WIDTH=71 HEIGHT=21
CLASSID="CLSID:8BD21D10-EC42-11CE-9E0D-00AA006002F3">
<PARAM NAME="VariousPropertyBits" VALUE="738215963">
<PARAM NAME="Size" VALUE="1873;564">
<PARAM NAME="Value" VALUE="MIDDLE">
<PARAM NAME="FontCharSet" VALUE="0">
<PARAM NAME="FontPitchAndFamily" VALUE="2">
</OBJECT>
<SCRIPT LANGUAGE="JavaScript" FOR="SpinButton1" EVENT="SpinUp">
<!--
TextBox1.Text= "UP";
// -->
</SCRIPT>
<SCRIPT LANGUAGE="JavaScript" FOR="SpinButton1" EVENT="SpinDown">
<!--
TextBox1.Text= "DOWN";
// -->
</SCRIPT>
</BODY>
</HTML>
Output of Simple:
COM:
The Component Object Model, or COM, is an extremely elegant and efficient methodology for inter-process communications. COM allows developers to build stand-alone components (servers). Users, or clients, of COM servers can use pre-built functionality in server objects without intimate knowledge of the server object during development; instead of requiring the developer to create a link to a component's functionality at design time or provide a path to the component in the source code, COM is able to ask the registry for the object's location. This means that as long as the registry knows where to find the server object, your client application is in business. Asking the registry to point the way to the server is as easy as asking directions to a city street.
DCOM:
Distributed COM (DCOM) is the big brother of COM. The definition of "distributed" is that it is able to run clients and servers in different processes across an intranet or internet. DCOM works just like COM: a client asks the registry where the server is located and, instead of pointing it to someplace on the local machine, it points to an IP address (for example, 123.234.199.27). The primary difference between using COM and DCOM is that COM processes run on the same machine in different address spaces, but DCOM processes are spread across a network. When you work with processes in different address spaces, whether on the same machine or across a network, you need to implement marshalling. The actual internal implementation of the marshalling is the only difference between COM and DCOM from the COM-enabled application developer's standpoint.
References:
Web Developers guide to Visual J++ & ActiveX - Trevor Harmon
Component Strategies - Magazine
Web Sites: