In March 1996, Microsoft announced its "ActiveX" strategy which goes far beyond OLE by combining the desktop services with the World Wide Web. In other words, ActiveX combines Web browsers and Java applets with the desktop services such as Word documents, spreadsheets, transaction support, scripting, and many other (still evolving) capabilities. Like OLE, DCOM (Distributed Component Object Model) serves as a core technology for remote communications between ActiveX components. Figure 7.16 shows a conceptual view of the interrelationships between OLE, ActiveX, and DCOM.

Microsoft is making it clear that ActiveX is not just a compound-document technology. Instead, Microsoft is positioning ActiveX as a complete environment for components and distributed objects. Almost everything coming out of Microsoft at the time of this writing is being based on ActiveX. Although ActiveX provides many capabilities, from a distributed objects point of view, the following features are significant (we will see the details in the following subsections):

Figure 7.16 OLE, ActiveX and DCOM

As discussed previously, ActiveX uses DCOM (the distributed version of COM) to provide communications between remote ActiveX components. In this sense, DCOM is the ORB for ActiveX. The basic scenario is that Windows will be a huge collection of ActiveX components and interfaces, with DCOM serving as the ORB. It is expected that all system services will be written as DCOM objects. These, and other services, can be provided by Microsoft or any third-party vendors.

DCOM provides the basic brokerage services for ActiveX. It supports APIs for static as well as dynamic invocation of objects. DCOM uses DCE RPC for interactions between DCOM objects. DCOM’s object model is somewhat limited because DCOM does not support multiple inheritance. In other words, DCOM supports inheritance through pointers that link different interfaces together. Figure 7.17 shows the role of DCOM in ActiveX.

Figure 7.17 Communications Between ActiveX Components

The following facilities of DCOM should be noted (see the sidebar "DCOM versus CORBA" for additional discussion):

An ActiveX component is the basic unit of ActiveX applications. Different components can be combined to develop and deploy new applications. These components may be specifically written for this application or reused from some other project or even purchased off the shelf.

Components by definition cannot survive on their own–they require containers in which to execute. Visual Basic is a common example of a container in the desktop world. Visual Basic applications load needed components from a machine's local disk or a file server. In the Internet World, the Web browsers are a common example of a container–they load Java applets (Java applets are basically components) and provide an environment to run them (i.e., contain them). Let us focus on Web browsers as containers.

Before ActiveX, Web browsers were primarily serving as containers for Java applets. We have discussed Java applets in Chapter 4. These applets are downloaded from Web servers (embedded in HTML pages) and then the Web browser is used as a container. ActiveX has extended the scope of browsers as a container by allowing ActiveX components to be "contained" by Web browsers. At present, the Microsoft Internet Explorer is the main browser that can be used as ActiveX container. This can be very useful. For example, the Web browser can now contain spreadsheets, Word documents, and code written in C++, C, Java, or other programming languages. You can build powerful applications that may, for example, supply specialized viewers with the data to be viewed (the viewer and the data is loaded as needed from the network and runs inside the Web browser as a container).

Microsoft's ActiveX Controls (formerly called either OLE controls or OCXs) are the special brand of ActiveX components that perform common tasks in standard ways and have been optimized for Internet use. ActiveX controls are, in principle, very similar to Java applets. For example, ActiveX controls, like Java applets, are self-contained pieces of functionality that run inside some kind of container (e.g., a Web browser). Thus ActiveX controls can be embedded in Web pages and downloaded on demand. However, unlike Java applets, ActiveX controls can be written in various languages such as C, C++, in addition to Java. Unlike Java applets, which are downloaded in a machine-independent format and usually interpreted within the browser, ActiveX controls are binaries. Another difference is that Java applets today are supported primarily by only one kind of container–the Web browsers. ActiveX controls, on the other hand, are supported by different kinds of containers (e.g., Visual Basic applications).

Developers of downloadable Web-based application developers have two basic choices: Java applets or ActiveX Controls. See the sidebar "Java versus ActiveX Controls" for discussion.

A plethora of different ActiveX controls already exist in the marketplace. Examples are the controls that implement spreadsheets, data viewing, mainframe connectivity, voice recognition, and the like. Many of these existing controls can be downloaded and executed within an ActiveX-capable browser. Thus there is an instant supply of available ActiveX components for Web-based applications.

The ActiveX Server is based on the Microsoft Information Server (IIS) that is integrated with the Windows NT network operating system. The ActiveX Server includes the Microsoft BackOffice family which includes the Microsoft SQL Server and the Microsoft Systems Management Server. ActiveX Server provides scripting and control facilities to tie into legacy systems or to perform other specialized functions on the server side. The scripting capabilities support PERL, JavaScript and Visual Basic Script.

The facilities of ActiveX will evolve with time. However, competitors to ActiveX such as CORBA are expected to mature considerably while ActiveX for distributed objects is still in its very initial stages at the time of this writing. Depending on the market shifts, ActiveX may be combined and "bridged" to CORBA and other technologies. For example, before ActiveX, proposals for uniting OLE and CORBA had been discussed actively in the industrial press (see, for example, Hayes [1994]). At present, DCOM to CORBA bridges are available from companies such as Iona. For example, the Iona COM/CORBA bridge provides two way mapping: it allows DCOM objects to be treated as CORBA and vice versa.

Literature on ActiveX is growing rapidly. The Microsoft Web site (http://www.micro- soft.com) provides access to latest announcements, white papers, and frequently asked questions (FAQs). The book by David Chappell, Understanding ActiveX and OLE, Microsoft Press, 1996, is a good overview of the subject matter.