In addition to supporting component object model (COM) for interprocess communication on a local computer, Windows NT Server now supports distributed component object model (DCOM). DCOM (or Networked OLE) is a system of software objects designed to be reusable and replaceable. The objects support sets of related functions, such as sorting, random-number generation, and database searches. Each set of functions is called an interface, and each DCOM object can have multiple interfaces. When applications access an object, they receive an indirect pointer to the interface functions. From then on, the calling application doesn't need to know where the object is or how it does its job.
DCOM allows you to efficiently distribute processes across multiple computers so that the client and server components of an application can be placed in optimal locations on the network. Processing occurs transparently to the user. Thus, the user can access and share information without needing to know where the application components are located. If the client and server components of an application are located on the same computer, DCOM can be used to transfer information between processes. DCOM is platform independent and supports any 32-bit application that is DCOM-aware.
Note
Before you can use an application with DCOM, you must use DCOM Configuration to set the application's properties.
DCOM is the preferred method for developers to use in writing client/server applications for Windows NT.
With DCOM, interfaces can be added or upgraded without deleting the old ones, so applications aren't forced to upgrade each time the object changes. Functions are implemented as dynamic-link libraries, so changes in the functions, including new interfaces or the way the function works, can be made without recompiling the applications that call them.
Windows NT 4.0 supports DCOM by making the implementation of application pointers transparent to the application and the object. Only the operating system needs to know if the function called is handled in the same process or across the network. This frees the application from concerns with local or remote procedure calls. Administrators can choose to run DCOM applications on local or remote computers, and can change the configuration for efficient load balancing.
For example, suppose your company's payroll department uses an application with DCOM to print paychecks. When a payroll employee runs a DCOM-enabled client application on a desktop, the application starts a business-rules server. Then, the server application connects to a database server and retrieves employee records, such as salary information. The business-rules server then transforms the payroll information into the final output and returns it to the client to print.
Your application may support its own set of DCOM features. For more information about configuring your application to use DCOM, see your application's documentation.
DCOM builds upon remote procedure call (RPC) technology by providing a more scalable, easier-to-use mechanism for integrating distributed applications on a network. A distributed application consists of multiple processes that cooperate to accomplish a single task. Unlike other interprocess communication (IPC) mechanisms, DCOM gives you a high degree of control over security features, such as permissions and domain authentication. It can also be used to launch applications on other computers or to integrate web-browser applications that run on the ActiveX™ platform.
Microsoft Visual Basic®, Enterprise Edition customers who are currently using Remote Automation can easily migrate their existing applications to use DCOM. For more information, see your Visual Basic documentation or visit the Visual Basic web site at www.microsoft.com/vbasic.
The Windows NT 4.0 security model is easily extended to DCOM objects. Administrators set permissions on DCOM applications and can vary those permissions for local and remote execution.
Once a DCOM-enabled application is installed, you can use DCOM Configuration (in Control Panel) for the following purposes.
The computers running the client application and the server application must both be configured for DCOM. On the computer running as a client, you must specify the location of the server application that will be accessed or started. For the computer running the server application, you must specify the user account that will have permission to access or start the application, and the user account that will be used to run the application.
The connection between the client and server portions of distributed applications must allow data to flow in both directions. There are a number of ways to establish this connection. The Windows NT operating system provides seven different Interprocess Communication (IPC) mechanisms.
A pipe is a portion of memory that can be used by one process to pass information to another. A pipe connects two processes so that the output of one can be used as input to the other.
Named pipes and mailslots are actually written as file system drivers, so implementation of named pipes and mailslots differs from implementation of other IPC mechanisms. There are entries in the registry for NPFS (Named Pipe File System) and MSFS (Mailslot File System). As file systems, they share common functionality, such as security, with the other file systems. Local processes can also use named pipes and mailslots. As with all of the file systems, remote access to named pipes and mailslots is accomplished through the redirector.
Named pipes provide connection-oriented messaging. Named pipes are based on OS/2 API calls, which have been ported into the Win32 base API set. Additional asynchronous support has been added to named pipes to make support of client/server applications easier.
In addition to the APIs ported from OS/2, the Windows NT operating system provides special APIs that increase security for named pipes. Using a feature called impersonation, the server can change its security identity to that of the client at the other end of the message. A server typically has more permissions to access databases on the server than the client requesting services has. When the request is delivered to the server through a named pipe, the server changes its security identity to the security identity of the client. This limits the server to only those permissions granted to the client rather than its own permissions, thus increasing the security of named pipes.
The mailslot implementation in the Windows NT operating system is a subset of the Microsoft OS/2 LAN Manager implementation. The Windows NT operating system implements only second-class mailslots, not first-class mailslots. Second-class mailslots provide connectionless messaging for broadcast messages. Delivery of the message is not guaranteed, although the delivery rate on most networks is quite high. Connectionless messaging is most useful for identifying other computers or services on a network, such as the Computer Browser service offered in the Windows NT operating system.
For a description of connectionless messaging, see "Data Transfer Modes," earlier in this chapter.
NetBIOS is a standard programming interface in the personal-computing environment for developing client/server applications. NetBIOS has been used as an IPC mechanism since the introduction of the interface in the early 1980s.
A NetBIOS client/server application can communicate over various protocols:
From a programming perspective, higher-level IPC mechanisms, such as named pipes and RPC, have superior flexibility and portability.
NetBIOS uses the following components.
Figure 1.14 NetBIOS programming interface
MS-DOS and NetBIOS applications are hard-coded to use a specific LANA number for communicating on the network. You can assign a LANA number to each network route. The network route consists of the protocol driver and the network adapter that will be used for NetBIOS commands sent to its assigned LANA number.
To assign a LANA number to a network route
1. Click Start, point to Settings, and click Control Panel.
2. Double-click Network.
3. Click the Services tab.
4. Click NetBIOS Interface, and then click Properties.
The NetBIOS Configuration dialog box appears.
5. Click the number you want under Lana Number, and then click Edit.
6. Type a new number, and click OK.
The Windows Sockets API provides a standard interface to protocols with different addressing schemes. The Sockets interface was developed at the University of California, Berkeley, in the early 1980s. The Windows Sockets API was developed to migrate the Sockets interface into the Windows and Windows NT environments. Windows Sockets was also developed to help standardize an API for all operating system platforms. Windows Sockets is supported on the following protocols.
Figure 1.15 Windows Sockets programming interface
Windows Sockets consists of the following items.
Much of the original work on Remote Procedure Call (RPC) was initiated at Sun Microsystems. This work has been carried forward by the Open Software Foundation (OSF) as part of their Distributed Computing Environment (DCE). The Microsoft RPC implementation is compatible with the OSF/DCE standard RPC.
It is important to note that it is compatible but not compliant. In this situation, compliance implies that you started with the OSF source code and worked forward. For a number of reasons, Microsoft developed RPC from the ground up. The RPC mechanism is completely compatible with other DCE - based RPC systems, such as the ones for HP and IBM/AIX systems, and will interoperate with them.
The Microsoft RPC mechanism is unique in that it uses the other IPC mechanisms to establish communications between the client and the server. RPC can use the following to communicate with remote systems:
If the client and server portions of the application are on the same machine, local procedure calls (LPCs) can be used to transfer information between processes. This makes RPC the most flexible and portable of the IPC choices available.
RPC is based on the concepts used for creating structured programs, which can be viewed as having a "backbone" to which a series of "ribs" can be attached. The backbone is the mainstream logic of the program, which should rarely change. The ribs are the procedures that the backbone calls on to do work or perform functions. In traditional programs, these ribs were statically linked to the backbone and stored in the same executable.
Windows and OS/2 use data-link libraries (DLLs). With DLLs, the procedure code and the backbone code are in different pieces. This enables the DLL to be modified or updated without changing or redistributing the backbone portion.
RPC takes the concept one step further and places the backbone and the ribs on different computers. This raises many issues, such as data formatting, integer-byte ordering, locating which server contains the function, and determining which communication mechanism to use.
RPC is the developer's preferred method for writing client/server applications for Windows NT. The components necessary to use a remote procedure call are the following items.
Client applications are developed with a specially compiled "stub" library. The client application "thinks" it will call its own subroutines. In reality, these stubs will transfer the data and the function to the RPC RT module. This module will be responsible for finding the server that can satisfy the RPC command. Once found, the function and data will be sent to the server, where they are picked up by the RPC RT component on the server. The server piece then loads the library needed for the function, builds the appropriate data structure, and calls the function.
The function interprets the call as coming from the client application. When the function is completed, any return values will be collected, formatted, and sent back to the client through the RPC RT. When the function returns to the client application, it will have the appropriate returned data or an indication that the function failed.
Figure 1.16 How RPC calls operate
Network Dynamic Data Exchange (NetDDE) is an extension of the Dynamic Data Exchange (DDE) protocol that has been in use since Windows version 2.x. NetDDE enables users to use DDE over a NetBIOS-compatible network. To understand NetDDE, you need to know something about DDE.
DDE is a protocol that allows applications to exchange data. To perform such an exchange, the two participating applications must first engage in a DDE conversation. The application that initiates the DDE conversation is the DDE client application, and the application that responds to the client request is the DDE server application.
A single application can be simultaneously engaged in multiple DDE conversations, acting as the DDE client application in some DDE conversations and as the DDE server application in others. This allows a user to set up a DDE link between applications and have one of the applications automatically update another.
Figure 1.17 NetDDE
NetDDE extends all of the DDE capabilities so that they can be used across the network, using the NetBIOS emulator. This enables applications on two or more workstations to dynamically share information. NetDDE is not a special form of DDE but rather a service that examines the information contained in a DDE conversation and looks for a special application name. Implementing NetDDE in this manner allows any DDE application to take advantage of NetDDE without modification.
The NetDDE service examines DDE requests, looking for the use of a special application name reserved by NetDDE, which is preceded by the name of the remote system. The reserved application name is NDDE$; therefore, NetDDE is looking for DDE requests that use an application name in the following form: \\<servername>\ndde$.
Before a user can connect to a printer or directory from a remote location, the printer or directory must be shared. Similarly, a NetDDE share must be created on a computer before an application on that computer can use NetDDE to communicate with the application on another computer. NetDDE-aware applications, such as Chat, automatically create a NetDDE share for themselves during installation. For other applications, a NetDDE share can be created with ClipBook Viewer, and data can then be exchanged through the ClipBoard. In addition, Windows NT includes the DDE Share utility (Ddeshare.exe), which can be used to set up a NetDDE share so that applications can directly exchange data.
NetDDE shares are defined in the registry. They are accessed by communicating with the Network DDE Service Data Manager (DSDM), which is the Windows NT operating system service that supports the rest of NetDDE.
Because NetDDE is simply an extension of DDE, the same APIs used to establish a DDE conversation are used to establish NetDDE conversations.
In Windows NT 3.1, the NetDDE services automatically load at system startup. In Windows NT 3.5 and later, the default startup type for NetDDE is manual, which improves startup time. The startup type for the NetDDE services can be configured through Control Panel.
The Server Message Blocks (SMB) protocol, developed jointly by Microsoft, Intel, and IBM, defines a series of commands used to pass information between networked computers. The redirector packages network-control-block (NCB) requests meant for remote computers in a SMB structure. SMBs can be sent over the network to remote devices. The redirector also uses SMBs to make requests to the protocol stack of the local computer, such as "Create a session with the file server."
SMB uses four message types, which are listed below.
The provider DLL listens for SMB messages destined for it and removes the data portion of the SMB request so that it can be processed by a local device.
SMBs provide interoperability between different versions of the Microsoft family of networking products and other networks that use SMBs, including those on the following list.