POSTECH DPE Lab

CORBA: Architecture, Concepts and

S/W Development

J. Won-Ki HongDistributed Processing Environment Lab

Dept. of Computer Science and EngineeringPOSTECH

Pohang, KoreaTel: +82-562-279-2244

Fax: +82-562-279-5663

Email: jwkhong@postech.ac.kr

http://www.postech.ac.kr/~jwkhong

2

POSTECH DPE Lab

Introduction

3

POSTECH DPE Lab

The Problem• Today’s computing, telecommunication and service

environments are inherently distributed and heterogenous– inter-networked computing and telecommunication devices

running different operating systems

• Distributed applications are needed in most areas– banking, retail, education, medical, government,

telecommunication, management, etc.

• Developing distributed applications whose components collaborate efficiently, reliably, transparently and scalably is very hard

4

POSTECH DPE Lab

Existing tools (Sockets, ONC, DCE) are too low-level; do not offer a unified view of all distributed applications.

Existing Tools?

• A major problem stands in the way:– There is no single, commercially available, widely

recognized & standardized integration approach and framework

5

POSTECH DPE Lab

Distributed Object Technology

• It is widely believed that an approach based on distributed object technology simplifies the problem:– offers a single view of a distributed, heterogeneous

system– three key concepts in object technology help

integration of distributed systems:• Encapsulation

• Inheritance

• Polymorphism

6

POSTECH DPE Lab

Candidate Solution: CORBA

Goals:

• Simplify development of distributed applications

• Provide flexible foundation for higher-level services

7

POSTECH DPE Lab

CORBA Overview

8

POSTECH DPE Lab

Contents

• Background & History• Object Management Architecture (OMA)• CORBA Architecture• Internet Inter-ORB Protocol (IIOP)• CORBA Services• CORBA Facilities• CORBA Implementations

9

POSTECH DPE Lab

Background & History• Object Management Group's (OMG) answer to the

need for interoperability among the rapidly proliferating number of hardware and software products available today

• CORBA Specification Version 1.1 in 1991– failed to provide out-of-box multi-vendor interoperability

among ORB implementations

• CORBA 2.0 in December 1994– defines true interoperability by specifying how ORBs from

different vendors can interoperate.

10

POSTECH DPE Lab

• Non-profit Consortium based in US, with representations in UK, Japan & Germany

• Founded in April 1989• Dedicated to creating and popularizing object-

oriented standards for application integration based on existing technology

• Object World subsidiary for market studies, training, seminars and conferences

• No internal development carried out• Over 500 members from around the world

Object Management Group

11

POSTECH DPE Lab

Object Management Architecture (OMA)

• A high-level vision of a complete distributed environment

• System Oriented Components – Object Request Broker (ORB)– Common Object Services

• Application Oriented Components– Application Objects– Common Facilities

12

POSTECH DPE Lab

Object Request Broker

Application Objects

Common Facilities

Vertical Common Facilities

Horizontal Common Facilities

UserInterface

InformationManagement

SystemsManagement

TaskManagement

Naming Persistence Life Cycle Properties Concurrency Collections Security Trader

Externalization Events Transactions Query Relationships TimeChange

ManagementLicensing

Common Object Services

13

POSTECH DPE Lab

OMA Components (1)

• Object Request Broker (ORB)– The mechanism and interfaces that enables objects to make

requests and receive responses.– Provides an infrastructure allowing objects to converse,

independent of the specific platforms and techniques used to implement the objects.

• Application Objects– specific end-user client/server applications

14

POSTECH DPE Lab

OMA Components (2)• Common Object Services

– A collection of services for maintaining objects

– Interfaces are provided to create objects, to control access to objects, to keep track of relocated objects, and to control the relationship between objects

– Event Notification, Persistence, Lifecycles, Naming, Concurrency Control, Relationships, Transactions, Collections, Externalization, Time, Security, Query Service, Licensing, Trading, Change Management, Properties, etc.

– Much of these services are currently being defined

15

POSTECH DPE Lab

OMA Components (3)• Common Facilities

– a set of generic application functions that can be configured to the specific requirements of a particular application

• e.g., printing, document management, database, and electronic mail facilities

– Horizontal Common Facilities • User Interface

• Information Management

• Systems Management

• Task Management

– Vertical Common Facilities support various vertical market segments:

• Healthcare, Retailing, CAD, etc.

– Much of these services are currently being defined

16

POSTECH DPE Lab

OMG Object Model• Underlying specification for all OMG compliant

technologies• The goal is to support interoperability and application

portability• Provides the semantics that define the interfaces that

are used to interact with the object• The basic core concepts of Object Model:

– Objects: instances of types– Operations: the actions that can be performed on data in

objects and are defined by a signature (name, parameters)– Subtyping: defining a type via inheritance

17

POSTECH DPE Lab

Common Object Request Broker Architecture (CORBA)

• An OMA-compliant ORB specification of an architecture and interface that allows an application to make request of objects (servers) in a transparent, independent manner, regardless of platform, operating system or location considerations

• Based on the OMG Object Model

18

POSTECH DPE Lab

CORBA Architecture

19

POSTECH DPE Lab

CORBA Components (1)• Object Implementation• Client• Object Request Broker (ORB) Core• ORB Interface• CORBA IDL Stubs & Skeletons• Dynamic Invocation Interface (DII)• Dynamic Skeleton Interface (DSI)• Object Adapter• Interface Repository• Implementation Repository

20

POSTECH DPE Lab

CORBA Components (2)

• Object Implementation– defines operations that implement a CORBA IDL interface.– can be written in a variety of languages including C, C++,

Java, Smalltalk, and Ada

• Client – the program entity that invokes an operation on an object

implementation

• Object Request Broker (ORB) – provides a mechanism for transparently communicating

client requests to target object implementations– makes client requests appear to be local procedure calls

21

POSTECH DPE Lab

CORBA Components (3)

• ORB Interface– an abstract interface for an ORB– de-couples applications from implementation details– provides various helper functions such as converting object

references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface

• CORBA IDL Stubs & Skeletons– the static interface between client and server– generated by an IDL compiler

22

POSTECH DPE Lab

CORBA Components (4)

• Dynamic Invocation Interface (DII)– allows a client to directly access the underlying request

mechanisms provided by an ORB

• Dynamic Skeleton Interface (DSI)– the server side's analogue to the client side's DII– 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 – provides the run-time environment for instantiating server obje

cts, passing requests to them, and assigning them object references

23

POSTECH DPE Lab

CORBA Components (5)

• Interface Repository– a run-time database that contains machine-readable version

s of the IDL-defined interfaces

• Implementation Repository– a run-time repository of information about the classes a serv

er supports, the objects that are instantiated, and their IDs

24

POSTECH DPE Lab

CORBA Inter-ORB Architecture

25

POSTECH DPE Lab

Interoperability Protocols

• General Inter-ORB Protocol (GIOP)– specifies request format and transmission protocol that

enables ORB-to-ORB interoperability

• Internet Inter-ORB Protocol (IIOP)– specifies a standardized interoperability protocol for the

Internet– works directly over TCP/IP, no RPC necessary– can be used with any transport mechanism that meets

certain requirements

• Environment-specific inter-ORB protocols (ESIOPs)– e.g., DCE

26

POSTECH DPE Lab

CORBA Implementations (1)• IONA Orbix, OrbixWeb

– http://www.iona.org• Digital ObjectBroker

– http://www.digital.com/info/objectbroker/• IBM DSOM

– http://www.software.ibm.com/ad/somobjects/• Expersoft CORBAplus

– http://www.expersoft.com/Products/products.htm• HP ORB+

– http://www.hp.com/gsy/orbplus.html• CHORUS/COOL

– http://www.chorus.com/Products/Cool/index.html• Visigenic VisiBroker

– http://www.visigenic.com/prod/vbrok/vb30DS.html

27

POSTECH DPE Lab

CORBA Implementations (2)• Sunsoft NEO

– http://www.sun.com/software/neo/• Netscape Internet Service Brokers

– http://developer.netscape.com/one/corba/• Object-Oriented Concepts, Inc. OmniBroker

– http://www.ooc.com/ob.html• Olivetti & Oracle Research Laboratory OmniORB2

– http://www.orl.co.uk/omniORB/omniORB.html• Object-Oriented Technologies Ltd. DOME

– http://www.netlink.co.uk/users/oot/dome-index.html• ICL Inc. DAIS

– http://www.iclsoft.com/sbs/daismenu.html

28

POSTECH DPE Lab

IONA’s Orbix (1)• General Features

– Orbix 1.0 (93), 2.0 (95), 2.2 (97), 2.3 (Nov. 97)– Supports C++ binding– Runs on multiple OSs (Windows 3.1, Windows 95, Windows

NT & most Unix platforms) – TCP/IP, socket(WinSock), ONC-RPC– Provides the Implementation of CORBA services

• OrbixTalk, OrbixNames, OrbixEvents, OrbixTrader, OrbixOTS, OrbixSecurity, OrbixManager

– http://www.iona.com/

29

POSTECH DPE Lab

IONA’s Orbix (2)• Integration

– Orbix for Windows: integration with Microsoft OLE & ActiveX– OrbixWeb: a full Java implementation of Orbix– Integration with Peerlogic's PIPES, Black & White Software's

UIM, Objectstore, Versant, ODAF and more.– Orbix-Isis: integration Isis Reliable run-time technology for

reliable distributed computing

• Orbix CORBA Extensions– C++ class libraries as a framework for programming– Filter: mechanism to attach one or more callback functions

to different ORB events– Smart Proxy: normal proxy(marshal) + filters(cache,

callbacks) to extend or customize

30

POSTECH DPE Lab

Digital’s ObjectBroker• General Features

– V2.7 is compliant with the CORBA 1.2 specification and parts of the CORBA 2.0 specification (including the Initialization Service)

– TCP/IP, DECnet, socket, (DCE RPC, MS COM, DECmessageQ) (DCE & Kerberos)

• Includes– Implementation Mapping Language (IML)– Method Mapping Language (MML)– Dynamic Data Exchange (DDE), Object Linking and

Embedding (OLE) interfaces• http://www.digital.com/info/objectbroker/

31

POSTECH DPE Lab

IBM’s DSOM

• SOMobject (System Object Model object)– provides an object-structured protocol that allows

applications to access objects, regardless of the programming language and regardless of where the object resides

• DSOM (Distributed SOM)– a distributed framework which ships with the SOMobjects

Toolkit and a CORBA-compliant ORB

• SOM 3.0 for AIX, OS/2 and Windows NT is freely available at http://www.software.ibm.com/ad/somobjects/

32

POSTECH DPE Lab

Expersoft CORBAplus• General Features

– CORBA 2.0 compliant ORB– available for Windows 95/NT, Solaris, HP-UX and AIX

• CORBAplus, Enterprise Edition– integration between a CORBA-based ORB and message-

oriented middleware (MOM)

• CORBAplus, Java Edition– Java/CORBA integration

• CORBAplus, ActiveX Bridge– creates a bridge from CORBA to COM (Windows apps)

• CORBAplus, Transaction Service• http://www.expersoft.com/Products/CORBAC/corbac.htm

33

POSTECH DPE Lab

Chorus’s CHORUS/COOL

• General Features– a CORBA 2.0 compliant ORB for distributed real-time

embedded systems– Optimized on CHORUS products– Supports Windows NT, Windows 95, SCO OpenServer5,

Solaris, SunOS, AIX 2.3, CHORUS/ClassiX 3.1, HP/UX, Linux 1.2

• CHIC: CHORUS IDL Compiler• CHORUS/COOL ORB 4.1 is freely available at

http://www.chorus.com/Products/Cool/index.html

34

POSTECH DPE Lab

S/W Development with CORBA

35

POSTECH DPE Lab

Contents

• CORBA Interface Definition Language (IDL)• Application Development Steps using CORBA• Servers Launching Modes• Web-based Application Development using

Java/CORBA

36

POSTECH DPE Lab

CORBA IDL (1)• Used to specify the interfaces (operations and data)

of an object• Not a programming language itself• Provides no implementation details• IDL compilers are used to compile IDL definitions and

generate language specific client and server stubs• Actual body of client and server applications are

written in ordinary programming languages (C, C++, Java, Smalltalk, etc.)

37

POSTECH DPE Lab

CORBA IDL (2)• Basic Types: long, unsigned long, short, unsigned short, float,

double, octet, char, boolean, any• Constructed Types: structure, discriminated union• Template Types : sequence, string, array• Interface

– Inheritance Specification– Type Declaration– Constant Declaration– Exception Declaration– Attribute Declaration– Operation Declaration

• Module (can be nested any number of times)– Type, Constant, and Exception Declaration– Interface Declaration– Module Declaration

38

POSTECH DPE Lab

An IDL Specification

// IDL in file grid.idl

interface Grid {

readonly attribute short height;

readonly attribute short width;

void set (in short n, in short m, in long value);

long get (in short n, in short m);

};

39

POSTECH DPE Lab

Application Development Steps using CORBA

1. Allocate Tasks

2. Define Remote Object Interfaces

3. Implement Remote Objects

4. Generate Client Stubs

5. Obtain Remote Object References

6. Invoke Remote Methods

7. Configure the System

40

POSTECH DPE Lab

From IDL to Executables

41

POSTECH DPE Lab

Allocate Tasks

• Decide how to allocate responsibilities• Client Side: UI & user input error checking• Server Side: shared resources, software that controls

access to the resources• Multi-threading allows the user some GUI interaction

event while a remote invocation is pending

42

POSTECH DPE Lab

Define Remote Object Interfaces

• Using IDL, define interfaces in terms of the operations that clients can invoke on the remote objects

interface cMSO : ObjectMIO { boolean get_attr(in Token my_token,

in SOID so_id, in OID oid, out AttrType attr) raises (InvalidSOID);

}

43

POSTECH DPE Lab

• IDL compiler generate some of the remote object’s server program (skeleton) which includes – definitions for the types defined in the IDL – codes for dispatching incoming requests– the empty bodies of the methods

CORBA::Boolean cMSO_i::get_attr (CORBA::Long my_token,SOID so_id,const char* oid, AttrType*& attr,

CORBA::Environment &IT_env) {// implementation body goes here

}

Implement Remote Objects (1)

44

POSTECH DPE Lab

Implement Remote Objects (2)• Implement the source code of these methods to

provide the remote object’s capabilities• Build a server program which activates a server

– e.g., using CORBA Basic Object Adapter (BOA)

int main() {MIO_i *mio_ptr = new MIO_i("cMSO", "tigris", 1.2);

cMSO_var cmso_ptr = new cMSO_i(mio_ptr);try {

CORBA::Orbix.impl_is_ready("cMSO");} catch (CORBA::SystemException &sysEx) { cerr << "Unexpected system exception" << endl; cerr << &sysEx;}

}

45

POSTECH DPE Lab

Generate Client Stubs• Use IDL compiler to generate client-side stub• Write a client program which invokes the remote

object interfaces• Stub relays an invocation to the real remote object

via ORB

CORBA::Boolean cMSO:: get_attr (Token my_token,SOID so_id, const char * oid, AttrType*& attr, CORBA::Environment &IT_pEnv)

throw (CORBA::SystemException,cMSO::InvalidSOID) {

{// compiler generated stub code here

}

46

POSTECH DPE Lab

Obtain Remote Object References• Obtain a reference to an instance of the remote

object’s class• Suggested mechanisms

– object_to_string(), string_to_object(): convert ORB-specific object references to a standard string form and vice-versa

– Naming Service Interface: allows remote object servers to register their objects by name

try { cmso_var = cMSO::_bind(":cMSO", host_name); } catch (CORBA::SystemException &sysEx) { cerr << "Unexpected system exception" << endl;

cerr << &sysEx; }

47

POSTECH DPE Lab

Invoke Remote Methods

• Invoke methods on an object as if it were a local object• Stub handles all of the transport-level messaging and

data marshaling

try { cmso_var->get_attr(my_token, so_id, buffer, attr); } catch (const cMSO::InvalidSOID& userEx) { cerr << "Invalid Server ID" << endl;

cerr << &userEx; } catch (CORBA::SystemException &sysEx) { cerr << "Unexpected system exception" << endl;

cerr << &sysEx; }

48

POSTECH DPE Lab

Configure the System

• Check if an ORB daemon is running on the server host

• Install the remote server program on the server host• Make its object reference available• Install the compiled stub class files and a client

program on each client host

49

POSTECH DPE Lab

Servers and Implementation Repository

• Each server has a name, unique within its host machine.

• The name of an object (object reference) contains:– A unique name within its server (object's marker)– Its server name (implementation name)– The host name of its server

• Implementation Repository maintains a mapping from a server's name to the file name of the executable code which implements that server --> the developer of the server must register it

50

POSTECH DPE Lab

Modes for Launching Servers

• Shared Mode– at most one process for any given server

• Unshared Mode– one process per active object

• Per-method-call Mode– a separate process for each operation call

• Persistent Mode– always active (i.e., not started by Object Adaptor)

51

POSTECH DPE Lab

Distributed Applications

Development using Java/CORBA

52

POSTECH DPE Lab

Introduction of CGI vs. Java/CORBA for Web-based applications

• Various applications are being developed and used in Internet/Intranet environments

• WWW Common Gateway Interface (CGI) has been used widely for providing simple Web-based client/server applications

• WWW, Java and CORBA can provide a powerful set of tools for developing and deploying distributed applications

• Java applets for WWW-downloadable client software and CORBA objects for server software

53

POSTECH DPE Lab

WWW CGI-based Application

Display request form

Display requests

WWW browser

User host

WWW browser

User host

WWW server

Spawn CGI program

CGI

Program

Server host

Resulting HTML file

HTTP:Request URL

HTTP:Download HTML with forms

HTTP:Request URL of CGI program

HTTP:Download HTML with results

54

POSTECH DPE Lab

WWW Java/CORBA-based Application

Display request form

Display requests

WWW browser

User host

WWW browser

User host

WWW server

Server hostHTTP: Request URL of applet

HTTP: Download executable applet code

CORBA: Server method invocationCORBA: method result return

Javaapplet

RemoteCORBAObject

RemoteCORBAObject

RemoteServer

55

POSTECH DPE Lab

CGI vs. JAVA/CORBA ApproachCGI Java/CORBA

Flexibility UI and operations definitions arecoupled in HTML forms.

Client limited to displaying UIand invoking remote operations.

Remote operation argumentsare string only; no structuredtypes.

UI and remote operations aredefined separately.

Client may perform other tasks inaddition to managing UI andinvoking remote operations.

Remote operation arguments maybe of any type, including structured.

Maintainability Changes to an HTML form mustbe manually accounted for in itscorresponding CGI program.

Changes to IDL can beautomatically propagated to bothclient and server via output of IDLcopiler.

ServerConfiguration

HTML files are installed on theWWW server host.

A CGI program is written tohandle one distinct remoteoperation.

The WWW server spawns a newCGI program instance to handleeach remote invocation.

Java applet client software isinstalled on the WWW server host.

A remote object server programmay be written to handle manydistinct remote operations.

A single remote object serverinstance may handle many remoteinvocations.

56

POSTECH DPE Lab

CGI vs. JAVA/CORBA ApproachCGI Java/CORBA

ClientDeployment

Automatic, on demand, viaWWW Platform independent.

Automatic, on demand, via WWWPlatform independent.

User InterfaceIntuitiveness

Developer has limited controlover UI component layout.

Developer limited to using HTMLINPUT tag components.

Developer has broad control overUI component layout.

Developer may create newcomponents with available ones.

Responsiveness Simple UI update requires downloading a new HTML files.

Each remote invocation isslowed by the spawning of a CGIprogram.

Each remote invocation slowedby acquisition of neededresources.

Client is single-threaded.

Simple UI updates are handled bythe client applet.

Each remote invocation may behandled by an already executingserver program.

Remote object server may alreadyhave acquired needed resourcewhen remote invocation arrives.

Client can exploit multi-threading.

57

POSTECH DPE Lab

Application Development Steps using Java/CORBA

• The development steps are almost identical to using CORBA only1. Allocate Tasks

2. Define Remote Object Interfaces

3. Implement Remote Objects

4. Generate Remote Object Proxies

5. Obtain Remote Object References

6. Invoke Remote Methods

7. Configure the System

• The differences are in steps 4 and 7

58

POSTECH DPE Lab

Generate Remote Object Proxies• Use IDL-to-Java compiler to generate client-side

proxy class (stub)– e.g., OrbixWeb IDL compiler

• Proxy relays an invocation to the real remote object via ORB

public boolean get_attr ( int my_token, short so_id,

String oid, MSO.AttrType attr) throws MSO._cMSO.InvalidSOID,

IE.Iona.Orbix2.CORBA.SystemException {

// compiler generated Java stub code here }

59

POSTECH DPE Lab

Configure the System

• Install the remote server program on the server host• Make its remote object’s reference available• Install the compiled Java class files of each client

applet on the WWW server host• Install an HTML file for each applet on the WWW

server host• User sites need not install any executable or data

files other than those for a Java-enabled browser

60

POSTECH DPE Lab

Summary• CORBA is more than a “hype”• Most widely-used distributed object technology today• Applications

– building distributed systems and applications– telecommunication network & management software– many other areas (such as healthcare, banking/finance, retail,

and transportation) are beginning to use CORBA

• WWW, Java and CORBA combination can provide a powerful set of tools for developing and deploying distributed applications

• Future Work– defining more object services – work on light-weight, lean, efficient ORBs– development & experience of more diverse applications

61

POSTECH DPE Lab

Useful References[1] OMG CORBA Documents, “http://www.omg.org/library/schedule/Technology_Adoptions.htm”

[2] Jon Siegel, CORBA, Fundamentals and Programming, Wiley Computer Publishing Group, 1996.

[3] R. Orfali, D. Harkey and J. Edwards, The Essential Distributed Objects, Survival Guide, John Wiley & Sons, Inc., 1996.

[4] Java CORBA Integration Strategies, “http://nittany.ca.sandia.gov:8001/java.corba.html”.

[5] CORBA for Beginners, “http://www.omg.org/news/begin.htm”.

[6] schmidt’s CORBA page (Overview, Tutorial, Papers, Researches, Product, Real-time ORB), “http://www.cs.wustl.edu/~schmidt/corba.html”.

[7] Inter Domain Management, “http://www.bell-labs.com/user/mazum/recent_work.html”.

[8] CORBA and OMG Information Resources, “http://www.acl.lanl.gov/CORBA/”.

[9] Real-time CORBA with TAO (The ACE ORB), “http://www.cs.wustl.edu/~schmidt/TAO.html”.

[10] CORBA software, “http://www.infosys.tuwien.ac.at/Research/Corba/software.html”.

[11] CORBA FAQ, “http://www.cerfnet.com/~mpcline/corba-faq/toc-alphabetical.html”.

[12] CORBA Interoperability, “http://mordor.cs.hut.fi/~kta/corba-interop/”.

[13] CorbaMan, “http://amazon.postech.ac.kr/CorbaMan”.

[14] CORBA Object Trader Service, “http://amazon.postech.ac.kr/trader.html”.

[15] MAESTRO, “http://amazon.postech.ac.kr/maestro”.

[16] Web-based Management, “http://amazon.postech.ac.kr/wbm”.