The CORBA specification defines an architecture of interfaces and services that must be provided by the ORB, no implementation details. These are modular components so different implementations could be used, satisfying the needs of different platforms.
The ORB manages the interactions between clients and object implementations. Clients issue requests and invoke methods of object implementations.
The client side architecture provides clients with interfaces to the ORB and object implementations. In consists of the following interfaces : Dynamic Invocation - This interface allows for the specification of requests at runtime. This is necessary when object interface is not known at run-time. Dynamic Invocation works in conjunction with the interface repository. IDL Stub - This component consists of functions generated by the IDL interface definitions and linked into the program. The functions are a mapping between the client and the ORB implementation. Therefore ORB capabilities can be made available for any client implementation for which there is a language mapping. Functions are called just as if it was a local object. ORB Interface - The ORB interface may be called by either the client or the object implementation. The interface provides functions of the ORB which may be directly accessed by the client (such as retrieving a reference to an object.) or by the object implementations. This interface is mapped to the host programming language. The ORB interface must be supported by any ORB.
ORB core - Underlying mechanism used as the transport level. It provides basic communication of requests to other subcomponents.
The implementation side interface consists of the ORB Interface, ORB core and: IDL Skeleton Interface - The ORB calls method skeletons to invoke the methods that were requested from clients. Object Adapters (OA) - Provide the means by which object implementations access most ORB services. This includes the generation and interpretation of object references, method invocation, security and activation. The object adapter actually exports three different interfaces: a private interface to skeletons, a private interface to the ORB core and a public interface used by implementations. The OA isolates the object implementation from the ORB core. The CORBA specification envisions a variety of adapters, each providing specific services. The Basic Object Adapter (BOA) is the most generic of the Object adapters.
The client has an object reference,an operation name and a set of parameters for the object and activates operations on this object. The Object Management Group / Object Model defines each operation to be associated with a controlling parameter, implemented in CORBA as an object reference. The client does not know the location of the object or any of the implementation details.The request is handled by the ORB, which must locate the target object and route the request to that object. It is also responsible for getting results back to the client.
The request makes use of either the dynamic invocation (dynamic link) or the IDL Stubs (static link) interface. Static links use the IDL stubs IDL stubs (as local function calls) and dynamic request use the DII . The object implementation is not aware of the difference. If the interface was defined in the IDL and the client has an interface for the target object the IDL stub is used. This stub is specific to the target object. The DII is used when the interface is not known at runtime. The DII uses information stored in the interface repository to establish the request. Request are passed from the ORB to the object implementation through the IDL skeleton. The object implementation is made available by using information stored in the implementation repository. The object implementations encapsulate state and behavior of the object. CORBA only defines the mechanisms to invoke operation, it does not define how activated or stopped, made to persist, etc.
The client side architecture provides clients with interfaces to the ORB and object implementations. In consists of the following interfaces : Dynamic Invocation - This interface allows for the specification of requests at runtime. This is necessary when object interface is not known at run-time. Dynamic Invocation works in conjunction with the interface repository. IDL Stub - This component consists of functions generated by the IDL interface definitions and linked into the program. The functions are a mapping between the client and the ORB implementation. Therefore ORB capabilities can be made available for any client implementation for which there is a language mapping. Functions are called just as if it was a local object. ORB Interface - The ORB interface may be called by either the client or the object implementation. The interface provides functions of the ORB which may be directly accessed by the client (such as retrieving a reference to an object.) or by the object implementations. This interface is mapped to the host programming language. The ORB interface must be supported by any ORB.
ORB core - Underlying mechanism used as the transport level. It provides basic communication of requests to other subcomponents.
The implementation side interface consists of the ORB Interface, ORB core and: IDL Skeleton Interface - The ORB calls method skeletons to invoke the methods that were requested from clients. Object Adapters (OA) - Provide the means by which object implementations access most ORB services. This includes the generation and interpretation of object references, method invocation, security and activation. The object adapter actually exports three different interfaces: a private interface to skeletons, a private interface to the ORB core and a public interface used by implementations. The OA isolates the object implementation from the ORB core. The CORBA specification envisions a variety of adapters, each providing specific services. The Basic Object Adapter (BOA) is the most generic of the Object adapters.
Request
The client request a service from the object implementation. The ORB transports the request which invokes the method using object adapters and the IDL skeleton.The client has an object reference,an operation name and a set of parameters for the object and activates operations on this object. The Object Management Group / Object Model defines each operation to be associated with a controlling parameter, implemented in CORBA as an object reference. The client does not know the location of the object or any of the implementation details.The request is handled by the ORB, which must locate the target object and route the request to that object. It is also responsible for getting results back to the client.
The request makes use of either the dynamic invocation (dynamic link) or the IDL Stubs (static link) interface. Static links use the IDL stubs IDL stubs (as local function calls) and dynamic request use the DII . The object implementation is not aware of the difference. If the interface was defined in the IDL and the client has an interface for the target object the IDL stub is used. This stub is specific to the target object. The DII is used when the interface is not known at runtime. The DII uses information stored in the interface repository to establish the request. Request are passed from the ORB to the object implementation through the IDL skeleton. The object implementation is made available by using information stored in the implementation repository. The object implementations encapsulate state and behavior of the object. CORBA only defines the mechanisms to invoke operation, it does not define how activated or stopped, made to persist, etc.
Object Adapters
Object Adapters (OA) are the primary ORB service providers to object implementations. OA have a public interface which is used by the object implementation and a private interface that is used by the IDL skeleton.- Example services provided by OA's are:
- Method invocation ( in conjunction with skeleton),
- Object implementation activation and deactivation,
- Mapping of object reference to object implementations,
- Generation of object references, and
- Registering object implementations, used in locating object implementations when a request comes in.
Object references
Request are issued upon object references. Object references are opaque references only uniform within an ORB implementation. Since both clients and servers using objects references as opaque references, different representation will not affect them. CORBA does have an object reference that is used to denote no object. It is guaranteed to be different from any other object reference, and usually maps to the null or nil object.Object Services
Object services refer to fundamental services provided by their own objects that support common interactions between other objects. The services follow the OMG Common Object Services Specification (COSS) guidelines. Current object services include:- Event Management services which refer to the asynchronous communication of different CORBA objects with one another.
- Naming Object services that maps a human-readable name ( string) to an object relative to its context.
- Persistent services assure that an object (CORBA developed) outlives its creator. It allows an objects state to be retained at a given point in time. This feature is used when a host crashes or is rebooted.
- Life-cycle services determine the methods for an objects creation and termination.
- Concurrency services provide for distributed locks on a given object.
- Externalization services collect objects and transport them as serial objects.
- Relationship Objects are used for CORBA object modeling and graphing.
- Transaction object services allow the sharing of a transaction amongst multiple objects.