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.
calls / secms / callcalls / secms / call "Pentium? ,," in-process3,224,8160.000313,277,9730.00031 "Alpha ?," in-process2,801,630 0.000362,834,2690.00035 "Pentium," cross-process2,377 0.42 2,0230.49 "Alpha," Cross-Process1,925 0.5216340.61 "Alpha," To Pentium Remote376 2.73063.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.
