2.3.1 ORB structure
Figure 2-4 Request by orb
Figure 2-4 shows a client to send a request to an object. Client is an entity that wants to operate on objects, and the object entity is code and data that implements an object. ORB is responsible for locating an object according to a request, and arranges object implementation to accept requests, communicating with requested data. The client's interface is completely, and the language of the object is realized, and other aspects that are not reflected in the object interface.
Figure 2-5 shows the structure of a single ORB. Use the rectangle frame of the oblique provision to represent the interface of the ORB, the arrow indicates that the information calls the ORB or ORB to transfer the information upward.
Figure 2-5 ORB interface structure
CLINET issues a request using Dynamic Invocation Interface (independent of the interface of the target object) or OMG IDL Stub (STUB related to the target object interface). For some reason, Client can also contact ORB directly. The object implements Skeleton or dynamic SKELETON generated using OMG IDL to accept requests in a UP-CALL. Object implementations can also call Object Adapter and ORB. You can define object interfaces in two ways: First, use OMG Interface Definition Language (OMG IDL) to define interfaces. This language defines object types based on the operations that may be performed on objects and parameters used by these operations. The second method is to put the interface (interface) into the interface repository service; the service describes the elements in the interface into an object. Any software that enables ORB, Interface Definition Language (possibly based on the content of the document) and Interface Repository have the same role. A client To complete the request with Object Reference, it must know the type of object and the specific operation. The Client initialization request has two methods. One is to create a dynamic creation request by calling the Stub Routines of the target object (shown in Figure 2-6).
Figure 2-6 Client Using Stub or Dynamic Invocation Interface
Regardless of using Stub or Dynamic Invocation Interface, the request has the same semantics, the recipient of the information cannot tell which method is to be delivered. ORB determines the appropriate implementation code, pass the parameters, transmits the control to the Object Implementation by IDL Skeleton or Dynamic Skeleton (as shown in Figure Figure 2-7). Each interface and Object Adapter use different Skeletons. In order to complete the request, Object Implementation may use Object Adapter to use services from ORB. The control and output result return to the client when the request is completed.
Figure 2-7 Object Implementation Accept request
Object Implementation Select what Object Adapter used. It is determined by the type of Object Implementation requires services. Figure 2-7 shows how Clients and Object Implementations use interfaces and implementations. Use OMG IDL or Interface Repository to define an interface; this definition is used to generate Client Stubs and Object Implementation Skeletons.
Figure 2-8 Interface and Implementation Repositories
Put the Object Implementation information in the Implementation Repository in installation to use.
2.3.2 Main components in the ORB structure
Figure 2-9 CORBA ORB structure
Object Implementation: It defines the operation of implementing a CORBA IDL interface. It can be written in various languages such as C, C , Java, SmallTalk, and ADA. Figure 2-10 Typical Object Implementation Structure
Client: This is a program entity that calls an object implementation in an object. To call this, accessing the remote object server should be transparent. It should be as simple as the method in the call object, such as OBJ-> OP (ARGS).
The client can only understand the logical structure of the object according to the interface of the object, although we generally regard the client as a program or a process, but knowing a client is related to an object. For example, an implementation of an object may be a client of other objects.
Figure 2-11 Typical Client Structure
Client uses objects and ORB interfaces through language mapping. When this mapping relationship changes, it is not necessary to change the client. Client does not need to understand the implementation of the object, the object adapter and ORB.
Object Request Broker (ORB):
ORB provides a mechanism that enables transparent communication between the Client request and the target object implementation. It makes the Client request as a local process call. When a client references an operation, orb is responsible for finding an object implementation, if you need to activate it, then submit the request to the object, and finally returns to the caller. When implementing, the ORB can be not as a single ingredient, but it can only be defined by its interface. The interfaces provided by any ORB implementation are acceptable. You can divide the operation in the interface into three categories:
1. Operation is the same for all ORB implementations
2. Action of specific types
3. Take a specific category with the object
Different ORBs have different implementations, but they all include: IDL compiler, repositories, various Object Adapters, providing various service sets to Client, object implementation with different attributes, etc.
There are now a variety of different ORB implementations. A Client can access two object references managed by different ORB implementations (Object References) When these two ORBs need to work together, they can distinguish their object references. Client does not need to be responsible for it. ORB CORE is an component of ORB that provides basic representation of an object and communication with requests.
There are four different types of ORBs:
1. Client- and importation-resident orb
2. Server-based ORB
3. System-based ORB
4. Library-based ORB
ORB Interface:
An ORB is a logical entity that can be implemented in various ways (such as one or more processes, or a libraries collection). In order to mitigate the difficulties of writing, the CORBA specification defines an abstract interface. This interface provides a variety of help functions.
Corba IDL Stubs and Skeletons:
It is equivalent to "glue" between the Client, Server applications and ORBs. The CORBA IDL compiler automatically implements the conversion between the CORBA IDL definition and the target programming language.
Using a compiler can reduce the potential contradiction between Client Stub and Server Skeletons.
Dynamic Invocation Interface (DII):
This interface allows Client to directly call ORBs to provide the most underlying requesting mechanism. The application uses DII to dynamically transmit request to objects without requiring IDL interfaces (including specific stubs). Unlike IDL Stub (which only allows RPC mode), DII also allows Clients to use a blockless delay synchronous call (send operation is independent) and one-way call (send-only). Dynamic Skeleton Interface (DSI):
Similar to the CLIIT side, the interface located in the Server end. The DSI allows ORB to send requests to object implementations, which do not include the types required for compilation. A request for the request does not know that the implementation is the use of the IDL SKELETONS or use dynamic Skeletons.
Object Adapter:
It helps ORB to transmit requests to objects and activate the object. More importantly, an Object Adapter is always connected to an object implementation (Object Implementations). Object Adapter can be defined to support specific object implementation types (such as OODB Object Adapters for continuous objects (Persistence) and Library Object Adapters is used for non-remote objects).
Figure 2-12 Typical Object Adapter structure
Its role is:
(1) Produce and interpret object reference
(2) Method call
(3) Safety of interactions
(4) Implementation and revocation of objects and activation
(5) Implement the object reference to the corresponding object
(6) Register object implementation
