DCOM implementation distributed application
DCOM overview
Microsoft's Distributed COM (DCOM) extends the component object model technology (COM) that allows it to support communication between the LAN, WAN, and even the objects of different computers on the Internet. With DCOM, your application can achieve distribution at the location to meet your customers and applications. Because DCOM is a seamless expansion of the world's leading component technology COM, you can transfer you now to COM-based applications, components, tools, and knowledge to standardized distributed computing areas. When you are doing distributed calculations, the DCOM handles the low-level details of the network protocol, allowing you to concentrate on solving the problems required by the user.
Why do you want distributed applications?
Distribute application is not the end of the problem. Distributed applications introduced a new design and extension concept, which increases the complexity of software products, but brings considerable rewards. Some applications themselves have distributed, such as multi-person fighting games, chat procedures, and remote conferencing systems. Therefore, the benefits of a robust distributed computing framework are not self-motivated. Many other applications are also distributed, that is, it has at least two components on different computers, but because it is not designed for distributed applications, their scale and scalability have great limitations. . Any workflow or group application, most client / server applications Some desktop office systems are essentially controlled their users' communications and collaboration. These systems can be used as a distributed system and can operate the correct components in the correct place will benefit the user, and people will make people more confidence in the use of networks and computer resources. The distribution is designed to consider distribution, which can make the app to apply different customers with different performance through the client running components. Distribution is designed to consider distribution to make the system high flexibility. Distributed applications have greater scalability than their non-distributed versions. If the logical structure of the entire complex application can be represented by a simple model, only one way to increase the product's work efficiency: the faster machine, without the need to adjust itself. Although the current server and operating system are upgraded soon, buying a same performance machine is still less than twice the speed of the server. With a proper distributed application, a server that is not a powerful server can run all components. When the load increases, some components can be extended to an attached machine.
DCOM structure
DCOM is a further extension of the component object model (COM). COM defines how many ways between components and their customers. It allows components and clients to connect without any intermediary components. The client process directly calls the method in the component. Figure 1 illustrates the representation of the component object model:
Figure 1 COM components in the same process
In the current operating system, each process is shielded between each process. When a customer process needs to communicate with the component in another process, it cannot call the process directly, and the regulations that need to follow the operating system to process inter-process communication. COM enables this communication to perform in a fully transparent manner: it intercepts the call from the customer process and transmits it to another process. Figure 2 shows how the COM / DCOM runtime provides contact between client processes and components.
Figure 2 COM components in different processes
When a customer process and component are in different machines, DCOM is just a communication between the local process only by the network protocol. Whether customers or components do not know that they have a lot of lines longer than before.
Figure 3 shows the overall structure of DCOM: The COM Runter provides object-oriented services to customers and components, and uses RPC and security mechanisms to generate standard network packages that meet DCOM line protocol standards.
Figure 3 DCOM: COM components on different machines
Components and multiplexing
Most distributed applications are not produced in air. Existing hardware structures, software, components, and tools need to be integrated to reduce development and expansion time and fees. DCOM can directly improve existing investments in COM components and tools. The huge market for a wide variety of components makes it possible to integrate standardized solutions into an ordinary application system. Many developers familiar with COM can easily use their experience in COM to use DCOM-based distributed applications. Any components developed for distributed applications may be reused in the future. To organize the development process around the component mode, you can constantly improve the functionality of the new system on the basis of the original work and reduce development time. Design of COM and DCOM enables your components in the present and future.
Position independence
When you start designing a distributed app on a true network, the following mutual conflict design issues will be clearly reflected:
Frequent components with frequent interactions should be more close to each other. Some components can only run in a specific machine or location. The widget adds the flexibility of the configuration, but it also adds the network's congestion. The large component reduces the congestion of the network, but it also reduces the flexibility of the configuration.
When you use DCOM, the restrictions on these design will be easily resolved because the details of the configuration are not illustrated in the source code. DCOM is completely transparent to you, whether it is in the same process of the customer or on the other end of the earth. In any case, the way the client connection component and the method of calling the components are the same. DCOM does not need to change the source code, but no need to recompile the program. A simple reconfiguration action changes the way the component components are connected to each other.
The location independence of the DCOM greatly simplifies the task of distributing the components to enable it to achieve the most suitable execution. For example, an idea is required to be on a specific machine or a particular location, and this app has many widgets, you can configure these components on the same LAN, or on the same machine, even A process to reduce the load of the network. When the application is composed of a few large components, the network load is not a problem. At this point you can put the components on a fast machine, and don't take the machine where these machines are.
Figure 4 shows how the same "effectiveness check components" are configured separately in two different situations. One situation is when the bandwidth between the "Customer" machine and the "Intermediate layer" machine is large enough, it is configured on the client; the other is when the customer process accesses the component through a relatively slow network connection. How is it configured on the server.
Figure 4 Independence
With the location independence of the DCOM, the application can put the inter-associated components on the machine, and can even put them in the same machine or in the same process. Even with a large number of small components to complete a function of complex logical structures, they can still be effective to interactions. When the component is running on the client, check the user interface and validity checks on the client or close to the client. The centralized database transaction should close the server near the database.
Language irrelevant
When designing and implementing a distributed application system, a common problem is to develop a specific language and a problem with the tool. Language selection is a typical compromise between development costs, available technical support and execution performance. As the expansion of COM, DCOM has language independence. Any language can be used to create COM components, and these components can use more languages and tools. Java, Microsoft Visual C , Microsoft Visual Basic, Delphi, Powerbuilder, and Micro Focus Cobol can be well interacting with DCOM.
Because DCOM has language independence, application system developers can choose their most familiar language and tools to develop. Language independence also enables some prototype components to develop advanced languages such as Visual Basic, while in the future, in a different language, such as Visual C and Java, and this language can better support These advanced features such as the free thread / multi-threads, such as DCOM are shared. Connection management
The network connection itself is more fragile than the connection in the same machine. When a customer is no longer valid, especially when a network or hardware error occurs, the components in distributed applications need to be noted.
DCOM manages a connection problem for components by holding each component, which may be just just to a customer, or may be shared by multiple customers. When a client is connected to a component, DCOM adds an index count for this component. Similarly, when the customer releases the connection, DCOM reduces the index count of this component. If the index count is zero, the component can be released.
DCOM uses a valid address legitimate check (PINGING) protocol to check if the customer process is still active. The client periodically sends a message. When the components are not received by the PING cycle, the components do not receive the ping message, the DCOM thinks this connection is interrupted. Once the connection is interrupted, the DCOM reduces the index count, and the component is released when the index count is zero. From this point of view, whether it is a customer's process you interrupt this benign situation or a network or client crash, it has been processed by the same index count.
In many cases, the information flow between the components and its client processes is no direction: the component needs to perform some initialization operations on the client, such as the end of a long process, the user's update, or such as TV and multi-user games in these collaborative environments, etc. Many agreements make it very difficult to complete this symmetry. Using DCOM, any component can make the functional provider, can be a user. The two directions of Tongxun use the same mechanism to manage the interaction between the end and the interaction between the client / server.
DCOM provides a distributed garbage collection mechanism for applying a fully transparent application. DCOM is a natural symmetrical network protocol and programming model. It not only provides the interaction between the traditional one-way client-server, but also provides a rich conversation between clients and servers and peer-to-peer processes.
Scalability
An important factor in distributed applications is that its processing power can increase as the user's number of data is increased. When the demand is relatively small, the application system is relatively small and fast, and it is able to process additional requirements without sacrificing performance and reliability. DCOM provides many features to enhance your application's scalability.
Symmetrical multi-process processing (SMP)
DCOM enhances the support of Windows NT for multi-process processing. For applications using free thread mode, DCOM uses a thread queue to process new requests. On multiprocessors, the thread queue is determined by the number of processors available: too many threads cause regular context to switch, and too little thread will cause the processor to be idle. DCOM only provides a manually encoded thread manager that enables developers from the thread detail to get the best performance. DCOM can easily apply applications from a single processor to a huge multiprocessor system by using Windows NT for advanced support features for symmetry multi-process processes.
Flexible configuration
When the load increases, even your budget supports you buy a fastest multi-process machine, it may not adapt to the needs. The location independence of DCO provides a simple and inexpensive way to improve the scalability, which is to put distributed components on other machines.
For components that are not status or unnecessary sharing status, the reconfiguration is even more prone to. For such components, multiple copy of them can be run on different machines. The user load can be assigned to each machine equally, even considering the processing capability of the machine and the load on these factors. With DCOM, you can easily change the connection method between the customer process and the components and components. The same component can be dynamically reconfigured even if the same component does not need to be recompiled. All must do just the update registration, file system, and the database where the components involved are. Example: An organization has a workshop in multiple places, such as New York, London, San Francisco, and Washington, etc., which can be installed on the server. Two hundred users have access to fifty components at the same time that can achieve the expected performance. When a new transaction application is sent to the user, the application in the application is simultaneously using some existing and new components, the server's load increases to 60 users, and the number of transaction components is increased to seventy. With these additional users and components, the response time of peak time becomes unacceptable. The administrator will be configured separately on another server, and put twentie components on the original server, while the remaining twenty components are running on both servers at the same time.
Figure 5 Parallel configuration
Most actual application systems include one or more key components involved in most operations. Such components have database components or transaction rules components, which must be executed serially to ensure "first serial service" strategy is executed. These components cannot be reused because their unique tasks are to provide a single time synchronization point for all users of the application system. In order to enhance the overall function of step-by-step applications, these bottleneck components must be placed on a dedicated, powerful server. DCOM allows you to separate these key components as early as the design phase, initially placing multiple components on a simple machine, and then put key components on a dedicated machine. This process does not need to be re-designed for components, and even do not need to recompile.
Figure 6 Separation of key components
The processing of DCOM for these decisive bottleneck components allows the entire task to perform quickly. These bottleneck components are often part of the process executing sequence, such as the trading command in the electronic trading system, which must be performed in the order of reception (first serve first). One solution for this issue is to divide the task into many small components and configure these components on different machines. This effect is similar to the pipeline Pipelining technology in today's microprocessor: the first request, the first component executes (eg, a consistency check), then passed the request to the next component (for example, it may be an update database) . Once the first component passes a request to the next component, it is ready to perform the next request. In fact, there are two machines to perform multiple requests in parallel, and can be performed in order to request. You can also use DCOM on the same machine to achieve the same effect: multiple components are executed in different threads or different processes. This method can simplify the extension in the future, we can distribute the thread to a machine with a plurality of processors, or can configure the process to different machines.
Figure 7 Pipelining
The location independent programming model of DCOM makes it easy to change the configuration design as the application increases. Initially, a functionally simple server can accommodate all components. As demand increases, other machines are added, and the components can be stepped into these machines without making any changes on any code.
(Next)
