Preface:
Distribution calculations play an increasingly important role in today's continuous networking world. This brings gram into the interior of the distribution of computing systems, excavating the substantive principle of distribution calculation, and tries to analyze the core architecture of the mainstream distribution computing system. I believe that the distribution computing system can greatly understand the problems encountered by actual development. This article briefly introduces the most primitive RPC (Remote Procedure Call) system, because other distribution computing systems can be said to be developed. Then, a mature object-oriented RPC system-DCOM system is introduced, and the mechanism of the various components of the DCOM system is clearly concise, and the Mechanism of each component of the DCOM system is clearly clear, and the complex execution process of the DCOM system hidden behind the surface. Web-oriented service is a trend of distribution calculation development. The last part of this article briefly introduces the Web Services system and Microsoft .NET Framework.
Process standards for information exchange mechanisms and application processes to resource access transparency is an extremely important factor in building distribution computing systems, Birrell and Nelson have introduced a different previous communication mechanism in 1984 - RPC, that is, remote process calls, This method allows the process on a machine to call the process on the remote machine and implement transparency in the call (ie, the user process does not need to know which machine is located on the remote). With object-oriented development ROI (Remote Object Invocation) system, the mainstream of the distribution computing system, such as Microsoft's DCOM, OMG Corba, and Java's RMI (Remote Method Invocation), and these can also be said to be from tradition RPC has been developed. These systems do much different on the surface, but when they explore their internal principles, they will find that these systems are similar. I believe that one of them can not only help understand the principles of distribution calculation, but also help to master this standard for distributed application systems, but also help more easily understand and master other systems. Because Microsoft's DCOM is based on the relatively basic object-oriented RPC system, while other two improvements have relatively many mechanisms, this article mainly explains the DCOM system. And everyone has seen the previous section, then this article is finally introduced to Web Service and .NET Framework, I believe it will be more easily grasped the spirit of Web Service and .NET Framework.
I have reviewed considerable English materials and have tried to try to make simple and accurately eliminate the core architecture of these systems and their internal mechanisms, but believe that it is still not exact The place. At the same time, I hope that those who do distribute computing system research and development can find some answers they have encountered in this article, and hope that this article will wish to distribute the principles of the distribution calculation, and the learners of the subject, As well as developers of distributed application systems will have a certain reference value.
1.RPC system Description:
Since the RPC mechanism, it has been widely adopted as the basic part of the middleware and distributed system, and there are many mature RPC models, which is very representative of the DCE (Distributed Computing Environment) RPC, which is by THE Open Group organization (predecessor OSF (Open Software Foundation), the RPC system used by Microsoft's distribution calculation object DCOM is based on DCE RPC. The Spectality of the DCE RPC has a total of more than 700 pages, and the contents of the entire RPC system are detailed, and the details are implemented. Because this paper mainly involves the core principle of RPC, many parts (not important) temporarily eliminate. Let's briefly introduce the DCE RPC.
1.1 DCE RPC core model:
Chart 1
First introduce the various parts of the above figure:
(1) Uuidgen is a program, its function is to generate an IDL prototype file containing a monogram (to be edited by user), this marker is a 128-bit binary number, used to indicate this IDL file, and Guarantees the global uniqueness of its entire domain. (2) Interface Definition file is an interface file that should be built by the user using the IDL prototype file generated by the UUIDgen using the IDL (Interface Definition Language) language. IDL is a language for explaining the operation (process or function), the operational parameters, and the data type, which inherits in the C language, but there are many different forms and C language. Of course, there are some suitable features. Special syntax for distribution calculations. Specifically, see the IDL Language Specification section in DCE RPC Specification.
(3) The functionality of the IDL Compiler is to compile the edited IDL file, and generate the following three files after compiling:
1.Header is a header file that contains global unique marking, data type definitions, relevant constant definitions, and function prototypes in this Idl file. It should be included in the customer code and server code (such as in the C language in the C language).
2. Client Stub is a client's Stub program.
3. Server Stub is the server-side STUB program.
First introduce STUB: RPC an important thinking to make remote calls look like local calls, that is, if the calling process does not need to know which machine is specifically in which the process is specifically executed. STUB is a very important part of this feature. Specifically, for example, in the client, a process is called to a function fn () during the execution process, and the specific implementation of this function is on a remote machine, then this process is actually called on the local machine. Another version of FN () () () () () () () () This c_fn () is a Stub of the client. Corresponding, when the client's message is sent to the server side, the server side is not directly handed over. Really Fn (), but also gives a different version of Fn () () () S_FN ()), which is a STUB of the server side.
The main function of STUB is MARSHAL (understandable) to be sent to the parameters to be transmitted and the associated parameters (or return value) are unmarshal (unpack). Marshal operations make data to be sent into a standard format (in the DCE RPC system, this format is called the NetWork Data Reperesentation (NDR) format), and UNMARSHAL reads the required data from the NDR format packet. In fact, the mechanisms involved in the actual system are quite complex. Take Marshal operation, the parameter type to be transmitted may be multiple, such as pilot value, passing the pointer to an array, pointing to the pointer to the structure, and the structure may contain a mandatory (Arbitrary) pointer, including cycling (CYCLIC) pointer or the like. For specific operations of these complex situations, this is no longer introduced, you can see DCE RPC Specification.
Let's take a look at what the client and the server's Stub are specifically do:
Client Stub's function: Responsible for collecting the parameters required to call the remote function, and send these parameters Marshal into a message, and then call the runtime system to send this message to the server side. It is also responsible for returning the result message back, returning the results to the application process after the server side returns the result message. Server Stub's function: Responsible for the parameter message sent to it unmarshal collecting parameters, and then calls the process that needs to be called on the real customer application process located on this unit. It is also responsible for the result of the result of this process Marshal into a message, then call the server-side runtime system to send the result message to the client.
(4) Client Code and Server Code are customer code and server code written by the application developer. The customer code may call to a variety of processes, the server code is the truly implementation of these processes. The figure is for C language written code, so the compiler used is a C compiler. Customer code and customer STUB code are compiled and generated by respectively generate respective target files. These target files have generated the entire client executable file with the runtime library connection. The server is also homing.
1.2 RPC execution process:
The following is a brief introduction to the execution of the RPC system according to Figure 2:
First, the customer process calls a remote procedure Add (i, j), actually calling local corresponding stub functions, and the Stub function will match the two parameters and function names into a message (as shown), then by the underlying The operating system sent the message to the server side. The server-side operating system handles the message to the server-side STUB function. This function uses these parameters to use these parameters to use these parameters after the parameter information, and the real implementation code of the ADD is executed. the result of. Similarly the return process of the result of the results.
The above can be said to be a simplest RPC execution process, and in the actual RPC system, the system must have general platformability (to be able to block the application developer shielded platform, can handle the calls in various situations) ), To handle an exception that occurs in remote calls, as well as issues such as cross-domain calls, which have caused real systems that are very complicated. Here, only the simplest description of the traditional RPC system is done in the next object-oriented system (DCOM).
