Deprecated distributed object
0 Preface
Distributed objects are widely used in network development and enterprise applications. However, there are many problems in this. So "use a distributed object with caution", you can use it without using distributed objects.
With a distributed object, there is a basic principle: placing the object in the correct position. If you don't place an object in the correct location, you will pay an expensive performance.
1 Distributed object FAQ
People want to distribute them. However, many errors are usually made during the distribution of objects.
1.1 Designer's dream, developer's nightmare
Figure 1-1 Design of Purchasing System
By placing different objects on different nodes to publish applications to listen to a good idea, but the cost of performance is huge. This is a distributed object system design, we assume that it is a certain procurement system. In this design, there are separate remote objects for customers, orders, products, and delivery, each with different processes nodes. It is very poor during actual operation.
Perhaps, the advantages of the distributed objects promoted by many software vendors are: You can choose some objects, and place them in the process node as you want. At the same time, their powerful middleware provides a transparent mechanism.
The transparent mechanism allows objects to be called each other within one process, without having to know if the caller is in this process or another process or on another machine.
The transparent mechanism does value, and many things in distributed objects can achieve transparent mechanisms, but performance is not possible to achieve transparent mechanisms. Although the design prototype is designed for performance factors, it is actually designed to weaken performance, making the system more difficult to create, more difficult to implement.
1.2 Local interface and remote interface
The computer system has such a basic fact: the program call inside the process is very fast, but the program call speed between two different processes is slower. Therefore, running a process on other machines, increasing one or two quantities of complexity, which is related to the topology of the network. Therefore, the local object interface and the remote object interface are very different.
The local object interface is a fineness. Therefore, if there is an address class, a good interface should have a separate method to get the city name, get the provincial name, set the city name, set the name of the name. The interface structure of the level is very good because it follows the general object-oriented principle: a large number of small pieces can be combined, reloaded in different ways, which can be extended to accommodate future needs.
However, it is not so easy to use when the level exit is handled. When the method call speed slows down, we want to use a call instead of using three calls to get or update the city name, provincial name and zip code. Therefore, the needed interface is a truss, which is not designed for flexibility and scalability, but to reduce the call design, it will see an interface with the address and update address function. Perhaps the coarse interface looks awkward, but for performance, the triangular interface must be used.
Of course, software vendors generally say that their middleware is applicable to remote calls or local calls. If it is local call, it has the speed of local calls; if it is remote call, the speed will be slow. Therefore, it is only necessary to pay the price of remote calls when needed. This statement is truly, but it does not solve a basic problem: Any object used to remotely call should be a truss, and each of the objects that are not used for remote should have a level. Interface. When two objects communicate, which interface must be selected. If the object is in different processes, you must use a dry-grade interface to pay more programming. Obviously, only the crude scale interface is used when necessary, there is a need to minimize cooperation between processes.
For these reasons, it cannot be just a set of classes in a process, then Corba, design a distributed model. Distributed design is never true. If the allocation policy is class, then face a large heap remote call and a thick-level interface. Such a number of remote calls and truss interfaces can cause crash of the program; even when there is a thick-class interface, it will crash because there are too many remote calls. 2 solution
The following is three methods that solve the distributed object, can be used alone or in combination.
2.1 Try not to distribute objects
Clustering method refers to placing multiple copies of the same application on different nodes. If you have to distribute, this method will eliminate potential problems.
Figure 2-1 Clustering method
In most cases, clustering methods: Place all classes in a process, then run the copy of the process at different nodes. With this method, each process can use local calls to complete work, so speed will be. It is also possible to use the level of interface to all classes within the process, so that better maintainability can be obtained in a simpler program model.
When do you have to distribute?
Therefore, you want to minimize the boundary of the division, and use your node as much as possible by clustering. However, contradictions are limited to the scope of use of clustering methods, and distributed objects must be used in some places, which is processed.
A obvious process segment is the segmentation of commercial software on traditional clients and servers. PCs on different user desktops are different nodes to share data warehouses. Since they are different machines, they must split the process of communicating with each other. Client / server segmentation is a typical cross-process segmentation.
Process segmentation often occurs between server-side application (application servers) and database servers. Of course, you can run all of your application by using the stored procedure in the database process. But this is not practical, so there must be a separate process. They may run on the same machine, but once there is a separate process, they will pay great overhead in remote calls. Fortunately, SQL is designed to remote interface so that it can be flexible to arrange business to minimize overhead.
Process segmentation occurs between web servers and application servers in a web system. If all events are the same, it is best to run web servers and application servers in a process - but unfortunately, not all things always have.
Due to software vendors, they must segment the process. If you use a package, it often runs in your own process, and this is also the same. A good package should have at least one truss interface.
There are other reasons for application server software segmentation. You may avoid them as much as possible, but the situation will still appear. So you must divide your software into a remote, truss part.
"Cautious treatment of object distribution", use other ways as much as possible, this is higher than all themes.
2.2 Use the distribution boundary
Remote front and data transfer objects are two important concepts that make remote structures work.
When designing the system, the distributed range is determined as much as possible, but this factor must be considered in places with distributed objects. All parts in the system must be changed to reduce remote calls. However, you can still be designed in a single process by using a fineness object. The key here is to use the fineness object inside the system, placing a coarseness object at the distribution boundary, and the role of the coarseness object is only to provide an interface for the level object. The coarseness object does not do anything, but they are the front of the fineness object, which is only used for distribution purposes - so called the remote front.
Using the remote front can minimize the difficulties introduced by the thickness interface. Therefore, only objects that truly need remote service can use a dry degree method, because of the developer, it is clear that they have to pay expensive considerations for the coarseness interface. The transparent mechanism does have its advantages, but do not need a transparent mechanism when calling.
By using the thick level object only as a front, as long as people determine that the level of grade objects are running in the same process, they can use them, which makes the entire distribution policy clearer. It works simultaneously with the remote front and data transmission objects. Because not only need a trip, it also needs to transmit a thick-level object. When you look for an address, you need to put this information in an information block. Because it is usually not possible to transmit domain objects itself because it is bundled in a local object network in a level. So the data required by all clients is packaged in a special object for transmission - the data transfer object. The data transfer object appears at both ends of the transfer chain, so it excludes anything that is not in this transport chain. This ensures that the data transfer object is only a basic object such as other data transfer objects and like sequences.
2.3 use distribution interface
Web services are only used when the direct method is not available.
The interface of the distributed object in the traditional sense is based on a remote procedure called, or through the global process or through an object method. However, in the last two years, we have begun to see an interface based on HTTP on the XML. SOAP may be the most common in this type of interface. In fact, many people have used this technology for many years.
XML-based HTTP communication is very convenient, because the following reasons:
ü XML is a public format, which has its parser on many platforms, which allows systems on different platforms to communicate with each other, just like HTTP;
ü XML allows a lot of data to be conveniently transmitted;
ü XML has a structured form;
ü XML only needs an annular process;
ü XML is based on text, it is easy to see what is passed through the transmission chain;
ü HTTP is easy to pass through the firewall, because security and political factors often cause other ports that cannot be opened, so this is very useful for information transmission.
Because you need to minimize remote calls, XML-based HTTP communication is a good thing.
Although this, the object-oriented interface of classes and methods also has its value. Transferring all transmission data into the XML structure and sequence will increase a considerable burden to remote calls. Of course, if remote calls are replaced with XML-based interface, the performance of the application will be significantly improved. If the same binary mechanism is used in both ends of the transmission chain, the XML interface will only give you a chaotic abbreviation. If the two systems are built on the same platform, it is best to use the remote call mechanism to be built on the platform. WEB services are convenient when you want to talk to each other. So only when a more direct method is not possible, use an XML web service.
Of course, you can build the length of both, establish an HTTP interface based on object-oriented interface. All calls to the web server will be interpreted to be called to the underlying object-oriented interface. To a certain extent, this is able to integrate the advantages of both, but increase complexity because it is necessary to simultaneously require components of the web server and remote OO interface. So, only when you need HTTP and remote OO API (application interface), or relative to the use of non-remote objects, remote OO API's ability to make it easy to handle these problems, so that both combine The way.
3 Conclusion
This article describes synchronization, RPC-based interface. However, although I describe this method, I don't think this is the best way to deal with distributed systems. I prefer to choose a message-based approach, because the essence is not synchronous, and I think this is the best way to deal with Web services. For the use of distributed objects, you must be careful.
(Special note: This article is published in the computer world network www.ccw.cn, if reproduced, please contact the computer world network, illegal reprint will be severely sanctions in the "Copyright Law"!) For more information, see China Soft Test League: WWW .cnitunion.com China Soft Test League
