DCOM Implementation of distributed applications (1)

DCOM Overview

Microsoft's Distributed COM (DCOM) extends the Component Object Model Technology (COM) to support communication between objects on different computers on the LAN, Wan, or even the Internet. With DCOM, your applications can be distributed in a location to meet the needs of your customers and applications. Because DCOM is the seamless extension of the world's leading component technology COM, you can transfer your current COM-based applications, components, tools, and knowledge to the standardized distributed computing field. When you are doing distributed computing, DCOM handles low-level details of network protocols, so that you can focus on solving the problems required by users.

Why distributed applications?

Application distribution is not the end of the problem. Distributed applications introduce a new concept of design and expansion, which increases the complexity of software products, but brings considerable returns. Some applications are distributed, such as multiplayer games, chat programs, and remote conference systems. Therefore, the benefits of a robust distributed computing framework are self-evident. Many other applications are also distributed, that is, they have at least two components running on different computers, but because they are not designed for distributed applications, therefore, their scale and scalability have great limitations. Most client/server applications in any workflow or group application, some desktop office systems control the communication and collaboration of their users in essence. Using these systems as distributed systems and running the right components in the right place will bring benefits to users and give people more confidence in the use of network and computer resources. When designing applications, considering the distribution, applications can be applied to different customers with different performance by running components on the client. When designing applications, considering distribution can make the system highly scalable. Distributed applications are more scalable than their non-distributed versions. If the logic structure of the entire complex application can be represented by a simple model, there is only one way to increase the efficiency of the system: faster machines, the application itself does not need to be adjusted. Although the current servers and operating systems have been upgraded quickly, it costs less to buy a machine with the same performance than to upgrade the server to twice the original speed. With an appropriate distributed application system, a server with less powerful functions can run all the components. When the load increases, you can extend some components to cheaper additional machines.

DCOM Structure

DCOM is a further extension of the Component Object Model (COM. COM defines how components interact with their customers. It allows components and clients to interact with each other without any intermediary components. The customer process directly calls the methods in the component. Figure 1 illustrates the representation of the Component Object Model:

Figure 1 COM component in the same process

In the current operating system, processes are blocked from each other. When a customer process needs to communicate with components in another process, it cannot directly call the process, but must follow the operating system's rules for inter-process communication. Com enables this communication to be fully transparent: it intercepts calls from the customer process and transmits them to components in another process. Figure 2 shows how the COM/DCOM Runtime Library provides connections between customer processes and components.

Figure 2 COM components in different processes

When customer processes and components are on different machines, DCOM only uses network protocols to replace communication between local processes. Neither the customer nor the component knows that the line connecting them is much longer than before.

Figure 3 shows the overall structure of DCOM: the com Runtime Library provides object-oriented services to customers and components, and uses RPC and security mechanisms to generate standard network packages that comply with DCOM line protocol standards.

 

Figure 3 DCOM: COM components on different machines

Component and reuse

Most distributed applications are not created out of thin air. Existing hardware structures, software, components, and tools need to be integrated to reduce development and expansion time and cost. DCOM can directly and transparently improve existing investment in COM components and tools. The huge market demand for various components makes it possible to integrate standardized solutions into a common application system. Many developers familiar with COM can easily apply their com experience to distributed applications based on DCOM.

Any component developed for distributed applications may be reused in the future. The development process is organized around the component mode so that you can continuously improve the functions of the new system and reduce the development time on the basis of the original work. The Design Based on COM and DCOM enables your components to be used well in the present and future.

Location independence

When you start designing a distributed application on a real network, the following conflicting design issues are clearly reflected:

• Components with frequent interactions should be closer to each other.
• Some components can only run on a specific machine or location.
• Small components increase configuration flexibility, but they also increase network congestion.
• Large components reduce network congestion, but they also reduce configuration flexibility.

When you use DCOM, these design restrictions will be easily solved, because the configuration details are not described in the source code. DCOM makes the component location 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 customer connects to the component and calls the component in the same way. DCOM not only does not need to change the source code, but also does not need to re-compile the program. A simple reconfiguration action changes the way component components are connected to each other.

The location independence of DCOM greatly simplifies the task of distributing application components so that they can achieve the most appropriate execution results. For example, imagine that a component must be on a specific machine or a specific location, and the application has many small components. You can configure these components on the same LAN, or reduce the network load on the same machine or even the same process. When an application is composed of a small number of large components, the network load is not a problem. At this time, you can place the components on a fast machine without worrying about where these machines are.

Figure 4 shows how the same validity check component is configured in two different cases. One case is how the bandwidth between the "customer" machine and the "intermediate layer" machine is configured on the client when the bandwidth is large enough; another scenario is how a customer's process is configured on the server when it accesses a component through a slow network connection.

Figure 4 Location independence

With the location independence of DCOM, the application system can place the associated components on machines that are relatively close to the ground, or even put them on the same machine or the same process. Even if a large number of small components are used to complete a function with a complex logical structure, they can still interact effectively. When a component runs on a client, it makes more sense to put the user interface and validity check on the client or a machine that is relatively close to the client. Centralized database transactions should bring the server closer to the database.

Language independence

When designing and implementing a distributed application system, a common problem is the selection of languages and tools for developing a specific component. Language selection is a typical compromise between development costs, available technical support, and execution performance. As an extension 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 interact well with DCOM.

Because DCOM has language independence, application system developers can choose the languages and tools they are most familiar with for development. Language independence also allows some prototype components to be developed in advanced languages such as Visual Basic at the beginning. In the future, a different language will be used, for example, Visual C ++ and Java can be implemented again, and this language can better support such advanced features as free threads/multithreading of DCOM and sharing of threads.

Connection Management

The network connection itself is more vulnerable than the connection on the same machine. When a customer is no longer valid, especially when a network or hardware error occurs, the components in the distributed application need to be noted.

DCOM manages component connection issues by keeping an index count for each component. These components may be only connected to one customer, or shared by multiple customers. When a customer establishes a connection with a component, DCOM increases the index count of the component. Similarly, when a customer releases a connection, DCOM reduces the index count of this component. If the index count is zero, the component can be released.

DCOM uses a valid pinging protocol to check whether the customer process is still active. The client sends messages cyclically. When the ping cycle is greater than or equal to three times and the component does not receive the ping message, DCOM considers the connection to be interrupted. Once the connection is interrupted, DCOM reduces the index count and releases the component when the index count is zero. From this point of view of components, whether the customer process breaks the connection itself, or the network or client crash is fatal, it is processed by the same index counting mechanism.

In many cases, the information flow between a component and its customer process has no direction: the component needs to perform some initialization operations on the client, such as the end of a long process, updates to the data watched by the user, or the next information in a collaborative environment such as TV or multi-user games. Many protocols make it very difficult to achieve this symmetry. With DCOM, any component can provide both functions and can be a function user. Communication is managed using the same mechanism in both directions, making it easier to implement the interaction between communication and Client/Server.

DCOM provides a distributed garbage collection mechanism completely transparent to applications. DCOM is a natural symmetric network protocol and programming model. It not only provides the traditional one-way interaction between client and server, but also provides rich communication methods between client and server and peer processes.

Scalability

An important factor in distributed applications is that their processing capabilities increase with the increase in the number of users and the amount of data required for performance. When the demand is relatively small, the application system is relatively small and fast, and it must be able to handle additional requirements without sacrificing performance and reliability. DCOM provides many features to enhance the scalability of your applications.

Symmetric Multi-process processing (SMP)

DCOM improves the support of Windows NT for multi-process processing. For applications that use the free-threaded mode, DCOM uses a thread queue to process new requests. On a multi-processor machine, thread queues are determined by the number of processors available: too many threads will lead to frequent context switching, too few threads make the processor idle. DCOM only provides one manually-encoded thread manager, which frees developers from the details of the thread and achieves the best performance. DCOM can easily extend applications from a single processor to a large multi-processor system by using Windows NT's Advanced Support for Symmetric Multi-process processing.

Flexible configuration

When the load increases, even if your budget allows you to buy the fastest multi-processor, it may not be able to meet your needs. The location independence of DCOM provides a simple and inexpensive way to improve scalability, that is, to place distributed components on other machines.

Configuration is easier for stateless components that do not need to be shared with other components. For such components, multiple copies can be run on different machines. User loads can be equally distributed to various machines, or even distributed based on the processing capability and current loads. With DCOM, you can easily change the connection mode between the client process and components and between components. The same component can be dynamically reconfigured without any changes or re-compilation. All the work that must be done is to update the registration, file system, and the database where the involved components are located.

Example: An organization has offices in multiple places, such as New York, London, San Francisco, and Washington. It can install components on servers. Two hundred users can access 50 components at the same time to achieve the expected performance. When a new transaction application is sent to the user, some existing and new components are used in the application system, and the server load increases to six hundred users, at the same time, the number of transaction components has increased to 70. With these additional users and components, the response time of the peak time becomes unacceptable. The Administrator separately configures thirty components on the other server, and separately stores the 20 components on the original server, at the same time, the remaining 20 components run on both servers at the same time.

Figure 5 parallel Configuration

Most real application systems have one or more key components that involve most operations. Such components include database components or transaction rule components, which must be executed in serial to ensure that the "first-come first-served" policy is executed. These components cannot be reused because their only task is to provide a single time point for all users of the application system. To enhance the overall functions of the distributed application system, these bottleneck components must be placed on a dedicated and powerful server. DCOM allows you to separate these key components as early as the design phase. At first, you can place multiple components on a machine with simple functions, and then place the key components on a dedicated machine. This process does not require component re-design, or even re-compilation.

Figure 6 separation of key components

DCOM's handling of these decisive bottleneck components enables the entire task to be executed quickly. These bottleneck components are often part of the execution sequence of the process. For example, the sales commands in the electronic trading system must be executed in the order of receipt (first-come, first-served ). One solution to this problem 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 comes, the first component executes (for example, consistency check), and then passes the request to the next component (for example, may be updating the database ). Once the first component passes a request to the next component, it is ready to execute the next request. In fact, two machines execute multiple requests in parallel, and ensure that the requests are executed in the order they come. You can also use DCOM on the same machine to achieve the same effect: multiple components are executed in different threads or processes. This method can simplify expansion in the future. We can distribute threads to a machine with multiple processors, or we can configure processes on different machines.

Figure 7 pipelining

The location independence programming model of DCOM makes it easy to change the configuration design as the application increases. Initially, a simple server can accommodate all the components. As demand increases, other machines are added, and components can be added to these machines step by step without any code changes.