Post on 20-Dec-2015
CORBA Framework Eelements 1
CORBA Framework Elements
Object Request Broker (ORB) This is the object manager in CORBA
Mechanisms for specifying interfaces Interface Definition Language (IDL) - for static interface definitions Dynamic Invocation Interface (DII) - lets clients access interfaces as first-class
objects at run-time from an Interface Repository.
Internet Inter-Orb Protocol (IIOP) A binary protocol for communication between ORBs. Was added in CORBA 2.0
CORBA Framework Eelements 2
Object Request Broker (ORB)
One standardised interface
One interface per object operation
ORB-dependent interfaceOne interface per object adapter
DynamicInvocation DynamicInvocation
ClientStubsClientStubs
ORBInterface ORBInterface
Implementation SkeletonsImplementation Skeletons
ClientClient Object ImplementationObject Implementation
ORB CoreORB Core
ObjectAdapter ObjectAdapter
There can be more than one object adapters
CORBA Framework Eelements 3
Object Request Broker (ORB) The Object Manager in CORBA Both on the client side and the server side (allows agents to act
as both clients and servers of remote objects) On client side the ORB is responsible for
accepting requests for a remote object finding implementation of the object accepting client-side reference to the remote object(converted to a language
specific form, e.g., a Java stub object) routing client method calls through the object reference to the object
implementation
On server side the ORB lets object servers register new objects receives requests from the client ORB uses object’s skeleton interface to invoke object’s activation method creates reference for new object and sends it back to client
CORBA Framework Eelements 4
Internet Inter-Orb Protocol (IIOP) CORBA specification is neutral with respect to network protocols
the CORBA standard specifies what is known as the General Inter-ORB Protocol (GIOP) GIOP is a high-level standard protocol for communication between ORBs not used directly; instead, it is specialized by a particular protocol that would then be
used directly
Internet Inter-ORB Protocol (IIOP) IIOP is the GIOP-based protocol for TCP/IP networks As of the 2.0 version of the CORBA specification, vendors are required to implement the
IIOP protocol
CORBA Networking Model CORBA applications are built on top of GIOP-derived protocols such as IIOP these protocols, in turn, rest on top of TCP/IP, DCE, or other underlying transport
protocol the network uses an application architecture can be designed to use a bridge that would interconnect, for
instance, DCE-based application components with IIOP-based ones.
CORBA Framework Eelements 5
Internet Inter-Orb Protocol (IIOP)
ORBORB
OLE
RPC
BridgeBridge
ORB
ComponentComponentComponentComponent
ComponentComponent
ComponentComponent
ComponentComponent
ComponentComponent
ComponentComponent
CORBA Framework Eelements 6
Passing Objects by Reference In a distributed application, there are two possible methods for
an application component to obtain access to an object in another process: When an object is passed by reference, the object itself remains "in place"
while an object reference for that object is passed. Operations on the object through the object reference are actually processed by the object itself.
When an object is passed by value, the object's state is copied and passed to its destination (via object serialization), where a new copy of the object is instantiated. Operations on that object's copy are processed by the copy, not by the original object.
Note: in CORBA, objects are only passed by reference (however, the new CORBA specifications include facilities for passing objects by value).
CORBA Framework Eelements 7
Object References An Object Reference is the information needed to specify an object
within an ORB. The representation of an object reference handed to a client is only valid for the lifetime
of that client. The language mapping also provides additional ways to access object references in a
typed way for the convenience of the programmer. There is a distinguished object reference, the null reference, guaranteed to be different
from all object references, that denotes no object. In Java, this is a Java null.
To invoke a CORBA object, you need a reference for the object. There are two ways to get a reference for a CORBA object: from another object, such as a factory or a name service
from a string that was specially created from an object reference
Interoperable Object References CORBA uses IOR as a “pointer” to a specific instance of a class in a distributed
environment encodes host, port, object identity may be externalized (using object_to_string)
CORBA Framework Eelements 8
Object References Lifecycle and Longevity of Object Reference
Object Reference can be created without instantiating any servant object Object Reference outlives the CORBA object to which it refers.
(CORBA::OBJECT_NOT_EXIST meaning the object has been permanently deleted.)
Factory Objects Create objects on remote servers (Example: a customer at a bank needs to create an
Account object when opening a new account.) ‘remote constructor’ Factory design pattern IDL definition:
…Interface Account{
…};Interface AccountFactory {
Account create (in string name, in long initialBalance);Account find (in string name);
};…
CORBA Framework Eelements 9
Object References Interoperable Object Reference
Structure of an IOR
Repository id identifies the type of object Number indicate the version of the ID interface, and usually is 1.0 Each profile is specific to a particular transport protocol and contains
complete details about the location of an object and how to open a connection to the object
– Make the same object accessible via different protocol
– Multiple profiles can be used as a way of implementing fault tolerance.
“ID:::Foo:1.0” n profile1 Profile n…
RepositoryId Profiles
CORBA Framework Eelements 10
Object References IIOP
0 1.2 host Optional components
Tag IIOP Version
port object_key
CORBA Framework Eelements 11
CORBA Components Client stub
Each stub represents (it is a proxy) an object operation (a possible request) which a client invokes in a language-dependent manner (e.g., by calling a subroutine which represents the operation).
The stubs make calls on the rest of the ORB using interfaces that are private to JavaIDL. Alternatively, a client may dynamically construct and invoke request objects which can
represent any object operation.
Implementation Skeleton Each skeleton provides the interface through which a method receives a request (dynamic
and static skeletons)
Object Adapter Purpose is to interface an object's implementation with its ORB Each object adapter provides access to those services of an ORB (such as activation,
deactivation, object creation, object reference management) used by a particular type of object implementation.
ORB Interface The interface to the small set of ORB operations common to all objects, e.g., the
operation which returns an object's interface type.
CORBA Framework Eelements 12
ORB and Object Interface ORB Interface
module CORBA {interface ORB {// PIDL string object_to_string(in Object obj); Object string_to_object(in string obj); Object resolve_initial_references(in ObjectId identifier); … ….};interface Object { interfaceDef get_interface();
boolean is_nil(); Object duplicate(); void release(); boolean is_a (in string logical_type_id); boolean non_existent(); boolean is_equivalent(in Object other_object)
…};ORB ORB_init();
};
CORBA Framework Eelements 13
Duplicate() and release()Text book Chapter 2: figure 2.8 – 2.11
CORBA Framework Eelements 14
The Portable Object Adapter (POA) The POA defines standard interfaces to do the
following: Map an obj ref to a servant that implements that object Allow transparent activation of objects Associate policy information with objects Make a CORBA object persistent over several server process lifetimes POA interface is locality constrained interface (i.e., references to the
POA cannot be passed outside of a server’s address space). Main functionality: dispatch incoming invocation requests to the
correct servant There can be multiple POAs active in a particular server There is always a root POA from which all of the other POAs are
created Relative name to the parent POA
CORBA Framework Eelements 15
The Portable Object Adapter (POA) Related concept
Servant Object ID Active Object Map Incarnate Etherealize Default Servant
Server details
Host, port (for client toLocate the server process)
Object_Key
Used by server
POA name ObjectID
POA instance Servant Objectmanages
Not necessarily 1-1
IOR Location Details
CORBA Framework Eelements 16
POA ArchitectureText book: figure 2.12
CORBA Framework Eelements 17
Object and Servant Lifetimes Servant object is associated with server process Incarnation: binding the servant object to CORBA
object Etherealization: break the binding
Text book: figure 2.13
CORBA Framework Eelements 18
ObjectAdapter
ImplementationSkeletons
ORB Core
Client Object Implementation
ClientStubs
ORBInterface
DynamicInvocation
standard interface
One interface per object operation
One interface per object adaptor
Proprietary ORB interface
Normal call interfaceUp call interface
CORBA Components
CORBA Framework Eelements 19
Client
ClientStubs
ORBInterface
DynamicInvocation
Clients perform requests using object references.
Clients may issue requests through object interface stubs (static) or dynamic invocation interface.
Clients may access general ORB services:
• Interface Repository.• Context Management.• List Management.• Request Management.
Client Side
CORBA Framework Eelements 20
Object Implementation
ORBInterface
ObjectAdapter
Implementations receive requests through skeletons (without knowledge of invocation approach).
The Object Adapter provides for:• management of references;• method invocation;• authentication;• implementation registration;• activation/deactivation.
ImplementationSkeletons
Implementation Side
CORBA Framework Eelements 21
Static v. Dynamic Invocation Static Invocation
Static interfaces are generated in form of client stubs by the IDL (pre-) compiler.
This means that the structure of the object has to be known before hand (at compile time).
Allows for better type checking; less runtime overhead; self-documentation.
Dynamic Invocation Dynamic Invocation Interface (DII) allows clients to invoke operations on
remote objects without having access to object stubs (another way to do this without dynamic invocation is to download static client stubs via a Java applet).
Clients must discover interface-related information at runtime (e.g., using the interface repository)
Servers can offer new services anytime without the need for recompilation on the client side.
CORBA Framework Eelements 22
Dynamic Requests The Dynamic Invocation Interface (DII) allows clients to
dynamically: discover objects; discover objects’ interfaces; create requests; invoke requests; receive responses.
Major features of Dynamic Invocation Interface: requests appear as objects themselves; requests are reusable; invocation may be synchronous or asynchronous; requests may be generated dynamically, statically or in combination approach.
CORBA Framework Eelements 23
CORBA Interface Repository The Interface Repository is a service that provides persistent
objects that represent the IDL information in a form available at runtime. Note: The JavaIDL runtime does not include an implementation of an Interface
Repository and one is not generally required by clients at runtime. Using the IR, it is possible for a program to encounter an object whose
interface was not known at compile time, yet be able to determine what operations are valid on the object and make invocation on it.
Interface Repository provides: Dynamic client access to interface definitions to construct a request. Dynamic type-checking of request signatures. Traversal of inheritance graphs. ORB-to-ORB interoperability.
CORBA Framework Eelements 24
CORBA Implementation Repository The Implementation Repository contains information that allows the
ORB to locate and activate implementations of objects. Ordinarily, installation of implementations and control of policies
related to the activation and execution of object implementations is done through operations on the Implementation Repository.
In addition to its role in the functioning of the ORB, the Implementation Repository is a common place to store additional information associated with implementations of ORB objects. (e.g., debugging information, administrative control, resource allocation, security, etc)
The Implementation Repository supports the implementation of object servers. It is not needed by clients in order to access servers.
CORBA Framework Eelements 25
IDL InterfaceDefinitions
ImplementationInstallation
ClientStubs
InterfaceRepository
ImplementationRepositoryImplementation
Skeletons
Client Object Implementation
Accesses Includes DescribesIncludes
Summary of CORBA Interfaces
All objects are defined in IDL by specifying their interfaces. Object definitions (interfaces) are manifested as objects in the Interface
Repository, as client stubs, and as implementation skeletons. Descriptions of object implementations are maintained as objects in the
Implementation Repository.
CORBA Framework Eelements 26
Summary: CORBA Remote Method Invocation
Clients use “object interfaces” through language mapping Java clients should work on any ORB that supports the Java language bindings. Clients can call any object instance remotely, so long as the object instance
implements the interface.
Clients can call remote objects statically or dynamically The server cannot tell whether the client is using static or dynamic invocation.
Objects are identified using a unique id: Interoperable Object Reference (IOR) CORBA normally passes objects by reference IOR was Introduced in CORBA 2.0 Object references can be converted to strings and back to “live” objects via
ORB interface functions.