• View
• Edit
• History
• Print

Distributed Object Computing - CORBA

A Distributed Computing Lecture by Steven Choy

Lecture Overview: Distributed objects computing paradigm - Introduction and overview of a CORBA system - Main components of a CORBA system - the working of a CORBA system - CORBA services.

Distributed Objects Computing Paradigm

• Object distributed over the network (location not important)
• Object interact through interface
• Interface hide the object implementation

Introducing CORBA

• CORBA stands for Common Object Request Broker Architecture
• CORBA is a specification for distributed object from the OMG (Object Management Group)
• CORBA specifies an architecture that allows application programs to communicate with one another regardless of what programming language they are written in, what software and hardware platforms they are running on, and the networks they communicate over.
• In CORBA, distributed applications are structured into objects.
• So, CORBA has the following desirable characteristics
  • Network Transparency
  • Language Independence
  • Platform Independence
  • Object interoperability

Overview a CORBA system

• object interfaces are strictly defined by the OMG Interface Definition Language (IDL)
• the communication module is by means of Object Request Broker (ORB)
• CORBA objects can be developed using any programming language and can then be executed on any computing platform.
• The ORBs installed at nodes of the distributed system can also be different from each other.
• One main function of the ORB is to ensure that an invocation is sent to the object’s server and the reply is passed back to the client.
• Every CORBA object has its own unique object reference, which is used by clients to direct their invocations.
• The client acts as if it is invoking an operation on a local object, but it is actually invoking through a client stub that acts as a proxy.
• The invocation then goes through the ORB, the server skeleton, and gets to the actual remote object.

CORBA is more than what we have mentioned above.

• more capabilities of a CORBA system
  • dynamic discovery of services provided within the distributed systems
  • dynamic invocation of remote programs
  • asynchronous communication between clients and servers
  • directory and trading services of distributed applications

Main Components of a CORBA system

The following outlines the three main components of CORBAs language-independent and object-based middleware system:

• An object-oriented interface definition language known as OMG IDL.

• An architecture that specifies the general organization of a CORBA system.

• An inter-ORB protocol known as the General Inter-ORB protocol or GIOP.

The Working of a CORBA System

CORBA Architecture

• CORBA RMI can be done in either static or dynamic ways.
• Static RMI means the interfaces of an object are known when the client application is being developed.
  • In other words, one has the predefined interface definitions of a remote object when he or she is writing the client program, so that the RMI statements are explicit in the program source.
• In dynamic RMI, the client application does not have the interface definitions of the remote object at compile time, so that it has to determine at runtime which method it will invoke at a remote object.
• Static RMI is easier to use because it provides a more natural programming model.

Client Side

• Client IDL Stub (Static Invocation)
• Dynamic Invocation Interface
• Interface Repository API
• ORB Interface

Static Invocation

Dynamic Invocation

Server Side

• Server IDL Skeleton
• Dynamic Skeleton Interface
• Object Adapter
• Implementation Repository
• ORB Interface

Object Adapter

• The function of an object adapter is to act as the interface between a CORBA object and the ORB itself.
• Each CORBA object is registered with its object adapter.
• An object adapter has the following tasks
  • It generates object references for CORBA objects.
  • It dispatches requests to registered CORBA objects.
  • It activates CORBA objects if they are not active when requests for them arrive.
• The idea of object adapters is to keep the ORB as simple as possible. Without object adapters, the size and complexity of the ORB will be large, for it needs to support diverse object implementation styles.

Implementation repository

• A CORBA system offers an implementation repository in the server side. Its responsibility is to provide information that is needed to activate and locate CORBA objects.
• Therefore, with an implementation repository, and given an object reference, an object adapter can find out which executable file the server should be loaded with and executed and which port number the new server should be listening for the specified object with.

Interface repository

• To make dynamic RMI possible, it is important to have a mechanism to find out during runtime what an IDL interface looks like.
• CORBA offers such a checking mechanism by a facility called the interface repository.
• Its responsibility is to provide information about registered IDL interfaces to clients on request.
• Specifically, for each registered interface, the repository provides the names of methods and, for each method, the names and types of the input/output argument.
• Thus, with an interface repository service, when a client receives a reference to a new CORBA object but does not have the corresponding IDL stub in advance, it can still find out the details of the interface to that object by asking the interface repository. Each IDL interface will be assigned a unique repository identifier by the IDL compiler. This identifier acts as a key to retrieve an interface definition from the repository. The identifier of a particular interface is embedded in references for CORBA objects that implement that interface, so a client can obtain the identifier from the object reference it receives.

CORBA services

• Besides the CORBA architecture, the IDL and the GIOP, OMG specifies a number of higher level services that might be required by or useful to distributed applications.
• These generic services, collectively called the CORBA services, were designed to be generic to support distributed applications and therefore are independent from the domain of distributed applications.
• The specifications of all the CORBA services can be found in the official website of OMG
• Services common to most implementations include:
• Lifecycle services- Control the creation and release of component instances
• Naming services - Allow identification and sharing of service instances
• Security services - Provide privacy of connection between client and server
• Transaction Services - Allow user to control start and completion of distributed transactions across components

Probing Further: CORBA, J2EE, or Microsoft .NET

• When it comes to component based development and standards, there are three competing standards.
  • CORBA
  • Java Technologies - Java RMI, J2EE, EJB (Enterprise Java Beans)
  • Microsoft Technologies - .NET, COM+
• CORBA - many languages, many platforms
• Java technologies - single language, multi-platforms
• Microsoft .NET - multi-languages, single platform
• CORBA, J2EE are not products; they are open specifications
• Microsoft .NET is a product strategy; specification is partly open, partly proprietary
• CORBA, J2EE are generalized enterprise-wide software strategies
• CORBA, J2EE are mature standards and multi-vendor supported; sophisticated programming model, better leverage of legacy systems

Extra Resources for Studying CORBA

• CORBA Basics from OMG

• Introduction to CORBA from Sun Developer Network

• The Rise and Fall of CORBA

• Overview of CORBA
• Java IDL: The "Hello World" Example

Thanks for Reading

If you would rather like to have this lecture note in printed format, please click the print action link in the top right corner.

If you find any problem in this lecture note, please feel free to reach Steven by steven@findaway.hk