COM and DCOM

Principle and application of com,dcom

1. DCOM

The process transparency of COM is manifested in the Component object and the client program can have their own process space, also can share the same process space, COM is responsible for the customer's call to the correct upload to the Component object, and ensure the correctness of the parameter passing. The Component object and the client code do not have to consider the details of the invocation pass, as long as the normal function call is implemented. If the process transparency feature is further extended, the process transparency is extended to location transparency, and the distributed Component Object model is referred to as DCOM, considering the situation of the Component object and the client program running on different computers.

DCOM is an extension of COM that can support communication between component objects and client programs on different computers, or between component objects, which can be on a local area network, on a wide area network, or 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 call, so DCOM is also a seamless extension of COM. DCOM handles all the details of the underlying network protocol.

2. Switching from COM to DCOM

The process of communicating between in-process components and the client program is straightforward. The communication between the local out-of-process component and the client is not straightforward, but it uses some of the cross-process communication methods supported by the operating system.

DCOM simply replaces the local cross-process communication with a network protocol transfer process, which is only a longer route for intermediate data transfer. Of course, network communication is much more vulnerable than cross-process communication in a single system environment, so in order to ensure the reliability of the collaborative process and the ability of the program to respond to unusual events, the client program and component programs need to consider more details.

3. Positioning of DCOM objects

The client program calls the COM library's underlying creation function (such as CoGetClassObject) to create a remote component object that needs to know the remote machine name and the 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 parameter that creates the function, and the other is to use the DCOM Config tool to specify the remote machine name.

When the COM library's creation function obtains the location information of the remote object, the task created by the object is given to the SCM, and the SCM communicates with the remote machine via RPC. The SCM (program named Rpcss.exe) is also part of the COM library, but it is a separate process. The SCM is responsible for creating new COM objects and also 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, initiates the component process by the SCM on the remote machine, creates the Component object, and then returns to the client machine.

Of course, after the remote Component object is created, it will go through the processing of column sets and hashes on the way back to the client machine, including creating proxy objects and loading stub code, which are identical to the processing of the 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 is done directly through the proxy object and the stub object, as well as the underlying transport mechanism provided by the COM library.

4, column set and scattered sets

Column sets and hashes are key techniques for implementing the cross-process characteristics of COM component objects, including standard column set methods and custom column sets. The same technique applies to the communication between the DCOM Component object and the client, the difference being that the column set packet is passed differently, uses LPC for the local Component object, and uses RPC delivery for the DCOM Component object.

DCOM provides a complex set of column set and hashing mechanisms, built on the basis of RPC. Since RPC is defined as part of the DCE (Distributed Computing System) standard, DCE RPC defines the data representation of all commonly used data types, the network data Representation (Ndr,network representation). In order for stub code and proxy objects to correctly set and scatter parameters and returned results, they should use a consistent data representation NDR so that they can be called remotely in 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 expressed, and how they are maintained. The ORPC protocol has been submitted as an Internet draft to the IETF (Internet Engineering Task Force, Internet Engineering Department).

In an Internet or intranet network environment, ORPC still uses standard RPC packets, attaching some information specific to DCOM-interface pointer identifiers (Ipid,interface point identifier), version information, and extended information- is passed as an additional parameter called and returned, where Ipid represents a specific interface that invokes a particular 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 Features

As a basic architecture of distributed Application Systems, DCOM can form a client/server relationship between a client program and a DCOM Component object, which can further form a multi-tier software model. DCOM components have 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 scheme that allows different component objects to be allowed on different servers, and the location transparency of DCOM ensures that this change does not have to modify the component source program.

(2) configurable. Installation and management are two important aspects of distributed software system. DCOM provides a graphical interface configuration tool (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, which is implemented on non-NT platforms, also includes an NT-compatible security provider. The security implemented by DCOM is divided into Access security and activation security, and access security specifies that those users can invoke component objects, and fire security specifies which users can create new objects in a new process.

(4) Protocol independence.

(5) Platform independence

7. Object activation

Activation (activation) A Component object consists of two scenarios: one is to create a new Component object, and the other is to establish a connection between the existing Component object and the customer.

After COM extends to DCOM, the creation of remote objects differs. In order to identify a remote object, providing only a 128-bit GUID is not enough, you must also provide the machine name on which the remote object resides, also known as the remote server name "RemoteServerName".

(1) Creating a DCOM component method one

The DCOM Configuration tool specifies the remote server name, which enables the DCOM component to have positional transparency. On the Windows System platform, the remote server name RemoteServerName value is saved under the system registry HKEY_CLASSES_ROOT\AppID key.

From the structure of the CLSID and AppID keys, it can be seen that each appid can be used for multiple component objects, which typically represents a process shared by multiple CLSID, all of which share the same configuration information, including the remote server name and security information. The introduction of the AppID concept in DCOM avoids too many registry keywords.

(2) Creating a DCOM component method two

The first method does not always meet the requirements of the application, and some applications require control of the server to be connected during the program's operation, such as multiplayer programs, network remote management tools, and so on. For such an application, DCOM allows the name of the remote server to be specified in the CREATE function. You can specify the creation function of the remote server name: CoCreateInstanceEx, CoGetClassObject, Cogetinstancefromfile, Cogetinstancefromeistorage.

Another function of specifying a server name in a program is to implement dynamic load balancing for distributed applications. At present, it is very difficult for DCOM to implement the automatic load balancing feature, but we can set up an Allocation Service component object, all clients create the dispatch service component object on the specified machine, and create another remote object that really implements the application function, in return this remote object to the client program, Later, the client program no longer uses the dispatch service component object and calls the remote object directly. Instead, the dispatch Service component object can create a remote object by selecting the lightest-loaded server from a set of servers based on the current load state.

8. Remote creation of in-process components: Agent process (surrogate)

In order to remotely run an in-process component that is a DLL component, there is an agent process (surrogate processes) on the remote machine. In addition to the ability to remotely start in-process components, the agent process provides the following features:

A critical error in an in-process component program only affects the agent process and does not cause the client process to crash;

L an agent process can provide services to multiple clients at the same time;

• Customers can protect themselves from unreliable component program code and access only the services provided by the component program;

Running in-process services in the agent process enables the DLL to have the security of the agent process.

Windows introduces the default agent process and the protocol specification for writing custom agent processes. The default implementation of the agent process is a hybrid threading model, a pseudo COM service program. When multiple DLL components are loaded into a single agent process, the process instantiates each DLL component object according to the threading model specified in the registry. If a DLL Component object supports two threading models, then COM chooses the free-threaded model. COM can control the uninstallation of DLL component programs or terminate the agent process.

If an in-process component meets the following criteria, it will be loaded into the agent process:

In the system registry, the AppID value must be specified under the CLSID keyword of the Component object, as well as the corresponding AppID keyword;

L The client program must set the CLSTX_LOCAL_SERVER flag when creating an object instance;

The LocalServer32, LocalServer, LocalService values are not specified under the CLSID keyword of the Component object;

The CLSID keyword of the Component object contains the InProvServer32 subkey;

L The DLL file specified in the InProcServer32 subkey must exist;

The DllSurrogate value is specified under the AppID key corresponding to the Component object.

If the LocalServer, LocalServer32, or LocalService values under the CLSID key of the Component object indicate the presence of the EXE, the EXE program will be executed preferentially and COM no longer starts the agent.

9. Connect to a remote object instance using a moniker (moniker)

Typically COM object instances are not interchangeable, or cannot be exchanged with each other. It differs from other object instances of the same class by its own unique state.

The COM naming and binding mechanisms described in Chapter 8th apply to remote objects as well.

10. Connection management--control of remote object lifetime

The most basic mechanism for the lifetime of a COM control object is the reference count, which takes advantage of IUnknown's AddRef and release member functions to control the object's lifetime. DCOM optimizes the invocation of AddRef and release for remote objects. The optimization process uses the OXID (object exporter identifier, objects management identifier) object. OXID is a 64-bit value that can be used by OXID to call RPC string bindings to their target ipid. However, before executing the call, the calling process must translate OXID into a set of bindings that the underlying RPC can interpret.

On each DCOM-capable machine, there is a service called the OXID parser (Oxid Resolver), which is responsible for providing the client with the RPC string binding information used to connect to the OXID, as well as receiving the "pinging" information sent remotely. The OXID parser communicates via RPC, which implements the RPC interface Ioxidresolver (not the COM interface).

11. Connection Management--pinging mechanism

If you do not consider that the client process may terminate abnormally, it is sufficient to take advantage of the remote reference count to control the object lifetime. To detect whether the client program is terminating abnormally, DCOM provides an easy way to "pinging". In the version of DCOM now implemented, pingperiod=2 (min) and numpingstotimeout=3, these values cannot be changed.

12, connection management--Connection point Management

Many real-world distributed applications require two-way communication between two of objects. Because DCOM is a seamless extension of COM, the COM-provided connection point mechanism introduced in the 6th chapter also applies to remote object scenarios.

13, connection management--Connection transfer

The load Balancing feature for distributed applications using the dispatch Service Component object actually uses the connection transfer feature.

Connection passing is not equal to the delivery of remote object creation, and DCOM does not support the delivery of object creation under location transparency, but it can take advantage of the connection passing attribute to implement the delivery of remote object creation by controlling the server name.

14. Concurrency Management--Threading model

COM itself does not have a threading model, you can think of COM borrowing the threading model provided by the Windows operating system, the WIN32 program design model separates threads into UI threads and worker threads, and COM separates threads between sets of threads and free threads. The suite thread uses the CoInitialize API function to perform the initialization of the COM library, and COM creates a hidden window inside the suite thread that is responsible for sending the client's call to the Component object in the suite to the correct member function.

15, concurrency Management--Message Filter

The threading model of COM and DCOM enables us to understand the thread transitions in the process of calling client programs and component objects, but calls can block programs and even cause client programs to fail. For this reason, COM provides a message filtering mechanism that can be used both for client programs and component programs, allowing them to choose between incoming and outbound calls.

COM divides the invocation into three categories: the first is synchronous invocation, which is the most common invocation type, the client invokes the Component object, waits until the object executes all functions and then returns, and the second is an asynchronous invocation, the client invokes the Component object, but does not wait for the object to finish functioning and then returns to the client, This is the connection object mechanism we introduced in the 6th chapter, and the third is the input synchronous invocation, the called object must be returned before discarding control to ensure that the user interface is not affected, that is, the object cannot invoke any functions that might enter the message loop during the call execution.

16. DCOM Security Model

DCOM security is built on the underlying security provider, and some operating systems can support multiple security providers, and DCOM and RPC can support multiple security providers at the same time. All security providers have one thing in common, they provide a way to represent security roles (typically user accounts), a way to identify security roles (typically through passwords or private keys), and a set of mechanisms for managing security roles and their authentication data.

17. DCOM security model--security policy

(1) Access security and excitation security.

(2) The security identity of the object.

(3) protect the data.

(4) Level of accreditation.

(5) Imitation level.

18. DCOM security Model--Security Configuration

DCOM provides a variety of ways to protect applications, on the one hand, DCOM can enforce the use of security without any object or object's client program to do any work, the object's security settings can be externally configured and DCOM will automatically be forced to use. On the other hand, DCOM exposes its complete security structure to the developer, so that both the client and the object can program their security policies.

COM and DCOM