Evaluation and Comparison of CORBA (Object Request Broker) Implementations

Gelbmann, Roland

Evaluation and Comparison of CORBA (Object Request Broker) Implementations

Zusammenfassung

Inhaltsangabe:Abstract:
Common Object Request Broker Architecture (CORBA), a standard from the Object Management Group (OMG), defines a vendor-independent architecture and infrastructure for distributed systems. Further CORBA species a client-server platform as well as an object-oriented programming model for distributed computing.The Object Request Broker (ORB) implements the part of CORBA which manages communication and data exchange between objects. CORBA-based applications often have to communicate with ORBs from different vendors. Therefore testing the interoperability is one important point in this work.
Six actually available ORB implementations are shown and compared at given features. If a problem has to be solved with CORBA, it is necessary to choose the best ORB implementation for that purpose, because they differ often at significant points. Important details for decision are Standard Conformity, Robustness, Functionality as well as Functional Range or Interoperability. Exactly these properties are to be examined in this work. The investigation is performed on six, at the web available ORBs indeed Jacorb 1.4 beta 2, Orbacus 4.1.0, Orbix E2A 2.0, OpenORB 1.2.0, J2SE ORB 1.4.0 as well as TAO 1.2.1 all in their most actual released version.
Additionally to these properties the correct implementation of the most important CORBA Services is checked. They are Event Service, Notification Service, Name Service and Transaction Service. The ORBs are compared at this given properties.It shows
that the ORBs differ very much from each other and that the CORBA Services are often implemented incorrectly. Further a high costly implementation is no guarantee for best quality at all points. The evaluation shows that a freely available ORB can be as good as or better than a commercial one.

Inhaltsverzeichnis:Table of Contents:
1.Introduction
1.1Motivation1
1.2Project Objectives1
1.3Related Work2
1.4Content of the following Sections2
2.CORBA Basics
2.1Overview5
2.2Major Parts of an ORB9
2.2.1Core Compnents9
2.2.2Object Adaptors11
2.3CORBA Services12
2.4OMG Interface Definition Language21
2.5BOA to POA Migration23
3.ORB Evaluation and Comparison
3.1Chosen ORBs25
3.1.1Jacorb1.4 beta225
3.1.2Orbacus 4.1.025
3.1.3OrbixE2A 2.025
3.1.4OpenORB 1.2.026
3.1.5J2SEORB 1.4.026
3.1.6TAO The Ace ORB 1.2.126
3.2Evaluation-Environment26
3.3Installation27
3.4Standard Conformity30
3.4.1Interface Definition Language30
3.4.2Basic Remote […]

Leseprobe

Inhaltsverzeichnis

ID 5602

Gelbmann, Roland: Evaluation and Comparison of CORBA (Object Request Broker)

Implementations / Roland Gelbmann - Hamburg: Diplomica GmbH, 2002

Zugl.: Wien, Technische Universität, Diplomarbeit, 2002

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die

der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,

der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der

Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,

vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im

Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der

Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem

Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche

Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten

wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht

vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder

Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.

verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2002

Printed in Germany

Abstract

Common Object Request Broker Architecture (CORBA), a standard from the Object

Management Group (OMG), defines a vendor-independent architecture and infrastruc-

ture for distributed systems. Further CORBA specifies a client-server platform as well as

an object-oriented programming model for distributed computing. The Object Request

Broker (ORB) implements the part of CORBA which manages communication and data

exchange between objects. CORBA-based applications often have to communicate with

ORBs from different vendors. Therefore testing the interoperability is one important

point in this work.

Six actually available ORB implementations are shown and compared at given features.

If a problem has to be solved with CORBA, it is necessary to choose the best ORB

implementation for that purpose, because they differ often at significant points. Im-

portant details for decision are Standard Conformity, Robustness, Functionality as well

as Functional Range or Interoperability. Exactly these properties are to be examined

in this work. The investigation is performed on six, at the web available ORBs indeed

Jacorb 1.4 beta 2, Orbacus 4.1.0, Orbix E2A 2.0, OpenORB 1.2.0, J2SE ORB 1.4.0 as

well as TAO 1.2.1 all in their most actual released version.

Additionally to these properties the correct implementation of the most important

CORBA Services is checked. They are Event Service, Notification Service, Name Service

and Transaction Service. The ORBs are compared at this given properties. It shows

that the ORBs differ very much from each other and that the CORBA Services are often

implemented incorrectly. Further a high costly implementation is no guarantee for best

quality at all points. The evaluation shows that a freely available ORB can be as good

as or better than a commercial one.

Kurzfassung

Common Object Request Broker Architecture (CORBA), ein Standard der Object Man-

agement Group (OMG), definiert eine herstellerunabh¨

angige Architektur und Infrastruk-

tur f¨

ur verteilte Systeme. Desweiteren spezifiziert CORBA eine Client-Server Plattform

und ein Modell zur objektorientierten Systementwicklung. Der Object Request Broker

(ORB) ist ein Teil von CORBA, der f¨

ur die Kommunikation und den Datenaustausch

zwischen den einzelnen Objekten verantwortlich ist. CORBA-basierte Programme kom-

munizieren meist ¨

uber ORBs unterschiedlicher Hersteller, weshalb das Testen auf Inter-

operabilit¨

at ein wichtiger Teil dieser Arbeit ist.

Es werden sechs aktuelle ORB Implementierungen gegen¨

ubergestellt und anhand vorge-

gebener Merkmale verglichen. Soll eine Aufgabenstellung mit CORBA gel¨

ost werden,

kommt es auf die Wahl der richtigen Implementierung an, da sich die verf¨

ugbaren ORBs

teilweise sehr stark voneinander unterscheiden. Dabei k¨

onnen Standardkonformit¨

at,

Robustheit, Funktionalit¨

at oder auch Funktionsumfang und Interoperabilit¨

at die aus-

schlaggebenden Punkte f¨

ur eine bestimmte Auswahl sein. Genau diese Eigenschaften

werden in der vorliegenden Arbeit f¨

ur sechs verschiedene, im Web verf¨

ugbare, ORB

Implementierungen untersucht. Ausgew¨

ahlt wurden Jacorb 1.4 beta 2, Orbacus 4.1.0,

Orbix E2A 2.0, OpenORB 1.2.0, J2SE ORB 1.4.0 sowie TAO 1.2.1 jeweils in ihren

letzten, freigegebenen Versionen.

Zus¨

atzlich zu den oben angef¨

uhrten Eigenschaften wird weiters untersucht, ob die wichtig-

sten CORBA Services implementiert wurden. Zu diesen z¨

ahlen Event Service, Notifica-

tion Service, Name Service sowie Transaction Service. Die verschiedenen ORBs werden

bez¨

uglich der angef¨

uhrten Eigenschaften und Services verglichen. Dabei wird deutlich,

dasz die einzelnen Implementierungen sehr voneinander abweichen, bzw. die Services

in einigen F¨

allen nur unzureichend oder aber sehr fehlerhaft implementiert wurden.

Desweiteren ist die teure Implementierung nicht zwangsl¨

aufig immer besser als z.B. eine

frei Verf¨

ugbare.

Acknowledgement

I want to thank Univ.Prof. Dipl.-Ing. Dr.techn. Richard Eier substitutional for the

Institute of Computer Technology, who made it possible for me to write this work.

A special thank is addressed to Univ.Ass. Dipl.-Ing. Wolfgang Radinger as well as

Dipl.-Ing. Martin Jandl, which gave me some inspirations and did the organizational

tasks.

Last but not least i want to thank my family and especially my parents for encourage-

ment and for supporting me in pushing my objectives.

iii

Danksagung

Bedanken m¨

ochte ich mich bei Univ.Prof.

Dipl.-Ing.

Dr.techn.

Richard Eier stel-

lvertretend f¨

ur das Institut f¨

ur Computertechnik, welcher es mir erm¨

oglicht hat diese

Diplomarbeit zu verfassen.

Mein besonderer Dank gilt Univ.Ass. Dipl.-Ing. Wolfgang Radinger sowie Dipl.-Ing.

Martin Jandl, die es neben einer Reihe inhaltlicher Anregungen organisatorisch m¨

oglich

gemacht haben, dasz diese Arbeit in der vorliegenden Fassung zustande gekommen ist.

Meiner Familie und besonders meinen Eltern gilt mein Dank, da sie mich immer in

meiner Absicht und im vorantreiben meiner beruflichen Ziele mit aller Kraft unterst¨

utzt

haben und mir stets mit Rat und Tat beiseite stehen.

Abbreviations

ACE

Adaptive Communication Environment

AMI

Asynchronous Method Invocation

API

Application Programming Interface

ART

Adaptive Runtime Technology

BOA

Basic Object Adapter

COMCommon Object M

odel

CORBA

Common Object Request Broker Architecture

DII

Dynamic Invocation Interface

DIOP

GIOP over UDP/IP

DLL

Dynamic Link Libraries

DSI

Dynamic Skeleton Interface

GIOP

General Interoperability Protocol

HTML

Hyper Text Markup Language

IDL

Interface Definition Language

IIOP

Internet Inter ORB Protocol

ImR

Implementation Repository

IOR

Interoperable Object Reference

Internet Protocol

Interface Repository

JDK

Java Development Kit

LAN

Local Area Network

MIOP

GIOP over Unreliable Multicast

OAD

Object Activation Daemon

OCI

Open Communication Interface

OMA

Object Management Architecture

OMG

Object Management Group

ORB

Object Request Broker

PDK

Plug-in Development Kit

Portable Interceptors

POA

Portable Object Adapter

POOP

Plain Old Orbix Protocol

RPC

Remote Procedure Call

SAAL

Signaling ATMAdaptation Layer

SCCP

Signaling Connection Control Part

SHMIOP

GIOP over Shared Memory

SOAP

Simple Object Access Protocol

SSL

Secure Sockets Layer

SSLIOP

Secure Socket Layer Inter ORB Protocol

TCP

Transmission Control Protocol

TLS

Transport Layer Security

UDP

User Datagram Protocol

UIOP

GIOP over Local IPC

CONTENTS

Contents

Introduction

1.1

M otivation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4

Content of the following Sections . . . . . . . . . . . . . . . . . . . . . .

CORBA Basics

2.1

Overview

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

M ajor Parts of an ORB . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1

Core Components

. . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.2

Object Adaptors . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3

CORBA Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4

OM G's Interface Definition Language

. . . . . . . . . . . . . . . . . . .

2.5

BOA to POA M igration . . . . . . . . . . . . . . . . . . . . . . . . . . .

ORB Evaluation and Comparison

3.1

Chosen ORBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1

Jacorb 1.4 beta 2 . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.2

Orbacus 4.1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.3

Orbix E2A 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.4

OpenORB 1.2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.5

J2SE ORB 1.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.6

TAO The Ace ORB 1.2.1 . . . . . . . . . . . . . . . . . . . . . .

3.2

Evaluation-Environment . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3

Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4

Standard Conformity . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.1

Interface Definition Language . . . . . . . . . . . . . . . . . . . .

3.4.2

Basic Remote Invocation

. . . . . . . . . . . . . . . . . . . . . .

3.4.3

Dynamic Type M anipulation . . . . . . . . . . . . . . . . . . . .

3.4.4

Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5

Throughput- and Robustness-Tests . . . . . . . . . . . . . . . . . . . . .

3.5.1

Test-Environment

. . . . . . . . . . . . . . . . . . . . . . . . . .

CONTENTS

3.5.2

Test-Description . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5.3

Test-Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5.4

Reactivation M echanism for Crashed Servers . . . . . . . . . . .

3.6

Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.7

Functional Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.8

Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.9

CORBA Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.9.1

Event Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.9.2

Notification Service

. . . . . . . . . . . . . . . . . . . . . . . . .

3.9.3

Name Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.9.4

Transaction Service

. . . . . . . . . . . . . . . . . . . . . . . . .

3.10 M iscellanea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.10.1 Requirenments . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.10.2 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.10.3 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.10.4 Vendor

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusion

4.1

Essential ORB Decision-Contributing Features . . . . . . . . . . . . . .

4.2

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A Appendix

A.1 Class-Diagrams for the generated Java Classes

. . . . . . . . . . . . . .

A.2 Stock Example IDL-Listing . . . . . . . . . . . . . . . . . . . . . . . . .

vii

Introduction

The Object Management Group (OMG) [OMG02a] is an international consortium of

over 800 companies. OMG publishes specifications of technology that are meant to en-

able the development of distributed object-oriented applications. The specifications are

submitted for technology adoption by members of the OMG who have an interest in a

specific technology. The specifications are developed and refined by a process of con-

sensus decision making. None of the member organizations can dominate or otherwise

unduly influence the process. Once published, specifications are made available free of

charge, and anyone can develop products based on these specifications.

In 1990, the OMG has introduced its Object Management Architecture (OMA), a stan-

dardized architecture for distributed computing in a heterogeneous environment. In

OMA, a pivotal role is played by the Object Request Broker (ORB), specified by the

Common Object Request Broker Architecture (CORBA).

1.1

Motivation

Over the years, both, the CORBA standard, and the implementations of CORBA have

envolved considerably. Right now, major CORBA vendors offer a range of C++ and

Java ORBs that differ in many significant aspects. For a customer who is not intimate

with the many OMG standards, it is becoming harder to assess the practical impact of

the differences between various ORB implementations.

So it is a big advantage if considering to work with CORBA to know the pros and cons

of actually available ORB implementations. With this knowledge it is easier to make

the right decision.

1.2

Project Objectives

The main goal of this work is to identify a set of criteria that would help to evaluate

an ORB implementation, and to evaluate a set of ORBs using these criteria.

The

criteria should cover those aspects of the ORB functionality that are important from the

application developer's point of view (this includes functionality specified in the OMG

standards, together with useful proprietary extensions). For testing purposes, an IDL

example is also specified, which is tested with all the compared ORB implementations.

Concrete the following six ORBs are to be compared:

· Jacorb 1.4 beta 2

· Orbacus 4.1.0

· Orbix E2A 2.0

· Open ORB 1.2.0

Introduction

1.3 Related Work

· J2SE ORB 1.4.0

· TAO The Ace ORB 1.2.1

The evaluation criteria range from standard conformity, over robustness to functional

range and interoperability. Additional the six most important CORBA Services are also

objectives of this thesis.

1.3

Related Work

An early attempt at comparing CORBA implementations can be found in [Car96], dated

1996. The attempt forms a simple set of criteria, which are, in the authors's point of

view, essential for constructing large-scaled enterprise systems. Another serious attempt

is described in [Fre97], where several ORB implementations are mutually compared. In

the following years, several other attempts appeared, mostly from the ORB vendors

themselves (simple tests showing the ORB performance compared to a couple of other

ORBs). The most serious step ahead was publishing the CORBA Comparison Project

report [CG98] on the Web. This report is significantly more thorough than any of the

comparison attempts existing before, and the work outlined in this report is also a core of

my thesis. Following this, several works based on similar tests were published at [VA99].

The work of Douglas Schmidt from the Washington University, St. Louis, U.S.A., de-

serves a special attention. It includes ORB implementation, which serves as referential

model, and series of articles of CORBA and distributed computing. Some of the arti-

cles focus on individual ORB components (e.g. multi-threading, object adapter) or on

overall performance (e.g. [ASG98], [Sch98]).

1.4

Content of the following Sections

By starting with an overview about CORBA, the background of the work is given. After

an introduction the Object Request Broker, a main point in this work, is described.

Continued by CORBA Services, the evaluated Core Services provided by CORBA are

explained. The overview ends with the OMG Interface Definition Language (IDL), which

is of interest because this work also includes an IDL example.

In Chapter 3 the work concentrates on the ORB implementations which were chosen for

evaluation. It gives a short overview about the ORBs as well as about the reason for

the decision of the ORBs.

Chapter 4 is the core evaluation and comparison of the ORBs. It confronts the ORBs in

points e.g. the Object Request Broker or the CORBA Services (only the most important

CORBA Services are chosen). It also evaluates the ORBs in miscellanea points e.g. the

requirenments or the development.

In Chapter 5 the conclusion of the work can be found and a table showing the most

important decision-constributing features of the ORBs and finally a summary closes the

work.

Introduction

1.4 Content of the following Sections

With this division it should be possible for the majority of readers to understand the

core points of this work. Nevertheless it is clear that some of technical knowledgement

should be available. Further reading about CORBA can be found at [Wil95a], [Wil95b],

and [Wil95c]. Further reading from OMG can be found at [Wil95d], [OMG94], and

[Sig96]. A reference especially for programming CORBA in Java is [GB01].

CORBA Basics

System development today is about rapid change and responding to the realities of

the business environment. The key to successful system development is how well an

enterprise can perform system integration, and finding suitable supporting technologies.

Software development itself (programming) is no longer the central issue [TJM97].

System Integration

Information systems development methods have changed from a reliance on uncon-

strained design and development to an increasing reliance on software integration meth-

ods in which new systems or applications are created by connecting existing components,

as show in figure 1.

Facilities

Management

Data

Warehouse

DBMS

Human

Resource

System

Financial

Management

System

Product

Development

Word

Processor

Forms

Spreadsheet

Figure 1: Sample Integration Scenario

These software components could have been previously developed, could be under de-

velopment, or could be acquired from a vendor. Integration is often viewed as a simpler

process than new development. Unfortunately, integration has not resulted in deploy-

ment of new capability at either a faster or a cheaper rate. This is primarily due to

the need to customize interfaces for components that were not originally designed to

work together. In addition, a networked environment requires communications across

heterogeneous hardware platforms. The time and energy spent to develop the interfaces

can easily exceed the effort required to develop the code for the functions themselves.

CORBA Basics

2.1 Overview

Other stumbling blocks to good systems integration are:

· Development and integration are fundamentally different activities requiring dif-

ferent talents and experiences.

· The potential always exists for locking into proprietary products and custom de-

velopment, limiting flexibility in the future.

· Off-the-shelf products do not always work together or meet the needs of users.

Rapid changes in the computer hardware and operating system software industries have

changed the face of information systems development. The proliferation of networks,

workstations, personal computers, and graphical user interfaces have shifted the func-

tional and economic advantage to client-server systems. An expanding software appli-

cation marketplace has produced an abundance of low cost, easy-to-use end-user ap-

plications This has also produced increasingly sophisticated users, with much higher

expectations for system performance, capability, and utility and information technology

has become a key to economic survival in the competitive global environment.

These changes have produced increased system complexity, intensified user demands, and

heightened management expectations, which have resulted in higher economic stakes

for organizations, information systems, and software developers. These pressures are

further exacerbated by the requirenment to maintain and grow a large portfolio of legacy

software and systems.

TechnologyAvailability

While system software manufacturers have long recognized the need for tools that sup-

port system integration, many have fallen short of satisfying the needs of the system

implementors. The tools that do exist consist primarily of scripting languages, code

libraries, and clipboard functions. Most of these provide only low-level communications-

oriented functions, such as sockets and remote procedure calls. Rarely do these tools

support integration across heterogeneous operating system platforms [TJM97].

2.1

Overview

Fundamentally, the Common Object Request Broker Architecture (CORBA) is a dis-

tributed object-oriented client/server platform. The idea is to provide an object-oriented

programming model for distributed computing that is as close as possible to program-

ming with ordinary objects. The job of CORBA is to take out all the low level work of

distributed programming and take the focus to the business logic.

CORBA consists of a large set of specifications that run to thousands of pages [OMG02a].

However, the fundamental services it provides can be summarized as followed:

· an object-oriented Remote Procedure Call (RPC) mechanism,

CORBA Basics

2.1 Overview

· CORBA services (such as the Naming or Trading Service),

· language mappings for different programming languages,

· interoperability protocols,

· programming guidelines and patterns.

With CORBA there should be no worry about infrastructure and ad-hoc and home-

grown communication mechanism, because it provides an open and standardized plat-

form that is both portable and scalable.

Advantages and Disadvantages of CORBA

CORBA offers quite a few advantages. Among them is the fact that CORBA is not a pro-

prietary technology, so implementations are available from a large number of vendors for

almost every imaginable combination of hardware, operating system, and programming

language. There are also a lot of open source implementations free of charge. CORBA

makes distributed programming easier. Most of the low-level and difficult work required

for distribution is capsulated, so dealing directly with the network is not needed.

On the down side, CORBA suffers from a few problems too. Because the OMG publishes

specifications, not source code, there is no reference implementation that would defini-

tively state what CORBA is. This means that specifications are sometimes too loose

or ambiguous and permit implementation behavior to diverge until the OMG catches

up with the problem and fixes the specification. Consensus decision making is also not

necessarily the best way to establish a specification. While the specification usually do

what most parties want, they are typically not as elegant or tight as they could be, due

to the need to accommodate everyone's needs.

Heterogenity

CORBA hides most of the differences that are present in heterogenous systems, which are

composed of components from different vendors that use different technologies. Specifi-

cally, CORBA provides the following features [Ion02e]:

· Location transparency:

The client does not know or care whether the target object is local to its own

address space, is implemented in a different process on the same machine, or is

implemented in a process on a different machine. Server processes are not obliged

to remain on the same machine forever; they can be moved around from machine

to machine without clients becoming aware of it.

· Server transparency:

The client does not need to know which server implements which objects.

CORBA Basics

2.1 Overview

· Language independence:

The client does not care what language is used by the server. For example, a C++

client can call a Java implementation without being aware of it. The implemen-

tation language for abjects can be changed for existing objects without affecting

clients.

· Implementation independence:

The client does not know how the implementation works. For example, the server

may implement its objects as proper C++ objects, or the server may actually

implement its objects using non-object oriented techniques, such as implementing

objects as lumps as data. The client sees the same consistent object-oriented

semantics regardless of how objects are implemented in the server.

· Architecture independence:

The client is unaware of the CPU architecture that is used by the server and is

shielded from such details as byte ordering and structure padding.

· Operating System independence:

The client does not care what operating system is used by the server. The server

may even be implemented without the support of an operating system - for exam-

ple, as a real-mode embedded program.

· Protocol independence:

The client does not know what communication protocol is used to send messages.

If several protocols are available to communicate with the server, the ORB trans-

parently selects a protocol at run time.

· Transport independence:

The client is ignorant of the transport and data link layer used to transmit mes-

sages. ORBs can transparently use various networking technologies such as Eth-

ernet, ATM, token ring, or serial lines.

The Object Management Architecture (OMA)

The Object Management Architecture (OMA) and its core, the CORBA specification

- provide a complete architectural framework that is both rich and flexible enough to

accommodate a wide variety of distributed systems. The OMA uses two related models

to describe how distributed objects and the interactions between them can be specified

in platform-independent ways. The Object Model defines how the interface of objects

distributed across a heterogeneous environment are described using an Interface Defini-

tion Language (IDL), and the Reference Model characterizes interactions between such

objects.

The Object Model defines an object as an encapsulated entity with an immutable distinct

identity whose services are accessed only through well-defined interfaces. Clients use an

CORBA Basics

2.1 Overview

object's service by issuing requests to the object. The implementation details of the

objects and its location are kept hidden from clients.

The Reference Model provides interface categories that are general groupings for object

interfaces. As figure 2 shows, all interface categories are conceptually linked by an Object

Request Broker (ORB). Generally, an ORB enables communication between clients and

objects, transparently activating those objects that are not running when requests are

delivered to them. The ORB also provides an interface that can be used directly by

clients as well as objects.

Figure 2: The Object Management Architecture (OMA)

Figure 2 shows the interface categories that use the ORB's activation and communication

facilities.

· Object Services (CORBA Services) are domain-independent interfaces used by

many dirstributed object applications. For example, all applications must obtain

references to the objects they intend to use. Both the OMG Naming Service and

the OMG Trading Service are CORBA services that allow applications to look up

and discover object references. CORBA services are normally considered part of

the core distributed computing infrastructure.

· Domain Interfaces play roles similar to those in the CORBA Services category

except that domain interfaces are domain-specific. For example, there are domain

interfaces used in health care applications that are unique to that industry, such as

a Person Identification Service. Other interfaces are specific to finance, manufac-

tureing, telecommunication, and other domains. The multiple Domain Interface

bubbles in the preceding diagram indicate this multiplicity of domains.

· Application Interfaces are developed specifically for a given application. They are

not standardized by the OMG. However, if certain application interfaces begin to

CORBA Basics

2.2 Major Parts of an ORB

appear in many different applications, they become candidates for standardization

in one of the other interface categories.

None of the interfaces in these categories are privileged in any way, and they are inde-

pendent in using [Ion02e].

2.2

Major Parts of an ORB

2.2.1

Core Components

Figure 3: Core Components of an ORB

Figure 3 shows the major components of an ORB which are:

· ORBCore:

The ORB core is proprietary to each implementation and encapsulates basic net-

working facilities. Application code does not ever access the ORB core directly,

and the proprietary interfaces and features of the core are hidden behind a facade

of standardized APIs.

· ORBInterface:

On top of the core, the ORB interface allows clients and servers to communicate

with the core. The ORB interface is standardized and the same for all clients and

servers and exists mainly for initialization purposes and a few other basic services.

· Static Stub:

The purpose of a static stub is to accept a client request and to pass it to the

ORB core, which in turn sees to it that the request makes its way to its - possibly

remote - target object. The stub is a piece of code that is generated by an Interface

Definition Language (IDL) compiler. The way IDL is compiled into a language-

specific API is standardized by language mapping specifications. This means that

CORBA Basics

2.2 Major Parts of an ORB

the static stubs offer the same interface on all ORBs. However, the specific API

is dependent on the type of object being accessed. For example, a person object

has a different interface than a car object, and the difference is reflected in the

generated API.

· Dynamic Invocation Interface:

The Dynamic Invocation Interface (DII) provides an alternate way to access remote

objects. Instead of being specific to a specific interface, the DII is general enough

that it is possible to send a request to any type of object, even an object whose

interface was unknown when the client was compiled (no IDL-generated code is

involved). The main advantage of the DII is that it does not require compile-time

knowledge of the types of objects a client can communicate with and is therefore

very flexible. The DII is usually used to implement dynamic applications, such

as debuggers and browsers, that cannot have compile-time knowledge of all the

interfaces they need to deal with. The downside of the DII is that it is much more

complex than the static stub interface. The DII interface is identical for all ORBs.

· Skeleton:

The skeleton is the server-side equivalent of a stub. It is generated from IDL - and

therefore specific to each object type - and provides an up-call interface into the

application code. In effect, it provides a callback mechanism so it is possible to

implement the behavior of the objects in the server.

· Dynamic Skeleton Interface:

The Dynamic Skeleton Interface (DSI) is the server-side equivalent of the DII.

With its help it is possible to write a server that implements objects whose type is

unknown at the time the server is written. This sounds almost like a contradiction

in terms, but makes sense when thinking about things like protocol bridges. A

bridge must accept requests for objects whose types it has never seen before and

pass them on via some other protocol, translating these requests on the fly. The

type knowledge necessary for this translation is supplied to the bridge in form of

dynamic configuration information, or taken from an Interface Repository (IR),

which is a database of IDL definitions.

· Object Adapter:

The object adapter mediates calls between the ORB and the server and serves two

main purposes:

· It keeps track of how to map incoming requests onto programming language

artifacts, such as objects or procedures. To do this, the object adapter must

know which objects exist and when objects are created or destroyed. The

object adapter therefore offers APIs that allow the application code to keep

it informed of the life cycle of objects. The object adapter is also involved in

creating and tracking the identity of objects.

· The object adapter straddles the boundary between language-independent

requests received from clients and language-dependent up-calls that need to

CORBA Basics

2.2 Major Parts of an ORB

be made to pass control to the application code in the server. For this reason,

object adapters have some components that differ for each language mapping.

Only one object adapter, the Portable Object Adapter (POA) is currently stan-

dardized. (The Basic Object Adapter (BOA) was deprecated with CORBA 2.2

and is no longer part of the standard.) However, vendors can create other object

adapters for special purposes, for example, for real-time systems or object-oriented

databases.

· Interface Repository (IR):

The IR is a run-time database that contains machine-readable versions of IDL-

defined interfaces. With the help of the IR it is possible to obtain and modify

the descriptions of all of the registered component interfaces, the methods they

support, and the parameters they require. The IR allows every component that

lives on the ORB, including the ORB, to have self-describing interfaces.

· Implementation Repository (ImR):

The ImR provides a run-time repository of information about the classes supported

by servers, the objects that are instantiated, and their IDs. It also serves as a

common place to store additional information associated with the implementation

of an ORBs. Additionally it is used by the most ORBs for starting servants on

demand as well as for automatically restarting of crashed servers.

2.2.2

Object Adaptors

Essentially the CORBA Object Adaptors are a peace of CORBA architecture, dispaching

client requests to the servants (implementations). Object Adaptors are only on the server

side.

The key functions are:

· Create CORBA Object References, which are unique values identifying the loca-

tion of each Object Implementation.

· Ensure that target objects are incarnated by servants.

· Direct requests to the servants, more exactly they connect the ORB with the

servants and they perform locating of servants and marshaling of parameters.

BOA:

The Basic Object Adaptor (BOA) was the original CORBA Object Adaptor.

The BOA was underspecified and therefore less portable between ORB implementation.

Further the BOA has no servant management.

So the Basic Object Adaptor has been removed from the CORBA standard and was

replaced by the POA.

CORBA Basics

2.3 CORBAServices

POA:

The Portable Object Adaptor (POA) provides features than the BOA. It was

introduced in CORBA 3.0. POAs are concerned with tasks such as keeping track of

which servants are currently instantiated and their addresses in memory, the activation

and deactivation of servants, the creation of object references, and various other life

cycle issues (such as permitting a servant to be deleted at a time when no operation

invocation is in progress for that servant).

The POA is now standard in CORBA and is implemented in nearly all actual ORB

implementations.

A detailed description of Object Adaptors can be found in [Ion02e], [OMG02a], [TJM97],

and [DS99].

2.3

CORBA Services

The CORBA Services are a set of enabling interfaces for globally applicable service

capabilities. In the top-level OMA, CORBA Services all reside at the same architectural

level, without an organizational structure for the services. These services are related

logically in the groups in which they were adopted with respect to the OMG's request

for proposal activities. CORBA Services are enabling services. They are primitive,

fundamental, and globally applicable.

There are over 20 different services specified by OMG. The theoretical background of

the following four Services is given, because they are part of the ORB Evaluation:

· Event Service

· Notification Service

· Name Service

· Transaction Service

Event Service

The Event Service defines generic interfaces for passing event information among mul-

tiple sources and multiple event consumers. The sources and consumers do not need to

have direct knowledge of each other, which is the primary advantage of this particular

service.

This service can also be used as a multicast capability. The service provides a general

set of mechanism for allowing multiple recipients of event information to register their

interest in events. This also allows the source of a multicast message to post it once

and have the message sent to multiple recipients without direct knowledge between the

events source and the recipients or direct connections between the two pairs of objects.

The Event Service supports multiple interaction styles. This means that there are many

ways application code can supply or consume events. The two principal styles are the

Details

Seiten
Erscheinungsform: Originalausgabe
Erscheinungsjahr: 2002
ISBN (eBook): 9783832456023
ISBN (Paperback): 9783838656021
DOI: 10.3239/9783832456023
Dateigröße: 1.6 MB
Sprache: Englisch
Institution / Hochschule: Technische Universität Wien – Informatik
Erscheinungsdatum: 2002 (Juli)
Note: 1,0
Schlagworte: open orbix orbacus jacorb
Produktsicherheit: Diplom.de

Autor

Roland Gelbmann (Autor:in)

Evaluation and Comparison of CORBA (Object Request Broker) Implementations

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Roland Gelbmann (Autor:in)