Original Address: http://www.techvanguards.com/com/concepts/serversandobjects.asp Title: Server and Object Original title: Servers and Objects original author: Binh Ly translation: wood wild fox (Roger Chen) Translator's Note:
In view of my personal preferences, some terms may be slightly different from habits. For example, Object (object) I like to call it "object." Please pay attention to when readers read. text:------------------------------------------------ -------------------------------------------------- ------- Simply said that Server is the container of Objects. Server can be implemented as a binary DLL (IN-Process) Server, because the DLL runs within the address space of the client). You can also achieve binary EXE (Out-of-process) Server Because EXE is running within a different process of client).
Benefits to create a DLL Server:
Run mode is in-Process's DLLS and client running in the same address space. Therefore, mutual communication is optimal (maximum performance). When you want to create some user-interface-based features, it is best to use DLLS. Because it doesn't make a reason for the server that creates the EXE with the window. DLL Servers is usually more easily tested / debugged than EXE Servers. Because of the potential of debugging in a remote environment. And DLL is usually debugged in a machine and a client program. Sometimes it has an advantage in using DLL Servers itself. For example, when used to extension of the Web Server to DLL, or when your Server needs to integrate with MTS.
The benefits of creating EXE Servers:
EXE Servers is more robust in error isolation. When using EXE Servers, if the customer crashes, it will not affect the server. And the DLL, whether it is a customer or a Server crash, all things will be finished together. EXE Servers is more suitable for consideration of remote deployment and security. Sometimes the EXE binary architecture itself has an advantage. For example, when you want to create a NT service.
Although DLL Servers usually run in the process with customers, if it is also possible to give him a Wrapper's EXE. This EXE is equivalent to his Host or Surrogate. In this way, any DLL Servers can be used as an EXE, just because Host is executed outside the process. MTS is an example of a DLL Host Application.
Dll Servers have become more important with the integration of MTS and COM in Windows 2000 and COM . All the servers you want can be executed by a Host that belongs to COM Runtime.
SERVER activation
Now let's discuss how the client contacts Server and then requests a specific object on a Server. How is the client do? Does he use shellexecute to load the Server? How does the client enters Server and requests an object?
Suppose the Client launches Server by calling Win32 API Shellexecute. Shellexecute requires a complete path (or at least your program must be in the system directory). This means if you move Server to another, you need to modify the path and recompile the client. Solving this question may be to save the path to the registration table. Customers always read the path of Server from the registry. But sooner or later, Server will become more and more large, so that we must put him in other machines. At this time, I can't work anymore. Because Shellexecute cannot call the program on another machine. Now we need to develop a program that can perform SHELLEXECUTE between the machine. Of course, this issue should be solved by those experts. This way we only need to use simple use. Server Location is a detail we don't want to waste too much time. COM solves this problem by defining the following criteria. 1) How to tell Clients where they are. 2) How CLIENTS can activate Servers without considering the location problem.
registered
A Server tells this world to tell this world through a process called "registration". For example, Server gives the COM interface about his own position. This is a registry in Windows. In fact, Client is not interested in Server itself. It is interested in those objects in Server. So we actually need to store Server Objects. And under each Object, there is a subkey point to the physical path to the Server file. In this way, if the client needs an object such as foo, it will say: Hi, COM, I need a object called Foo! Then COM looks checked the registry and found the actual Server file name under his sub-key. Then start Server. This is the main mechanism of Server activation in COM.
Let's take a look at the advantages of the activation mechanism described above:
Client does not need to process the details of the registration. This step is made by Server. This indicates that there must be some code to register information to COM. This process usually includes writing information to the Windows registry. If Server is locked, you only need to re-register Server. In this way, your registry will contain server registration information that update the address information. When the client requests the object next time, COM knows where to find Server. Client and Server are separated. Client as long as you tell COM, what objects are needed, scan the registry, activation Server These actions are done by COM. The same is true if Server needs to move to a remote machine. The registration information will contain a remote address, COM is responsible for establishing a remote connection, activating an object, etc., the Client does not care where Server is.
In order to let Server can register his objects. There must be a mechanism to mark these objects. Like the interface of the previous discussion, each object also has a friendly, an ugly name. The ugly name (GUID) is a number of numbers to ensure uniqueness; friendly names in order to make Client easy to identify. GUID is generated by using a statistically unique mechanism in COM. The GUID of the interface is often referred to as Interface Identifiers or IIDS, and the GUID of the object is called Class Identifiers or CLSIDS.
Back to registration. Server registers yourself through this way: it fills in the owned Objects CLSID. Each CLSIDS in the registry contains a subkey pointing to the Server file path. For example, you have a server called Fooserver.exe (assuming this file in C: / down), and the server contains two objects foo and bar. The registration information is roughly like this:
Client If you want to create foo, you only need to pass foo's CLSID. COM complete the scanning registry, locate and activate the work of Fooserver. Client can also be called with a friendly name. Server Objects' friendly names are as follows:
In order to enable the client to create objects through Progids, Progids is also registered. Their registration information is roughly like this:
Location Transparency is a term used to represent the characteristics of COM processing.
Object creation
After activating Server, the thing to do next is to enter the server and request objects. COM once again defines a protocol that makes the server to the client to the client. This agreement is simple, and its working principle is roughly like this:
The customer requests an object, COM finds the registry, positions and activates Server, as described above. Once the Server starts, COM requires Server to provide an "object creator). Object creators are objects used to create other objects. In particular, the object creator directly creates a true object required by the client. The object founder exposes a basic interface. This interface contains a method CREATEINSTANCE. Used to create a real Server object. The COM (or Client) then calls this CreateInstance method to create a Server object and get a pointer to an interface. Then pass this interface pointer back to the client.
Figure: Basic Server Object Creative Protocol
Factory factory
The "object founder" mentioned earlier is called "Class Factory" in COM (many people think it is called "object factory", because the object is created, not class). The class factory exposes a basic interface called iClassFactory, which contains the CreateInstance method, and some other methods.
IClassFactory = interface procedure createinstance; ... End;
This type of factory agreement is COM forced, which means that all Server must: implement a class factory function correctly. The objects in each Server require a type of work factory. This will create him to create him when the Client requires a object. Implement a class plant like achieving other ordinary Server objects. Or, since the class is exported to the IclassFactory interface, it is a Bonafide COM object. This means that the class factory must specify and support vTable binding.
In order to let us know more about this process, let's take a look at what happened when Client asked Fooserver to create a foo object:
Client Request COM "Create a A Fooserver.foo object" CoM to the registry to find "fooserver.foo" this progid, translate him into foo's CLSID. CoM activation Fooserver.exe COM enters Fooserver.exe, Request "Give me a class factory for this object" and passed into the foo's CLSID so that Fooserver can know which type of factory gave him. Remember, each of the objects in Fooserver has a corresponding class. For example, there is a Foo class factory and a class factory of Bar. Through Foo CLSID, Fooserver look up the corresponding class factory, if you find it, pass the iClassFactory pointer to this class factory to COM. COM call iClassFactory.createInstance to create an instance of the Foo object. The call returns an IFOO pointer. CoM put this ifoo pointer back and passed it to the client.
Figure: Server Object Creation Using The Class Factory
Taking the way, Co also provides a mechanism. Let Client directly request the object of the object of the object. In this case, COM will perform the same step to step 5. Step 5, COM returns to the Client IclassFactory pointer. The Client is then manually calling the iClassFactory.createInstance method to create an instance of the Server object.
Creating a factory is very boring. Fortunately, the current development environment hides more than half of the details involved in the creation of a factory. For example, VB completely hides the class factory creation protocol, so that most of the VB programmers don't know the concept of a class factory.
Where are we?
We have just seen the basics of Server, Server activation, and how objects are created. These concepts are very important to make you a milestone for a great COM developer.
Further reading:
Understanding ActiveX and Ole by David Chappell Inside COM by Dale Rogerson Essential CoM by Don Box
