Common Object Request Broker Architecture CORBA By Naresh

Common Object Request Broker Architecture (CORBA) By: Naresh Nagwani NIT Raipur

Introduction • What is the purpose / goals of CORBA? • How to meet goals? • Conclusion

Object Management Group • OMG creates specifications, not implementations. • Some Key Specifications: – OMA: Object Management Architecture. – CORBA: Common Object Request Broker Architecture.

OMA Object Model • Objects provide services. • Clients makes a request to an object for a service. • Client doesn’t need to know where the object is, or anything about how the object is implemented! • Object interface must be known (public) provides signature for each object method.

Object References • Clients don’t have objects, they just have object references. • Object references can be persistent (saved for use later).

Accessing Remote Methods • Clients can call remote methods in 2 ways: – Static Invocation: using stubs built at compile time (just like with RPC). – Dynamic Invocation: actual method call is created on the fly. It is possible for a client to discover new objects at run time and access the object methods.

What is the purpose / goals of CORBA? • Enable the building of plug and play component software environment • Enable the development of portable, object oriented, interoperable code that is hardware, operating system, network, and programming language independent

How to meet goals? • Interface Definition Language (IDL) • Object Request Broker (ORB)

Interface Definition Language (IDL) • • Language Independence Defines Object Interfaces Hides underlying object implementation Language mappings exist for C, C++, Java, Cobol, Smalltalk, and Ada

Interface Definition Language • IDL is the language used to describe object interfaces, the same basic idea as a protocol definition file for RPC. • IDL is a declarative language, it only describes object interfaces. • IDL is language neutral - there are mappings for many object oriented languages (C++, Smalltalk, Java).

Interface Definition Language (IDL) module <identifier> { interface <identifier> [: inheritance] { <type declarations>; <constant declarations>; <exception declarations>; <attribute declarations>; [<op_type>] <identifier>(<parameters>) [raises exception][context]; } } Defines a container (namespace) Defines a CORBA object Defines a method

IDL Compiler IDL Definitions 1. 2. IDL Compiler Stubs 3. Define objects using IDL Run IDL file through IDL compiler Compiler uses language mappings to generate programming language specific stubs and skeletons Skeletons

IDL Compiler • Compiles IDL definition into stubs and skeletons • Uses OMG specified language mappings to translate IDL into a language specific implementation Object Adapter

Object Request Broker (ORB) • • • What is it? Architecture Request Handling Scenario CORBA Services CORBA Facilities

Object Request Broker • The ORB is an abstract entity that acts as the middleman in all remote method invocations. • The ORB finds a server that can handle a method invocation, passes the request to the server, receives the response and forwards it to the client. • The functions handled by an ORB are actually implemented in both client and server.

What is it? • • Implementation of CORBA specification Middleware product Conceptual Software Bus Hides location and Application implementation details Middleware about objects OS Hardware Drivers

Client / Object Interaction Client Obj Impl IDL IDL Network IPX ATM OSI TCP/IP IPX ATM ORB OSI TCP/IP ORB

ORB Architecture Interface Repository Client IDL Stub IDL Compiler Object (servant) OBJ Ref DII GIOP/IOOP Implementation Repository ORB Interface IDL Skeleton ORB Core DSI Object Adapter

Interface Repository • • • Database of object definitions Contains metadata about each object Allows for introspection Allows clients to discover interfaces at run-time Used in support of dynamic invocations Object Adapter

Interface Repository • An IR provides persistent storage of IDL interface declarations. • IR serves 2 purposes: – tool for programmers. Basically a database of object interfaces and inheritance hierarchy. – Support dynamic invocation interface (DII).

Implementation Repository • Contains information that allows the ORB to locate and activate object implementations • Provides information about the classes a server supports, the objects that are instantiated, and their IDs Object Adapter

ORB Core • Provides mechanism for transparently communicating client requests to target object implementations • Makes client requests appear to be local procedure calls • GIOP – General Inter-ORB Protocol • IIOP – Internet Inter-ORB Protocol Object Adapter GIOP/IOOP ORB Core

ORB Interface Client Object (servant) ORB Interface • Provides helper functions • Converting object references to strings Object Adapter • Creating argument lists for requests made through DII

IDL Stub Client IDL Stub • Static invocation interface (SII) • Marshals application data into a common packet-level representation – Network byte order (little-endian or bigendian) – Size of data types

IDL Skeleton • Demarshals the packet -level representation back into typed data that is meaningful to an application – Network byte order (little-endian or bigendian) – Size of data types Object (servant) IDL Skeleton

Dynamic Invocation Interface • Client • Dynamically issue requests to objects without requiring IDL stubs to be linked in Clients discover interfaces at runtime and learn how to call them Steps: DII 1. 2. 3. 4. 5. Obtain interface name Obtain method description (from interface repository) Object Create argument list Adapter Create request Invoke request

Dynamic Skeleton Interface • Server side analogue to DII • Allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of object it is implementing Object (servant) DSI Object Adapter

Object Adapter • • • Accept requests for service on behalf of the server’s objects Demultiplexes requests to the correct servant Dispatches the appropriate operation upcall on the servant Registers classes it supports and their run-time instances with the implementation repository Portable Object Adapter (POA) • policies control object behavior (ie. Lifespan. Policy) Instance of the adapter design pattern Object (servant) IDL Skeleton DSI Object Adapter

Object Adapters • Object Adapters provide a layer between object method requests and the servers that service the requests. Functions include: – generation of object references – starting up the actual server program(s) – handling security

Basic Object Adapter • Simplest Object Adapter, can support a number of different implementations: – one server that always is running – one program that can handle requests for multiple objects. – one program per object implementation. – one program for each object method.

Object Reference Client OBJ Ref Object (servant) • Interoperable Object Reference (IOR) • Uniquely identifies each object • Contents • Type Name (repository ID) Object Adapter • Protocol and Address Details • Object Key (object adaptor name, object name)

Request Handling Server Application POA Incoming Request ORB POA Servants

Scenario Interface Repository Client IDL Stub IDL Compiler Object (servant) OBJ Ref DII GIOP/IOOP Implementation Repository ORB Interface IDL Skeleton ORB Core DSI Object Adapter

CORBA Services • Provide basic infrastructure functionality • Currently there are 15 defined services – Naming - maps human names to object references (White Pages) – Event - provides both a push and pull event model – Object Trader - discover objects based on the services they provide (Yellow Pages) – Transactions – allows distributed objects to participate in atomic transactions

CORBA Facilities • Provide higher-level functionality at the application level • Provide standard components that can be used “off -the-shelf” • Two Categories – Horizontal – user interface, information management, systems management, and task management – Vertical – domain based, telecommunications, financial services