(Previous)
DCOM implementation distributed application (5)
Load balance
The more successful distributed application system, the higher the load brought by all components in the application due to the growth of users. A frequent situation is that even the fastest hardware computing power cannot meet the needs of users. One of this problem is unmanable to distribute the load into multiple servers. In the Scalability section, it briefly refers to how DCOM can promote several different technologies of load balancing: parallel configuration, separation of key components and continuous processes. "Load Balancing" is a normally used, which describes a set of related technologies. DCOM does not transparently provide load balancing in a variety of sense, but it makes it easy to complete the load balance of various ways.
Static load balance
One way to solve the load balancing is to constantly assign certain users to some servers running the same application. This method is called static load balancing because this assignment does not change with the network condition and changes in other factors. DCOM-based applications can be easily configured to operate them on some specific servers by changing the registration entry. The customer registration tool can use Win32 remote registration functions to change the settings of each customer. In Windows NT 5.0, DCOM can use the extended directory service to complete the storage of the distributed class, which makes it possible to change these configuration changes. In Windows NT 4.0, application systems can use some simple technologies to achieve the same effect. A basic method is to save the name of the server into a well-known centralized environment such as a database and a small file. When the component wants to connect to the server, it can easily obtain the name of the server. Changes to databases or file contents also change all users and related user groups. A flexible approach uses a refined complex indicator component. This component resides in a server that is known for everyone. The client component is first connected to this component requesting an index that pointing to the service it. Indicates that the component can confirm the issued user using the security mechanism of the DCOM and select the server according to the requestor's identity. Indicates that the component does not return directly to the server name, which actually creates a connection to the server and passes the connection directly to the customer. Then DCOM transparently connects the server and the client, and the job indicating that the component is completed. We can also make the above mechanisms completely masked the customers through things such as a customer's agent store in an indication component. When the user needs an increase, the administrator can transparently select different servers through changing the components. At this point, the customer component does not make any changes, and the application can be made from a non-centralized manager to a centralized management mode. The location independence of the DCOM and its support for effective instructions make this design flexibility possible.
Dynamic load balancing
Static load balancing methods are a good way to solve growing user needs, but it requires administrators to intervene, and only work well when they are predictable. Indicates the idea of components to provide a clearest load balancing method. Indicates that components can be selected based on user IDs, but also selects servers using network topology structure between server load, customer, and available servers and statistics for a given user past demand. Whenever a client connects to a component, indicating that the component assigns it to the most suitable available server at that time. Of course, from the viewpoint of the customer, all this is transparent. This method is called a dynamic load balancing method. For some applications, the dynamic load balancing method of connection may still be insufficient. Customers cannot be interrupted for a long period of time, or the load distribution between users is uneven. DCOM itself does not provide support for this dynamic reproduction and dynamic approach, because this requires a very familiarity that needs to interact between the client process and components, and the component is kept during the method activation. Special status information for some customers. If DCOM suddenly connects customers and another different component on another machine, then this information is lost. However, DCOM enables the application system to easily introduce this logical structure into the protocol between customers and components. Customers and components can use a special interface to determine when a connection can be securely resected to receive another server without losing any important status information. From this point of view, whether the customer or component can initialize another component on another machine before the next method is activated. DCOM provides all the extensive protocol expansion mechanisms for completing these additional protocols for special applications. The DCOM structure also allows the code to be facing special components to the customer process. Whenever the customer process is to activate a method, the proxy components provided by the real component component intercept this call in the customer process, and can find it again to another server. The customer does not need to understand this process, and DCOM provides a flexible mechanism to transparently establish these "distributed components". With the unique characteristics above, DCOM makes it possible to develop a general underlying structure for handling load balancing and dynamic methods. This underlying structure can define a set of standard interfaces that can be used to pass state information and disappear between client processes and components. Once the component is located at the part of the client disappears, it can dynamically connect the customer to another server. Example: Microsoft's transaction server (previously called "Viper") uses this mechanism to extend the DCOM programming model. Through a simple standard state information management interface, the transaction server can obtain the necessary information to provide high-level load balancing. In this new programming model, the interactions between customers and components are bundled into the transaction, which can point out when a series of method invoking the status information of the components involved is clear.
DCOM provides a powerful underlying structure used to complete dynamic load balancing. Simple indication components can be used to transparently complete dynamic server allocation work when they are connected. The mechanism used to invoke a single method to retrofitting the diameter to different servers can also be easily completed, but it requires a more in-depth understanding of the interaction between the client process and components. Microsoft's complete DCOM-established transaction server ("Viper") provides a standard programming model to pass the relevant details of this additional special application to the underlying structure of the transaction server, which can be used to perform very advanced Static and dynamic reconfiguration and load balancing.
Fault
Fault tolerance is very important for applications that require high reliability for key tasks. For erroneous recovery, it is usually implemented by a certain amount of hardware, operating system, and software mechanism for the application system. DCOM provides general support for fault tolerance at the protocol level. A advanced pinging mechanism describing the network and the client's hardware error can be found in the "Shared Connection Management" section of the application system. If the network can recover within the required time interval, the DCOM can automatically re-establish the connection. DCOM makes it easy to achieve fault tolerance. One technology is the technique of the first part of the indication component. When the client process finds an error, it is reconnected to the indicator component that establishes the first connection. Indicates which servers in the component no longer valid, and provide a new instance of this component running on another machine. Of course, in this case, the application system still needs to process the error recovery problem in high-level (consistency, message loss problem, etc.). Because DCOM can put a component to the server side and client, the user can fully transparently implement the connection and reconnection and consistency problems of the components. Figure 15 for fault-tolerant distributed components
Another technology is often referred to as "hot backup." Two copies of the same server components are running on different machines in parallel, which handles the same information. The customer process can be explicitly connected to these two machines. DCOM's "Distributed Components" By putting the processing-fault service code to the client, the above process is completely transparent to the user. Another method is to use a collaborative component running on another machine, which is sent to the two server components on behalf of customers. It is failed to transfer a server component to another machine when an error occurs. The initial version of the Windows NT group uses this method, of course it can be done at the application level. DCOM's "distributed component" makes it easier to complete this machine, and it covers the user's detail. DCOM makes it easier to complete advanced fault tolerance techniques. Distributed component technology that uses DCOMs run in the customer process can cause the details of the problem to be transparent to the user. Developers do not need to change customer components, and even client reconfiguration can enhance the fault tolerance of distributed application systems. Easy configuration If it is not easy to install and manage, even the best application system is useless. For distributed applications, it is critical to centrally manage and make a simple customer installation process. At the same time, some ways to make system administrators can find it as early as possible before any damage causes any damage to distributed applications. What technology does DCOM can make an app more easy to manage?
installation
A common way to simplify the client installation can be summarized as a word "thin customers", which means that the less functional, and the less installation, and possible maintenance issues. However, the more "thin", the more "thin", the lower the user-friendly, the higher the demand for the network and the server. Thin customers don't make full use of the powerful computing power you can get in today's desktop, and because of the characteristics of the desktop production application, these desktop production application systems themselves are uniform, most users are The demand for powerful computing power of this system will not be weakened. Therefore, "strong" is a very important decision to achieve the design of distributed applications in the correct level. DCOM promotes the balance between configuration and flexibility by allowing developers or even administrators to select the balance between configuration. The same transaction component (e.g., data login check components) can be performed on the server and client by simply modifying the configuration. Applications can dynamically select the user interface assembly used (the HTML generator or client's ActiveX control on the server). One of the biggest issues that keep the "obese" customer is to update these customers to the latest version. Now, by support for code download, Microsoft's Internet Explorer 3.0 provides a very elegant approach to solve this problem. As long as the user browsing a page page, Microsoft's Internet Explorer will check the ActiveX control used in the page and automatically update it if necessary. Applications can also use this Microsoft's direct support when using the browser when not explicitly uses the browser (Active CocreateClassFromurl function). In Windows NT 5.0, the concept of code download will be expanded to the local COM class library. This class library will use the extended directory to store the configuration information of the component and the index of the actual code, which changed the currently used local registration concept. This class library will provide code warehouses to intranet (Extended Directory) and Internet (Code Download, Internet Path Search) and make them completely transparent to existing applications. Installing and updating server components is usually not a serious problem. However, in a highly distributed application, all customers are updated to be unlikely. The robust version of the DCOM of the "functional development: version" section is allowed to join new features on the basis of maintaining backward compatibility. Server components can handle both old customer processes and process new customer processes. Once all customers are updated, the components can stop support for the functions that new customers. Use code download technology and its expansion technology, class library, administrators to install and update customers safely and safely, and can turn "obese" customers to smart customers without cutting too many features. DCOM's support for healthy version makes it possible to update the server program without updating all customers. management
Part of the installation and update client component is the configuration of these components and the holdings of these configurations. The most important configuration information involved in DCOM is a message of the server that runs the required components required. Using code download and class library technology, we can manage configuration information in a centralized location. A simple change to configuration information and installation packs can transparently update all customers. Another technique for managing client configuration is the indication component technology described in the Load Balance section. All customers are connected to the indicator component, indicating that all configuration information is included in the component, which returns the appropriate components to each customer. Simply change the indicator component to change all customers. Some components, especially server components, require additional special components configuration. These components can use DCOM to display the interface that allows changing configurations and recovery existing configurations. Developers can use DCM's security underlying frames such that these interfaces can only be used by administrators with appropriate access. The broad support for the accelerated development process allows us to easily write the front-end interface using the management interface. The same interface can be written with a simple script language such as Visual Basic Script or Java Script to complete an automatic configuration transformation. Code download and class library techniques can be used to centrally configure components, and the component method is a method that makes configuration information more centralized. Some components can make the additional DCOM interface can only be seen and used by the administrator, which allows the same DCOM underlayer structure to be used to configure and manage the components. Protocol independence
Many distributed applications need to be integrated into a customer or company's existing network structure. At this time, there may be a special network protocol, which requires all potential customers, which is impossible in most cases. Therefore, the developer applied to the application needs to be carefully used to maintain independence as much as possible of the next network underlying structure. DCOM makes this process transparent: because DCOM can support any of the transport protocols including TCP / IP, UDP, IPX / SPX, and NetBIOs. DCOM provides a security framework based on all of these unconnected and connected protocols. Developers can easily use DCOM to provide features and confident that their application is completely unrelated to the protocol.
Platform independence
Distributed application systems often integrate different platforms to the client and server side. Developers often face important differences between platforms in many ways: different user interface principles, different system services are even different from the entire network protocol. All this makes it very difficult to use and integrated multi-platform. One solution to this problem is that all platforms are the most special one and use an abstraction layer to save the simple code based on all platforms. This method is used by traditional cross-platform development framework systems, such as Java virtual machine environments. Its implementation depends on a code set or even binary code for all supportable platforms. However, this simplification is to pay a price. The introduction of abstract layers has brought additional expenses and cannot use some powerful services and optimizations related to the platform. For user interface components, this method means that it is very small to similar extent to other applications, causing more difficult to use more money to train. For server components, this method sacrifies the ability to coordinate the performance performance of important components in any platform. DCOM technology is open to all cross-platform development work. It does not exclude service and optimization based on special platforms, nor does it specifically apply to certain systems. The DCOM structure allows the platform-independent framework and virtual machine environment (Java), and high execution performance, platform-optimized customer components to a distributed application.
Platform binary standard
From a certain aspect, DCOM defines a platform binary standard, so customers and developers can use components developed by different sellers to mix and match each other, and even use them in different DCOM runs. Although the details of the DCOM runtime may vary with completion time, the interaction between runtime and components and components is standardized. Unlike other abstract object touch, use DCOM to distribute a binary component to a platform running all other components and run libraries.
(Next)
