OMG CORBA components technology system
Author: Yu Jia
Email: jia_yu@263.net
[All rights reserved of any form of copying and reference must be licensed]
1. CORBA Overview
Object Management Group is an industrial standardization organization that develops practical distributed object technology and its object management specification as a task, the basic goal of OMG is to establish a general integrated framework for application systems, in distributing heterogeneous environments A reusable, portable and interoperable, non-profitable international organization consisting of more than 600 information system manufacturers, software developers and users, is established in 1989, which is established in 1989, and OMG formulated.
In 1990, the OMA object management architecture has been released.
1992 CORBA 1 .0
1996 Corba2.0
Corba2.2 in February 1998
1999 CORBA3.0 makes CORBA enters the componentized architecture
The CORBA (Common Object Request Broker Architecture) is based on the distributed object standard of an abstract object model. Under the support of the distributed software bus, the communication and system integration between the object-oriented software components in the distributed heterogeneous environment is integrated. Express the application system, the connection technique of effective communication between application components.
The high-level protocol of the distributed computing of CORBA, located in the application layer of the ISO / OSI seven-layer model, which is object-oriented to hide the difference between different programming languages, operating systems, object locations, and the like. CORBA object-oriented methods make different types of implementation on the same layer. It uses an OMG IDL interface definition language for portability interface definitions.
(1) Architecture model of CORBA specification
Understanding the key to the structure of CORBA is the relationship model, its relationship model includes the following ingredients:
Object Request Agent (ORB). It enables objects to establish and receive requests and answers in a distributed environment. It is the basis for establishing distributed object applications and is also the basis for interactivity between the heterogeneous and group environments.
Object Services (OS). It is a collection of services that support the basic functions of use and implement objects. Establishing any distribution applications requires an object service, which is often independent of the application domain. For example, lifecycle service defines the conversion of establishment, deleting, copying, and moving objects, but does not indicate how objects are implemented in an application. The object service specification is included in the Public Object Service Specification (COSS) of the CORBA service.
General facilities (CF). It is a service collection for end user applications, for example, a system management or email device can be divided into a general facility.
Applications Objects (AO). It is a single vendor for controlling the interface. Application objects follow traditional application concepts, so they are not normalized by OMG. The application object constitutes the highest layer of the relational model. The relationship model of the CORBA specification is shown in Figure 1:
Figure 1 Relationship model of CORBA specification
In the four parts shown in the figure, the object request agent is the core of the relationship model. It is like a telephone switch that provides the basic mechanism for creating and receiving calls. ORB combines with the object service to ensure effective communication between the application components that meet the CORBA specification.
(2) Basic concepts in the CORBA specification
In order to truly understand the CORBA specification, we will first describe some of the basic concepts in CORBA.
Object. An object system includes a plurality of object entities. An object is a packaged entity that provides one or more services to the customer request. In the distributed environment of ORB support, an application can consist in many objects, through the interaction between objects, and the interaction between the objects is passed through ORB.
request. The customer is required to be served by constructing a request, and the requesting party is called a customer in the CORBA specification. In the request, you want to specify an object implementation, execution of the service, execution, and the parameters used in the context and the operation. Object reference. This is the identifier of the object to specify the object is called an object reference, and an object can have multiple object references, but an object reference only corresponds to a unique object. Object implementation. In the CORBA specification, the service provider is an object implementation, which uses the interface to describe the operations that can be performed on it.
method. An executable code corresponding to a certain operation described in an object implementation is called a method. Make a method to act activate.
activation. When a service request is performed, the method in the object or object implementation is called, if the object or object implemented initial state does not meet the requirements of the method call, it is necessary to change its status by way of a method to meet the method call. Requirements, this process is called activation, the opposite process is called to live.
(3) Object Request Agent (ORB) structure
ORB is the core of the CORBA specification, providing a number of mechanisms, which are used to receive requests, positioning requests, or to prepare data communication with components, etc.. The interface you see is completely independent of the location of the object, and it is also independent of the programming language it implements. Object requests the architecture of the agent. See Figure 2.
As shown in Figure 2, the architecture is composed of a single ORB consisting of a dynamic call interface (DII), IDL pile, an ORB interface, a static IDL frame, a dynamic frame interface, and an object adapter, which gives a set of interfaces to support application objects. Among them, IDL piles, dynamic call interface, orb interface (provided by ORB kernel) can be used by customers, called customer interface; IDL framework, dynamic frame interface, object adapter, orb interface can be used for object implementation, called object implementation Foundation interface.
In order to create a request, the client is used to use a dynamic call interface (independent of the destination object interface) or an IDL pile (depending on the special pile of the target interface). Customers can also interact with ORBs for some features.
Figure 2 ORB architecture
Object implementation receives a request as two modes, that is, the frame generated by IDL, or through a dynamic frame. When the request is processed, the object implementation can be implemented by calling the object adapter and the ORB.
Different ORBs can do different implementation options, and the IDL compiler, libraries, and different object adapters provide a service to customers. There can be multiple ORB implementations, which have different representations for object references, and there are different ways to perform calls. Customers can access two object references that are managed by different ORBs. When two ORBs work together, these ORBs must distinguish their object references this is not the customer's responsibility.
The ORB kernel is part of the ORB that provides basic object representation and request communication. CORBA is designed to support different object mechanisms, which is implemented by components over the ORB kernel, which provide interfaces that mask the difference between the ORB core.
(4) Implementation of customer interface and object implementation interface
(4.1) Client interface implementation The customer interface consists of IDL pile, dynamic call interface, ORB interface, and customers can obtain services provided by ORB and object implementation through these interfaces. The customer's way of accessing the object server through the ORB visits. The client creates a request by accessing the object reference and the type of object to grasp the type of object you want, which initiates a request by calling a dedicated pile program corresponding to the object or by dynamically create a request. The dynamic interface for calling a request and the pile interface can satisfy the same request syntax. The recipient of the information does not have to indicate which way the request is called.
Figure 3 Customer Access Object Services via ORB
The following describes the IDL piles in the client interface, and the dynamic call interface, and the ORB interface are described below.
IDL pile. The IDL pile represents the access to an OMGIDL definition operation on an object, which defines how the customer activates the corresponding service. The IDL pile is generated by the IDL compiler to compile the specific IDL interface. When the client program issues a request, it issues a call request through the private interface with the ORB kernel. This static call mode is only possible when compiling, the IDL interface is known. In contrast, if the object implementation is known when running, use a dynamic call interface to dynamically construct a request. Dynamic Call Interface (DII). The interface also allows the dynamic creation of the object call. The dynamic call interface is not called a pile program that performs special operations on the specified object, but a customer indicates the object being called by one or more calls, the operation and call operation to be executed. Parameters, etc. This is in some special applications, customers discover service, get interface, dynamic construct requests at runtime, so that the client calls the object implementation. Customers create an ORB request through function create / request, but actual calls are done by the function invoke and send / get response. Invoke is a normal request call. Returns the end of the operation; the send function is a delayed synchronization operation, and the request is immediately returned immediately, and then perform the next step. Get / Response is used to obtain operational execution.
ORB interface. The ORB interface is directly reached to the ORB interface, which is the same for all ORBs, and does not rely on the object's interface or object adapter. Since most ORB functions are provided by object adapters, piles, contours, or dynamic calls, only a few operations are common for all objects, which are useful for customers and object implementations. The ORB interface is also seen for the client and object implementation. It provides some functions that can only be provided by the ORB kernel, including object reference operation, ORB initialization, object adapter initialization, and get initial object references.
(4.2) Object implementation interface implementation
The object implementation interface includes a static IDL frame, a dynamic frame interface (DKI), an object adapter, orb interface. It connects the specific object implementation and ORB to make the ORB to call the specific implementation of the object. The ORB interface of the object implementation is consistent with the client's ORB interface. ORB access object implementation can be represented by Figure 4.
Figure 4 ORB Access Object Implementation
ORB is implemented by an IDL contour or a dynamic contour positioning implementation code, transmission parameters, and transfer control to object implementation. The outline is specific for the interface and object adapter. When performing a request, the object implements some service from the ORB through the object adapter. The control and output value are returned to the customer when the request is completed. Object implementation can select the corresponding object adapter based on the type it needs.
Static IDL frame. The static IDL framework is an interface that calls an object implemented by the ORB generated by the IDL compiler. Through it, you can use the method in the object implementation in the ORB to implement the specific implementation routine based on the interface. The existence of the IDL frame does not mean there is a corresponding customer IDL existence. The ORB can also use the IDL framework to call the object implementation method, and the object adapter can be used to call the method. Special language mapping can be implemented on the object adapter because it has an interface to the object.
Dynamic Frame Interface (DKI). The dynamic frame interface is an interface that allows dynamic processing object calls, ie, is not to access object implementations by the contour associated with the specific operation, but by an interface to provide an operation name and parameter, an interface similar to a dynamic call interface is accessed. Object implementation. Both the customer pile or dynamic call interface can call the dynamic frame interface. The basic idea of the dynamic frame interface is on the specified object, allowing the ORB to call the same toner DIR (dynamically subroutine) to implement all requests, while the object implementation only needs to give a specific implementation routine according to DIR.
Object Adapter (OA). Object adapter is the main way for objects to access ORB-providing services. The services provided by ORB often include: the generation and interpretation of the object, the method call, the security of the interaction, the activation and release of the object, and the implementation, the object reference to the implementation of the implementation. Due to the particle size, life cycle of each different object, the ORB kernel cannot provide a unified and efficient interface for all objects. We can divide the destination object into several groups, served by the specific object adapters. However, in order to reduce the type of object adapter, the CORBA specification gives the basic object adapter (BOA) to meet the needs of most objects. BOA provides a function of generating and interpreting objects, authenticating requests, activating / deactivating implementation, activating / deactivating a single object, and passing a frame call call. When providing these features, BOA is used to use some knowledge related to the operating system, which is provided by the realization of the warehouse, and realizes the information of the warehouse also stores object implementations.
(5) IDL and its mapping to programming language
(5.1) OMG IDL (Interface Definition Language) OMG interface definition language (OMG IDL) is a neutral language specified in the CORBA specification, which is used to describe the interface and object implementation provided by customer object calls, but not involved The specific implementation of the object. OMG IDL defines the type of object by indicating an object's interface. Users using the IDL interface can determine how to issue requests and reception responses based on the information in the IDL interface, so that the customer object is completely independent of the location and programming language used by the specific object. The syntax of the IDL, the lexical rules are basically followed by C grammar, semantic specification, just add some keywords that support the distribution concept.
IDL is a way, through it, the specific object implementation tells its client to apply and how to call these operations. IDL definitions can map CORBA objects to special programming languages or object systems. IDL is completely a descriptive language that cannot be used to implement a client. In order to enable objects to be uniformly using IDL interface information, CORBA specifies the map of IDL to specific languages.
(5.2) OMG IDL to the mapping of programming language
Different object-oriented or non-directional programming languages can access CORBA objects in different ways. For object-oriented languages, you need to see the CORBA object as a programming language object; for the language of the non-objective object, a good way is to represent the CORBA object with the other object reference, the method name of the method name.
OMG IDL to each programming language Special Mapping is the same for all ORB implementations, language mapping includes definitions of language-specific data types and definitions of process interfaces of ORB access objects, including customer pile interfaces The structure, dynamic call interface, the structure of the contour, the structure of the object adapter, and the structure of the direct ORB interface.
Each language mapping also defines interactions between object references and thread control in the customer. The most common mapping provides synchronous calls. In this synchronization call, the subroutine is returned when the object operation is completed. Additional mappings can be provided for allowing starting a call and control to return to the program. In this case, the additional special language subroutine must be provided for thread control and object calls for synchronization programs.
Full language mapping allows programmers to use a particular programming language to easily call all ORB support functions, all ORB implementations for a particular language must support the same IDL mapping to enable the program to achieve the source code. Level portability. The mapping specifications for IDL to C, C , and SmallTalk languages are developed in the CORBA specification.
(6) Interoperability between ORBs
Due to the promotion of CORBA1.0, a variety of ORB products that have different performance indicators have different performance indicators, in order to allow them to share them in a distributed environment, CORBA 2.0 increases the ORB interoperability specification. Two concepts --orb services and ORB domains are introduced in the ORB interoperability specification. The so-called domain refers to such a range that has a common feature, obedient from the same rule. Interoperability between ORBs is the mechanism of mutual identification and conversion of mutual identification and conversion for different implementation ORBs. From the strategy, it is divided into indirect and direct two bridge mechanisms, and from the implementation level, it can be divided into two bridges inline bridge and request layer bridge: line bridge refers to performing necessary turns in the ORB inside. Code mapping; request layer bridge refers to execution request conversion and code mapping outside ORB. In order to implement inter-ORB interoperability, the CORBA specification also defines Giop protocols and IIOP protocols. The Giop protocol is used to specify the standard transport semantics and message format sets between orb, and the IIOP protocol is used to indicate how to use TCP / IP connections to exchange Giop messages, which is a standard interactive protocol for Internet. Add the ORB interoperability specification to the ORB architecture, which causes some changes in the internally performing ablation in the ORB.
(7) Application prospects for CORBA specifications
With the launch and continuous improvement of CORBA specifications, there are many computer suppliers and researchers in the world to conduct in-depth research and specific implementation of CORBA specifications. Today, CORBA-based products are more and more, and the famous is the following Three types:
(7.1) Visigenic Visibroker where Visibroker -forjava is a development tool for establishing, managing, and development of Java applications that are open-multiple platform interoperability. VisibrokerForc is a perfection. CORBA 5.0 ORB implementation, it is a development tool for establishing, managing and developing a C app that is open across multiple platform interoperability; VisibrokernamingService implements C and Java to implement CORBA naming service specification, which developers can Register the object name at runtime. VisibrokereventService completely implemented C and Java fully implemented CORBA event service specification. Various Visibroker products can run on a variety of platforms such as Windows 95, WindowsNT, and UNIX.
(7.2) Digital's ObjectBroker fully implements the CORBA 1.1 specification, including static IDL piles, dynamic interface calls, static IDL frameworks, dynamic frame calls, interfaces, and realization warehouses, etc., it can run on multiple platforms and implemented IDL Language to C language mapping.
(7.3) IBM's DSOM IBM DSOM is based on its SOM, SOM is available in the form of a library toolbox. It can be used to easily create a binary library required for application. DSOM provides a distributed framework, using SOM Toolbox to implement ORB. With the development of network distributed technology, CORBA-based products are increasingly applied, and CORBA standards solve diversity problems between different CORB A products and interoperability between them.
With the development of Internet / Intranet technology, distributed object technology will play an important role in future Internet / Intranet technology, and give new content based on Internet application integration technology. Netscape has decided to use OMG's CORBA technology to implement object visits on the Internet. The NEO and its Joe launched by Sun also work hard toward this direction because it can not only use the infrastructure of the new Internet client / server application, but also effectively integrated with existing applications and data. . In summary, the CORBA specification will play an increasingly important role in future system integration and application development environments, we should carefully study the CORBAA specification, thus implementing software in distributed heterogeneous environments on the basis of applying Corbaa specification technology. The component's "Plug and Play" feature enables existing applications and system software to be reasonable, efficient, and used to meet different needs.
Attached CORBA Specification (Version 2.3.1).
Part 1: CORBA CORE
Chapter II: Object Model, Describe the Calculation Model in the CORBA Environment
Chapter II: Corba Summary, Description ORB Structure, and Interface, Implement Information
Chapter III: OMG IDL Lexist and Semantics, Description OMG IDL, IDL is used to describe client object calls, interfaces provided by object implementation
Chapter 4: ORB Interface, Defining ORB does not depend on the function interface of the object adapter
Chapter 5: Value type semantics, describes the semantics of the value of the value.
Chapter 6: Abstract Interface Semantics, explaining an abstract interface, which provides a delay to runtime to determine the object by reference or value.
Chapter 7: Dynamic Call Interface (DII), client interface allows for dynamically creation and issuing an object.
Chapter 8: Dynamic Skeleton Interface (DSI), server-side interface, can be issued from ORB to objects, which does not have compiled knowledge of the object type it implements.
Chapter 9: Any Values Dynamic Management, Description Dynamic Any Values interface.
Chapter 10: Interface Pool, describing an component of ORB, managing and providing access to an object definition collection.
Chapter 11: Portable Object Adapter (POA), defines a set of IDL interfaces to implement them to access the ORB function.
Part II: CORBA interoperability
Chapter 12: Summary of Interoperability
Chapter 13: ORB Interoperability Architecture
Chapter 14: Building an ORB Interoperable Bridge
Chapter 15: General Inter-ORB Protocol (Giop)
Chapter 16: DCE ESIP - Environment-Specific Inter-ORB Protocol (ESIOP)
Part III: CORBA Collaboration
Chapter 17: Collaborative Architecture
Chapter 18: Mapping: COM and CORBA
Chapter 19: Mapping: Ole Automation and Corba
Chapter 20: Interoperability with non-CORBA systems
Chapter 21: Interceptors
