2.2.2 DCOM System Core Architecture:
The above figure is the DCOM system architecture diagram, some of the concepts involved in the figure have been introduced in the previous part. The DCOM system core architecture is clarified by explaining the implementation of the DCOM system behind a specific application routine.
The client application code is as follows:
void main ()
{
Isample * pisample; // Define interface pointer
/ / Define three parameters of Pisample -> Method
Parameter1 Para1;
Parameter2 para2;
Parameter3 para3;
Result resl; // Define result variables
Coinitialize (NULL); // Initialization COM
CoCreateInstance (CLSID_CSAMPLE, NULL, CLSCTX_SERVER,
IID_ID_ID **) & PISAMPLE); / / Generate the desired object and return the interface pointer
Resl = Pisample -> Method (Para1, PARA2, PARA3); // Remote calls using interface pointers
Couninitialize ();
}
The server application code is as follows:
void main ()
{
HEVENT = CREATEEVENT (NULL, FALSE, FALSE, NULL); // The server is multi-thread, so coordinated through HEVENT
HR = CoinitializeEx (null, coinit_multithread);
CCLASSFAACTORY * PCF = New CcLASSFACTORY;
HR = CoregisterClassObject (CLSID_CSAMPLE, PCF,
CLSCTX_SERVER, REGCLS_MULTIPLEUSE, & DWREGISTER; // After the registration function is executed, the main thread switches to the service thread.
WaitForsingleObject (HEVENT, Infinite); // Wait until HEVENT is set by STEVENT (HEVENT) function, this function is called in CSAMPLE's destructor Csample :: ~ csample (). At this point, the server-side service thread switches to the main thread.
CloseHandle (HEVENT);
Couninitialize ();
}
The following is divided into two processes to clarify the complex execution of the DCOM system behind a simple application.
Procedure 1: Object activation process
When the client application process calls the CoCreateInstance () function in the COM library with CLSID_CSAMPLE and IID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID_ID, the COM library delegates the task to the client's SCM. If this SCM consults the local registry, find that the required object should be in another On the machine (server), it sends a request to the server's SCM, and then the server's SCM starts the required service (which can be seen as a component). This start-up service (component) is to associate with an Object Exporter And this Object Exporter is to be given an OXID.
The process of starting the service is the process of generating the required service objects (in general, one service component can have only one object, or multiple objects can have multiple objects, and the generated object needs to pass these objects, which is roughly The server's SCM first finds the information from the desired class, then load the class factory code and generates the object of the class factory, and registers the interface pointer of this object in a class object table (Class Object Table). The registration process corresponds to CoregisterClassObject () in the server application code, but can be seen from the program. After registration, the current process of the server is waiting, and other operations are handed over to other processes, if the class object The table is originally required in the table without the above process, and then the server's SCM should be retrieved from the class object table to the desired type of factory object interface pointer, call its CREATEINSTANCE () method (IclassFactory :: CreateInstance generates the required service object. The binding information of the launched service object and its corresponding OXID are registered in the OXID Resolver of the server. CreateInstance () Generates the desired service object and returns the IID_ID_ISAMPE interface pointer by calling queryinterface (). The server generates a corresponding Object Stub (ie, stub manager) for the newly generated service object. This Object Stub will call ComarshalInterface first. Function The interface pointer IID_ISAMPLE interface pointer Marshal is standard format (the specific content after the interface pointer after Marshal "See the front part), then COMARSHALINTERFACE calls the iMarshal :: getUnmarshalclass method to get a CLSID, this CLSID will determine how to the client A Proxy class is loaded into the customer's process space and generates the corresponding proxy manager. This CLSID will return to the client with the IID_ISAMPE interface pointer after Marshal. Object Stub also enters the IID_ID_ID and service objects by consulting the registry for IID_ISAMPLE to generate the corresponding interface stub, and associate this interface stub and the actual IID_ISAMPLE interface.
Then the server's SCM returns the IID_ID_ID_ID_ID_ID_ID_ID_ID_ISAMPE interface pointer after Marshal to the client. On the client, IClassFactory :: CreateInstance (internally called inside client code) actually calls a CounmarshalInterface function, this function reads the CLSID from the returned message package and generates an Object Proxy by calling CocreateInstance ( That is, Proxy Manager. This Object Proxy then the IID_ID_ID_ID_ID_ID_IXY, which generates its client's Interface Proxy. And Object Proxy gets the desired OXID from UNMARSHAL IID_ISAMPLE interface pointer. Oxid Resolver's binding information, then calls the ioxidResolver: ResolveOxid method for local Oxid Resolver: ResolveOxid.
The client's Oxid Resolver first checks if it caches the desired OXID and the binding information of the service object corresponding to this OXID. The binding information of the service object. Client Oxid Resolver first caches this information, then return it to Object Proxy. Now, the client has generated IID_ISAMPLE corresponding to Interface Proxy, and Object Proxy has also obtained the binding information of the service object required. Next, Object Proxy will link this Interface Proxy and an RPC Channel object. From then on, the client's interface proxy can use the binding information of the remote service object and through this RPC Channel object directly and the remote server corresponding to Interface. STUB interaction.
Finally, at the client, the interface pointer of this Interface Proxy object will return to the client application process, which to assign the Pisample of the sample program. Since then, the client application process can use Pisample to easily call the remote approach.
Procedure 2: Remote method calling process
Pisample -> Method (Para1, Para2, Para3) in the client application is actually triggered, and Interface Proxy has made three parameters Marshal into standard format (NDR format) and other information together. A RPC message package, then call the SendRecEceptive () method of the RPC Channel object to transfer the RPC message package to the server-side RPC Channel object.
The server-side RPC Channel object finds the target Object Exporter through the resolution of the OXID Resolver of the server, and sends a request to the target Object Exporter. In addition, the RPC message package contains an interface pointer marker (ie, IPID, which is included in the interface pointer to the client), and the RPC Channel object uses this IPID to find the target Interface Stub, and triggered the Interface Stub object. .
The interface stub then the unmarshal parameter and uses the method sequence number included in the RPC message package to call the actual service object corresponding to the actual service object, and the result obtained after the execution is returned to Interface Stub, Interface Stub will return this again. Marshal The NDR format is sent to the client through the RPC Channel object. The client returns the results to the application process again after similar processes.
The above is the main process of the DCOM system in the example, which also clarifies the DCOM system core architecture and its operation. There is no doubt that there are many complex mechanisms in the real mature DCOM system (such as security, fault-tolerant-related) not involved in this article, but if there is a core architecture of the DCOM system, learning and researching other related mechanisms It is more simple.
3.Web Services:
3.1 Description of Web Services:
With the further development of distribution calculations, the distribution calculation system for web, open, suitable for the entire Internet, which is the web service. Traditional distributed component technology has several disadvantages when building a service system to the web:
1. Interoperate difference: Several standards (DCOM, CORBA, RMI) often cannot be consistent, such as life cycle management, whether constructor is supported, and the degree of implementation of inheritance. 2. They require service clients to be closely coupled between the services provided by the system itself, that is, a similar basic structure. Such systems are often very fragile: if the execution mechanism of one end changes, the other end will crash. In contrast, web services are loosely coupled to each other. Any party in the connection can change the execution mechanism, but does not affect the normal operation of the application.
3. For DCOM and CORBA / IIOP, if the firewall or proxy server separates the machine and server machine, any IIOP or DCOM package has passed by the possibility of passing, mainly because most Internet connection technology is HTTP protocol The preference is caused.
Therefore, although it is very suitable for building a service system in an intranet environment using traditional distributed components techniques, it is difficult to build web services. The Web Service system came into being.
What is web service? A comparative general acceptance is: a web service is an application or component that is labeled by a URI (Uniform Resource Mark), which can be described in a standard form, and it You can interact directly with other applications or components via standard Internet protocols. The emergence of Web Service has led to a new concept - SOA (Service-Oriented Architecture), a service-oriented architecture, and actually, the previous distribution component system (DCOM, CORBA, RMI) is SOA. Although Web Service is a very big innovation in many ways, there is no doubt that we can easily find the shadow of many traditional distribution calculations from its principles. Let's take a brief introduction to the main principle of Web Services.
Some people call Web Services as an Internet middleware, but this new type of middleware does not require a full new protocol (this different from the previous middleware system), the following will be described as the core of Web Services as the core:
(1) Data format: Web services uses XML (Extensible Markup Language as a data format protocol, not only providing a unified data format for web services, which greatly facilitates cross-platform interoperability, and this agreement is also Web Services Other The foundation of the agreement.
(2) Data Transmission: Web Services mainly uses SOAP (Simple Object Access Protocol, an XML extended protocol) to define the transfer and message format of the Web Services system.
The message format of SOAP is XML, which can be represented as an RPC trigger message (including an RPC parameter in the format of XML and the structure of the return value), or an XML text.
The binding information defined by SOAP can make messages above different protocols, but there is no doubt that HTTP protocols are primarily and is the most widely used protocol, which is also an important factor in Web Services. one.
Other parts of SOAP also how to represent program data as XML, and how to use SOAP to remotely call (RPC). These optional specifications are used to implement an application in the RPC form.
(3) Service Description: Web Services describes the service with WSDL (Web Services Description Language), in fact, WSDL is very like IDL in the DCOM, a WSDL document describes the abstract interface of the web service, specific binding information, etc., and can be compiled Generate a client agent, this agent can call Web services through SOAP. (4) Discovery mechanism: Web Services is implemented through UDDI (Universal Description, Discovery and Integration) services to implement service registration and service discovery mechanisms. This service is similar to the name service in DCOM, and the specific mechanism is not described herein.
From the above point, it can be seen that many mechanisms of Web Services have many similar points in principle, but the Web Services is widely used in the unified data format (XML) of the entire Internet, and the Internet it is widely used. The HTTP Transfer Agreement guarantees that it is truly open, WEB-oriented service system, which is the previous system that cannot match. In fact, Web Services This Internet Middleware should also have a trigger mechanism (how do applications interact with SOAP and WSDL, how to call remote services, etc.), which will be embodied in different development environments. Here is a specific environmental Microsoft .NET Framework.
3.2 .NET Framework Introduction:
Microsoft's .NET Framework offers two different distributions to become models: distribution objects and web services, which correspond to .NET Remoting and ASP.NET Web Services. Where .NET Remoting has a lot of similar points, such as its remote object, object activation, proxy objects, or even channel (RPC Channel compared to COM system), Of course, these aspects will have a lot of differences in detail. In general, .NET Remoting and COM maximum (substantive) are still in .NET Remoting is a system that is capable of building open, internet (although it is worse than Web Services), use XML, HTTP and SOAP, of course it The RPC mode is still available and provides tools to compatibility with COM systems (such as using SOAP Toolkit to package COM components to make COM services to Web). In fact, using .NET Remoting to build web services is not suitable (objectively said), and there is controversy.
ASP.NET Web Services provides a loosely coupled architecture that provides a simple API for web services to web services to web services based on image SOAP messaging to method calls, but also because of exchanging SOAP messages to a single method call, Simple programming model. Compared to .NET Remoting, ASP.NET Web Services provides simple messaging mechanisms, while .NET Remoting provides complex multi-function, such as delivery of objects, multi-object trigger, callback, and EVENT mechanism, and .NET Remoting also supports a high efficiency Binary encoding method. However, the loose coupling structure, higher interoperability, and efficient use of WSDL, asp.net web services, and effective use of WSDL make it more suitable for building a heterogeneous environment, while .NET Remoting is suitable Construct the distributed computing system in the group environment. 4. Conclusion:
As the distribution computing system has experienced traditional RPC systems, object-oriented RPC systems, as well as Web Service three generations, the Internet is also increasingly obvious to change our lifestyle. We can say that open, web-oriented distribution computing system is a general trend, but we cannot deny that some previous distribution computing systems have advantages in building a system under the Intranet environment. In addition, the combination of distribution computing and other aspects, such as database, artificial intelligence, etc. also produce the emergence and development of research directions such as distributed databases, intelligent agents. With the new generation of infrastructure-grid computing research and application in international and my country, in full swing, believe in distribution computing technology (Web Service technology, even previous distribution components technology) and grid technology It is a hot spot for research (actually has a research on Web Service and Grid), and distributed computing technology will play a growing role in our future life.
