2.3.3 System Integration
Figure 2-13 Method for integrating different object systems
2.3.4 Interoperability
ORB interoperability provides a way to understand objects in the network, which are managed by diverse, different kinds of (compatible with CORBA). Since elements in CORBA can be combined in many ways to meet a variety of different needs, it is convenient to obtain "interorbability".
Support interoperability elements
Elements that support interoperability are:
ORB interoperability structure
2. Inter-ORB Bridge Support (Bridge Support)
3. General and Internet Inter-ORB Protocols (Giops and IIOPS)
Moreover, this structure also supports Environment-Specific Inter-ORB Protocols (ESIP), which optimizes specific areas such as DCE)
ORB interoperability structure
This structure introduces two concepts of IMMEDIATE AND MedIated Bridge in the ORB domain. IIOP is the basis for WAN bridges. The Inter-ORB bridge can be used to directly bridge, and can also be used for "half bridge connections" and use half bridges to build for indirect bridging. Use these bridge techniques, orb can interoperate without the need to know each other's implementation details, such as what special IPC or protocol (such as ESIP) to implement the CORBA specification.
Use "half bridge connections" that can communicate with IIOP, two or more ORBs can bridge each other. This approach can be used for stand-alone ORBs, and can also be used in network ORBs such as ESIP. IIOP can also be used to implement internal messaging mechanisms in ORB.
Inter-ORB Bridge Support
The interoperability structure explicitly points out the role of different domains in ORB, including object reference domains, type domains, security domains (such as the Scope of a Principal Identifier, " Transaction Domain, etc.
When two ORBs are in the same domain, they can communicate directly, in most cases, this is a good way. However, since each institution needs to build the respective control fields, this method is not commonly used. When the information needs to leave its domain, you must use bridge to pass information. The role of bridging is to ensure that the information is fully mapped from an ORB to another. Inter-ORB Bridge Support also provides interoperability with non-CORBA systems such as Microsoft's Component Object Model (COM)).
General Inter-ORB Protocol (Giop)
The General Inter-ORB Protocol (GIOP) component provides a standard transport syntax (low-layer data representation method) and information formatting in communication between ORBs. Giop can only be used between ORB and ORB, and can only be used in conjunction with the ideal condition. It does not need to use a higher level of RPC mechanism. This protocol is simple (as simple as possible, but not simplified), can be upgraded, easy to use. It is designed to be movable, high-performance performance, less dependent on other low-level transport protocols. Of course, because different transmission uses different versions of Giop, they may not work directly, but it can easily connect the network domain.
Internet Inter-ORB Protocol (IIOP)
The Internet Inter-ORB Protocol (IIOP) component indicates how Giop information is swapped through TCP / IP connection. IIOP provides the Internet with a standard collaboration work agreement that makes compatible ORBs can work based on the currently popular protocols and products to work with the "Out of the Box" mode. It can also be used in the agreement between the two semi-bridges (HALF-Bridges). This protocol can be used for collaboration between any ORB and IP (Internet Protocol), unless ORB selections a special protocol. At this time, it is the basic Inter-ORB protocol under the TCP / IP environment, the most common transport layer. The relationship between IIOP and Giop is like the relationship between special language and omg IDL; Giop can be mapped to different layers, which can specify protocols. Just like IDL can't see a full program, Giop itself cannot provide complete cooperation work. IIOP and other similar mappings on different transport layers, implement abstract giop definitions, as shown in Figure 2-14.
Figure 2-14 Inter-ORB Protocol Relationship
Environment-Specific Inter-ORB Protocols (ESIPS)
It proposes a solution for conditions using Environment-Specific Inter-ORB Protocols (ESIOPS).
Domain
The domain divides the elements in a system into several parts according to some feature. In this structure, the domain is a range, a collection of objects, objects are members of the domain, and these members have a common feature. It can be seen as an object, and its life may also be a member of other domains.
Figure 2-15 Various types of domains
The domain in CORBA is divided into the following sections:
Referencing Domain - Object reference
Representation Domain - Information Transport Syntax and Protocol
Network addressing domain - Network address range
Network connectivity domain - possible network information scope
Security Domain - Special Security Strategy
TYPE DOMAIN - Special identifier range
Transaction Domain - Specific Things Service
There are two ways to use the domain: one is embedded, one domain is included in another domain; the other is combined, and the two domains use. When interaction occurs on the boundaries of the two domains, you need to use a mapping mechanism (such as bridging) to deliver relevant elements at the boundary. There are two ways here, one is the indirect bridge, and the first bridge (IMMEDIAT BRIDGIN).
Figure 2-16 Two bridge technology is used between two domains
Mediated bridging
When using indirect bridging, on the boundaries of each domain, deliver elements related to domains in an negotiated, universal format. The indirect bridge can be observed from the following aspects:
(1) The application range of public formats may differ from private agreements in two ORB / domains.
(2) There may be multiple public formats, each format corresponds to an application purpose.
(3) If there are multiple alternative public formats, the option can be divided into two, one is static selection (between two ORB developers), and the other is dynamic selection (each object is selected).
(4) This method differs from the embedded compilation (compared to STUB) or a normal library code (such as encryption routine).
2. Immediate bridging
When using direct bridging, on the boundaries of each domain, the associated elements go directly from the internal format of one domain to another domain. The indirect bridge can be observed from the following aspects:
(1) This method has the possibility of optimization (at this time, interaction is not passed through a third party) but it is achieved by sacrificing flexibility and versatility.
(2) This method is usually only used in pure management (no exchange technology) that needs to be transmitted to the boundary. For example, when you need to deliver messages in two similar orb, you don't need to use universal indirect criteria.
In summary, when two ORB / domains use private mechanisms, it is difficult to distinguish between these two methods.
3. Inter-Domain FunctionAlity
Logically, whether it is indirect bridge or direct bridging, as long as an inter-domain bridge, it has an element in both domains. However, on the one hand, the domain can span the ORB boundary, and the ORB can also span the machine and system boundary; on the other hand, a machine or a process may span multiple ORBs. From an engineering point of view, this means that the elements in a domain clip adopt dispersed or pending distribution in accordance with the ORB or system. For example, if an ORB includes two security domains, the domain bival bridge can be implemented in the internal portion of the ORB. Similarly, there is also a bridge between two ORB or domains in a process or system. From engineering, in this case, the domain bival bridge is limited, it is limited to a single system or process. If all bridges are implemented in this manner, the collaboration between system or processes can only occur in a single domain or ORB.
4. Bridge level (Bridging Level)
Bridge can be in ORB or higher and implemented. They are called an in-line bridge and request-level bridge. Request-level bridges use the CORBA API, including the use of Dynamic Skeleton Interface, Accepts and Exfractions (Issue) requests. However, there is also an "implicit context" class, which is integrated with some references, holding ORB Service information such as things information and security information, and the usual API includes this class.
5. Bridge in the network
ORB in the network, we will introduce the concept of "Backbone" ORB. Whether it is a large network or a small-scale network, it is necessary. Large network manufacturers can define their central ORB, while small-scale networks choose a commercial ORB as its hub.
Figure 2-17 An ORB acts as a central, it connects other ORBs through a half bridge and a full bridge
This central structure is a standard network management technology. It can reduce bridges and meet the management of the Internet. For large networks, increasing the ORB bridge does not need to add new nodes (HOP) to the network line.
Bridging
1.in-line bridging (embedding bridge)
The code embedded in the bridge is in ORB, which is the necessary translation and mapping. It is the most direct method for two ORBs for bridging. It is similar to the structure of the overseas Chinese in the system in a single ORB (eg, indirectly uses some internal processing communication modes, such as network protocols). This shows that implementing the embedded bridge may modify some of the basic elements in the ORB, such as inserting a new internal processing communication mode. (Some ORBs are designed to make certain modifications). When using this method, use the integration of software elements at different levels to complete the desired bridge function:
(1) ORB provides additional or selectable services
(2) Additional or selectable Stub and Slex Code
Figure 2-18 Using the API Construction In-line Bridges in ORB
2. Request-Level Bridging Request grade bridging code is outside the ORB, which is the necessary translation and mapping. This method is also called "half bridge" by using a normal protocol (one element) of two orb (one element) provided by the network, shared memory, and other IPCs provided by the network, shared memory, and host operating system).
The basic principle of request grade bridge:
(1) Original request is passed to the proxy object in the client ORB.
(2) The agent object translates the request content (including target object reference) into a format that ORB (Server ORB) can understand
(3) Agent reference to the operation required on transparent service object
(4) Use the supplemental path to return the results to the customer a
Figure 2-19 Constructing Request-Level Bridges using public ORB API
CORBA CORE defines the following interfaces that use them to construct a request grade bridge:
(1) Dynamic Invocation Interface (DII) Allows the bridge to call an object reference, while the type of object reference is not required when the bridge is established.
(2) Dynamic Skeleton Interface (DSI) Even when the bridge is established, it is not known that the type of object reference is created, and the bridge is allowed to call the agent object reference.
(3) Interface Repositories bridges to get information to drive DII and DSI, including the type of operational parameters and return values and accidents.
(4) Object adapters (such as Basic Object Adapter) Create an object referenced by the object when booting the bridging and mapping object reference (dynamically transmitted from an ORB).
(5) Corba Object References provides actions that fully describe their interfaces and builds to map object references to their agents (or vice versa). Interface Repositories Although a given pool ID (such as interface type ID, an unexpected ID) or operation ID, the INTER ID, but the information in the interface pool connected to the half bridge can be different.
