COM principles and applications----Distributed COM (DCOM)

1. DCOM

The process transparency of COM is manifested in the Component object and client program can have their own process space, can also share the same process space, COM is responsible for the customer's call to the Component object correctly, and ensure the correctness of the parameters passed. Component objects and client code do not need to consider the details of the invocation delivery, as long as the normal function calls are implemented in the way. If the process transparency feature is further expanded, the process transparency is extended to the location transparency, and the distributed Component Object model is called DCOM, considering the situation that the Component object and the client program run on different computers.

DCOM is an extension of COM that enables communication between component objects and client programs or component objects on different computers, on the local area network, on the WAN, and on the Internet. The location of the component program is transparent to the client, and we do not have to write any code to handle the remote invocation, so DCOM is also a seamless extension of COM. DCOM handles all the details of the underlying network protocol.

2. Switch from COM to DCOM

The communication process between an in-process component and a client program is relatively simple. The communication between the local out-of-process component and the client is not done directly, but it is used for some of the cross-application communication methods supported by the operating system.

DCOM simply replaces local cross process communications with a network protocol transfer process, but the intermediate data is delivered in a longer route. Of course, network communication is much more vulnerable than a stand-alone system environment, so in order to ensure the reliability of the collaborative process and the ability of the program to cope with abnormal events, the client program and component program need to consider more details.

3, the location of DCOM objects

The client invokes the underlying creation function (such as cogetclassobject) of the COM library to create a remote component object that requires knowledge of the remote machine name and object clsid.

There are two ways to get the machine name information for a remote object: One is to specify the COSERVERINFO structure in the parameters of the creation function, and the other is to specify the remote machine name using the DCOM Configuration tool.

The creation function of the COM library gets the location information of the remote object, and then the task creates the object to the SCM, and the SCM communicates with the remote machine through RPC. The SCM (program name Rpcss.exe) is also part of the COM library, but it is a separate process. The SCM is responsible for creating a new COM object and is also responsible for establishing a connection between the Component object and the client program. If you are creating a remote object, it invokes the SCM on the remote machine via RPC, starts the component process on the remote machine, and creates the Component object, then returns to the client machine.

Of course, after the remote Component object is created, it is returned to the client machine and is processed by the set of columns and the hashing, including creating proxy objects and loading stub code, which are identical to the processing of local out-of-process component objects. Once the Component object is created, the communication between the customer and the component is no longer through the SCM, but directly through the proxy object and stub object and the underlying transport mechanism provided by the COM library.

4, Lie and scattered sets

The column set and the hashing are the key technologies to realize the cross process characteristics of COM component objects, including the standard set method and the custom column set method. The same technique applies to the communication between the DCOM Component object and the client program, which differs in that the column set packet is passed in a different way, using LPC delivery for the local component object, and RPC delivery for DCOM component objects.

DCOM provides a complex set of Lie and hashing mechanisms that are based on RPC. Since RPC is defined as part of the DCE (Distributed Computing System) standard, DCE RPC defines the data representation of all common data types, namely, the network data representation (ndr,network data representation). In order for the stub code and the proxy object to correctly set and scatter the parameters and return results, they should use a consistent data representation NDR so that it can be invoked remotely under different operating system environments.

5, Object RPC

The DCOM protocol, also known as Object RPC (Orpc,object remote Procedure Call), is based on the DCE RPC protocol and can be used in a variety of component-based distributed systems. ORPC establishes a set of object-oriented remote invocation specifications that specify how calls are made on the network, how references to objects are represented, and how to maintain them. The ORPC protocol has been submitted as a draft of the Internet to the IETF (Internet Engineering Task Force, Internet Engineering).

In an Internet or intranet network environment, ORPC still uses standard RPC packets, with some information dedicated to DCOM-interface pointer identifiers (Ipid,interface point identifier), version information, and extended information- is routed as an additional parameter called and returned, where Ipid represents a specific interface that invokes a specific object on the remote machine being processed. The DCOM client must periodically "pinging" objects on the remote machine to ensure that the client and the object remain connected.

6, DCOM characteristics

As the basic architecture of distributed Application System, DCOM can form a client/server relationship between client program and DCOM Component object, and it can form multilayer software model. The DCOM component has some basic features of COM components, including reusability, language independence, and so on. Location transparency is a fundamental feature of DCOM. Other features of DCOM are as follows:

(1) scalability. On the one hand, DCOM leverages the scalability of the operating system itself; On the other hand, DCOM provides a flexible configuration that allows different component objects to be allowed on different servers, and DCOM's location transparency ensures that this change eliminates the need to modify component source programs.

(2) configurable. Installation and management are two important links of distributed software system. DCOM provides a graphical interface Configuration utility (DCOMCNFG.EXE) that enables client programs and component programs to adapt to different network environments without changing the code.

(3) security. DCOM uses the extensible security framework provided by Windows NT, and DCOM, implemented on non-NT platforms, also includes an NT-compliant security provider. The security that DCOM implements is divided into Access security and activation security, and access security specifies that users can invoke component objects, and fire security to specify which users can create new objects in a new process.

(4) Protocol independence.

(5) Platform independence