CORBA (Common Object Request Broker Architecture) is a system composed ofOMGA standard formulated by the organizationobject-orientedApplication System Specification.Or CORBA architecture is an object management organization (OMG)distributed processingA solution for interconnection of hardware and software systems in DCE;OMG is an international organizationNon profit organization, whose responsibility is toapplicationDevelopment provides a common framework, formulates industrial guidelines and object management specifications, and accelerates the development of object technology.
Chinese name
Common Object Request Broker Architecture
Foreign name
Common ObjectRequest Broker Architecture
Abbreviation
CORBA
Advantages
Easy to expand and modify, universal and adaptable
CORBA is a public object request broker structure proposed by OMG in 1991technical specifications。CORBA has a wide range of applications. It is easy to integrate different computers from different manufacturers, from mainframe to the terminal desktop of micro embedded systems. It is an excellent middleware for large and medium-sized enterprises.Most importantly, it enables the server to handle the access of a large number of users with high speed and stability.Many servers on the back end of large websites now run CORBA, some of which you may visit every day[1]。
CORBA's underlying structure is based onObject oriented modelIt is composed of three key modules: OMG Interface Definition Language (OMG IDL), Object Request Broker (ORB) and IIOP standard protocol (Internet Inter ORB Protocol, also known as Network ORB Exchange Protocol).
The object interface written by the interface description language makes it possible to be independent of the language.IDL enables all CORBA objects to be described in one way, and only requires a "bridge" from the local language (C/C++, CORBA or Java) to IDL.CORBA object intercommunication should be mediated by the object request proxy. This kind of intercommunication can be realized on a variety of popular communication protocols (such as TCP/IP or IPX/SPX).On TCP/IP, ORBs from different developers communicate with IIOP standard protocol.
We know that in order to maintain the business neutrality and language neutrality of CORBA, there must be a mediation between entities such as C++CORBA server code and Java CORBA client, which is IDL.Several related methods and properties of an underlying object are integrated into a single interface by IDL.Once the IDL interface is defined, it can be compiled into the selected language in the form of Stub code or framework code.IDL compilers are available in all ORBs.
It is worth noting that IDL is different from other object-oriented programming languages, and we cannot use it to specify the specific implementation of defined classes or methods.Therefore, it is much better to just use it as a language to define the underlying object interface.
Basic components
Announce
edit
Figure 1
CORBA structure diagram is shown in Figure 1[2]。
communal facilities
Public facilities are divided into two categories:
one
Horizontal facilities refer to objects defined in the general domain.Information management, network management, system management, task management and user interface belong to the general field.
two
Vertical facilities refer to objects defined in the special domain.Telecommunications, finance, commerce, health care, etc. are all specialized fields.
Object service
Object services are basic services provided for public facilities and various application objects, such as naming services, event services, transaction processing services, notification services, transaction services, life cycle services, security services, and so on.
one
Naming service.CORBA objects are registered in the naming service, which can find the object reference in the corresponding server according to the object name.
two
Event service.Event service consists of one or more suppliers, consumers, and event channels.The latter is the medium for transmitting events (messages) between suppliers and consumers.The supplier places messages to consumers in the event channel. According to the working mode of the event channel - push mode and pull mode, these messages are either pushed to consumers or pulled from the channel by consumers.
three
Transaction service.It ensures that all operations included in a transaction are executed successfully, or none is executed in case of failure and restores to the initial state, so as to maintain the consistency of data before and after the transaction.
four
Trade service.Trading services are composed of exporters, importers and traders.Exporters give service descriptions and announcements to traders, and importers inquire about service information that meets relevant conditions from traders, and then obtain the required services from exporters.
five
Life cycle service.The lifetime of objects is controlled through direct object-oriented services, such as object creation, deletion, transfer, and replication.
six
Security service.CORBA level one security service provides authentication, restriction, authorization, audit, encryption, registration and other services to comprehensively solve the security problems in the distributed system.
seven
Notification service.It is an extension of event service function, adding structured events, event filtering mechanism, quality of service control and other functions.
Application Object
This is an entity that has not been standardized by OMG and is developed by various application developers. Application objects use various object services provided by CORBA.
Object Request Broker
Object Request Broker (ORB) is the foundation of CORBA and the software bus based on object model used by CORBA applications in a distributed environment.Its basic responsibility is to solve the request of object reference and establish the connection between application objects. Through the standard interface, this connection is independent of the hardware and software platform used, thus ensuring the transparency of the platform and the transparency of the operating system, network protocol and programming language.
Interface definition language
The Interface Definition Language (IDL) is used to define the interfaces used by CORBA objects and between application components.It is not a procedural language. It can only define interfaces, not implement them.IDL is independent of any programming language. IDL compiler can map it to other commonly used languages, such as C++, C, COBOL, Java, etc[1]。
The IDL framework mainly includes four elements:
Module.It contains many interfaces grouped by function, forming an additional hierarchical structure.Therefore, the module defines a namespace.
Interface.It defines data and operations (or methods) for the customer to call.An interface can include declarations of types, constants, properties, and exceptions.In fact, the IDL interface defines the classes in CORBA.
Operation.It represents the service that can be called by the customer and is in the object.The operation characteristic (signature) refers to the parameters of the operation and the returned result type.An operation can also include optional exception events and a set of attributes that describe the customer's locale.In this way, the operation defines the method in CORBA.
Data type.It is used to describe the allowable values of parameters, properties, return values, exceptions, etc.A type is an identifiable entity with a predicate that is the same as its value. If the result of its action on an entity is true, then the entity meets this type and is called a member of this type.The data types supported by CORBA can be basic types, template types, construction types, complex types, and local types.
Core role
Announce
edit
Positioning of objects
When the client program gets an object reference, it will call the operation of the object reference.At this time, the ORB of the client will locate the object implementation according to the information in the object reference (the specific location method will be discussed in the following chapter), and ensure that the object implementation can accept the request.Because ORB can locate the server according to the object reference, the client program does not need to care where the object is implemented.The client invokes remote objects just like local objects, thus realizing the position transparency of CORBA.
Marshalling and Ungrouping
When the client initiates the call, the input parameter format is related to the specific platform and language. The client ORB is responsible for encoding them into a format that can be transmitted on the network, or called the online format. This process is called marshalling.This "0101" format is transmitted on the network and then arrives at the server ORB. The server ORB is responsible for "restoring" these online formats to the format of the specific platform and language used locally. This process is called unmarshalling.On the contrary, after the end of the server side call, the server side ORB is responsible for encoding the output parameters and return parameters into an online format and transmitting them to the client side ORB through the network. The client side ORB then "restores" these online formats to the format of the specific platform and language used locally, and sends them to the client program as output parameters and return parameters.In general, the importance of marshalling and unmarshalling is shown in the following aspects: First, it turns calls to remote objects into one-dimensional ordered code streams, which is conducive to transmission on the network.Second, it provides an "intermediate format" that is independent of each platform and language. Different languages on different platforms use this "intermediate format" to "talk" (the rules of the intermediate format will be described in the following chapters).It is precisely because of the introduction of marshalling and unmarshalling that the platform and language of the client and server can be different, which brings the characteristics of platform independence and language independence of CORBA.
Initial Services
At the beginning of the program, you need to get some general object references, such as object references of object adapters, naming services, and interface libraries.Due to the special stage of program startup, it is difficult to obtain these object references with conventional methods.ORB can provide two operations through the pseudo object interface CORBA ∨ ORB to complete this function: list initial services () and resolve initial references () (see the section "ORB initialization" for details).
Shielding protocol
ORB is responsible for dealing with the details of the underlying network communication. It can use different underlying network protocols, such as TCP/IP, IPX, SS7, etc., thus freeing clients and servers from complex network programming.
Provide interface library
Figure 2
Each ORB has an interface library, which is responsible for storing the information of the interface defined by the interface definition language (IDL). It also supports some standard APIs to traverse or query the interface information in the system. It is an indispensable part of CORBA dynamic call.In addition, ORB also provides other general APIs through the pseudo object interface CORBA ∨ ORB, which can be used by both client programs and server programs (the contents of this part will be described in detail in the section "ORB Interface").Based on the above discussion, the role of ORB core can be summarized as follows (see Figure 2):
one
When the customer activates a called operation, the object reference of the target object indicated in the operation is passed to the ORB core through the code root.The ORB core automatically finds the corresponding server on behalf of the customer (that is, the object implementation of the target object).After finding the server, ORB should ensure that the server is ready to receive requests.
two
The ORB core of the client receives the parameters of the called operation (or method) and codes it into a format acceptable to the network.The ORB core on the server side ungroups the operation parameters from the network, sends them to the server, and starts the server to execute the called operation.
three
After the operation is completed, if there is a return parameter, the ORB core transmits its group code to the network.The client ORB core decodes it and returns the operation result to the client.
operation mode
Announce
edit
Static mode
To better understand the way CORBA works, let's first look at a fabricated metaphor.
Figure 3
Suppose there is a king with a group of so-called scholars, such as philosophers, mathematicians, theologians, etc.In fact, they don't have much knowledge. The only magic weapon is that everyone has a magic "card" to help them find the real answer.(See the process shown in Figure 3).
One day, the king suddenly became interested in philosophy. He found the most appreciated philosopher and asked him a question (see ① in Figure 3).
The philosopher knew nothing about this problem, so he made a phone call according to the information on his "business card", which led to a distant country (see ② in Figure 3).The person who answered the phone was a philosopher's partner. In fact, he did not understand anything, but he was the personal representative of a real "prophet". He conveyed this question to his master, the reclusive "prophet" (see Figure 3, ③).
After thinking, the prophet gave a detailed answer to the question (④ in Figure 3).
The philosopher's partner conveyed all the contents into the microphone (⑤ in Figure 3).
The next day, the philosopher announced the answer to the king (⑥ in Figure 3).
If you change the phone call to a letter, this fictional scenario might have happened thousands of years ago. In fact, CORBA is not more complicated in "scenario" than it.
The king is the client, his philosopher is the stub, and other "scholars" are also code roots, but their corresponding interfaces (problems that can be solved) are different.The king asked the philosopher that the customer called the code root, the magic "business card" was the object reference, and the telephone responsible for communication was the ORB core.According to the business card, the philosopher partner found by phone is the skeleton, while the reclusive "prophet" in the plot is the object implementation.
The problem is passed on step by step, which is the process of request. The philosopher's partner answers the phone, which is the process of accepting the request.When the prophet is thinking, it is the process that the request is executed, and the answer is delivered step by step, which is the process of returning the result.
In the static mode, the code root is compiled from the IDL interface file in advance, which includes the definition and implementation of proxy objects.The definition of proxy object is consistent with the definition in the IDL interface, including name, operation, parameter, etc. The implementation of proxy object is encapsulated in the proxy object. In fact, it does not implement the implementation expected by the customer, but groups the customer's request to the ORB core, and waits for the remote object implementation to implement this operation.The returned parameters and results obtained after execution will be sent back to the code root through the ORB core for unmarshalling, and then the code root will send the returned parameters and results back to the client program waiting for the results in the way of local operation.
The client program directly calls the operations defined in the code root through the object reference.In the static mode, the framework is compiled and generated by the IDL interface file in advance, and a specific framework accepts a specific request for an interface.
Dynamic mode
Suppose that the above fictional plot has changed, and the king has hired a new secretary. Whenever there is a problem and no scholar around can "solve" it, the king will pick out a card from the card book of an expert he thinks can solve the problem, and hand it to the secretary. The secretary does not claim to be an expert on a problem, but only works according to the king's will,Call the other party according to the contents of the business card, and tell the king the answer.
This is the dynamic call mode. The versatile secretary is DII, and the business card book storing business card information is the interface library.
Compared with the static mode, the dynamic mode has the following advantages:
one
Flexible.The dynamic mode allows you to operate on any object. All you need is an object reference of the target object.In addition, with the help of the interface library, you can dynamically query the information about the operations supported by objects at run time, and operate on previously unknown objects.Whether it is the object of operation, the parameters of the call, or the number of calls, etc., can be determined by the client program at runtime according to the current environment and needs.Therefore, the dynamic way is more flexible than the static way.
two
Enhanced portability of client programs.It can be seen from the ORB's structure diagram that the interfaces between DII and customers and between DSI and object implementations are standard. No matter how the ORB is implemented, these interfaces should be consistent with the specifications.Because the client and object implementations use standard interfaces, theoretically, the code implemented in a dynamic way should have good portability.
three
The "volume" of executable programs is small.Unlike code roots and frameworks, DII and DSI do not need to generate code roots and frameworks for each interface.In the existing implementation mode, these code roots or frameworks need to be linked to the client programs and object implementations that use them respectively at compile time.In the dynamic mode, no matter how many interfaces are used in the program, all that is needed is a set of interface libraries that support DII and DSI. If this library is a dynamic library, the "volume" of the executable program will be smaller.
However, compared with the static mode, the dynamic mode has the following disadvantages:
one
Complex to use.When using the static mode, operations on the target object are applied to a local proxy object. All operations supported by the corresponding object and their formats have been predefined in this proxy object, so it is convenient to use.However, in dynamic mode, programmers need to build a request by themselves and send it out temporarily. In many cases, the program may also need to query the interface library to obtain a necessary information for operation. These processes are more complex than those in static mode.
two
Slow speed.In terms of function, the DII and code root on the client side, the DSI on the server side and the framework should complete the same function (initiating or receiving requests, encoding and decoding). However, since the type information is determined in the static mode, its implementation can be described as "tailor-made" and fast;In dynamic mode, type information is obtained dynamically, which is inevitably slower.In addition, programs often spend a lot of time to query the interface library, especially when the queried interface definition is stored at the remote end, these queries will also cause remote calls, resulting in a slower dynamic mode.
Figure 4
The above speed comparison between dynamic mode and static mode is only qualitative, and its quantitative comparison depends on the implementation of specific ORB to a large extent. In the book Instant CORBA, the author's experimental conclusion is that the dynamic mode is about 40 times slower than the static mode.Therefore, programmers should properly balance their requirements for flexibility and speed before considering adopting dynamic mode.Generally, when the client frequently calls the server object and the server object remains unchanged, the static precoding and decoding method can be used;When the client seldom calls the server object, or the client finds the server object at runtime, the dynamic call mode can be considered.In the same program, both dynamic and static modes can be used, as shown in Figure 4.
application
Announce
edit
Telecommunications Applications TMN
TMN（Telecommunication management network）With the rapid development of network information technology, network equipment is increasingly advanced, network services are increasingly rich, and network structure is increasingly complex, all of which need an intelligent network management system to manage[3]。
Different international organizations and forums have formulated many standards and specifications for network management, such as the TMN developed by ITU-T (International Telecommunication Union) for telecommunications network management, and the Internet network management developed by IETFSNMP protocolWBEM developed by W3C for computer desktop management, etc.The TMN standard consists of a set of protocol documents, mainly including ITU-TX.700 series and ITU-TM.3100 series recommendations. It covers the architecture, functional requirements, information model, protocol, consistency, methodology and many other aspects of the telecommunications management network.It is actually composed of ITU-TStudyGroup7 and ISO（International Organization for Standardization）It was first jointly formulated in 1988, and has undergone many revisions and improvements since then.TMN is not only used to manage OSI (Open Systems Interconnection) protocols, but also to manage the entire network[4]。
