2. Object-oriented RPC system:
Object-oriented technology has been widely used in various aspects of computer technology, and of course, distribution calculations. Distribution objects are calculated in today's computing world being increasingly important, and it is also more extensive. Object-oriented technology and traditional RPC systems have produced a variety of object-oriented RPC systems, which analyzes a mature Object-Oriented RPC system - Microsoft's DCOM system.
2.1 Distribution Object:
Since it is object-oriented technology, it is very important to understand the concept of objects. An object has some packaged data called its status (state), there are some ways to operate these data, which can only operate the object through the interface (interface). An object can implement multiple interfaces, which give an interface definition, or multiple objects can be implemented.
The concept of distribution objects is to separate the interface of the object and objects, and the object can be placed on a machine, and the interface of the object is placed on another machine. The client application only needs to see these interfaces, and there is no need to pay specific implementations of these interfaces, and it is not necessary to know that the object it wants to access is specifically on the network and which type of operating system runs. Distribution objects can also have dynamic, which can be moved on the network.
Distribution objects and objects in the traditional sense have some difference. Traditional object-oriented technology emphasizes two features: packaged and inheritance. The distribution object is often referred to as an assembly, which can be a simple object, or a combination of related objects, can jointly provide some service (note the concept of the service here). The distribution object technology mainly uses object-oriented technology-oriented packaging, which is mainly concerned about the interface (interface) of the component, as for how to implement inside, without considering. In addition, the distributed object computing system does not support distribution inheritance (inherits of different machines), that is, if two objects are on different machines, then one of the objects cannot inherit the data and code of another object (implementation) This complexity and cost of this inheritance is generally not implemented.
2.2 DCOM system:
Since the popularity of object-oriented technology, the DCE RPC system has also used modifications to object-oriented methods, but here is a more mature and more popular model - Microsoft's DCOM system. In general, DCOM is built on the DCE RPC system and is a perfect combination of object-oriented technology and traditional RPC. DCOM is using an ORPC (Object RPC) system, which explains the architecture of DCOM.
2.2.1 Concept of DCOM:
Before introducing the core architecture of DCOM, it is necessary to explain some important concepts in DCOM.
(1) Interface related:
Each interface of the IID-object represents a different view of this object. The interface is labeled by a 128-bit global unique indicator that is called Interface ID (IID).
The interface used in the DCOM is similar to the RPC system, and a set of abstract operations (methods), represents a certain function. The interface here is also a file edited by the Interface Description Language (IDL). In the DCOM system, the interface STUB code for the client and the server is generated in the DCOM system (the STUB of the RPC system is used to execute. Marshaling and unmarshaling), but in the DCOM system, the client's Stub is called Interface Proxy. The server is called Interface Stub. The interface stub and interface proxy generated by MIDL are also stored as class libraries in the client and server, when needed Export and generate the corresponding COM object from the COM library. Each Interface To register (using its IID) in the system registry, the corresponding stub and proxy are also registered, for example:
[Hkey_classes_root / interfaces / {
@ = {
[HKEY_CLASS_ROOT / CLSID / {
@ = "c: /proxy-stub.dll"
The concept of CLSID used here will be set forth below.
(2) Objects and classes:
Object Class (Class) - is a specific implementation of one or several interface.
Object Instance (Object) - Objects generated after class instantiation.
CLSID-Class ID The marker of each class.
Each class also registers in the system registry, for example:
[Hkey_classes_root / clsid / {
There is also the proxystub class registered in the upper part.
Class Factory-Class Factory is a very important concept in the DCOM system. In the C syntax, you can use the New operator to generate the desired object, but this is limited to generating the desired object in the same process space. In the DCOM system, you can allow for different processes, or even different machines to generate the desired objects, such as the required generated objects will be on a remote machine, then use the general sense on the local machine. NEW operations have not much sense. In order to provide the application process to the location transparency generated by the object, that is, the application process does not need to know which machine required for the desired creation and use, the DCOM system introduces the concept of the class factory.
In the DCOM system system, most implementations are used with one and itself associated with class mill classes, such platforms implemented the IclassFactory interface, where the iClassFactory :: CreateInstance method is used to generate the desired object (of course, the object may be The same process space, it is also possible on the remote machine, IclassFactory :: CreateInstance will perform different processes according to different situations). For the client application, it simply calls the CoCreateInstance function (this function will call the corresponding IclassFactory :: CREATEINSTANCE, without paying specific locations of the object to be created.
(3) Object Exporter: If a service implements one or several objects, these objects can be accessed by remote clients, then this service can be called an object outputer. Object Exporter. Each Object Exporter is labeled by an 8-byte indicator that is called an Object Exporter Identifier, ie OxID.
(4) Binding Information:
A process wants to trigger a remote object, it needs to know some information about the remote object, including the network address of the remote host where the object is located, the protocol used, the port used for the object. This information is binding information, here is all of the above information, also known as string bindings.
(5) Oxid Resolver:
Each host has an OXID resolver, each Oxid Resolver is maintained (cache) a table, each of which records an OXID and its implementation of objects information. As shown below:
When the server is launched, the OXID and the corresponding binding information are stored in the local OXID Resolver to pass the binding information to the client when needed.
When a process of a client requires a binding information of a remote object A, it first looks for a table in the local Oxid Resolver. If not, local Oxid Resolver calls the IoxidResolver :: ResolveOxid method to the server A The Oxid Resolver inquiry (Because the binding information on the server is transmitted to the client when the interface pointer is sent to the client, this will also be introduced when introducing the interface pointer), and then the server Oxid Resolver then sends the required object binding information to the client's Oxid Resolver.
One of the problems here is: Why do the server transfer the binding information of the objects required to the client when the interface pointer is transmitted to the client, but first to transfer its OXID Resolver binding information to the client? This is because the DCOM system supports different protocols, such as TCP / IP, UDP / IP, IPX / SPX. The same service needs to support different protocols, need to register all protocol information when initialized, and load support The code of the protocol, this will have a lot of resources waste. Optimization is that the corresponding service object is subjected to the required protocol registration and the required protocol code to load according to the specific situation when the client calls IoxidResolver :: ResolveOxID sends a request. In this way, the same service can also transfer the binding information of the objects they need according to the specific client to the client (possibly the same object to different versions of different versions of different clients).
(6) Service Control Manager (SCM):
SCM is an important part of the DCOM system, which has two main functions: Locate Implementation and Activate Implement. It can be a brief description of its functions as follows:
The client's SCM also maintains a table, caching the cacity information that may be used, when the user process calls to a class, first check the internal table to find the required CLSID information, if not, it accesses the registry Find the corresponding information. If found, it starts a remote service (requesting request to the SCM on the remote host). The server's SCM first loads the Class Factory to load into the internal maintained table (if you already exist, you don't need this), then find the required class factory information in the internal table, and get this The pointer of the class instance, then stimulates the CREATEINSTANCE () method in the class, generating the required objects and interfaces. (7) Marshaled Interface Pointer:
In the previous conventional RPC system, it is mentioned that the desired remote call is required, which is to be a standard format (in the DCE RPC system, this format is called the network data representation (NDR) format) and then passed to the remote host after the DCE RPC system. . In the ORPC system in the DCOM, this format is extended, and the NDR format made in the interface pointer Marshal is added, which is also supported by the Marshal interface pointer.
One refers to the interface pointer, maybe someone will immediately think of a pointer to a structure, which contains a pointer to each function of the object corresponding to this interface. But to make this interface pointer Marshal into a packet and transmit it to the customer process, so that the customer process is convenient to call the remote object, this understanding does not make much sense (the client process and service object process are located on different machines, It is not at the same running space at all. So, what is the interface pointer to the client after this Marshal?
In fact, it represents an object reference (AN Object Reference), the specific main content is an Objref structure (the Objref structure has three forms of Standard, Handler, and Custom, only introduces the Standard form):
Typedef struct tagobjref
{
Unsigned long signature; // must be objref_signature
Unsigned long flags; // Objref Flags
GUID IID; // IID
StDobjref std; // standard objref
DualstringArray SareSaddr; // Resolver Address
}
Among them, the IID is this interface ID (previously introduced), SareSaddr is the binding information of the server Oxid Resolver (earlier), STD is the following structure:
Typedef struct tagstdobjref
{
Unsigned long flags; // sorf_ flags
Unsigned long cpublicrefs; // count of reviews passed
Oxid oxid; // Oxid of Server with this OID
Oid Oid; // Oid of Object with this iPID
IPID IPID; // ipid of interface} stdobjref;
Its main information is the OXID (OXID) of this service. The ID (OID) of this object, and the ID (IPID) of this interface pointer.
By analyzing the two structures, the primary content of the interface pointer required to be remotely transmitted is clearly clear, and the specific use of it will be explained in the explanation of the DCOM system architecture.
(8) Proxy Manager and STUB Manager:
In the DCOM system, the customer process is to deal with a proxy object. This proxy object is called Proxy Manager. There is a Stub Object corresponding to the server, called Stub Manager. Proxy Manager By calling some methods to generate the Interface Proxy object required for the customer process. (Returns the Interface Proxy object pointer to the customer process). A class can implement multiple interfaces, each Proxy Manager can also generate multiple different interface proxy objects, these generated interface proxy objects and proxy manager aggregate (also seeing the interface proxy object is Proxy Manager) Some), enabling the client application process to expose all the interfaces to it through an object, and only the customer process should only be deald by the same object, making it easier to get the customer process to get the desired interface pointer. . The server STUB Manager can generate interface stub, but it does not aggregate these interface stubs, so the server's Stub Manager is relatively simple.
The above simply introduces some important concepts in the DCOM system, and then explain some of the other concepts in the DCOM system architecture.
