Chapter II Corba's Core
2.1 Basic concept:
1. ORB (Object Request Broker) Object Request Agent: It is a "software bus" to connect to different objects on the network, providing object location and method call, which is the key to CORBA implementation.
2, OA (Object Adapter) Object Adapter: Used to construct an interface between the object to implement and the ORB. It gives the framework, calls and supports the life cycle of the server object (such as the creation and deletion of the object).
3, BASIC OBJECT Adapter Basic Object Adapter: Responsible to activate the object, that is, when the customer requests the object's service, activate the object implementation.
4, POA (Portable Object Adapter) Portable Object Adapter: It is an alternative to BOA, providing a large number of scalable interfaces to handle some unreasonable requirements for BOA. characteristic:
(1) Supports transparent activation objects.
(2) Allow a single server to support a lot of object identity.
(3) Allow a server to have multiple POAs, each has its own set of management strategies.
(4) Enter a request for the default server to the request for the server, or request a suitable server to the server's manager.
5, DYNAMIC Invocation Interface Dynamic Call Interface: Located in the client, send a client's call request.
6, DSI (Dynamic Skeleton Interface) dynamic frame interface, located on the server side, transferring the client's call request.
7, IDL (Interface Definition Language) Interface Definition Language: Define a static interface between the client and the server, generate the customer stub, server framework, and the computer mapping according to the compiler to automatically generate code from a CORBA IDL.
Currently supported language mappings include: Java, C , Ada, SmallTalk and Cobol, etc. CORBA IDL is made by Object Management Group to define all CORBA interfaces. Here is an IDL browsing that allows you to create IDL files to define most objects. The latest IDL complete definition See OMG's Web site (Info@omg.org).
You can define types (types), constans, and interfaces. This is similar to the type, constant and class defined in C . IDL is a language defined interface and type, which does not provide you with an element that implements a part. The interface defined in the IDL file must be implemented in separate implementation units.
The identifier of the IDL file includes English letters, numbers, and underscores, but can not begin with the underscore. IDL is sensitive. However, avoiding using underscores is usually a good idea because Idl translates to a language that does not support underscore. Similarly, only the case identifier is not well used, which will cause problems in case in case insecure.
8, SII (Static Invocation Interface) Static Call Interface: A static interface between the client, the customer and the ORB.
9, SSI (Static Skeleton Interface) Static Frame Interface: A static interface located between the server side, the ORB and the server.
10, STUB stub: Located in the client, compile the IDL file by the IDL compiler, and its function is similar to a customer agent.
11, Skeleton Frame: Located on the server side, compile the IDL file by the IDL compiler, which is responsible for sending an operation call to implement this service.
12, IR (Interface Repository) Interface Repository: The IDL specification required to store the runtime. 13, IMR (Implementation Repository) implements repository: Details of storage object implementation (a server) (ie, one executor needs to be placed on which server).
14. Giop (General Inter-ORB Protocol) A protocol between Universal ORB: Defines an interface between different ORBs. Giop is the core part of the CORBA method call. Giop is not based on any special network protocol, such as IPX or TCP / IP. To ensure interoperability, the OMG must define the Giop defined above specific transmissions supported by all vendors. If there is a detailed and concise message specification, interoperability is not provided because all vendors use different transfer mechanisms to implement this interoperability.
15. The protocol between IIOP (Internet Inter-ORB Protocol) Internet ORB: IIOP maps Giop message data to TCP / IP connection behavior and input / output flow / write. OMG standardizes GIOP on the most widely used communication transmission platform - TCP / IP. Giop plus TCP / IP is equal to IIOP! It's that simple.
Note: IIOP is not a protocol that is completely separated from Giop, which is more like a Giop instance.
16, IOR (Interoperable Object Reference) Operable Object Reference: It includes all the information required to contact the server (including the IP address of the CORBA server object process and TCP port, etc.), the ORB will generate it only on the network. Identify the message that will be distributed.
17. Orbaservices CORBA Services: On the ORB level, it defines the public services used by most distributed enterprise objects.
Such as:
Naming service
Trading object service
Relationship service
Lifecycle service
Outerization service
Persistence service
Query service
Object Collection Service
Property service
Event service
License service
Time service
Transaction service
Concurrent control service
Security service
18, Corba Facilities Corba Plant: Located on Corba Services defines a higher level of distributed service and framework. Such as: printing, email, document management, etc.
The picture below is a framework of CORBA:
Figure
2-1 CORBA Frame
2.2 Overview of CORBA Architecture
The CORBA specifications make full use of the latest achievements in the development of today's software technology, implementing integration of application software in a network-based distributed application environment, making it reusable, portable and interoperable in distribution and heterogeneous environments. Its characteristics can be summarized as the following aspects:
The core of CORBA is a set of standard language, interfaces, and protocols to support interoperability between heterogeneous distribution applications and objects independent of platforms and programming languages.
Introducing Middleware (MiddleWare) as a transaction agent, completes the service request proposed by the client (CLIENT) (introducing the middleware concept after the introduction of the middleware concept is shown in Figure 2-2);
Figure 2-2 Relationship between the client and the server is introduced into the middleware
2. Realize the complete separation of customer and service objects, customers no longer need to understand the implementation process of the service object and the specific location (see the CORBA system architecture shown in Figure 2);
3. Provide soft bus mechanisms such that in any environment, software developed by any language can be integrated into a distributed system as long as it meets the definition of the interface specification;
4. The CORBA Specification Software System uses object-oriented software implementation methods to develop application systems, realize the full package of internal details, retention the external interface definition of the object method.
In the above features, the most prominent is the introduction of the middleware, referred to as the object request agent (ORB, Object Request Broker) and an object-oriented development mode in the CORBA system. Object models are specific abstractions for applying developers' properties and functions of objective things. Since CORBA uses an object model, all applications in the CORBA system are viewed as a collection of objects and related operations, so through the object request Agent (ORB), the acquisition of the application objects distributed in the network in the CORBA system depends only on the network. The exact degree of smoothness and service object feature acquisition is independent of the location of the object and the device environment where the object is located.
Figure 2-3 CORBA system architecture
The main contents of the CORBA system include the following parts:
(1) Object Request Broker: The object is responsible for transparently transceiving requests and responses in a distributed environment, which is a basis for building distribution object applications, implement inter-application interoperability in heterogeneous or homonomers.
(2) Object Services: These services should be independent of the application domain for use and implementation of the basic object collection. The main CORBA services include: Naming Service, Event Service, Lifecycle Service, Relationship Service (Transaction Service), etc. These services almost include all aspects of the distribution system and object-oriented systems, each component is very complicated.
(3) CommON Facilitites: Provide a set of shared service interfaces to end users, such as system management, combined documents, and email.
(4) Application Interfaces: Products that can control their interfaces, corresponding to traditional application layers, the highest layer in the reference model.
(5) Domain interfaces: Interfaces provided for application areas. For example, the OMG organization is a specification established by the PDM system.
Corba has its own specific background, which is in the object-oriented technology, and the customer / server mode is generally applied. To shield communication and implementation requirements, inherit existing systems, eliminate "Island" phenomenon of. He made up for the shortcomings of traditional distribution systems (such as RPC, etc.), with many new features:
(1) Introduced the agent (Broker) concept. The agent acts as follows: Complete mapping of abstract service requests for the client; automatically discover and find the server; automatically set the route, implement the execution of the server program.
(2) The client program is completely separated from the service program. It is very different from traditional customer / server methods, and customers will no longer have direct contacts with the server, but only need to contact the agent, and the customer and server side can easily upgrade.
(3) Provide "software bus" mechanism. Any application system can easily integrate into the CORBA system as long as you provide a set of interface specifications defined by the CORBA system. This interface specification is independent of any language and environment. In this way, the customer is applied to the service object to be transparently interacting, and the application software "plug and play" on the "Software Bus".
(4) The layered design principles and methods are implemented. The underlying core of the CORBA system is a refined system, various complex systems and applications can be extended and extended by cores.
CORBA technology is the result of advanced technology development. It combines object-oriented concepts into distributed calculations, making the CORBA specification into industrial standards for open, customer / server mode, object-oriented distribution calculations.
