Development of function: version
In addition to the size of the user's number and the number of transactions, the application system also needs to scale when the new feature is added. Over time, the new task is added, and the original task is updated. Traditional approach is that or client processes and components need to be updated simultaneously, or old components must be reserved until all customer processes are updated, when a large number of geographically distributed sites and users are using the system, this is a very Fault management problem.
DCOM provides a flexible extension mechanism for components and customer processes. With COM and DCOM, the customer process can dynamically query the functionality of the component. A COM component is not a simple, unified method, and attribute group, but is different from different customer processes. Customer processes using specific features require only methods and properties they need to use. The customer process can also use multiple features of one component simultaneously. When new features add components, it does not affect the old customer process that does not involve these features.
To organize components in this way, we can have a new way to develop component functions: the initial component is characterized by a core feature such as a COM interface, which is required for each customer process. When the components need new features, most (even all) interfaces are still necessary, and we must put new features and properties in the attached interface without changing the original interface. Old user processes don't seem to have a continuous access to the core interface. The new customer process can test whether the new interface exists so that it can be used, or still only use the original interface.
Figure 8 Survival version development
Because the machine can be packet into the interface in the DCOM programming model, you can design new client programs for old server programs, or you can design new server programs for old clients, or mix them to be suitable for Your needs and programming resources. When using a traditional object model, it is afraid of a subtle change to a method, which may fundamentally change the protocol between customers and components. In some models, the method can be added to the tail of the method queue, but the new method cannot be tested on the old components. From the prospects of network development, these things will become more complex: coding and other features typically depend on the order of methods and parameters. Increase or modifying methods and parameters will also change the network protocol. DCOM designs a simple, elegant and unified approach to the object mode and network protocol to solve these problems.
Performance
If the initial execution performance is not satisfactory, scalability will not bring too much benefits. It is often considered that more better hardware will make the application to develop down, but what is these needs? Is these cutting-edge expansion characteristics useful? Whether to support each language from COBOL to assembly hazard to the system's execution performance? Does the ability of the component can operate on the other side of the Earth hinder the performance performance when it and the customer is in the same process?
In COM and DCOM, customers can't see the server themselves, but unless they are necessary, the customer process will never be separated by the system components. This transparency is implemented by a simple idea: the only way to interact with components with the customer process is to call. The customer process gets the address of these methods from a simple method address table (a "vTable"). When a customer process wants to call a method in a component, it gets the address of the method and then calls it. The only expense of calling a traditional C or assembly function in the COM and DCOM model is a simple query for method addresses. If the component is in the process of running in the same thread in the same thread, you can find the address of the method without calling any COM or system code, COM only defines the standard of finding the method address table.
What is the situation when the user and the component is not so close-in another thread, or in another machine in another program? COM places its remote procedure call (RPC) frame code in the VTABLE, then put each method call to a standard buffer structure, this buffer structure will be sent to the component, the component opens the package and re-runs The initial method call. In this respect, COM provides an object-oriented RPC mechanism. How fast is this speed of this RPC mechanism? Below is a different performance scale that needs to be considered:
How fast is a "empty" method call? How fast is the "true" method to send and receive data? How fast is it to turn a circle on the network?
The following table shows some real performance parameters of COM and DCOM, enabling us to understand the relevant execution performance of DCOM and other protocols.
Parameter Size 4 bytes 50 bytes calls / sec ms / call calls / sec ms / call "Pentium® ,," in-process 3,224,816 0.00031 3,277,973 0.00031 "Alpha ™," in-process 2,801,630 0.00036 2,834,269 0.00035 "Pentium," cross-process 2,377 0.42 2,023 0.49 "Alpha," Cross-Process 1,925 0.52 1634 0.61 "Alpha," To Pentium Remote 376 2.7 306 3.27
Started two columns to represent an "empty" method call (send and receive a 4-byte length integer). The last two columns can be considered a "real" COM method call (50-byte length parameters).
This table shows how components in the process have achieved zero-spend performance (first row and second row).
Method between processes (third row and fourth row) need to store parameters into the buffer and send it to other processes. In a standard desktop office system hardware, you can perform 2000 method calls per second, which can meet most of the execution performance requirements. All local calls are completely determined by the processor speed (somewhat by memory capacity), and can be well applied to multiprocessor machines.
Remote calls (fifth rows and sixth rows) are primarily limited to network speed, and it can be seen that the expenditure of DCOM is approximately 35% more than TCP / IP (TCP / IP cycle time is two seconds).
Microsoft will quickly provide formal DCOM performance parameters on many platforms, which will display DCOM and the number of clients related to the number of processors in the server.
Bandwidth and potential problems
Distributed applications use the advantages of the network to combine components together. In theory, DCOM hides components to run this in different machines. In fact, the application must take into account the two main limits resulting from the network connection:
Bandwidth: The size of the parameters pass to the method call directly affect the time of the completion method. Potential problems: physical distances, and related network devices (such as route transmitted transmission lines), can even make the smallest packets are significantly delayed.
How do DCOM helps apply these limitations? The DCOM minimizes network cycle time so that potential congestion in the network is possible. DCOM sees no connected UDP protocol in the TCP / IP protocol suite as its own transport protocol. The connectionless characteristics of the protocol allow DCOM to mix many low-level confirmation packages and actual data and address legality check (pinging) information to improve performance. Even on the connection-oriented protocol, DCOM is also superior to traditional protocols facing special applications. Sharing connection management between applications
Most application level agreements need some kind of management from beginning to end. When the client has a serious hardware failure or network connection interrupt between customers and components has been fed for a certain period of time, it should be notified in time.
A universal method for solving this problem is a time (pinging) to send a keep-alive message. If the server does not receive a ping message in a certain time interval, it concludes that the customer process is "dead".
DCOM uses a Keep-alive message for each machine. Even if a client uses 100 components on a server, only one of the PING messages allows all of these client connections to be active. In order to combine all PING messages, DCOM minimizes the size of these ping messages using the Delta pinging mechanism. For this 100 connections, it is not to send 100 customer identifiers, but create a variable identifier to repeat the 100 references representative. When the reference set changes, only the part of the intersection of the two sets is exchanged. Finally, DCOM translates all ping messages to normal messages. Only when a client is completely idle, it is scheduled to send a ping message (once every two minutes).
Figure 9 Combined Life Management
DCOM allows multiple applications (even from different sellers) to share a simple and optimized life-ascation management and network error detection protocol, which can significantly reduce bandwidth. If you run 100 different applications using 100 different traditional protocols on a server, each application on each customer is connected to each app, the server should receive a ping message. Only when these protocols work together on their pinging strategies, the overhead of the entire network is likely to decrease. And DCOM automatically provides this collaboration in any DCOM-based protocol.
Optimize the ringback of the network
A universal problem for designing distributed applications is to reduce the number of excessive returning windings on the network between components on different machines. On the Internet, each network winding will introduce 1 second or more delay. Even on a fast-fast local area network, the rotary time is also calculated in microseconds - it exceeds the level of time required for local operations.
A universal method of reducing the number of network windings is to bundle multiple methods. DCOM extends this technique to address the tasks such as connecting an object or creates an object to query objects. This technique is that it is too large to program model models in local and remote conditions.
Example: A database component provides a method that can branch or multi-line display results. In the local case, developers only need to use this method to add a list of results to the list box. In the remote situation, each of each line will cause a certain network aversion. Using a bulk method requires developers to assign all columns that can accommodate all columns out, and then retrieve it in one call and add one column to the list box. Because the programming model changes very large, developers need to make great changes to design so that applications can work effectively in distributed environments.
DCOM enables component developers to easily perform batch techniques without having to use a client to use a bulk form. The Marshling mechanism of the DCOM allows the component to add the code to the client, called "proxy object", which can block multiple method calls and bundled it into a remote call.
Example: Because the needs of the logical structure of the application system (the requirements of the list box API), the developer of the above example still requires one way to list the method. However, in order to list the first call applications of the query result, it has all columns (or a batch of columns) and caching them into the proxy object. Later calls are issued from this cache, avoiding the network aversion. Developers still use a simple programming model, and the entire application is optimized. Figure 10 Component Model: Client Cache
DCOM also allows valid guidelines from one component to another. If a component saves an index of a component on another machine, it can pass it to a customer process running on a third-party machine (assuming this customer process is using another component running on another machine. ). Customer Process Use this index to communicate directly and the second component. DCOM shortens this index and makes the first component and machine can be detached from this process. This makes it possible to provide an indexed conventional directory service for remote components.
Example 1: A chess application system enables users who are waiting for the opponent to log in to a chess directory service. Other users can browse and query the list of users who are waiting for the opponent. When a user selects his own opponent, the chess directory service system returns the opponent's client component index to the user. DCOM automatically connects two users, and the directory service system does not need to involve any other transaction process.
Example 2: A "broker" component monitors 20 servers running the same component, which monitors the server's load and the server's joining and deletion. When a customer needs to use the component, it is connected to the "broker" component, which returns the index of a component on the lightest server. DCOM automatically connects to customers and servers. At this time, "brokers" components are independent of the future process.
Figure 11 Index indication
If desired, DCOM even allows the component to insert any of any of the traditional protocols, which can be used in the DCOM functionality. Components You can use traditional configuration methods to place any proxy objects in the customer process, which can return information to the component using any protocol.
Example 1: A server-side component can communicate with an ODBC connection and a SQL Server database. When the customer gets the object, the client directly and the SQL Server database (using ODBC) is more effective than using DCOM and server communication, while the server and SQL Server database communications are more effective. In the traditional configuration of DCOM, database components can copy themselves to the client and connect themselves with SQL Server, and at this time, customers are not realized that they are no longer connected to the database components on the server, but And a local copy of the component is connected.
Example 2: A commercial system requires two communication mechanisms, one is identified from the client to a central system, which is used to issue and undo command; the other is a distributed channel, which is used To send command information simultaneously to customers connected to the system. Synchronous connection methods using DCOM can be easily and efficiently operating channels between clients / servers, while broadcast channels require a more cutting-edge mechanism, which uses multipoint broadcast technologies to accommodate a large number of listeners. DCOM allows traditional protocols ("Reliable Broadcast Protocol") to seamlessly insert into the architecture of the application system: A data receiving component can encapsulate this protocol and make it completely transparent to customers and servers. When the number of users is small, the standard DCOM point to point protocol is sufficient; and for sites with many users, advanced broadcast protocols need to be used. DCOM will provide a standard multi-channel broadcast transmission protocol that can be seamlessly ported to the application system.
Figure 12 Replace DCOM with a Custom protocol
safety
Using the network to distribute application system to a challenge, not only because of the physical limitations of bandwidth and some potential issues, but also because it produces some security issues between customers, components, and clients and components. Because many of the operations can be accessed by any person in the network, access to these operations should be limited to a high level. If the distributed development platform does not provide safe support, each distributed application must complete your own security mechanism. A typical method is to use a certain login method to require the user to detect the username and password, which is generally encrypted. The application system will confirm the above user identity through the user database or the relevant directory, and return dynamic identifiers so that the user is used to call. User needs to pass this security check each time you involve a safe checkup method. Each application system has to store and manage many usernames and passwords, preventing users from performing unauthorized access, management password changes, and is dangerous to handle passwords on the network.
Therefore, the distributed platform must provide a security framework to independence different users or different groups of users so that the system or application has a way to know who will operate a component. DCOM uses the extended security frame for Windows NT. Windows NT offers a set of solid built-in security modules that offer a complex identity confirmation and authentication mechanism from traditional credit fields to non-centralized management models, which greatly expands public key security mechanisms. The central part of the security frame is a user directory that stores the necessary information used to confirm the user credentials (username, password, public key). Most of the Windows NT platform-based systems provide similar or identical extension mechanisms, we can use this mechanism without using which security module is used on this platform. Most DCOM's UNIX versions provide security modules with Windows NT platforms.
Security settings
DCOM does not need to make any coding and design work for any specifically for security on the client and components, can provide security guarantees for distributed applications. As the DCOM programming model is blocked, it also shields the security needs of the component. The binary code that works in a single-machine environment that does not need to consider the safety of safety can work in a safe way in a distributed environment.
DCOM enables the developer and administrators to set security environments for each component to make security transparency. Just like the Windows NT allows administrators to set the Access Control List (ACLS) for files and directory, DCOM stores the component's access control list. These lists clearly indicate which users or user groups have access to a component of a class. These lists can be set by using the DCM setup tool (DCMCNFG) or the REGISTRY of Windows NT and Win32 in programming.
As long as a customer process calls a method or creates an instance of a component, DCOM can get the current user name of the user using the current process (actually being currently being executed). Windows NT ensures that this user's credentials are reliable, then DCOM will run the username's machine or process. Then the DCOM on the component once again checks the user name again, and finds the component in the Access Control List (actually looking for the first component that is running in the process of this component). If this user is not included in this list (neither directly in this table is not a member of a user group), DCOM will reject this call before the component is activated. This security mechanism is completely transparent to users and components.
