SEMINAR ON

DISTRIBUTED OBJECTS

AND

C O R B A

SREERAM P

CORBA : COMMON OBJECT REQUEST BROKER ARCHITECTURE

- THE KEY TO THE TWENTY FIRST CENTURY TECHNOLOGY

Sreeram's Corba Page >> My Seminar Report Table Of Contents

4. Chapter 1 : Introduction to Object Oriented Programming

5. Chapter 2 : Distributed Objects and Components

2.1 Distributed Objects

2.2 Components

2.3 Supercomponents

6. Chapter 3 : Common Object Request Broker Architecture

3.1 The Object Management Group

7. Chapter 4 : CORBA Implementations and Projects

8. Chapter 5 : CORBA - Pros and Cons

11. References

Sreeram's Corba Page >> My Seminar Report >> Acknowledgement

Sreeram's Corba Page >> My Seminar Report >> Abstract

ABSTRACT

With the aid of the three magical properties of encapsulation, inheritance and polymorphism, the object oriented programming paradigm has won the hearts of most programmers. Remote object communication is an added jewel to an object's crown. Distributed objects provide this, and many other desirable properties too. The Common Object Request Broker Architecture defines the standards for communication between distributed objects. CORBA is the key technology for the next century. Hence, maximum research shall occur in CORBA/WWW integration in the coming years.

Sreeram's Corba Page >> My Seminar Report >> Introduction

INTRODUCTION

Programming paradigms have been evolving ever since man started programming. The latest in this series is the concept of distributed objects. Classical objects, no doubt, provide innumerable advantages to programmers; however they are confined to a single program. Realising this, programmers have started moving towards objects in client/server systems or distributed objects. This is the area where objects will realize their greatest potential and growth;in the process, they will become the new "mainstream computing model." Distributed objects are actually components, that are entities which, when assembled, form applications.

Common Object Request Broker Architecture or CORBA is a standard put forth by the Object Management Group for communicating between distributed objects. It is a significant step on the road to object-oriented standardization CORBA is interoperable, ie. distributed clients may contact servers on any operating system, any platform, in any part of the world. The communications heart of object-oriented systems, CORBA brings true interoperability to today's computing environment.

The success of the CORBA standard has invoked research in various areas of technology, including databases, client/server etc. Integrating CORBA and the Web in order to provide transactional information is the latest innovation in this field. Thus, CORBA is the key to the twenty first century technology.

This paper is a humble effort to bring out the phenomenal technology of CORBA. The initial pages provide an introduction to object oriented programming concepts, and an overview of distributed objects and components. Later, it introduces CORBA, defines the architecture in detail with an example. The last part dels with the implementations and projects involving CORBA, and finally, the advantages and drawbacks.

Sreeram's Corba Page >> My Seminar Report >> OOP

Introduction to Object Oriented Programming Concepts

Software development paradigms have been changing ever since people started programming. As we find new technologies and new tools that make programming easier and better, we change our ideas about how things should be done.

Tracing the history of the various programming paradigms, the first one was machine language programming which represented instructions as bits - which the computer could directly understand, but was very difficult for the humans to make out. Then came assembly language programming, which made use of mnemonics. The major improvements were the introduction of subroutines and macros, which in turn led to the development of libraries. This was the first step in modular programming.

The next phase was the high level programming languages, like C, ADA, FORTRAN, etc. They made programs much more readable and added control structures like DO loops etc. Thus evolved the importance of controlling the flow in the program and the concept of Structured Programming techniques, which were conciously introduced to the programming world. This concept is very useful in writing large programs and applications so that the program could be split into chunks of manageable code.

The last in this generation was the Object Oriented Programming paradigm. Examples of OOLs are C++, SmallTalk, etc. OOLs brought in the concept of objects and classes.

What's an object after all ?

As the name object-oriented implies, objects are the key to understanding object-oriented technology. We can see many examples of real-world objects: a dog, a desk, a bicycle. These real-world objects share two characteristics: they all have state and they all have behavior. For example, bicycles have state (current gear, current pedal cadence, two wheels, number of gears) and behavior (braking, accelerating, slowing down, changing gears).

Software objects are modelled after real-world objects. An object is a piece of code that owns things called attributes and provides services through methods.

Objects provide a better programming model, coupled with the three magical properties : encapsulation, inheritance, and polymorphism, and hence reusability.

Classes: A class is a blueprint or prototype that defines the variables and methods common to all objects of a certain kind. Technically speaking, objects are run-time instances of a class. An object is identified by a unique ID or reference.In the bicycle's example, each bicycle is an instance of the class bicycle.

Encapsulation

As shown, the object's variables make up the center or nucleus of the object. Methods surround and hide the object's nucleus from other objects in the program. Packaging an object's variables within the protective custody of its methods is called encapsulation. Typically, encapsulation is used to hide unimportant implementation details from other objects. For example, the method of changing gears is immaterial for a bicycle rider. Similarly, we don't need to know how a class is implemented, but only which methods to invoke. Thus, objects are self-contained atoms. The object allows access to it's methods and data using the public, private and protected interfaces ( packages also in Java ) Encapsulation brings with it, modularity and information hiding

Inheritance

Object-oriented systems allow classes to be defined in terms of other classes. For example, mountain bikes, racing bikes, and tandems are all different kinds of bicycles.

Each subclass inherits state (in the form of variable declarations) from the superclass. Subclasses can add variables and methods to the ones they inherit from the superclass. Subclasses can also override inherited methods and provide specialized implementations for those methods. In the bicycle's example, the tandem bike may inherit the properties of the superclass, and also add it's own features, say, an extra gear. We are not limited to just one layer of inheritance. The inheritance tree, or class hierarchy, can be as deep as needed. Methods and variables are inherited down through the levels.

Messages

A single object alone is not very useful and usually appears as a component of a larger program that contains many other objects. Through the interaction of these objects, programmers achieve higher order functionality and more complex behavior. Software objects interact and communicate with each other by sending messages to each other.

Polymorphism

Polymorphism means that the same operation may behave differently on different classes. Polymorphism lets one view two similar objects through a common interface; it eliminates the need to differentiate between the two objects.

                                 |-- parametric
                 |-- universal --|
                 |               |-- inclusion
  polymorphism --|
                 |               |-- overloading
                 |-- ad hoc    --|
                                 |-- coercion

Overloading is a variant of polymorphism that to define different versions of a method, each with different parameter types.

Sreeram's Corba Page >> My Seminar Report >> Distributed Objects

Introduction To Distributed Objects and Components

What are distributed objects ?

We have seen that the classical objects provide the programmer with a lot of advantages.However, these classical objects only live within a single program. Only the language compiler that creates the objects knows of their existence. The outside world doesn't know about these objects and has no way to access them. They're literally buried in the bowels of a program.

Hence we're moving on to the next step: objects in client/server systems or distributed objects. In contrast to the classical object, a distributed object is a blob of intelligence that can live anywhere on a network. Distributed objects are independent pieces of code that can be accessed by remote clients via method invocations. The language and compiler used to create distributed server objects are totally transparent to their clients. Clients don't need to know where the server resides or what operating system it executes on; it can be on the same machine or on a machine that sits across an intergalactic network. They can message each other transparently anywhere in the world. They are very dynamic-they come and go and move around.

Distributed objects are, by definition, independent software components These are smart pieces of software that can plug-and-play across different networks, operating systems, and tool palettes.

More recently, distributed objects have become the darling of the Business Process Reengineering (BPR) crowd since objects map very well to the way businesses are organized. They use objects to simulate, describe, and analyze the business process.

Today's desktop applications are monolithic and over-bloated and contain every possible feature, of which only 10% are used frequently - the rest simply add complexity and bulk. We must wait-it seems forever-to get the new features we really need, in the form of new upgrades as vendors must bring forward all the hundreds of product features with every new release.

To site an example, it took WordPerfect just under 14 developer years to upgrade their product from version 3 to 4. However, it took 250 developer years to move the same product from version 5 to 6. It could cost them as many as 4,464 developer years to move the product to version 8. They realized this and are now rearchitecting the product using OLE and OpenDoc components. Microsoft, Lotus, etc. have similar stories to tell.

These have led to the component revolution .

What Exactly Is a Component?

A component is a piece of software small enough to create and maintain, big enough to deploy and support, and with standard interfaces for interoperability. Some are called white boxes - they behave like classical objects and have all their properties.eg: CORBA and OpenDoc. Others are called black boxes - are similar to objects. eg: OLE components - do not support inheritance. They are the optimal building blocks for creating the next generation of distributed systems.

A component is what Brad Cox calls a software IC. Frameworks are the boards we plug these components into. The object bus provides the backplane. Families of software ICs that play together are called suites. These will be available from the market, through standard part catalogs.

OpenDoc and OLE are currently the leading component standards for the desktop; CORBA provides a component standard for the enterprise. CORBA and OpenDoc complement each other-OpenDoc uses CORBA as its object bus.

Features of a minimalist component :

It is an extended object.
It is a marketable entity.
It is not a complete application; rather, a building block.
It can be used in many combinations using plug-and-play.
It has a well-specified interface ( eg: CORBA IDL ).
It is interoperable across address spaces, networks, etc.

Supercomponents are components with added smarts like :

Self-installing, self-registering and self-testing.
Licensing, versioning and metering.
Configuration and property management.
Security - protection, authentication and verification.
Life cycle management : creation, destruction, and archival.
Support for open tool palettes.eg: for OLE OCXs or OpenDoc parts.
Scripting, metadata and introspection .
Transaction control and locking : for shared resources .
Persistence - to save data and restore it later.
Relationships - dynamic/static, with other components.
Ease of use and high level of abstraction.
Semantic messaging and Event notification.
Multithreading - for concurrent control.
Internationalization: Multiple languages, symbols, etc.
Object repositories and class browsers.
Dependency tracking.
The influence of components on users will be :
Power users will assemble their own personalized applications using off-the-shelf components using scripts.
Small developers can create individual components that will integrate smoothly with existing software created by larger development shops-saving them the re-invention of the wheel.
Large developers will use component suites to create enterprise-wide client/server applications in record time, with about 80% off-the-shelf components and the rest, value-added.
Desktop vendors will use components to assemble specific applications. Instead of selling monster suites packed with everything, at exorbitant prices, they will be able to provide their consumers with what they really need.
Thus, components reduce application complexity, development cost, and improve software reusability, flexibility, maintainability, platform independence, etc.
When Can We Expect These Components?

By late 1997, most new software will be developed (assembled) using components. According to Strategic Focus, 25% of developers were building component software in 1995. This number climbed abruptly to 66% by the end of 1996. Components will foster the emergence of three new markets: for Components, Component assembly tools and Custom applications.
So, the million-dollar question is: Why didn't this happen any sooner?

Without standards, we cannot have components. Our industry did not have the right component infrastructure or standards. Now, we have two standards to choose from: OpenDoc/CORBA and OLE/COM and hence the boom.
Why Distributed Objects ?

Distributed objects may be used :
1. to share information across applications or users.
2. to synchronize activity across several machines.
3. to increase performance associated with a particular task.
4. to connect applications running on different platforms.
5. to allow people in different cities to contribute to work together.
6. . to allow business processes to be modified or reimplemented without altering applications which use the distributed objects.
But, not every business object should be distributed, as it brings network overhead and management overhead.

Sreeram's Corba Page >> My Seminar Report

The Object Management Group ( OMG )

OMG is the largest software development consortium of system vendors, software developers, and users developing and promoting distributed object theory and practice. It has around 700 members (SunSoft, HP, DEC, IBM, Iona, ... ) at present. The primary goal of OMG is to create an open interoperability standard for object-oriented distributed computing. It aims at reducing complexity, lowering costs, and hastening the introduction of software applications.
OMG realizes its goals through creating standards that allow interoperability and portability of distributed object oriented applications. They do not produce software or implementation guidelines;only specifications which are put together using ideas of OMG members who respond to RFI (Requests For Information) and RFP (Request For Proposals) Most major software companies interested in distributed object oriented development are among OMG members.
They released the Object Management Architecture(OMA) in late 1990 and Common Object Request Broker Architecture (CORBA) version 1.1 in late 1991. Version 2.0 was adopted in Dec. 1994 & the standard was released in July 1995.
OMA is a "big picture" view of the elements required to enable disitributed components (business objects). These elements are;
- CORBA; object intercommunication and activation
- CORBAservices; basic object services.
- CORBAfacilities; horizontal facilities. e.g. systems management, asian input, repositories
- Domain Interfaces; business object interface specifications for vertical domains. e.g. telecom, finance, health care
  These can be roughly divided into two parts: system oriented components (ORB and Object Services), and application oriented components (Application Objects and Common Facilities).
  Other CORBA related consortia:
  - Object Database Management Group (ODMG)
  - ComponentWare Consortium
  - An OMG IDL to Modula-3 translator (IDLM3)
  - Component Integration Laboratories (CIL - Opendoc )
  - Bioinformatics Java/CORBA working group
  Sreeram's Corba Page >> My Seminar Report >> CORBA
  
  WHAT IS CORBA???
  
  The Common Object Request Broker Architecture , commercially known as CORBA, is OMG's answer to the need for interoperability among the rapidly proliferating number of hardware and software products available today. Simply stated, CORBA allows applications to communicate with one another no matter where they are located or who has designed them. It defines the "communications heart" of the object-oriented software framework.
  CORBA's basic paradigm is essentially RPC; remote procedure calls. An object presents an interface describing methods that it supports, and a client (object or otherwise) invokes the desired remote method. The client must pass in any required arguments, and then wait for a return value or returned arguments. This is called a synchronous twoway. CORBA automates many common network programming tasks such as object registration, location, and activation; request demultiplexing; framing and error-handling;parameter marshalling and demarshalling;and operation dispatching. The OMG CORBA specifications define the basic CORBA architecture, the Interface Definition Language( IDL ) and the Application Programming Interface ( API ).
  At the lowest level CORBA supports synchronous request/response which allows an application to make a request to some CORBA object and then wait for a response, and a deferred synchronous request/response which allows an application to make a request to some CORBA object. The deferred synchronous communication does allow a certain degree of asynchronous communication through polling for responses.
  
  Sreeram's Corba Page >> My Seminar Report >> CORBA
  
  The Basic CORBA Architecture
  
  The CORBA architecture is designed to support the distribution of objects implemented in various programming languages. This is achieved with the help of the IDL that can be mapped to many languages. CORBA defines a wire protocol for making requests to an object and for the object to respond. IIOP ensures interoperability between clients and servers. CORBA extends on this basic functionality by defining a set of low level services defined in IDL.
  The following figure illustrates the primary components in the basic CORBA architecture.
  
  The Basic CORBA Architecture
  The Object Implementation ( ~Server )
  
  The CORBA object model revolves around the idea that objects are encapsulated entities that provide services that can be requested by clients. Thus objects are servers. The objects implement the CORBA IDL interface. Servers can be written in a variety of languages including C, C++, Java, Smalltalk, and Ada.
  The server :
  - Provides the semantics of the object.
  - Defines data for the object instance.
  - Defines code for the object's methods.
  - Can use other objects (or return references to other objects)
  - Can manipulate other non-object software systems
  Objects are denoted by object references (or objrefs for short). An object may be denoted by multiple distinct objrefs. Objrefs can be persistified (transformed into strings). Given a persistified form, one can get back the original objref and make requests to it. Objrefs have duplicate and release operations that implement reference counting, an is_a method that can be used for maintaining runtime type safety, an is_equivalent operation that compares two objrefs, etc.
  Client
  
  This entity invokes an operation on an object implementation. Clients access services by issuing requests which contain information about the target object, the operation, the parameters for the operation (if any) and an optional request context. These requests can be made through pre-compiled stubs or through a dynamic invocation mechanism. Requests cause a service to be performed. If an abnormal condition occurs, an exception can be returned. A request made by a client is conveyed to the corresponding server by the ORB. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args).
  Features :
  - The client is a client relative to a specific object. An implementation of one object may be a client of other objects.
  - The client performs a request by having an ObjRef for an object and the desired operation to be performed.
  - The client initiates the request by calling stub routines specific to an object (IDL interface) or by constructing the request dynamically (DII interface).
  - The client sees the same interface regardless of:
    - where the object is located
    - what programming language the object is implemented
  Object Request Broker (ORB)
  This is the core of the Reference Model. It is the middleware, similar to a telephone exchange, that provides a mechanism for transparently communicating client requests to servers. The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls.
  The ORB is responsible for
  - mechanisms to find object implementation for request
  - prepare object implementation to receive request
  - communicate the data in the request
  During a request the ORB:
  - Intercepts the client call
  - Locates the appropriate implementation code
  - Transmits parameters & transfers control to Server
  - Transmit output values & control back to the client
  ORB Interface
  
  An ORB is a logical entity that may be implemented in various ways (such as processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. This provides various helper functions such as converting objrefs to strings, and vice versa, and creating argument lists for requests made through DII.
  CORBA IDL stubs and skeletons ( Static Invocation Interface )
  
  The IDL compiler generates client stubs and server skeletons which serve as the ``glue'' between the client and server applications, respectively, and the ORB. The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler. The use of a compiler reduces inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.
  Dynamic Invocation Interface (DII)
  
  This allows a client to directly access the underlying request mechanisms provided by an ORB. DII allows applications to dynamically issue requests to objects and to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.
  Dynamic Skeleton Interface (DSI)
  
  This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing.
  Object Adapter (OA)
  
  This assists the ORB in delivering requests to the object and in activating the object. An OA associates servers with the ORB and provides for the creation and interpretation of objrefs, implementation activation/deactivation, registration, etc. OAs can be specialized to provide support for certain object implementation styles ( database adaptor, high security adaptor, and library OAs for non-remote objects). If the ORB Core provides these services, the OA provides an interface to it; otherwise the OA must implement it. The CORBA spec. defines the Basic OA (BOA).
  The functions of an OA are :-
  - Generation and interpretation of object references
  - Method invocation & Security of interactions
  - Object and implementation activation and deactivation
  - Mapping objref to corresponding object implementations
  - Registration of implementations
  The Interface Repository
  
  CORBA specifies an interface repository as a way of presenting type information at runtime, and an implementation repository as a way for an ORB to locate and activate servers. This component of the ORB provides persistent storage of object interface definitions and helps in type-checking of request signatures.
  The CORBA Interface Definition Language (IDL)
  - C++ ish : has preprocessor, object interfaces, etc.
  - IDL types: Integer, Float, Boolean, Strings, Octet, etc.
  - Exceptions : system or object implementation
  - Method types: Normal and One-way
  Language mappings define how to access objects through the ORB using a particular language. A mapping includes a definition of the IDL declarations into data types and procedures of that language, the structure of stubs and skeletons, the DII, the OAs and the ORB interface. It can also define the interaction between object invocations and thread of control in the client or the implementation.
  
  Sreeram's Corba Page >> My Seminar Report >> CORBA
  
  CORBA Services and Interfaces
  
  Object Services ( CORBAServices ) :
  
  The CORBAServices specification defines a whole set of interfaces and objects that support some basic services crucial to the building of distributed applications. CORBA defines roughly 15 different domain-independent services which augment the basic CORBA architecture. These services are horizontal application services. Some of these are vendor-dependent, not standard.
  Some examples are :
  - The Naming Service : to find objects based on names;
  - The Trading Service : to find objects based on their properties.
  - Life Cycle Service : to create, destroy or move objects.
  - Event Service: to support event notification between objects.
  - Services for security, transactions, persistence, email, etc.
  Corba Services
  Common Facilities
  
  Interfaces horizontally-oriented towards end-user applications eg: Distributed Document Component Facility (DDCF).
  
  Domain Interfaces
  
  Interfaces oriented towards specific application domains. eg: Product Data Management (PDM), medical , financial domains,...
  
  Application Interfaces
  
  Interfaces developed for specific application.
  
  Sreeram's Corba Page >> My Seminar Report >> Interoperability
  
  Interoperability
  
  The numerous ORB products currently available, have created the need for different ORBs to interoperate. Furthermore, there are distributed and/or client/server systems which are not CORBA-compliant and there is a growing need for providing interoperability between those systems and CORBA. In order to answer those needs OMG has formulated the ORB interoperability architecture and introduced the high - level concept of a domain.
  The interoperability approaches can be divided into immediate and mediated bridging. With immediate bridging, elements of interaction are transformed directly between the internal form of one domain and the other. With mediated bridging an intermediate form is specified between two domains.( eg: OMG's IIOP ) The first is faster, but less general. Internal mediation is called a "full bridge".( eg: TCP/IP ) If two different protoclos are used, it is a half bridge. Bridges can be implemented both internally to an ORB (in-line ) or in the layers above it ( request-level bridges ).
  In order to make bridges possible it is necessary to specify some kind of standard transfer syntax. This function is fulfilled by General Inter-ORB Protocol (GIOP) defined by the OMG for ORB-to-ORB interaction. OMG also specified how it is going to be implemented using the TCP/IP transport and thus defined the Internet Inter-ORB Protocol(IIOP). It is designed to provide "out of the box" interoperability with other compatible ORBs. IIOP can also be used as an intermediate layer between half-bridges and for internal ORB messaging. The specification also makes provision for a set of environment-Specific Inter-ORB Protocols (ESIOPs).
  An IOR is an Interoperable ObjRef, that allows an application to make remote method calls on a CORBA object. Once an application obtains an IOR, it can access the remote CORBA object via IIOP. The application constructs a GIOP message and sends it.
  
  Sreeram's Corba Page >> My Seminar Report >> Performance
  
  PERFORMANCE ISSUES
  1. Scalability across connected client applications.
  2. Scalability across objects within a CORBA server.
  3. Raw throughput between one client and one server.
  4. Activation time of server processes.
  5. Activation time of CORBA objects.
  6. Streaming time for different IDL types.
  7. Connection time of the first remote operation.
  8. Minimum memory consumed by a CORBA object.
  9. Number of file descriptors consumed by a complex network of distributed objects.
  Ways to tune CORBA applications for better performance :
  1. Distribution should only be used if essential. Avoiding excessive distribution yields better performance.
  2. IDL interfaces can be tuned to minimize network latency or increase network performance (band width). Another way is to reduce the number of network transfers.
  3. Caching results of remote operations can avoid network overhead.
  4. Many performance problems are associated with seriali- zation and blocking conditions. Utilize multiple server processes or threaded servers instead of single servers.
  Sreeram's Corba Page >> My Seminar Report >> WWW/CORBA
  
  CORBA AND THE WORLD WIDE WEB
  - Both CORBA and WWW are distributed object oriented client/server systems.
  - For communication, CORBA uses IDL, ORB and IIOP which supports multiple transfer protocols, whereas WWW services use the Hyper Text Transfer Protocol ( HTTP ).
  - HTTP requires some standard methods like GET and HEAD . CORBA defines no standard methods which all application services are required to support.
  - The IDL and API make remote invocations very similar to local invocations and programming very easy. In contrast it is harder to write clients and servers for WWW, because of the need to drive the protocol stack directly;there is no equivalent to client/server stubs.
  - To access resources, WWW uses Uniform Resource Locators which are associated with a particular resource at a particular location. So, if the object or resource has moved the access attempt will fail. In contrast, CORBA uses opaque ObjRefs and relies on the underlying ORB to locate the remote object.
  The WWW community has recognised the problems connected with URLs and are developing concepts which have very similar to CORBA's ObjRefs,using late binding to locate the server.
  CORBA objects can be accessed from WWW applications by :
  - Java applets can be downloaded via WWW applications. These Java applets are capable of directly accessing CORBA objects via IIOP.
  - Pure HTML based application are capable of accessing CORBA objects via CGI gateways. Arbitrary unknown CORBA objects can be accessed by a single pre-compiled client application via DII. A pre-compiled application can dynamically generate HTML pages based upon results obtained from arbitrary invocation of operations. This depends only on HTML, and not on the browser.
  - A similar approach to the CGI CORBA gateway described above, can allow CORBA objects to be accessed without the performance impact associated with rocess spawning. A plug-in can be developed for a particular browser which enables it to speak directly to any CORBA object through IIOP.
  - Web servers from Netscape and Oracle are beginning to to support IIOP directly.In addition to supporting HTTP, FTP and news group access, they will be able to access any CORBA object capable of supporting IIOP.
  Sreeram's Corba Page >> My Seminar Report >> CORBA Example
  
  A Simple Example of Using CORBA
  
  A simple example illustrating interfacing objects with CORBA can be constructed as follows. First, the programmer needs to write an OMG IDL specification of the object and the services it is supposed to perform.
  interface example_object{ void operation_on_object(in long a, inout boolean b); }
  This defines one object, on which a client can invoke one operation returning no results, but taking two arguments. In addition to the type, the parameters are described by in/out/inout attributes which signal whether the value will be passed from client to server, the other way around or both ways.
  This IDL specification is then passed through some IDL compiler, which generates client stubs and server skeletons in the languages in which client and server are written. These are then included in the client's program, the server's program and the repositories.
  Using inheritance,
  class example_object: public virtual CORBA::Object{ static example_object_Ref _bind(...); virtual void operation_on_object (CORBA::Long a, CORBA::Boolean& b); }
  The example_object class is used on the client's side. The function operation_on_object in this class represents a stub; its implementation will marshal parameters of the request, initiate sending the request to the server (through calling some ORB-specific routines which the compiler knows about) and wait for the answer. The _bind function will bind to a specific object of the example_object type given some of its characteristics (eg. its name, address, etc).
  class example_object_sk: public virtual example_object{ virtual void operation_on_object (CORBA::Long a, CORBA::Boolean& b) = 0; static void call_operation_on_object( /* a stream */); };
  On the server side, the up-call from the OA will be made through the skeleton function call_operation_on_object. Its implementation contains interface to the net on the server's side. After unmarshaling parameters, this function is going to execute a call to operation_on_object, which implements the service.
  class example_object_impl: public example_object_sk{ void operation_on_object (CORBA::Long a, CORBA::Boolean& b); };
  The last class contains the actual implementation of the object and has to be written by the programmer.
  In the simplest scenario, the main program of the server implementation contains an instantiation of the implemented object and a call to the BOA notifying it that the implementation is ready:
  CORBA::BOA::impl_is_ready();
  Then, a client can obtain an object reference to the server by calling the _bind method generated for the interface on the client side, and thus obtain a handle on the object in its own address space. Then it can invoke requests on the server as if it resided in its address space:
  example_object* x = example_object::_bind("my_example_object", [email protected]); x->operation_on_object(4,0);
  
  Sreeram's Corba Page >> My Seminar Report >> Implementations
  
  CORBA Implementations
  1. BBN's Corbus
  2. CIL's (Component Integration Laboratories) OpenDoc.
  3. DEC's (Digital Equipment) Object Broker
  4. DNS Technologies' SmallTalkBroker
  5. HP's (Hewlett-Packard) ORBplus
  6. Iona's Orbix, OrbixWeb (Java/CORBA), OrbixTalk (CORBA Messaging), OrbixNames (CORBA Naming)
  7. IBM's SOM and OpenDoc
  8. ParcPlace-Digitalk's Distributed SmallTalk (prev. HP)
  9. Prism Technologies' OpenBase
  10. Sandia National Labs' JIDL IDL compiler for Java.
  11. SIEMENS NIXDORF's SORBET
  12. Silvano Maffeis' (Cornell) Electra
  13. Stratus' Reliable Distributed Objects (RDO)
  14. Sun Microsystems' NEO, Java/CORBA system Joe, Java Remote Method Invocation (RMI),JavaIDL, JavaBeans and DOE ( beta )
  15. Taligent's TalAE/TalDV/TalOS... environment
  16. TIBCO's The Information Bus
  17. Tivoli Systems' Tivoli Management Environment
  18. TRW's Universal Network Architecture Services (UNAS)
  19. Visigenic's VisiBroker for C++ (formerly ORBeline) VisiBroker for Java (formerly Black Widow).
  20. Xerox PARC's ILU and an ILU/Java system Jylu.
  21. HyperDesk HD-DOMS
  Free Implementations of CORBA :
  1. Chorus's COOL for Solaris, Linux, Windows NT/95 etc.
  2. Xerox Parc's ILU
  3. OO Technologies' Distributed Object Management Environment (DOME) - Linux
  Sreeram's Corba Page >> My Seminar Report >> Projects
  
  Some major projects using CORBA :
  - Distributed Object Management Integration System(DOMIS)
  - Dialogos' ORB based applications using ICL's DAIS ORB.
  - University of Minnesota's DAMSEL Project ( Dynamic Mul- timedia specification Language ) uses CORBA and Java
  - The Sunrise project and the TeleMed subproject
  - Information Sharing System (ISS)
  - A Framework for Distributed Digital Object Services by Robert Kahn and Robert Wilensky
  - Distributed Systems Technology Centre (DSTC), Australia
  - The ANSA project ( Corba/WWW integration )
  - GTE Labs' DOC Distributed Object Computing Group
  - The Larch/CORBA project
  - TCL/Orbix Integration
  - The Web Broker
  - The Motorola Iridium project Tools for use with CORBA:
  - NetLinks Technology's ORBitize IDL builder/browser development tool
  - Black & White Software's suite of development tools
  - SNiFF+ development tool
  - IDE's Software through Pictures OOA/OOD CASE tool
  - METEOR multiparadigm Workflow management system
  - ObjecTime's ObjecTime Toolset and CORBA features
  - ProtoSoft's Paradigm Plus OOA/OOD CASE tool
  - Rational's Rose OOA/OOD CASE tool
  - I-Kinetics' Database Component product
  - Sandia's IDLdoc documentation tools
  - TINA-ACE CASE tool
    
    Sreeram's Corba Page >> My Seminar Report >> TOOLS
    
    Tools for use with CORBA
    - NetLinks Technology's ORBitize IDL builder/browser development tool
    - Black & White Software's suite of development tools TakeFive's
    - SNiFF+ development tool
    - IDE's Software through Pictures OOA/OOD CASE tool
    - METEOR multiparadigm Workflow management system
    - ObjecTime's ObjecTime Toolset and CORBA features
    - ProtoSoft's Paradigm Plus OOA/OOD CASE tool
    - Rational's Rose OOA/OOD CASE tool
    - I-Kinetics' Database Component product
    - Sandia's IDLdoc documentation tools
    - TINA-ACE CASE tool
    Sreeram's Corba Page >> My Seminar Report >> Advantages
    
    What advantages does CORBA provide?
    1. CORBA supports many existing languages (alone/mixed).
    2. CORBA supports distribution and Object Orientation.
    3. CORBA is an industry standard ; it creates competition among vendors and ensures quality implementations.
    4. CORBA provides out-of-the-box multi-vendor inter- operability and portability.
    5. CORBA is backed by over 700 companies : hardware, software, cable and phone companies, banks, etc.
    6. CORBA offers many services called CORBAServices.
    7. CORBA is well-suited for request/response applications over lower-speed networks(eg: Ethernet and Token Ring).
    8. Many application domains (such as avionics, multimedia, and telecommunications ) require real-time guarantees from the underlying networks, operating systems, and middleware components to achieve QoS requirements and the applications in these domains must be flexible and reusable.These motivate the use of middleware like CORBA. But, the performance of CORBA implementations is not yet suited for hard real-time systems like avionics and constrained latency systems like teleconferencing.
    9. Communication software and distributed services for next - generation applications must be reliable, efficient, flexible, and reusable. These requirements motivate the use of CORBA.
    10. Synchronous and quasi-synchronous communication.
    Sreeram's Corba Page >> My Seminar Report
    
    Drawbacks of CORBA
    1. CORBA is still growing, and not fully mature.
    2. While CORBA does support a deferred synchronous request/response, it does not directly support distributed requests with callback driven response,ie. to perform an operation on a distributed object, associate a callback with the response, continue with other processing.When the server responds, the associated callback is automatically executed within the original callers application.
    3. The standard lacks many features required for putting large scale applications. Though specific vendor implemen- tations provide some of these features, they are not part of the standard today.
    4. The security aspects have not been sufficiently addressed in CORBA 2.0 These have been the major obstacles to serious and mission-critical applications development, esp. those who still employ legacy systems.
    5. Conventional implementations of CORBA are very good for slow networks like ethernet, but incur considerable over- head when used for performance-sensitive applications over high-speed networks.
      Hence, CORBA requires many optimizations :
      
      Optimizations for High-Performance
      
      Sreeram's Corba Page >> My Seminar Report >> Conclusion
      
      CONCLUSION
      
      The communications heart of object-oriented systems, CORBA, is a signal step on the road to object-oriented standardization and interoperability. With CORBA, users gain access to information transparently, without them having to know what software or hardware platform it resides on or where it is located. The ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems.
      The success of the CORBA standard has spurred research in many domains based on this technology, esp. CORBA/WWW integration. The WWW community has recognised the problems associated with URLs and are developing concepts which have much in common with CORBA's ObjRefs.
      As a technology, CORBA is maturing rapidly and its specifications have received broad industry support. But, OMG technology has had only slow acceptance as OMG/CORBA technology is an objectoriented technology for distributed computing, an area where many users are not technically ready to apply and deploy in real environments. With the recent popularity of the Internet, the future of CORBA lies greatly in its use in open distributed tools and and services. This depends on both the publicity efforts on the part of OMG in encouraging software and system vendors to use CORBA and on CORBA's technical merits in enabling true compatibility among different platforms and other internet programming languages and applications.
      
      Sreeram's Corba Page >> My Seminar Report
      
      Abbreviations used in the paper
      1. CORBA : Common Object Request Broker Architecture
      2. SOM : Systems Object Model
      3. COM : Component Object Model
      4. IOR : Interoperable Object Reference
      5. ORB : Object Request Broker
      6. BOA : Basic Object Adapter
      7. IOP : Inter ORB Protocol
      8. CIOP : Common Inter ORB Protocol
      9. IIOP : Internet IOP
      10. OMG : Object Management Group
      11. OMA : Object Management Architecture
      12. OLE : Object Linking and Embedding
      13. IDL : Interface Definition Language
      14. QoS : Quality of Service
      15. ObjRef : Object Reference
      16. DCE : Distributed Computing Environment
      Sreeram's Corba Page >> My Seminar Report
      
      REFERENCES
      
      BOOKS
    6. An Introduction to Object Oriented Programming Timothy Budd ( Addison - Wesley )
    7. Object-Oriented Concepts, Databases, Applications. Won Kim, Lochovsky ( Addison - Wesley, 1989. )
    8. The Essential Distributed Objects Survival Guide Orfali, Harkey, and Edwards (Wiley, Sept 1995)
    9. Essential CORBA: Systems Integration Using Distributed Objects: T.J. Mowbray and R. Zahavi (Wiley/OMG, 1995)
    10. CORBA Fundamentals and Programming Jon Siegel ( Wiley, 1996 )
    11. Client/Server Programming With Corba Objects Dan Harkey and Robert Orfali ( Wiley, 1997 )
    12. Corba Design Patterns Raphael C. Malveau and Mowbray ( Wiley, 1997 )
    13. CORBA Distributed Objects, using Orbix Sean Baker ( ACM Press, Addison-Wesley, 1997. )
    14. CORBA 2.0 - Praktische Einf�hrung f�r C++ und Java Jens-Peter Redlich ( Addison-Wesley, 1996. )
    15. Instant Corba Robert Orfali ( Wiley, 1997. )
    16. Java Programming With CORBA Andreas Vogel and Keith Duddy ( Wiley, 1997. )
    17. The Corba Reference Guide : Understanding CORBA Alan Pope ( Addison-Wesley, 1997. )
    18. Understanding CORBA Randy Otte et al. ( Prentice-Hall, 1996. )
    19. Next Generation Computing:Distributed Objects for Business Fingar, Dennis Read, Stikeleather ( SIGS Books )
    20. Essential Client/Server Survival Guide. Orfali, Harkey, Edwards, Reinhold ( Wiley, 1994.)
    21. The Object Management Architecture Guide. Object Management Group ( OMG, 1990. Revised, 1995 )
    22. Distributed Objects: Creating The Virtual Mainframe Katy Ring & Philip Carnelley ( Ovum books, 1995 ) INTERNET SITES:
    23. http://www.omg.org/ ( OMG Page )
    24. http://www.corba.net/ ( CORBA net )
    25. http://www.cs.wustl.edu/~schmidt/corba.html
    26. http://www.cerfnet.com/~mpcline/Corba-FAQ (CORBA FAQ)
    27. http://www.acl.lanl.gov/CORBA/corba.html
    28. http://www.reccal.ernet.in/~sree/CorbaPage.html
      NEWSGROUPS
      comp.object.*
      comp.object.corba
      comp.databases.object
      MAILING-LISTS
      [email protected] (subscribe corba-dev)
      
      Thank You very much for
      going through my Seminar Report.
      
      Please send in your suggestions and comments to
      [email protected]

Table Of Contents

2.1 Distributed Objects

2.2 Components

2.3 Supercomponents

6. Chapter 3 : Common Object Request Broker Architecture

7. Chapter 4 : CORBA Implementations and Projects

8. Chapter 5 : CORBA - Pros and Cons

ABSTRACT

INTRODUCTION

Introduction to Object Oriented Programming Concepts

What's an object after all ?

Encapsulation

Inheritance

Messages

Polymorphism

Introduction To Distributed Objects and Components

What are distributed objects ?

What Exactly Is a Component?

When Can We Expect These Components?

So, the million-dollar question is: Why didn't this happen any sooner?

Why Distributed Objects ?

The Object Management Group ( OMG )

Other CORBA related consortia:

WHAT IS CORBA???

The Basic CORBA Architecture

The Object Implementation ( ~Server )

Client

Object Request Broker (ORB)

ORB Interface

CORBA IDL stubs and skeletons ( Static Invocation Interface )

Dynamic Invocation Interface (DII)

Dynamic Skeleton Interface (DSI)

Object Adapter (OA)

The Interface Repository

CORBA Services and Interfaces

Object Services ( CORBAServices ) :

Common Facilities

Domain Interfaces

Application Interfaces

Interoperability

PERFORMANCE ISSUES

CORBA AND THE WORLD WIDE WEB

A Simple Example of Using CORBA

CORBA Implementations

Free Implementations of CORBA :

Some major projects using CORBA :

Tools for use with CORBA

What advantages does CORBA provide?

Drawbacks of CORBA

CONCLUSION

Abbreviations used in the paper

REFERENCES

BOOKS

NEWSGROUPS

MAILING-LISTS

Thank You very much for going through my Seminar Report.

Please send in your suggestions and comments to [email protected]

Thank You very much for
going through my Seminar Report.

Please send in your suggestions and comments to
[email protected]