Chapter 5, based on CORBA distributed software development
5.1 Basic principle of distributed technology
5.1.1 Traditional object-oriented analysis and object-oriented design methods.
Conventional OOA and OOD methods can be applied directly to distributed systems analysis and design, however traditional OOP environments (such as C or Object Pascal) encountered problems when designing programming directly for distributed application systems. Traditional objects and programs accessing the object can only exist in the same process, and only the compilers of the relevant programming language can create these objects and perceive the existence of these objects, and the external process cannot understand and access these objects. This means that in conventional distributed client / server applications, the customer process is not possible to directly access conventional objects in the off-site service process. In order to solve this problem, people put forward the concept of distributed objects.
5.1.2 Distributed Object Technology
Distributed objects exist anywhere in the network, which can be accessed by remote customer application. As for distributed objects, what programming language and compiler are used, which is transparent to customer objects. The customer application does not have to know the specific location of the distributed object it accessed in the network and what is running on what operating system, which may be connected to the customer application, or may be distributed over a wide area network (such as the Internet). Different computers. The distribution object has dynamic, which can be moved everywhere on the network. Independent programming language and application system, reusable and self-contained software components are referred to as soft components. Distributed objects are typical soft components. Distributed application development based on distributed object technology is the development and assembly of distributed objects.
Distribution object technology uses object-oriented multi-layer client / server computational model, which will be distributed over all resources on the network (whether the system layer or application layer) is organized according to the concept of object, each object is defined Access interface. The application for creating and maintaining the distribution object entity is called a server, and the app is accessed to access the object is called a customer. The distribution object in the server can not only be accessed, but also itself may be a customer of other objects. Therefore, in the distribution object technology, the role of the customer and the server is relatively or multi-level. The core mechanism supporting the client access to the off-site distribution object is called the object request agent (Object Request Broker, ORB). ORB is in the core position of the distribution object technology.
By reusing existing soft components, software developers using component object models can quickly construct an application like a wood. This will not only save time and funds, improve work efficiency, but also produce more specifications, more reliable applications.
5.2 Distributed software components have the following characteristics
• Self-description components must be able to identify their properties, access methods, and events, which allows the development environment to seamlessly combine third-party software components;
• Customizable - Provides a typical graphical way environment, the properties of the software component can only be set by the control panel;
• Integrated-component must be directly controlled by programming languages. Components can also be connected to the scripting language or to connect from the coded access component, this feature allows the software components to be used in non-visualized development projects;
• The connection mechanism-component must produce events or other mechanisms that allow programmers to connect to each other in semantics. This means that programmers can easily add code to the button, so that the button can affect the action of other components.
The component model is an architecture and API set established for the developer to define software components, so that developers can establish an application system through a dynamic combination of software components. The component model is composed of two main components of the component and the container. The component is a basic software component having a reusable characteristic. The container is used to store and arrange components to implement interaction between components. The container can also be used as a member of another container.
5.3 Service of Distributed Objects
Distributed object services include all types of basic system-level services that support the normal operation of distributed systems, such as name management, event notification, object transaction management, object life, time synchronization, concurrent control, etc. Public facilities include all types of conventional services and tools for high-efficiency development and efficient work of distributed systems, such as GUI services, database services, email services, system management services, and field architects for telecommunications, simulations, and finance. and many more. Applications involve a variety of applications, which complete the corresponding application logic with the help of the object service and public facilities; orb is like a bus (BUS) to connect various objects and applications in the distributed system to integrate. 5.4 Distributed Application Based on CORBA
5.4.1 Main problems of distributed application design
The main problem with distributed application design is to determine the relationship between customers and service objects established on the object level. From its most fundamental function, the service object provides a remote interface, the client object calls the remote interface, and the customer object does not need to understand the location of the remote object and the details of implementation, and no matter which ORB is used for the interaction between objects. According to the implementation process, the implementation of CORBA is divided into two ways: naming service object reference modes and character string object reference methods.
The specific method of establishing a distributed application based on CORBA technology is described below with CORBA technology. ...... .. ~
5.4.2 Design of IDL in CORBA
From a technical point of view, the system is designed to n-layer structure needs to solve some problems on system management, such as network delays, system response time, service availability, distributed buffer and distributed Garbage collection, etc. Moreover, for each new solution that improves system efficiency, it will bring new problems. But these techniques for designing large-scale distributed applications can be solved by using some basic design methods and techniques.
The IDL language is defined by using an iterator design pattern, thereby solving problems such as performance management, buffering, distributed garbage recycling in the CORBA program.
I. Performance issues
Although the CORBA architecture simplifies the intrinsic complexity of the network. But it can't guarantee that you can construct a high
Performance, high efficiency system, to achieve this goal, the design of the entire system must consider the structure of the network inherent, mainly the following three factors.
1. The number of remote calls.
2. The number of data transfer.
3. Conversion and packaging of different data types.
These problems will be resolved if considering the beginning of the system design.
In CORBA-based impact design, IDL has played a lot in the design of the component, and should define the interface standards that the server program follows each other.
Second, IDL design
A problem that is typically overlooked in the IDL design is the application for server-side applications, as well as temporary (transient) and persistent CORBA objects.
1. A server-side application is an object-independent object that implements object methods. In the model of the CORBA program, the server is registered by the portable object adapter (That is, PoA), it can always accept the call to it.
2. Compared with the server-side objects, the temporary CORBA object does not have POA to register to the system, and they are generated by the application of the server during the user request. These temporary CORBA objects life cycle will not exceed the life cycle of the thread of the object, and their object handles are not disclosed.
3. Persistent CORBA objects are associated with persistent status, with special purposes.
The following mainly discusses the use of temporary CORBA objects to manage the transmission of large amounts of data. This method is very useful when dealing with programs that may lose data, as shown in the following example: The user wants to query a large amount of data, after obtaining the top 20 data, another user also puts a query, the possible situation is the data of the previous query Will be lost. This is not a problem in a single process application. But in distributed programming and design. Will take up a lot of network bandwidth and CPU processing time.
Based on the above, the diagram is a schematic diagram of the interaction between a client and a server-side program. The client's agent is a remote proxy class that handles the connection to the remote server program and sends a request to the server to the server. The client pays a request to the server side of the required service, and the server is returned to a group of products. If there is n products in this result, the n elements are returned after the parameter conversion. In the first look, this design is feasible, if not, the unpredictable situation mentioned above does not happen.
Enterprise-level applications are more complicated. The previous design has a great impact on the performance of the system. In the CORBA environment, the design of IDL is particularly important. Good IDL design, take advantage of JDK's API, such as timer, garbage collection mechanism, and assembly framework to improve system performance. This can construct a strong, highly available distributed system.
