by Michael Morrison
What could ActiveX possibly have in common with Music City, USA? Being born and raised in Nashville, Tennessee myself, I feel pretty qualified to provide an answer: absolutely nothing! Seriously,
Nashville is the code name of the new Windows shell that plans to integrate the Internet into the Windows interface. This chapter takes a look at ActiveX and the role it plays in the new Windows shell. You begin with a brief look at how ActiveX came to be,
which will help you understand the role it plays on the road to Nashville.
Understand, as you read this chapter, that Nashville is a very new technology that is still in development. Many of the specifics on Nashville have yet to be revealed. Knowing this, my goal in this chapter is to paint you a general picture of the role
ActiveX plays in the evolution of Windows to the new Nashville interface.
To fully understand the circumstances surrounding the Nashville interface and its dependence on ActiveX, you have to go back a few years and take a peek at the evolution of it all. The road to Nashville begins thousands of miles away in Redmond,
Washington, home of Microsoft.
Back before ActiveX or OLE meant anything, some insightful software engineers at Microsoft had an idea about developing a language-independent
standard for distributed software objects. They called the specification COM, which stands for Component Object Model. The COM specification provides a binary standard for how software objects are represented in memory and a programming model that
effectively hides an object's inner workings. It does this in a language-independent manner, meaning that COM objects can be developed using a variety of different programming languages.
At first glance, COM may not seem like that big a deal; it's such a low-level technology that it's hard to see the practicality of it. But, consider the effect of designing all the software objects in a system to support the COM standard. Since the
objects all share the same layout in memory, they all understand how to communicate with each other, resulting in a system composed of objects that know how to interact with each other. This creates some very powerful opportunities. Even though object
communication within a system is powerful in itself, COM goes much further; COM defines a standard for objects to communicate with each other in any environment, including distributed networks.
At the center of COM is the concept of a software component, which is a reusable piece of software in binary form that can be easily integrated with other components with relatively little
effort. Additionally, software components can be mixed and matched with components from other vendors. For example, a spellchecker component from one vendor could be plugged into several different word processing applications from other vendors. As simple
and logical as this scenario sounds, it has yet to be realized in the realm of computer software. The COM standard aims to change that.
The primary responsibility of COM is to ensure that software components behave consistently without limiting how programmers use different components. Objects written to support COM are collectively called COM components, or COM objects. COM offers a
way to address both the problems of application complexity and future enhancements to functionality, and it does so in a completely open way so that all software vendors can adopt it and put it to use immediately. Microsoft made the entire COM
specification fully available to the public; it was never positioned as a proprietary
technology.
Following quickly on the heels of COM, Microsoft unveiled its OLE technology, which stands for "object linking and embedding." Although object linking and embedding correctly identifies the original releases of OLE,
the technology eventually grew far beyond its original intentions. OLE's original goal was to provide a more document-centric architecture for Windows, but it has since evolved into a rich set of object-oriented system interfaces and services forming a
standard framework for building reusable, integrated software components.
It should come as no surprise that OLE is built on top of COM; it is an open, extensible architecture built on the foundation of COM. OLE and COM are so intertwined that they are often used
interchangeably when discussing component software technology. In fact, because OLE is based on the underlying object architecture of COM, it forms the basis of the strategic evolution of the Windows operating system family into fully object-based
operating systems. Every feature of OLE depends on COM to provide basic inter-object communication. In other words, COM provides the "plumbing and wiring" of OLE.
The OLE technology supplies a wide range of services, including application automation, reusable controls, version management, standardized drag-and-drop, documents, object linking and embedding, and visual editing. These services have shared great
success and account for much of the power and ease of use evident in the Windows operating systems.
When Microsoft finally decided to turn their attention to the Internet, they decided that OLE was the technology to focus their efforts on. Since they had put so much into OLE, it was already a very
stable and powerful technology, with a broad range of industry support. Therefore, their approach was to just figure out ways to extend OLE to support the Internet. The new, revamped OLE for the Internet was renamed ActiveX. ActiveX builds on the success
of OLE, and takes it to a new level, by giving it the ability to thrive in the online world of the Internet.
Although COM is certainly a sound technology at its core and a good basis for ActiveX, Microsoft realized that it
still lacked some of the support necessary for the widely distributed type of computing presented by the Internet. So, they went back to the drawing board and came up with DCOM (Distributed COM). DCOM picks up where COM left off and focuses on the
communication protocols between distributed objects. Where COM fleshes out the low-level physical issues for distributed binary objects themselves, DCOM addresses the communication protocols necessary to transfer information between these objects.
Like COM, DCOM is also designed as a component of the ActiveX technology. The difference is that DCOM addresses an application-level issue of handling remote communication between objects, and COM specifies the binary makeup
of the objects. The goal of DCOM is to provide a reliable, secure, and efficient means for software components to communicate in a distributed environment such as the Internet. DCOM is implemented as a generic protocol layered on the DCE (Distributed
Computing Environment) RPC (Remote Procedure Call) specification. Because of its relationship to the RPC specification, DCOM is sometimes also referred to
as Object RPC, or ORPC.
Since ActiveX essentially defines an Internet component technology, you often think in terms of client software when you think of ActiveX. This implies the need for a
client application that supports ActiveX components. Microsoft's primary ActiveX client application is Internet Explorer 3.0, a Web browser that fully supports embedded ActiveX components. (See Figure 16.1.)
Figure 16.1. Microsoft's Internet Explorer 3.0.
Internet Explorer is Microsoft's answer to Netscape Navigator, and they're doing all they can to make sure it succeeds. ActiveX is a significant
part of the Internet Explorer strategy; Microsoft is aiming to provide a smooth integration of popular desktop applications with Internet Explorer through ActiveX. In doing so, Microsoft is attempting to redefine the whole concept of Internet computing.
Their goal is to take things a significant step further than both static Web pages and dynamic Java applets by allowing users to work with familiar data types and full-blown client applications within Internet Explorer.
The idea of Internet Explorer is to create a universal client capable of understanding and responding to a wide variety of content types. To better understand this, consider the capabilities of a
browser such as Netscape Navigator. Navigator is primarily used to view HTML documents, but it can also view other document types, such as text documents and FTP directory listings. Navigator also supports plug-in modules, which allow it to support an
unlimited variety of content types. However, Navigator plug-ins are specific to Navigator and can't really be used in any other context.
Internet Explorer, on the other hand, supports both ActiveX controls and documents, which also encompass an unlimited range of content types. However, since ActiveX is based on OLE, ActiveX controls
and documents have a practical use beyond Internet Explorer; you can integrate them into your own standalone applications. Furthermore, support for a wide range of content types has already been implemented in OLE documents and controls, which are already
being converted to ActiveX. Because of this, Internet Explorer will immediately support a wide range of content types and ultimately be far more extensible than any other Web browser.
This approach of making Internet Explorer a universal client fits in well with Microsoft's movement toward a document-centric computing environment. Understand that when I say Internet Explorer
serves as a client for a particular document type, I don't just mean it's capable of only viewing documents. The nature of ActiveX makes it just as easy for Internet Explorer to also serve as an in-place editor for a wide range of documents. If you have
any experience with using OLE in-place editing, you already know what I'm talking about. Basically, in-place editing allows you to edit a document within a client application as though you were using the originating application, such as Word.
Beyond the issue of ActiveX, it's clear that Microsoft is directly challenging Netscape with Internet Explorer. Although Microsoft is late to the game, they are gaining ground fast. Internet Explorer 3.0 contains a lot of interesting features, such as
extensive customization options, a Web site ratings system, browsing with the keyboard, and an administration kit for building custom versions of the browser. Furthermore, Internet Explorer 3.0 offers complete support for both ActiveX and Java, along with
secure communications, code signing, and multilingual support.
Once Microsoft realized the power inherent in combining all their software component technology with the Internet and with an Internet browser,
they took yet another step back to examine things again. It occurred to them that merely providing a universal client for different types of content wasn't enough. There still existed a clear distinction between accessing information on the Internet and
information located on the local hard drive or network. Although this distinction is widely accepted by the current Web-using community, Microsoft was looking at things from a larger perspective. Why not make accessing computer information the same
regardless of its origin? That problem became the basis for the Nashville project.
Fortunately for Microsoft, this problem wasn't entirely new; they had tackled a similar problem on a smaller scale years earlier when they developed Windows for Workgroups. Windows 3.1 provided weak support for accessing data on a network, so Microsoft
developed a version with network extensions called Windows for Workgroups. Windows for Workgroups managed to successfully expand the Windows 3.1 File Manager to allow smooth access to network computers.
Windows 95 Explorer, which superseded File Manager, included this same functionality but with a much cleaner interface. With Windows 95 Explorer, you can easily examine other computers on a network
and copy and move files around just as though they were on your local hard drive. This consistency in file access is important and has helped make Windows much easier to use.
When it comes to the Internet, the problem of consistent data access rears its head again in a big way. To access
information on the Web, you have to launch a Web browser and work within it entirely. To work with things on your local hard drive, you launch Windows Explorer and run an application that works that particular type of information. Figure 16.2 shows the
current situation for working with information on the Internet versus working with it locally.
Figure 16.2. The current problem of information access.
Notice in the figure that access to local data is provided both by Windows Explorer and by client applications. Additionally, you can launch client applications from Windows Explorer. This scenario is familiar to most Windows users, and ultimately goes
back to the File Manager/Program Manager approach in earlier versions of Windows. Now look at how Internet data is accessed in the figure; the only way to access Internet data is through a Web browser, which is ultimately a specialized application. This
rift between accessing local data and Internet data presents a significant problem to the open-ended approach of data access promoted by Windows.
Microsoft realized that the most logical solution to this problem was to expand on the Windows Explorer concept to incorporate browsing information on the Internet. Since they already had a Web browser with a lot of potential (Internet Explorer), it
made sense to somehow combine the two Explorers into a single application that handles both hierarchical directory/file management and Internet content browsing.
Integrating Internet Explorer with the Windows 95 shell is a Microsoft project that has been code-named Nashville. Nashville marks the first attempt by a major software company to integrate
full-blown Internet services into an operating system. The Nashville project will no doubt change the way everyone views working with the Internet, since it mixes two entirely different modes of computing. The end result will hopefully be a more seamless
computing environment, in which accessing information on the Web will be much like opening a folder on your hard drive. The Nashville interface will likely rear its head in the next major release of Windows.
Figure 16.3 shows how the information access problem is solved by the Nashville interface.
Figure 16.3. Information access through the Nashville interface.
If you contrast this figure with Figure 16.2, you see how the Nashville Explorer solves the problem of inconsistent data access. By providing a unified means to access both local and Internet data, the Nashville Explorer successfully extends the
Windows interface to incorporate the Internet.
The success of the Nashville interface is highly dependent on the component and document-centric aspects of Internet Explorer, which is directly attributed to ActiveX. In this way, you can see how ActiveX is an even more important technology than OLE,
residing at the heart of all of Microsoft's Internet efforts.
Although brief, this chapter tries to give you some perspective on ActiveX as it applies to Microsoft's plans to integrate the Internet into Windows. You have reviewed a brief history of ActiveX, which gives you some insight into the push for component
technology. You then learned about Internet Explorer and how it makes use of ActiveX to provide support for a wide range of content types. This chapter concludes with a discussion of Nashville, Microsoft's new Windows interface that integrates Internet
Explorer into the Windows 95 shell.