'; window.popUpWin.document.write(zhtm); window.popUpWin.document.close(); // Johnny Jackson 4/28/98 } //--> Windows 98 Professional Reference -- Ch 15 -- OLE, COM, DCOM, and ActiveX


Windows 98 Professional Reference

Previous chapterNext chapterContents

- 15 -
OLE, COM, DCOM, and ActiveX


This chapter defines OLE, COM, DCOM, and ActiveX. It also addresses how to use these technologies in a Windows 98 environment.

The section "Understanding Client/Server Application Concepts" introduces and defines these four technologies. This section describes at a high level how Windows 98 works with programs, and how programs work with each other. The concepts introduced in this section will help you understand the section "Using the DCOMCNFG Utility" and the section "Using OLE."

The section "Sample Files Included on the CD" lists files referenced in the "Using OLE" section.

The section "Using OLE" shows you how to use Object Linking and Embedding to create and edit complex compound documents. The use of compound documents allows documents to present information to users in a more "document-centric" and therefore a less "application-centric" format. Many commonly used applications such as Microsoft Word, Excel, and PowerPoint, as well as many non-Microsoft applications, can be used to create compound documents. This section addresses the differences between linked documents and embedded documents and when each is most appropriate.

The section "Using the DCOMCNFG Utility" describes how to use the DCOMCNFG utility to change the Registry settings of server applications. Use this utility to specify which machine a client program should use to establish a session with a given server program. Also, you can make other changes relating to security, identity, and authentication.

Understanding Client/Server Application Concepts

The four technologies of OLE, COM, DCOM, and ActiveX are all related in that they provide some level of functionality when client and server programs need to communicate with each other. This section introduces each of these technologies and describes their purpose and use; it also provides an overview of how Windows 98 determines which server application to launch when a client program requests the services provided by a server application.

What is a Client/Server Application?

A client/server program is comprised of two programs that work together to provide some level of functionality to the user (see Figure 15.1).

Figure 15.1

A client program running on one machine and the server program running on another machine.

Many client and server programs are written as a pair, intended to work only together.

Other times, a shrink-wrapped server program such as Microsoft Word is used with a client program that is written at some later date by any programmer. For example, if a programmer wants to provide the ability to perform spell checking in his program, he could either write his own spell checker or use the CheckSpelling function exposed within Microsoft Word. Obviously, using a debugged program that provides the functionality you need can cut development time and costs.

Another scenario involves the combined use of two programs that were written in isolation, for instance, by two different manufacturers.

Both the client and the server programs can run on a single PC, or they can run on two different PCs that have some form of LAN, WAN, or Dial-Up Networking connection between them.

What Benefits Does Client/Server Provide?

The ability to segment a program and run the client portion on one machine and the server portion on another machine allows for a great deal of flexibility. One benefit is a reduction of hardware costs while maintaining throughput. Perhaps the server portion requires large amounts of RAM, or heavy utilization of the processor. The server portion of the program can be run on a machine with the necessary resources to handle the program, while the client portion can run on less substantial desktop machines. This reduces overall hardware costs by allowing the purchase of lower-end desktop machines.

Another benefit of client/server is the ability to place the server where the data resides; this can greatly reduce network traffic. Assume a program accesses very large data files, but needs to display only small amounts of data to the user. If the data files are stored on a file server and accessed by a traditional non-client/server program, the entire file usually must be pulled across the LAN or WAN by the user's program. However, by writing a client/server program and locating the server on the same machine as the data files, the client can send a small request to the server indicating the desired data. The server then reads the large data file, locates the desired data, and finally returns only the data requested to the client program via the LAN or WAN.

If both the client and server programs run on a single machine, the client program can still gain functionality provided by the server program. This can also make it easier for users to access data they need from a single document, rather than from multiple applications.

Another advantage is in the ability to reuse and leverage existing software, as in the earlier CheckSpelling example. This can reduce both development costs and timeframes.

What Are 3-Tier and N-Tier Applications?

A 3-Tier application has three programs that could run on one, two, or three machines (see Figure 15.2). One program is strictly a client, the second is strictly a server, the third program sits in the middle and is written to be both client and server. This middle tier acts as a server to the client program and as a client to the server program.

Three-tier applications allow a great deal of flexibility regarding where software components run. A typical scenario for a three-tier application places the server program on a central corporate server. Regional office servers run the middle-tier program, while the client program runs on end-user desktop machines in the regional offices. This example is only one scenario. However, other alternatives might include placing the middle tier on the corporate server or on the end-user desktop computer, if it makes more sense.

Figure 15.2

A 3-Tier application running on three separate machines.

N-Tier is a term that applies to three or more tiers in which there can be multiple (N) middle- tier programs between a client and a server. Each middle tier acts as both client and server. Many corporate applications are written as N-Tier applications. This approach allows for easy replacement of one portion such as a middle tier without requiring replacement of other tiers. This flexibility allows programmers to design code as modules, and simply replace one module with another when business rules or other functionality requires change.

Business rules are software checks run on newly entered data to ensure that incorrect or incomplete data is corrected prior to its being stored in databases or written to files. Business rules reside in almost every program and are often implemented within the middle tiers. Several examples of business rules might be a ZIP code that must contain only numeric characters, a required delivery address for shipments, or a maximum allowable discount for any product.

There is, however, an associated cost dependent on which tier holds the business rule(s). To illustrate this point, study the following example of a fictitious national retail chain store . This company has 100 stores with 50 Point of Sales stations per store, or a total of 5000 P.O.S. stations nationwide.

Suppose the client tier in the Point of Sales application has a rule that limits the maximum discount to 30%. The corporation makes a decision to allow up to a 40% discount. This business decision could require installing new programs on 5000 P.O.S. machines with many hours devoted to the installation. In this case, placing business rules on a client tier has disadvantages.

Equally difficult would be placing the business rules on the central corporate server. This placement incurs a great deal of WAN network traffic and burdens the corporate server with the mundane task of validating data.

If the business rules are instead placed on a middle-tier component located on a departmental (store) server, a balance between the two extremes is struck. If each store has 50 P.O.S. machines and one departmental server, then only the 100 store servers would require the new program. The client program incurs LAN traffic to the store server to validate data, but does not incur WAN traffic for validation.

What are OLE, COM, DCOM, and ActiveX?

OLE stands for Object Linking and Embedding. This technology first appeared in Windows 3.1 as OLE 1.0. By using OLE, you can create what is known as a compound document. A compound document simply contains data from two or more applications. For instance, an employee performance appraisal document created with Word could include the cell range from an Excel spreadsheet that displays salary history for the employee. This "document-centric" approach allows a manager to view both the written appraisal and the salary information in a single document from a single application.

The data from one application can be either linked or embedded in the other. In the performance appraisal example, if the data is linked, then changes to the spreadsheet are visible when the performance appraisal Word document is next opened. If data is embedded, changes to the spreadsheet are not updated in the Word document--there is no link between these two files.

Both linked and embedded data can be edited by their native applications; Excel is used to edit the spreadsheet portion of the appraisal, whereas Word is used for word processing the remainder of the performance appraisal. In this example, Word is the client application and Excel is the server application.

OLE evolved into OLE 2.0, which allowed for in-place editing. This feature allows the menu and toolbars of the server program to temporarily replace those of the client program while the user edits linked or embedded objects. With in-place editing, the user can edit the entire document without leaving the host application.

Another twist of OLE is OLE Automation. By using OLE Automation, a client program can launch a server and then use the services and functionality of the server program. The server can run as a task hidden from the user or it can be made visible for user interaction or display of data.

Up to this point, both client and server applications resided on the same machines. With Network OLE, the server program resides on a different machine from the client program. This not only allows for client and server processes, but also enables these processes to reside on client and server machines.

Microsoft now refers to OLE 1.0, OLE 2.0, OLE Automation, and Network OLE as OLE for simplicity. These variations of OLE all rely on an architecture known as COM.

COM stands for Component Object Model (see Figure 15.3). COM is a specification developed by Microsoft that describes how Component Objects should interface (communicate) with each other. A Component Object is a generic term that applies to many different types of software: client programs, middle-tier programs, server programs, individual controls such as a calendar control, databases, and entire applications. The COM specification by design is open, flexible, and nonrestrictive. COM describes how Component Objects should interface with each other, but does not prescribe how the code that implements the interface is written. This flexibility allows programs to be developed using different languages from different vendors, such as C++, Visual Basic, J++, or MicroFocus Cobol. For example, the client-tier program can be written with Visual Basic, the middle-tier program using C++, and the server using J++. The beauty of COM is its provision for easy component replacement with a new version of a program, such as the middle-tier program, without requiring changes to the other components.

Figure 15.3

COM allows two programs to communicate on a single machine.

DCOM stands for Distributed COM. By using DCOM, COM components can be placed on different machines and seamlessly communicate with one another without requiring changes to any of the components. DCOM relies on the widely utilized DCE-RPC (RPC) for network communication. By using RPC, DCOM running on one machine can establish a connection with DCOM running on another machine. After they are connected, DCOM acts as a middleman between the COM layers on the two machines (see Figure 15.4). Another great feature of DCOM comes from its reliance on RPC. Windows 98, Windows NT, UNIX, Macintosh, and many mainframe systems support RPC and potentially can use DCOM. You can download or purchase DCOM for a growing number of UNIX and mainframe systems. By using DCOM, components can reside not only on different machines but also on different platforms and still easily communicate with each other.

ActiveX is a term that applies to both controls and servers (or code components). With the recent popularity of the Internet, web pages began to evolve from static displays of text and pictures to a more interactive format. One way to achieve this format is to place controls onto the web page. If the control is not currently installed on the user's machine, the web browser can download and install it for the user. It is important to remember that controls developed by using the full COM specification are relatively large and take a long time to download. ActiveX controls, on the other hand, use a subset of the complete COM specification; this allows for smaller file size and, therefore, quicker downloading.

Figure 15.4

The software and hardware layers used when applications on different machines communicate using DCOM.

What Are Objects, Classes, and Instances?

Object is a generic term that applies to units of software. The intent is for an object to be self- sufficient and self-managing. An object should not depend on other software in order to run properly. This is not to say an object cannot communicate with other objects; however, one object does not depend on other objects in order to function.

Objects include both code and data. Some code and data are private to the object and not accessible from outside itself; other portions of code and data can be made available (or exposed) for use by other programs. For instance, Word exposes the CheckSpelling function, which is code made available for use by other programs.

Objects include many types of software, such as entire applications, individual controls, databases, and so on. Objects are composed of one or more classes; these classes contain software functions such as CheckSpelling. If these classes are marked as public, they are exposed by the compiler. The compiler generates a COM interface for the class and the functions within it, thereby allowing access from outside the object.

Before you can use an object, you must create an instance of the object. For example, if you want to build a new house, you need a set of plans or blueprints. You can't live in the plans; you must first create an instance of a house based on the plans. One fact about a plan is that from them you can build many instances, all of which are identical. In this example, a class correlates to the plans or blueprints. You must create an instance of a class before it can be used. To use another analogy, consider creating cookies using a cookie cutter. The cookie cutter is the class; it defines the shape of every instance created. From this one class, you can create many identical instances. Think of differently shaped cookie cutters ( star, bell, tree, and so on) as different classes.

To see an example of how Windows 98 creates instances of class objects, do this little experiment:

1. Minimize all applications.
2. Point the mouse toward the middle of your desktop (not at any existing icon), then click the right mouse button. Choose New, then choose Briefcase.
3. Repeat step 2 several more times.

You have just created several instances of the Briefcase object. This implies there must be a Briefcase class. To verify this, do the following:

1. Launch the Registry Editor by choosing Start, Run. Type REGEDIT and click OK.
2. Open the HKEY_CLASSES_ROOT subtree. Scroll down past all the three character extensions; the registered classes appear next. Scroll until you locate the Briefcase class.
3. Open up the Briefcase object and notice the ClassID subkey (see Figure 15.5).

Figure 15.5

The Briefcase class within HKEY_CLASSES_ ROOT.

What are GUIDs and CLSIDs?

Microsoft decided to use GUIDs (Globally Unique Identifiers) to uniquely identify a variety of objects. GUID is a generic term used to describe other more specific identifiers such as CLSID (Class ID), Interface (Interface ID), and TypeLib (Type Library ID). All of these identifiers represent extremely large numbers; these identifiers are all 128-bit integers, which translates to 3.4e*38, or 340,000,000,000,000,000,000,000,000,000,000,000,000. These numbers are represented in hex and appear as 32-hex digits; this is an example of a GUID {85BBD920-42A0-1069-A2E4-08002B30309D}.

GUIDs are randomly generated by the compiler during compilation of .EXE, .DLL, and .OCX files then assigned to public classes, interfaces, and so on. After they are compiled, the GUIDs never change.

By following GUID references, Windows 98, COM, and DCOM can locate a specific class or interface on this or another machine.

Fortunately, GUID creation and usage happen automatically, reliably, and without any user intervention.

Understanding HKEY_CLASSES_ROOT

Object .EXE, .DLL., and .OCX files that contain public classes must be registered in order for Windows 98, COM, and DCOM to locate and use them. These items are registered within HKEY_CLASSES_ROOT. The registration process adds key and data values in several locations. Normally, this registration process is part of the installation process of applications, or occurs automatically during the download process of .OCX controls. However, if you copy files onto a machine, they are not automatically registered. Executable servers (with an .EXE extension) self-register the first time they run, and .DLL and .OCX files can be manually registered using the REGSVR32.EXE program. After they are registered, controls and code components are usable by other OLE-compatible clients.

As you install applications onto your Windows 98 machine, you should see additional entries within HKEY_CLASSES_ROOT. If you scroll through the entries in HKEY_CLASSES_ ROOT, you should see a number of entries for Excel, Access, Word, and PowerPoint if these applications have been installed.

How Windows 98 Creates an Instance of an Object

When a user double-clicks on a file with a .doc extension, WordPad launches to display the document, or (if it is installed) Word launches instead to display the document. The system may have Word 2.0, Word 6.0, or Word 8.0 installed. This example is taken from a machine with Word 8.0 installed.

First, the .doc file extension is looked up in HKEY_CLASSES_ROOT (see Figure 15.6).

Figure 15.6

The Registry entry for .doc extensions.

The value named (Default) points to Word.Document.8 as the next location in the Registry to check.

Scroll down toward the bottom of HKEY_CLASSES_ROOT to find Word.Document.8 (see Figure 15.7). The entry Word.Document.8 is known as a ProgID. Often client programs use the ProgID to create an instance of an object. Notice the Subkey named CLSID and the (Default) value of {00020906-0000-0000-C000-000000000046}.

Figure 15.7

The Registry entry for Word.Document.8.

Scroll toward the top of the Registry to find the CLSID key. Open the CLSID key, then scroll to locate the {00020906-0000-0000-C000-000000000046} entry (see Figure 15.8). The LocalServer32 key points to D:\msoffice\Office\Winword.e XE as the location of the program. Windows 98 then launches Winword.e XE to display the file with the .doc extension.

Figure 15.8

The Registry entry for CLSID {00020906-0000-0000-C000-000000000046}.

Windows 98 follows this or a similar process whenever a user double-clicks a file with an associated extension, a client program requests an instance of a server created, or a user double-clicks a linked or embedded object within a compound document.

What Are Compound Documents?

A compound document is simply a file such as a .doc, .xls, or .ppt file that is capable of holding data created by the object information of other programs. To the user, a compound document presents a unified interface to data best created and maintained by other programs. Data from the other program can be embedded within the compound document, and therefore, does not change in relation to external documents. Alternatively, data from other documents can be linked. In this case, changes to the externally linked document are seen when the compound document is displayed. Compound documents rely on the ability to create and use files in a Structured Storage format.

What Is Structured Storage?

Structured storage can be thought of as a mini-file system within a single file (see Figure 15.9). The storage file contains two types of objects: storage objects and stream objects. Storage objects are analogous to directories in a file system; stream objects are analogous to files. The storage file starts with a root storage object and a single stream object. This original stream object holds the data created from the host (or container) application.

Figure 15.9

Storage and stream objects within a compound document File.

For instance, if you create a Word document, the text you type is stored in the original stream object. Later on, you link or embed an Excel spreadsheet. A new storage object is created below the root storage, and a new stream object is created below the storage object to hold spreadsheet data. This ability to nest storage in this manner allows for development of complex compound documents.

Sample Files Included on the CD

You can locate the following Word documents and Excel worksheets on the CD-ROM accompanying this book. These documents and worksheets can make it easy to follow the creation of Compound Documents described in the following "Using OLE" section.

Weekly Time and Expense Report.doc

Hours.xls

Expenses.xls

Salesperson of the Month.doc

Car Sales.xls

Using OLE

The following sections present how to create, use, and edit both linked and embedded Compound Documents. The examples shown use Word and Excel, but similar procedures can be used by many OLE-compliant applications.

Building Compound Documents

OLE makes building compound documents so easy that you may have created compound documents without even realizing what you have done.

The first step to creating a compound document is launching the container application; the examples in this chapter use Word as the container application. In OLE terms, the container application is the client program. At a later time, when data is linked or embedded, the application(s) used to create that other data are considered server applications.

When choosing a container application, consider starting with the application best suited to create and edit the majority of the data. For instance, if the majority of the data is textual, choose a word processor as the container application.

Creating Embedded Documents

One way to create an embedded document is to use an existing file created by another application. In this example, two Excel Spreadsheets, one to calculate the number of hours worked and the other to calculate expenses, are embedded into a Time and Expense Report document created with Word:

1. Create and save the two Excel spreadsheets. (Alternatively, use the files named Hours.xls and Expenses.xls included on the CD-ROM that accompanies this book.)
2. Launch Word and create a new document. (Alternatively, use the file named Weekly Time and Expense Report.doc included on the CD.)
3. Type the text that you want to appear in the Word document.
4. Place the insertion point at the location in the Word document at which you want to place the first spreadsheet.
5. On Word's menu choose Insert, Object. The Object dialog box appears.
6. Choose the Create from File tab. Next, type the name of the file, or use the Browse button to locate the desired Excel spreadsheet (see Figure 15.10). Disregard the Link to File checkbox for this example, but if in the future you want to create a linked document, you would select this checkbox.
7. Finally, click OK to embed the document.
8. To embed the second spreadsheet, place the insertion point at the location in the Word document where you want the second spreadsheet. Repeat steps 4 through 7 to choose and embed the second spreadsheet.
9. Finish the Word document, and then save it.

Figure 15.10

The Create from File tab used to select an object for embedding.

An alternate way to create embedded documents does not require first creating a file from the server application:

1. Launch Word and create a new document. (Alternatively, use the file named Weekly Time and Expense Report.doc included on this book's CD-ROM.)
2. Type the text that you want to appear in the Word document.
3. Place the insertion point at the location in the Word document at which you want to place a new spreadsheet.
4. On Word's menu choose Insert, Object. The Object dialog box appears.
5. Choose the Create New tab, then select one of the registered OLE Server applications listed in the Object Type list. For this example, choose Microsoft Excel Worksheet. Click OK.
Excel (the server application) launches automatically and provides a worksheet window. Notice that the menus and toolbars from Excel have temporarily replaced Word's menus and toolbars. You can resize the worksheet, enter cell headings, create formulas, and so on. However, when you click the mouse outside of the delimited worksheet area, Excel terminates and the menus and toolbars for Word reappear.
6. Finish the Word document, and then save it.

Using In-place Editing

Editing a compound document is very easy. Servers that are OLE 2.0-compliant allow in-place editing. This simply means that the user can edit the embedded or linked data objects within the structure of the container document. To see how to accomplish this, follow these steps:

1. Launch Word and open one of the Word documents you created that contains an embedded document.
2. Double-click on an embedded worksheet object. Excel launches automatically. Now make whatever editing changes you want to the worksheet.
3. When you are done, simply click outside the delimited area of the worksheet. The edit window closes and Excel automatically quits.
4. To save the changes, choose File, Save or click the disk icon.

Creating Linked Documents

There are several ways to create linked documents. You typically use a linked document when multiple users need to see and/or update information in real time. Linked documents always start by using an existing external file. Changes made to the external file are visible when viewed by the compound document.

The external file can be located locally or on a different machine in either a read-only or read-write share point. These share permissions can control whether users can only view the linked data, or if they have the ability to change the data. In either case, the data reflects the current contents of the file at the time the host document is opened.

In this example, a sales manager allows access to a spreadsheet on his machine. Salespersons use a Word document to view sales figures:

1. Create and save an Excel spreadsheet with monthly sales figures. (Alternatively, use the file named Car Sales.xls on the CD.)
2. Launch Word and create a new document, then type the text that you want to appear in the Word document. (Alternatively, use the file Salesperson of the Month.doc included on the CD.)
3. Place the insertion point at the location in the Word document at which you want to place the worksheet.
4. On Word's menu choose Insert, Object. The Object dialog box appears.
5. Choose the Create from File tab. Next, type the name of the file, or use the Browse button to locate the desired Excel spreadsheet (refer to Figure 15.10). (Alternatively, use the file Car Sales.xls included on the CD.) Choose the checkbox labeled Link to File.
6. Finally, click OK to link the document.
7. Finish the Word document, and then save it.

Editing Linked Documents

Editing a linked compound document can be very simple. However, unlike embedded documents, edits to linked documents are not performed in-place. Edits to linked documents launch a separate visible instance of the application used to create the linked data. This separate application is considered a warning to the user that they are updating an external file and not merely updating an embedded document. To see how to accomplish this action, follow these steps:

1. Launch Word and open one of the Word documents you created that contains a linked document.
2. Double-click on a linked worksheet object. Excel launches automatically. Now make whatever editing changes you want to the worksheet.
3. When you are done, save the file; choose File, Save. Choose File, Exit to return to the host document.

Drag-and-Drop Linking

Another way to create a link is to use drag-and-drop linking. By using this technique you can select a portion of the external document rather than the entire external document. For this example, use the same files as in the previous linking examples. Follow these steps:

1. Open Excel, then create and save an Excel spreadsheet with monthly sales figures. (Alternatively, use the file named Car Sales.xls on the CD.)
2. Launch Word and create a new document, and then type the text that you want to appear in the Word document. (Alternatively, use the file Salesperson of the Month.doc included on the CD.)
3. In Excel, highlight the cells you want to link into the Word document. If you have opened Car Sales.xls, drag the mouse to select D1 through D6. Right-click the mouse within the selected range, then choose Copy from the pop-up menu.
4. Return to Word and place the insertion point at the location where you want to insert the link. Then choose Edit Paste Special from Word's menu. The Paste Special dialog box appears.
5. In the Paste Special dialog box, choose Paste Link, and then select Microsoft Excel Worksheet Object from the list of available objects.
6. Finally, click the OK button to link the document.
7. Finish the Word document, and then save it.

Using the DCOMCNFG Utility

As described earlier, DCOM allows you to place client and server components on different machines. Following installation of a client component, the client computer has no knowledge as to which other computer holds the server component to communicate with. Configuring the client computer with the proper name of the server computer that contains the server component is one of the configuration tasks performed by DCOMCNFG. Assume that a server component used in a bank has the capability to access your bank account. The server component should be configured with information restricting who is allowed to see your account balance, and further restricts who has the ability to perform transactions on your account. DCOMCNFG has the ability to configure software use on a user-by-user basis, and even on a function-by-function basis if needed. As an administrator, you use DCOMCNFG to configure both the client and the server computers to ensure both secure and reliable communication.

The default security mechanism used by Windows 98 is known as share-level security, but is considered to be a relatively weak form of security. Windows 98 can alternately be configured to use user-level security, which is a more robust security scheme; however, in order to provide user-level security on Windows 98 you also use an external security provider such as a Windows NT Domain Controller or a NetWare server. DCOM relies on user-level security to protect the data that it accesses. Whenever a user attempts to access a resource, his UserID is checked against the security provider to determine if he should be allowed access.

Windows 98 requires that you change to user-level security prior to configuring DCOM. In fact, if you attempt to run DCOMCNFG while using share-level security, you see a dialog box stating that you must change to user-level security prior to using DCOM or DCOMCNFG (see Figure 15.11).

Figure 15.11

The dialog box you see when you run DCOMCNFG using share-level security.

The DCOMCNFG utility displays information about server applications that are read from the Registry, and also makes changes to the Registry. The majority of the configuration takes place within the HKEY_CLASSES_ROOT subtree.

DCOM on Windows 98

If you have configured DCOM on Windows NT, you should be aware that there are several differences when configuring DCOM on Windows 98. On Windows NT, the DCOM server can be launched on demand by a DCOM request from a remote DCOM client program; Windows 98 does not automatically launch the server. Typically, DCOM server components are run on NT servers instead of Windows 98 computers. However, if you want to use Windows 98 as a DCOM server you should provide a means to launch the server application during system boot.

Second, DCOM servers typically remain loaded in memory only as long as there is a client using the server. When the last client program ends, the server removes itself from memory. If a DCOM server is intended for use on Windows 98, it can be written so that it remains in memory indefinitely and does not follow the default behavior of a DCOM server. (The server program included on the accompanying CD-ROM is written to run indefinitely.)

NOTE: If both the client and server components reside on a single Windows 98 machine, the server does launch automatically when the client is run. This, however, is because COM is starting the server rather than DCOM.

Client/Server Program Included on the CD-ROM

The CD-ROM that accompanies this book includes a simple client/server program that you can install and use to test DCOM and configure DCOM using DCOMCNFG. Three setup programs are associated with this chapter: One installs only the server, one installs only the client, and another installs both the client and server on a single machine. Use the third setup if you want to test DCOM's ability to alternate where the client looks for the server (between the local machine and a remote machine). You can install the server-only setup on a remote machine, then alternate the client between the two server components.

The client program provides a user interface and accesses the server component. The server component includes two functions: One calculates mortgage payments and the other reverses a string of characters.

If you install the client/server program from the CD, you can use REGEDIT to see what DCOM has configured. The text refers to specific GUIDs and classes registered during the installation process.

If you would like, you can use REGEDIT to view HKEY_CLASSES_ROOT. After the installation you see the following:

A ProgID named DCOMDemo.Application

A CLSID of {FCB0026A-D7FA-11D1-8DE5-0020AF27BBB5}

These two entries are also repeated within the AppID section of HKEY_CLASSES_ROOT. DCOM places the name of the Remote Server in the RemoteServerName key of the CLSID.

Before you can do any configuration using DCOMCNFG, you first need a Windows NT Domain (or other security provider), and you must configure Windows 98 with user-level security. The steps to accomplish this are covered next.

Changing Windows 98 to User-level Security

To change Windows 98 from share-level to user-level security, follow the steps below. Chapter 21, "Understanding Windows 98 Networking," describes user-level security in greater detail. The following procedure is provided for your convenience:

1. Identify the security provider that you will use. Ensure that you have a valid account on the security provider by checking with the system administrator. Verify that your Windows 98 machine is running a transport protocol capable of communicating with the security provider.
2. Choose Start, Settings, Control Panel. Choose the Network icon. The Network dialog box opens.
3. Choose the Access Control tab (see Figure 15.12). Then choose User-level Access Control. In the Obtain List of Users and Groups From text box, type the name of an NT Domain. Click OK.
4. A dialog box appears warning you that all existing shares will be removed. Click Yes to continue.
5. You may be prompted for the Windows 98 CD to copy files to the hard drive. Following file copy, the System Settings Change dialog box appears, indicating that the computer must restart for the new settings to take effect. Click Yes to allow restart.
6. Following the restart, log on to Windows 98, then choose Start, Settings, Control Panel. Click the Network icon. The Network dialog box opens.
7. On the Configuration tab, select Client for Microsoft Networks, and then choose the Properties button. The Client for Microsoft Networks Properties dialog box appears (see Figure 15.13).
8. Choose the Log On to Windows NT Domain checkbox. In the Windows NT Domain text box, type the name of the NT Domain you want to use for authentication. Click the OK button.
9. The System Settings Change dialog box appears, indicating that the computer must restart for the new settings to take effect. Click Yes to allow the restart.

Figure 15.12

The Access Control property page from the Network applet.


Figure 15.13

The Client for Microsoft Networks properties page.

Select a Location in Which to Run the Server

After logging on to Windows 98 and being validated by a security provider, you can run the DCOMCNFG program. By using this utility you can determine where clients running on your Windows 98 machine will look for the server. For server components located on the computer you are configuring, you can select who has the ability to access and use the server component.

To launch the DCOM Configuration Utility, follow these steps:

1. Choose Start, Run.
2. Type DCOMCNFG in the Open text box, then click OK.

The Distributed COM Configuration Properties dialog box appears. In the Applications list, you see the OLE servers that have been registered on your machine. Through this utility, you can set default configuration settings that apply to OLE servers, or you can establish settings for a specific server that override the default settings (see Figure 15.14).

Figure 15.14

The Distributed COM Configuration Properties dialog box.

OLE servers (ActiveX servers) are typically registered by the setup program that installs the server; however, as an administrator, you can register and unregister server components manually. The process used to register a server component varies, depending on whether the component is an .EXE or a .DLL file.

All ActiveX/OLE server registrations occur within the HKEY_CLASSES_ROOT subtree.

Server components compiled as .EXE files self-register the first time they are run. Locate the name of the .EXE server file and double-click it. The server runs momentarily, then ends. In the process, the server checks the Registry and if not already registered, it registers itself. To unregister a server, run the .EXE file with the /unregserver switch. Server components compiled as .DLL (and .OCX for ActiveX controls) are registered by using the REGSVR32.EXE program. For instance, to register a .DLL file named MiddleTier.DLL, you would enter REGSVR32 MiddleTier.DLL from the Run command or a Command Prompt. To unregister the same .DLL you would enter REGSVR32 /u MiddleTier.DLL from the Run command or the command prompt.

Alternately, many 32-bit servers are unregistered when you remove the server application by using the Add/Remove Programs icon in Control Panel.

To establish DCOM settings for an individual server, select the server from the Applications list, then choose the Properties button.

The General tab displays information about the server (see Figure 15.15). There are no configuration settings on this tab.

Figure 15.15

The General tab of the Microsoft Excel Worksheet Properties dialog box.

The Location tab (see Figure 15.16) allows you to determine where a client program will look to find the server. The default setting is set up to run the server on the local machine. You can choose to run the server on a specific remote machine by selecting Run Application on the Following Computer and typing the name of the machine where the remote server application is located. You can also choose to run the application on the server that contains the data. After you have made your selections, click the Apply or the OK button.

Figure 15.16

The Location tab of the Microsoft Excel Worksheet Properties dialog box.

Use Appropriate Security Settings

The Security tab (see Figure 15.17) allows you to accept the default security settings, or to establish individual security settings for this server. To establish specific security settings, choose Use Custom Access Permissions, then choose the Edit button. The Access Permissions dialog box appears.

Figure 15.17

The Security tab of the Microsoft Excel Worksheet Properties dialog box.

The Access Permissions dialog box (see Figure 15.18) displays the users or groups that have been granted access to this server. To grant additional users or groups access to the server, choose the Add button. The Access Permissions dialog box appears.

Figure 15.18

The Access Permissions dialog box.

The Add Access Permissions dialog box (see Figure 15.19) allows you to choose users or groups that can use DCOM server applications. Select the names of users or groups from the Name list on the left, then choose either Grant Access or Deny Access. The names move to the corresponding window. When you have made your selections, click OK. The Registry is updated to reflect your new settings.

Figure 15.19

The Add Access Permissions dialog box.

Establish Default DCOM Settings

The Default Properties tab on the Distributed COM Configuration Properties dialog box (see Figure 15.20) allows you to establish default settings for server applications on this machine. Remember that individual settings can override the default settings you establish here.

Figure 15.20

The Default Properties tab from the Distributed COM Configuration Properties dialog box.

The Enable Distributed COM on this Computer check box determines whether DCOM on this machine is allowed to communicate with DCOM on another machine.

The Default Authentication Level list has two choices: None and Connect. This selection determines whether the security provider is checked by an inbound DCOM request. If you do not want to authenticate users, choose None. If you choose Connect, the security provider is checked for authentication when a DCOM connection request is received.

The Default Impersonation Level selection determines whether the server application can temporarily impersonate the UserID and password of the user on the client computer. This is useful and often necessary in order to gain access to sensitive data. Remember, server components are used by many people; some people require access to secure data and others do not. Identify allows the server to identify the UserID of the client. Impersonate allows the server to temporarily assume the security attributes of the user on the client computer.

The Default Security tab (see Figure 15.21) allows you to establish users and groups who have default permission to access servers on this computer. To establish or change these settings, choose the Edit Default button. The Add Access Permissions dialog box appears.

The Add Access Permissions dialog box (see Figure 15.22) is used to grant or deny access to the DCOM server application. Select the names of users or groups from the Name list on the left, then choose either Grant Access or Deny Access. The names move to the corresponding window. When you have made your selections, click OK. The Registry is updated to reflect your new settings.

Figure 15.21

The Default Security tab from the Distributed COM Configuration Properties dialog box.

Figure 15.22

The Add Access Permissions dialog box.

Conclusion

This chapter introduced several key client/server technologies available today on Windows 98. These technologies are open and supported by Windows NT, and to some extent by Macintosh, UNIX, and some mainframe platforms.

In corporate environments you might expect to see a growing number of applications using client/server and N-Tier applications. As a system administrator, you should know how to install, configure, and test distributed applications to ensure both reliable and secure connectivity between components.

Previous chapterNext chapterContents

� Copyright, Macmillan Computer Publishing. All rights reserved.