ActiveX-Centric Application Architectures

ActiveX/DCOM architectures are a type of network-centric architecture that is built using ActiveX components on top of DCOM (Distributed Component Object Model) infrastructure. In effect, DCOM provides an “object bus” (compare CORBA) for distributed applications to be built from ActiveX components. The DCOM infrastructure provides the foundation for the higher-level software services provided by ActiveX.

ActiveX Evaluation

Whereas Java component architectures are designed to be object-oriented and network-centric from the start, ActiveX/DCOM architectures are evolving from desktop-centric OLE/COM technology. The roots of ActiveX can be traced to Object Linking and Embedding (OLE) 1, a relatively simple mechanism for creating and managing compound documents. OLE 1 evolved into OLE 2, which was based on the Component Object Model (COM). COM established a component-based programming paradigm that could support many kinds of software (such as applications, libraries, and system software).

OLE 2 changed from an acronym to a proper name, dropped its version number, and was subsequently used to describe a broad range of COM-based technologies. With the increased importance of the Internet, Microsoft renamed the part of OLE that was concerned with the Internet and distributed applications to ActiveX. OLE once again refers to the technology that is related to compound documents.

ActiveX/COM Versus Objects

The conceptual difference between the ActiveX/COM component-based approach and the conventional object approach is contrasted in the following:

An object is a piece of software source code—or a specification that can be used to build part of an application. A component, on the other hand, is not merely a specification, it is an actual working software module. An analogy is the difference between a stereo component like a tape deck, and an engineering specification for the tape deck. The specification contains complex information that is useful for engineers, but is of little use for consumers trying to put together a home stereo system. The component itself, the tape deck, is very useful for consumers and can provide immediate value.

OLE and the Benefits of Component Software [Microsoft 1994]

The COM Object Model

The Component Object Model provides the underlying infrastructure for higher level services like ActiveX and OLE. The COM architecture supports:

· A binary standard for component interoperability. COM specifies standard ways to lay out virtual function tables and to call functions using these tables. As a consequence, any language that can call functions via pointers can be used to write components that can interoperate with other components using the same binary standard.

· Versioning. COM allows one system component to be updated without requiring other components of the system to be updated. The key to this is the interface specification, particularly the implementation of IUnknown:QueryInterface (i.e., object IUnknown and method QueryInterface) which allows run-time resolution of the interface to which a reference is being made.

· Programming language independence. Since COM represents a binary standard, and not a source code standard, it is language neutral. Any language that can call functions via pointers can be used to write components that can interoperate with other components using the same COM binary standard.

· Cross process interoperability. COM allows components to address objects that reside in separate address spaces. The key to this transparent access of objects across processor and network boundaries is the Component Object Library.

COM and Distributed Applications

It is important to note that, although COM was designed to support distributed applications, the current implementation can only run on a single node in a network. This limitation will be removed by Distributed COM (DCOM), which will allow COM components to provide services across networks.

ActiveX Components, Relationships, and Constraints

The following sections describe the components, relationships and constraints associated with ActiveX/DCOM component architectures.

As described in the generic components architectures, architectures are classified by topology and focus.

As with Java component architectures, ActiveX component architectures can support both client/server and peer-to-peer architectures. It can be adapted for various system topologies. An example of a three-tier architectural model for Internet/Intranet applications is shown in the following diagram:

In the model, IIS refers to the Internet Information Server, a high-performance and fully featured server architecture with integrated HTTP, FTP and Gopher services. The server can be extended via ISAPI (Internet Server API), which supports DLLs that handle requests and events for IIS.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.