DCOM Architecture (1) Technology White Paper --- Microsoft Abstract: This article mainly introduces the internal principles of DCOM, and the TCP / IP protocol of the object is implemented. This article is suitable for program developers, especially for developers who want to develop Internet, intranet, and deeper applications. In some aspects we assume that the reader is already familiar with the basic concept of COM, although some concepts are involved in discussing distributed programming. Overview Microsoft Distributed Component Object Model (DCOM) is an extension of Component Object Model (COM), which supports communication between components on different two machines, and whether they are running on the LAN, WAN, or Internet. With DCOM your application, you will be able to make a spatial distribution. Since DCOM is a seamless upgrade of COM, you can benefit from your existing COM, your previous applications, components, and tools developed in COM, can be moved into a distributed environment . DCOM will block the details of the underlying network protocol, you only need to concentrate your application. Who is suitable for reading this article
This article is suitable for program developers, especially for developers who want to develop Internet, intranet, and deeper applications. In some aspects we assume that the reader is already familiar with the basic concept of COM, although some concepts are involved in discussing distributed programming. How to get the main content of this article
This article is part of the series of information about COM and DCOM technology. You can read it from the end to the end, or it can be used as a technical reference. In the last chapter of this article, this paper introduces other articles in this series of articles. If you still don't know what DCOM is, "DCOM Technical Overview" article will be useful to you. If you want to know how to apply DCOM to solve a specific problem, "Solution In Action" article will help you. Where can I get DCOM?
DCOM is currently issued with Windows NT V4.0, Windows 2000 operating system, and DCOM's Windows 9x version can be downloaded from Microsoft Site. The chapter of the COM architecture will give you an overview of the interior of DCOM technology, and you will see how DCOM implements simple distributed computing for the client, and no flexibility, upgradeability, Loss performance, etc. DCOM is in your application component, it provides the ability to connect components transparent, as shown in the following picture: How does the core content of the positioning object COM technology create communication between components and how to create components? Example. These technologies are usually taken as "Activation Mechanisms) to discuss how they work. One foundation in the local and distal to create a new object distribution system is to create an object. The object class is named in the COM. When the GUID is named Class IDs when the GUID is named for the object class, these Class IDs are just some 128-bit integers, which provides the object class's non-renowned namespace. If you want to create a new object, you can call any of the following functions provided by the COM library:
COCREATEINTANCE (EX) Creating an uninitialized object class interface pointer COGETInstanceFromFile Creates a new instance of an object class, and uses files to initialize COGETInstanceFromistorage Create a new instance of an object class, and use Storage to initialize CogetClassObject Return to an object class. Interface pointer COGETCLASSOBJECTFROMURL Returns an object class's class pointer, if not specified class, the function will choose the most appropriate class for specifying the MIME type. If the target object is already installed on the system, it returns its instance, and if not, download and install it from the specified URL. The COM library function looks for information in the system registry, creates an instance of an object, and returns an excuse pointer to the caller. DCOM enhances the technology of creating objects in the COM library, which supports creating object classes on another machine. To create object classes on other machines, COM library functions require the machine name of the machine. If you know the machine name of the target machine and CLSID, COM bitter is called to call the SCM (Service Control Manager) to connect the SCM connection on the target machine. DCOM provides two techniques for obtaining a target machine name when creating a remote object class: 1, store the server name as a fixed configuration information in the registration information of the object class. 2, specify the target machine parameters in CocreateInstanceex, CogetherInstanceFromFile, CogetherInstanceFromStorage, COGETCLASSOBJECT. The external remote server is configured to configure the server name as a fixed configuration, which is especially effective for providing location transparency: the client does not need to know whether the component is running local or far run. When the server name exists as component configuration information on the client computer, the client does not need to maintain and obtain the location of the server. The client only needs to know the CLSID of the component, just simply call the CocreateInstance function, and the COM library will be transparently created on the server. Even the conventional COM components designed before DCOM can also use this method. Note that the server cannot be able to create a request to create an object once again to another server, for example: client X Applicable Server Name Develops Create Object A on the server y, and the server name of the object A on the server Y is a server named server Z, this time the object created on the client X will be done on the server y. For most applications, it is already enough for each component, which will make the client that the client does not need to maintain the server of the server created. If the server changes, just change the configuration information, and the client program does not need to change. Component's remote server configuration is stored in HKEY_CLASS_ROOT (HKCR) in the registry: [hkey_classes_root / appid / {appid-guid}] "remoteservername" =
For example: Auction Services A auction service is implemented as a DCOM component. All auction activities and auctions are managed by reorganizing components, and the buyer's bid will reach all customers through the connection point. In this application, customers don't need to know which server they connect, they only know to connect to the auction server. The server's DNS name has been written in the registry of the client computer, and the COM library function will automatically search the server. The following is the client's registry configuration: [HKEY_CLASSES_ROOT / CLSID /
MULTI_QI mqi [2] = {& IDD_IbackupAdmin, NULL, 0} {& IDD_IbackupConfig, NULL, 0} CONSERVERINFO srvinfo = {0, L "MyCentralFileServer.cia.gov", NULL, 0} HRESULT hr = CoCreateInstanceEx (CLSID_MyBackupService, NULL, CLSCTX_SERVER, & srvinfo, SizeOf (MQI) / SizeOf (MQI [0]), & MQI); IF (SucceSed (MQI [1] .hr)) {LPWSTR PSTATUS = NULL; ibackupconfig * PBackConfig = MQI [1] .pltf; hr = PBackupConfig -> getCurrentBackupStatus (& PStatus); PBackupConfig-> reslease ();} Remote Run internal components: The agent process To run components within a process in the server side (that is, a DLL implementation component), you need to run one on the server side Agent process. To be able to run far away, the proxy process needs to have the following features: l The runtime error of the components within the process is isolated from the proxy process. l A proxy process can serve multiple clients at the same time. l The customer program When accessing the service provided by the server, some unsafe codes in the proxy process should ensure the security of the customer process. l The proxy process should provide security in the process components to ensure that Windows NT V4.0Service Pack 2 and DCOM's Windows95 versions provide a sample agent process for developers' reference. The sample agent process provided is a virtual COM server for hybrid thread mode. This agent process guarantees that all DLL components will run in all DLL components when they are loaded into the proxy process. If the DLL component supports single thread and multi-thread mode, COM will select multithreading mode for initialization. The sample proxy process is implemented such that the COM can control the exit of the DLL component and the process termination. A process within a process will be loaded by the proxy process in the following cases: l There is an appid health in the CLSID registration in this component, and is set up appropriate proxy processes. l When you create a modified part, the CLSCTX_LOCAL_SERVER attribute should be used in the call, and the CLSID is not set to set LocalServer32, LocalServer, localService. l CLSID contains InprocServer32 Son. l The DLL file set in InProcServer32 exists. l Sets Dllsurrogate subjunction in AppID. If localserver32, localserver, localservice is set, there is an EXE file implementation component, and the EXE file is always prioritized for the order of the proxy process to load DLL components. You must give Dllsurrogate a specific proxy process file name. If you want to use the proxy process provided by the system, set the dllsurrogate to NULL. If one is to use his own agent process, set DllSurrogate to the full path name of the proxy process file. If you want to make a proxy on the server, you need to set RemoteServerName on the client, you do not need to set DLLSurrogate, and set DLLSurrogate on the server side. It is best to use the appid RunaS Subjust Settings a DLL component runs in a proxy process separately, while serving all connected customers.
