© city university london, dept. of computing distributed systems / 5 - 1 distributed systems...

© City University London, Dept. of Computing Distributed Systems / 5 - 1

Distributed Systems

Session 5:

Common Object Request Broker, (CORBA)

Christos KloukinasDept. of Computing

City University London


0.0 Review: RMI

RMI – Remote Method Invocation» RPC in Java Technology and more

» Concrete programming technology

» Designed to solve the problems of writing and organizing executable code

» Native to Java, an extension of core language

» Benefits from specific features of Java– Object serialization

– Portable, downloadable object implementations

– Java interface definitions


0.1 RMI: Benefits

Invoke object methods, and have them execute on remote Java Virtual Machines (JVMs)

Entire objects can be passed and returned as parameters» Unlike many other remote procedure call based

mechanisms requiring either primitive data types as parameters, or structures composed of primitive data types

New Java objects can be passed as a parameter» Can move behavior (class implementations) from client

to server and server to client


0.2 RMI: Benefits

Enables use of Design Patterns» Use the full power of object oriented technology in

distributed computing, such as two- and three-tier systems (pass behavior and use OO design patterns)

Safe and Secure» RMI uses built-in Java security mechanisms

Easy to Write/Easy to Use» A remote interface is an actual Java interface

Distributed Garbage Collection» Collects remote server objects that are no longer

referenced by any client in the network


0.3 RMI: Implementation


0.4 Developing RMI

Define a remote interface» define a remote interface that specifies the signatures of the

methods to be provided by the server and invoked by clients» It must be declared public, in order for clients to be able to

load remote objects which implement the remote interface. » It must extend the Remote interface, to fulfill the requirement

for making the object a remote one. » Each method in the interface must throw a java.rmi.RemoteException.


Developing RMI

Implement the remote interface Develop the server

Create an instance of the RMISecurityManager and install it

Create an instance of the remote objectRegister the object created with the RMI registry

Develop the client– First obtain a reference to the remote object from the RMI

registry


Developing RMI

Running the application» Generate stubs and skeletons - rmic» Compile the server and the client - javac» Start the RMI registry - rmiregistry

» Start the server and the client


Outline

1.0 The Object Management Group and Introduction

2.0 Object Management Architecture

3.0 CORBA Communication

4.0 Implementation, “Hello World” Example

5.0 RMI vs CORBA Comparison


Remember: Conceptual Framework

Architecture.

Accessing components from programming languages.

Interfaces to lower layers.

Component identification.

Service invocation styles.

Handling of failures.


CORBA

Object management architecture.

Accessing remote objects.

ORB interface.

Object identification

Activation strategies.

Request vs. notification.

Handling of failures.


1.0 The Object Management Group

The OMG is a non-profit consortium created in 1989 with the purpose of promoting theory and practice of object technology in distributed computing systems to reduce the complexity, lower the costs, and hasten the introduction of new software applications.

Originally formed by 13 companies, OMG membership grew to over 500 software vendors, developers and users.

OMG realizes its goals through creating standards which allow interoperability and portability of distributed object oriented applications. They do not produce software or implementation guidelines.


1.1 CORBA (Common Object Request Broker Architecture)

Specification by OMG of an OO infrastructure for Distributed Computing.

Defines Object Request Broker and IDL Enables Software interoperability across languages

and platforms Applicable to legacy, commercial-off-the-shelf(COTS)

integration and new software development CORBA is just a specification for creating and using

distributed Objects, it is an integration technology NOT a programming language


1.2 CORBA: A Specification Takes care of cross-language issues automatically Uses OMG IDL (Interface Definition Language

Runs over IIOP (Internet Inter-Orb Protocol)

Java Client

Cobol Client

Java Object

C++Object

CORBA/IIOP

CORBA/IIOP

CORBA/IIOP


1.3 CORBA Concepts

CORBA’s theoretical underpinnings are based on three important concepts;» An Object-Oriented Model

» Open Distributed Computing Environment

» Component Integration and Reuse CORBA Provides

» Uniform access to services» Uniform discovery of resources and object names» Uniform error handling methods

» Uniform security policies


1.4 . The OMG Object Model

The OMG Object Model defines common object semantics for specifying the externally visible characteristics of objects in a standard and implementation-independent way.

In this model clients request services from objects (which will also be called servers) through a well-defined interface.

This interface is specified in OMG IDL (Interface Definition Language). A client accesses an object by issuing a request to the object.

The request is an event, and it carries information including an operation, the object reference of the service provider, and actual parameters (if any).


1.5 About CORBA Objects

CORBA objects differ from typical objects in 3 ways» CORBA objects can run on any platform.» CORBA objects can be located anywhere » CORBA Objects can be written in any language that has an

IDL mapping A CORBA object is a virtual programming entity that

consists of an identity, an interface, and an implementation which is known as a Servant.» It is virtual in the sense that it does not really exist unless it is

made concrete by an implementation written in a programming language


1.6 Objects and Applications

CORBA applications are composed of objects. Typically, there are many instances of an object of a single

type - for example, an e-commerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer, and contains data representing the merchandise that its particular customer has selected.

For other types, there may be only one instance. When a legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on the network, there is usually only one instance.


2.0 Object Management Architecture (OMA)

ApplicationObjects

CORBA facilities

CORBA services

Object Request Broker


2.1 OMA Model CORBA is based on the object model, derived from the abstract core object

model of OMG’s OMA (Object Management Architecture) OMA groups objects into four categories

» CORBAservices» CORBAfacilities» CORBAdomain» Application object

O

M

A

CORBA


2.2 CORBAservices

CORBAservices» Provide basic functionality, that almost every object needs

– Naming Service-name binding ,associating names and references

– Event Service- asynchronous event notification

– Concurrency Control Service-mediates simultaneous access

CORBA facilities (sometimes called Horizontal CORBAfacilities)» Between CORBAservices and Application Objects» Potentially useful across business domains

– Printing, Secure Time Facility, Internationalization Facility, Mobile Agent Facility.


2.3 OMA model

Domain (Vertical) CORBAfacilities» Domain-based and provide functionality for

specific domains such as telecommunications, electronic commerce, or health care.

Application Objects» Topmost part of the OMA hierarchy

» Customized for an Individual application, so do not need standardization


2.4 CORBA Architecture

Dynamic Dynamic InvocationInvocation

ClientClientStubsStubs

ORBORBInterfaceInterface

ServerServerSkeletonSkeleton

ObjectObjectAdapterAdapter

ORB CoreORB Core

ClientClient Object ImplementationObject Implementation


CORBA Architecture

Client

DynamicInvocation

ORBInterface

DynamicSkeleton

StaticSkeleton

Stub

ObjectAdapter

Object Implementation(Servant)

Object Request Broker (ORB)

Interface identical for all ORB implementations There maybe multiple object adapters There are stubs and skeletons for each object type

Up-call interface

Normal call interfaceORB-dependent interface


2.5 CORBA Architecture

A general CORBA request structure

IIOP

Request from a client to an object implementation

Request

A request consists of•Target object (identified by unique object reference)

•Operation.

•Parameters (the input, output, and in-out parameters defined for the operation; maybe specified individually or as a list

•Optional request context

•Results (the results values returned by operation)


2.6 CORBA Architecture CORBA is composed of five major components;

» ORB,

» IDL,

» Dynamic Invocation Interface (DII),

» Interface Repositories (IR),

» Object Adapters (OA),

» Inter-Orb Protocol (IIOP)

CORBA provides both static and dynamic interfaces to its services

Happened because two strong proposals from HyperDesk and Digital based on a Dynamic API & from SUN and HP based on a static API. “Common” stands for a two-API proposal


2.7 Object Request Broker, ORB Core of CORBA, middleware that establishes the client/server

relationship between objects This is the object manager in CORBA, the software that

implements the CORBA specification, (implements the session, transport and network layers), provides object location transparency, communication and activation, i.e» Find object implementation for requests (provide location transparency)» Prepare the object implementation to receive request» Communicate the data making up request.

(Vendors & Products: ORBIX from IONA, VisiBroker from Inprise, JavaIDL from javasoft)


2.8 CORBA Architecture: ORB On the client side the ORB is responsible for

» accepting requests for a remote object» finding the implementation of the object» accepting a client-side reference to the remote object (converted to a

language specific form, e.g. a java stub object)» Routing client method calls through the object reference to the object

implementation

On the Server side» lets object servers register new objects» receives requests from the client ORB» uses object’s skeleton interface to invoke the object activation method» Creates reference for new object and sends it back to client.


2.9 CORBA Architecture: Stubs,Skeletons Client Stub

» provides the static interfaces to object services. These precompiled stubs define how clients invoke corresponding services on the server. From a client’s perspective, the stub acts like a local call- it’s a local proxy for a remote server object. Generated by the IDL compiler (there are as many stubs as there are interfaces!)

Server Skeleton» provides static interfaces to each service exported by the server. Performance

unmarshalling, and the actual method invocation on the server object ORB Interface

» Interface to few ORB operations common to all objects, e.g. operation which

returns an object’s interface type.


2.10 CORBA Architecture: Servant &Clients

Object -- This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant.

Servant -- This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.

Client -- This is the program entity that invokes an operation on an object implementation. 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. The remaining components help to support this level of transparency.


2.11 CORBA Architecture: DII

Dynamic Invocation Interface (DII)» Static invocation interfaces are determined at compile

time, and they are presented to the client using stubs

» The DII allows client applications to use server objects without knowing the type of objects at compile time

– Client obtains an instance of a CORBA object and makes invocations on that object by dynamically creating requests.

» DII uses the interface repository to validate and retrieve the signature of the operation on which a request is made


2.12 CORBA Architecture: DSI

Dynamic Skeleton Interface (DSI)» Server-side dynamic skeleton interface» Allows servers to be written without having skeletons, or

compile time knowledge for which objects will be called remotely

» Provides a runtime binding mechanism for servers that need to handle incoming method calls for components that do not have IDL-based compiled skeletons

» Useful for implementing generic bridges between ORBs» Also used for interactive software tools based on

interpreters and distributed debuggers


2.13 CORBA Architecture: IR

Interface Repository» allows YOU to obtain and modify the descriptions of all

registered component interfaces(method supported, parameters i.e method signatures)

» It is a run-time distributed database that contains machine readable versions of the IDL interfaces

» Interfaces can be added to the interface repository» Enable Clients to;

– locate an object that is unknown at compile time– find information about its interface– build a request to be forwarded through the ORB


2.13 CORBA Architecture: OA Object Adapter (OA) e.g (Basic-BOA or Portable-POA)

» Purpose:interface an object’s implementation with its ORB

» Primary way that an object implementation accesses services provided by the ORB.

» Sits on top of the ORB’s core communication services and accepts requests for service on behalf of server objects, passing requests to them and assigning them IDs (object references)

» Registers classes it supports and their run-time instances with the implementation repository

» In summary, its duties are:

– Object reference generation, and interpretation, method invocation, security of interactions, and implementation of object activation and de-activation


2.14 Implementation Repository

Provides a run-time repository of information about classes a server supports, the objects that are instantiated and their IDs

Also serves as a common place to store additional information associated with implementations of ORBS» e.g. trace information, audit trails and other

administrative data


2.15 Summary of CORBA Interfaces

Interface and Implementation Repositories

Accessesincludes includes Decsribes

•All objects are defined in IDL by specifying their interfaces

•Object definitions (interfaces) are manifested as objects in the interface repository, compiled to stubs and skeletons

•Descriptions of object implementations are maintained as objects in the implementation repository







ORB CoreORB Core

2.16 Accessing Remote Objects

ClientClient Object ImplementationObject Implementation


2.17 Client Side




ClientClient

Clients perform requests using object references

Clients May issue requests through object interface stubs (static) or dynamic invocation interface (Dynamic)

Clients may access general ORB services:

•Interface Repository

•Context management

•List Management

•Request Management


2.18 Implementation Side (Server side)

Implementations receive requests through skeletons (without knowledge of invocation approach)




Object ImplementationObject ImplementationThe object Adapter provides for:

•Management of references;

•Method invocation;

•authentication

•implementation registration

•activation/deactivation



CORBA Spec Neutral w.r.t network protocols» CORBA specifies GIOP, a high level standard protocol for

communication between ORBs

Generalized Inter-ORB Protocol (GIOP) is a collection of message requests an ORB can make over a network

GIOP maps ORB requests to different transports» Internet Inter-ORB Protocol (IIOP) uses TCP/IP to carry the messages,

hence fits well into Internet world

» Environment Specific Inter-ORB Protocol (ESIOP) complements GIOP enabling interoperability with environments not having CORBA support



GIOP contains specifications for» Common Data Representation (CDR)

» Message formats (Reply, Request, LocateReply, LocateRequest, CancelRequest, etc)

» Message transport assumptions– Connection-Oriented

– Reliable

– A Byte Stream Protocol


3.2 Communication: Inter-Orb Architecture

CORBA IDL

General Inter-ORBProtocol (GIOP)

Internet Inter-ORB

Protocol(IIOP)

TCP/IP

Internet

Others for example

OSI andIPX/SPX

Object Request Semantics

Transfer and Message Syntax

Transports


3.3 Other Features

CORBA Messaging» CORBA 2.0 provides three different techniques for

operation invocations:– Synchronous The client invokes an operation, then pauses,

waiting for a response

– Deferred synchronous The client invokes an operation then continues processing. It can go back later to either poll or block waiting for a response

– One-way The client invokes an operation, and the ORB provides a guarantee that the request will be delivered. In one-way operation invocations, there is no response


3.4 New Features

» Two newer, enhanced mechanisms are introduced– Callback The client supplies an additional object reference

with each request invocation. When the response arrives, the ORB uses that object reference to deliver the response back to the client

– Polling The client invokes an operation that immediately returns a valuetype that can be used to either poll or wait for the response

» The callback and polling techniques are available for clients using statically typed stubs generated from IDL interfaces (not for DII)


4.0 Implementation

Implementation


4.0 How to Write CORBA Applications

Create IDLdefinition

Server Skeleton

Example Servant Client IDL Stub

Implement Client

javac

Implementationrepository

Start server

Interface repository

Server Client

idl

Implement Servant

javacStart client

Object Adapter

load

is used by

instantiates


4.1 Example: Hello world ID

module HelloApp

{

interface Hello

{

string sayHello();

};

};


4.2 Example: Hello World Serverimport HelloApp.*;import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*; class HelloServant extends _HelloImplBase { public String sayHello() { return "\nHello world !!\n"; }} public class HelloServer { public static void main(String args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // create servant and register it with the ORB HelloServant helloRef = new HelloServant(); orb.connect(helloRef);

// get the root naming context org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); // bind the Object Reference in Naming NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; ncRef.rebind(path, helloRef); // wait for invocations from clients java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait(); } } catch (Exception e) {…} }}

Server Skeleton

Servant

ORB interface

Binding


4.3 Example: Hello World Client

import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CORBA.*; public class HelloClient { public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); // create and initialize the ORB // get the root naming context org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef);

// resolve the Object Reference in Naming NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; Hello helloRef = HelloHelper.narrow(ncRef.resolve(path)); // call the Hello server object and print results String hello = helloRef.sayHello(); System.out.println(hello); } catch (Exception e) {…} }}

Casting

Service Request


4.4 Static vs. Dynamic Invocation

Static invocation: IDL operations must have

been defined before client can be developed.

Does not suit every application (Example?)

Dynamic invocation interface enables clients

to define operation invocations at run-time.

Interface repository can be used to ensure

that calls are type safe.


4.5 ORB Interface

Object type Object.

Initialisation of object request broker.

Initialisation of client / server applications.

Programming interface to interface repository.


4.6 Object Identification

Objects are uniquely identified by object identifiers. Object identifiers are persistent. Identifiers can be externalised (converted into

string) and internalised. Identifiers can be obtained

» from a naming or a trading service,

» by reading attributes,

» from an operation result or

» by internalising an externalised reference.


C

4.7 Activation Strategies

Basic ObjectAdapter

ProcessObject

A

B

D A Shared ServerB Unshared ServerC Server per methodD Persistent server

RegistrationActivation


3.5 Request vs. Notification

IDL operations are handled synchronously. For notifications, it may not be necessary to

await the server, if operation does not» have a return value,

» have out or inout parameters and

» raise specific exceptions.

Notification can be implemented as oneway operations in IDL.

Client continues after notification is delivered.


3.5 Notification (Example)

/* person.idl */

enum sex_type {

FEMALE, MALE

};

struct Person {

string first_name;

string last_name;

sex_type sex;

string city;

};

interface PersonManager {

oneway void print(in Person);

long store(in Person pers);

Person load(in long pers_id);

};


3.6 Failures

CORBA operation invocations may fail for the same reasons as RMIs.

Exceptions give detailed account why an operation has failed.

System vs. application specific exceptions.


CORBA AND JAVA

1997: RMI Introduced with JDK1.1 1998: JavaIDL with JDK1.2 – Java ORB supporting

IIOP. ORB also supports RMI over IIOP remote objects written in the Java programming language accessible from any language via IIOP

CORBA provides the network transparency, Java provides the implementation transparency


4 Comparison

RMI architecture lacks interface repository (but

has reflection).

IDL and RMI allow for:» inheritance,

» attributes and

» exceptions. (These three are missing in RPC)

IDL has multiple standardised language

bindings. RMI is part of JAVA, RPC goes with C

and C++


4 Comparison (cont´d)

RMIs are lightweight.

Component identification is reflexive in IDL and RMI, as opposed to RPC.

Basic object adapter provides more flexible activation strategies.

Oneway operations can be used for asynchronous notifications.


4 Comparison (cont´d)

RMIs may be more efficient than CORBA operation invocations.

RMI comes with JAVA, whilst you would have to obtain a CORBA product (open-source ones exist).


6.2 RMI vs CORBA (ctd.)

Relatively speaking, RMI can be easier to master, especially for experienced Java programmers, than CORBA. CORBA is a rich, extensive family of standards and interfaces, and delving into the details of these interfaces is sometimes overkill for the task at hand.


6.3 RMI vs CORBA (ctd.)

CORBA is a more mature standard than RMI, and has had time to gain richer implementations. The CORBA standard is a fairly comprehensive one in terms of distributed objects, and there are CORBA implementations out there that provide many more services and distribution options than RMI or Java. The CORBA Services specifications, for example, include comprehensive high-level interfaces for naming, security, and transaction services.


6.4 The Bottom Line

So which is better, CORBA or RMI? Basically, it depends. If you're looking at a system that you're building from scratch, with no hooks to legacy systems and fairly mainstream requirements in terms of performance and other language features, then RMI may be the most effective and efficient tool for you to use.

On the other hand, if you're linking your distributed system to legacy services implemented in other languages, or if there is the possibility that subsystems of your application will need to migrate to other languages in the future, or if your system depends strongly on services that are available in CORBA and not in RMI, or if critical subsystems have highly-specialized requirements that Java can't meet, then CORBA may be your best bet.

© city university london, dept. of computing distributed systems / 5 - 1 distributed systems...

Documents

distributed computing

remote interface

computing distributed

remote objects

remote server objects

distributed systems

rmi registry slide

developing rmi