The World Wide Web was waiting for a distributed technology such as OLE. Web pages were already built from components such as graphic images and text blocks; the next step was to automate HTML documents by adding software components.
But OLE controls have one serious drawback: they tend to be large, at least for use on a network in which components must be transferred across phone or intranet lines. So Microsoft developed a refined version of the OLE control standard that allows developers to produce smaller components.
The result of that refinement is ActiveX technology, which facilitates the use of components in a network environment. Unlike OLE, ActiveX is optimized for the transfer of components; ActiveX allows you to download a control and its associated data asynchronously, and ActiveX controls have less overhead than their OLE counterparts, which results in smaller code modules. A web page can contain several embedded ActiveX controls, using Microsoft Visual Basic, Scripting Edition, or Java to communicate with them. Before I get into the programming details, let’s look at how components communicate with one another.
Confusion About ActiveX and Java
Industry publications are often filled with erroneous comparisons of Microsoft’s ActiveX technology and Java. Simply put, these two supposed competitors aren’t the same thing: ActiveX is a binary standard for intercomponent communication; Java is a programming language. Microsoft has extended its virtual machine to support the easy use of ActiveX controls in Java applications and defines techniques for making Java components available through the COM mechanism.
Even the Java Beans specification (see Chapter 8) is not in conflict with ActiveX. If anything, Java Beans is a higher-level component definition that was designed for compatibility with several component standards, including ActiveX and OpenDoc. In essence, many pundits are looking for a conflict where there is none.