EMOS - Lecture 8.ppt

40
Modern Operating Systems Lecture 8/9 Distributed Computing & CORBA

Transcript of EMOS - Lecture 8.ppt

Page 1: EMOS - Lecture 8.ppt

Modern Operating Systems

Lecture 8/9Distributed Computing & CORBA

Page 2: EMOS - Lecture 8.ppt

2

Mainframe Data and

Applications

TerminalAccess

From Mainframe Applications...

Page 3: EMOS - Lecture 8.ppt

3

Fat ClientFat Client

UnixUnixClientClient

MacMacClientClient

WindowsWindowsClientClient

CorporateCorporateDataData

Oracle, DB2, Oracle, DB2, MS SQL, MS SQL, Informix, Informix, Sybase, etc.Sybase, etc.

Back-endData

...to Client/Server Applications...

Page 4: EMOS - Lecture 8.ppt

4

CorporateCorporateDataData

Back-endBack-endDataData

Middle TierMiddle Tier

(NT/Unix)(NT/Unix)Thin ClientThin Client

WindowsWindowsClientClient

WindowsWindowsClientClient

JavaJavaClientClientJavaJavaClientClient

BrowserBrowserClientClient

BrowserBrowserClientClient

MobileMobileClientClientMobileMobileClientClient

Middle-Tier ServicesMiddle-Tier ServicesBusiness ProcessesBusiness Processes

Oracle, DB2, Oracle, DB2, MS SQL, MS SQL, Informix, Informix, SybaseSybase

ApplicationApplication

Server:Server:

…to Multi-tier DistributedApplications

Page 5: EMOS - Lecture 8.ppt

5

Enterprise Computing

Enterprises have a variety of computing platforms Unix, 95/98/NT, AS/400, VMS, Macintosh etc.

Enterprises write applications in a variety of programming languages C, C++, Java, COBOL, Basic, Perl, Smalltalk, etc.

Enterprises need an open architecture to support the heterogeneous environment

Page 6: EMOS - Lecture 8.ppt

6

Object-Oriented Computing for the Enterprise

Enterprise applications are being written in terms of objects - reusable components that can be accessed over the enterprise network

CORBA supplies the architecture for distributed applications based on open standards

Page 7: EMOS - Lecture 8.ppt

7

Distributed Application Advantages

Scalability Server replication Thin, heterogeneous clients

Re-usability Partitioned functionality = easy updating of either clients

or servers

Page 8: EMOS - Lecture 8.ppt

14

CORBA Design Goals

Transparency: The programming language The hardware platform The operating system The specific object request broker The degree of object distribution

Open Architecture: Language-neutral Interface Definition Language (IDL) Language, platform and location transparent

Objects could act as clients, servers or both The Object Request Broker (ORB) handles interaction

between client and object

Page 9: EMOS - Lecture 8.ppt

16

CORBA Objects

OMG definition - encapsulated entity with an immutable distinct identity whose services are accessed only through well defined interfaces.

Binary components on various hosts that remote clients can access via method invocation.

How object implemented is completely transparent to client. O/S, language, compiler ..

Client does not need to know where object is or which O/S it runs under.

Interface defined by IDL.

Page 10: EMOS - Lecture 8.ppt

17

OMG Interface Definition Language

Client must know interface offered by object before invoking an operation

Objects interface: operations types of data that can be passed to/from operations

Object interface defined using IDL.

Page 11: EMOS - Lecture 8.ppt

18

Language Mappings

Specifies how IDL translated into different programming languages.

Language support varies between suppliers of ORBs. Example - C++

Interfaces mapped to classes Operations mapped to member functions of classes Object references map to the operator-> function

Page 12: EMOS - Lecture 8.ppt

19

ORBInterface

A CORBA ORB(Client)

Object Request Broker Core (IIOP)

Interface Repository

Protocol Stack

DynamicInvocation

ClientIDL Stubs

Client

Network

Page 13: EMOS - Lecture 8.ppt

20

A CORBA ORB(Server)

ImplementationRepository

ORBInterface

Object Request Broker Core (IIOP)

DynamicSkeleton

Invocation

Server

Protocol Stack

Network

StaticSkeletons

ObjectAdaptor

Page 14: EMOS - Lecture 8.ppt

21

General Request Flow

ORBInterface

Client ORB Core

ClientIDL Stubs

Client

Network

ObjectAdaptor

Server ORB Core

StaticSkeletons

ServerRequest

Page 15: EMOS - Lecture 8.ppt

22

General Request Flow

Client makes request and server receives and acts on it. Flow:

1. Client makes request using static stubs (IDL) or Dynamic Invocation Interface (DII) into ORB core linked to process.

2. Client ORB transmits request to ORB core linked with server.

3. Server ORB core dispatches request to object adapter (OA) that created target object.

4. OA dispatches request to servant (class instance in C++) that implements target object using static skeletons or Dynamic Skeleton Interface (DSI).

5. Servant returns response to client.

Page 16: EMOS - Lecture 8.ppt

23

Interface Repository

Produced by IDL compiler. Distributed database containing machine readable

version of IDL defined interfaces. Contains information describing:

Operations supported by server Parameters to operations

Used for dynamic invocation of operations Clients can query repository to find out how to invoke

operation at run-time.

Page 17: EMOS - Lecture 8.ppt

24

ImplementationRepository

Used client ORB to locate servers for requested class/operation.

Run-time repository classes supported by server instantiated objects IDs

Page 18: EMOS - Lecture 8.ppt

25

Object Request Broker - ORB

Transports a client request to a local or remote object and returns the result. Implemented as: a set of client and server side libraries zero or more daemons in between, depending on ORB

implementation ORB transparently activates objects that are not

running. Provides:

Static method invocation - defined at compile-time Dynamic method invocation - find objects at run-time

Page 19: EMOS - Lecture 8.ppt

26

Operation Invocation

Static invocation: Client IDL stubs and server IDL skeletons created from

IDL Compiler knows at compile time name and parameters of

operations - strong typing. Dynamic invocation:

Operation invocation built at run-time. No compile info - weak typing Requires access to Interface Repository service to build

requestcontains details of interfaces and typesgenerated from IDL

Page 20: EMOS - Lecture 8.ppt

27

Object Adapter (OA)

An abstract specification Part of the server-side library - the interface between the

ORB and the server process Once server registers with ORB, listens for client

connections and requests Maps the inbound requests to the desired target object

instance - makes the operation call and handles return data Real OAs:

Basic Object Adapter (BOA)requires proprietary extensions to be useful

Portable Object Adapter (POA)Permits server-side ORB-neutral code

Page 21: EMOS - Lecture 8.ppt

28

IIOP - Internet Inter-ORB Protocol

General Inter-ORB Protocol (GIOP) Abstract protocol, specifies transfer syntax and message

formats. IIOP - implementation of GIOP using TCP/IP Developers don’t need to “learn” IIOP

the ORB handles this for them Specifies common format for:

object references, known as the Interoperable Object Reference (IOR)

Messages exchanged between a client and the object

Page 22: EMOS - Lecture 8.ppt

29

Request Invocation

Clients manipulate objects by asking its ORB to send message to object via server ORB.

How does client uniquely identify object? Client needs object reference before sending messages. Object reference - handle that uniquely identifies target

object.

Page 23: EMOS - Lecture 8.ppt

30

Client Invokes Operation via Object Reference

Client ORB: Locates target object Activates server application if not running Transmits arguments for call to object Activates instance for object if necessary

Instance could be generated by factory object if used. Waits for request to complete Returns out and inout parameters and return value to

client. Returns an exception if call fails

All this is transparent to client!

Page 24: EMOS - Lecture 8.ppt

32

Object References

Only way to access an object Also called Interoperable Object Reference (IOR) Distributed computing equivalent of a pointer Analogous to C++ class instance pointers

class name{

void amethod();....

};name *pname = new name;....pname->amethod();

Object References are opaque Implementation - not real pointers!

Page 25: EMOS - Lecture 8.ppt

33

Published by server somehow. Return a reference as result of invoking an operation Advertise reference in well-known service

Naming Service, Trader Service Convert object reference to string and write to file Transmit object reference using out-of-band mechanism

EmailWeb page

Result of invoking an operation is the normal way. Others used to get first object reference.

Reference Acquisition

Page 26: EMOS - Lecture 8.ppt

34

Repository ID - used to locate detailed description of interface in Interface Repository

Endpoint Info - info required to make physical connection to server, includes: protocol address data - IP/port if IIOP is used (TCP)

or address of implementation repository that contains

location of server

Interoperable Object Reference (IOR)

Repository ID

Endpoint Info

ObjectKey ••••

Page 27: EMOS - Lecture 8.ppt

35

Object key - includes object identifier Used by server Orb/OA to identify target object in sever

for each request Server creates identifier when server creates object

reference IORs can be converted from raw reference to string

form, and back Stringified IORs can be stored and retrieved by clients

and servers using other ORBs

Interoperable Object Reference (IOR)

Repository ID

Endpoint Info

ObjectKey ••••

Page 28: EMOS - Lecture 8.ppt

36

Interoperable Object Reference (IOR)

A stringified IOR IOR:010000000e00000049444c3a48656c6c6f3a312e30

00000001000000000000003000000001010000100000003132382e3130302e3130302e313032008a040000100000000000000006a33c37c0aa080000000000

Page 29: EMOS - Lecture 8.ppt

37

Simple Example

IDLinterface Add{ short add(in short a, in short b);};

Server implements operation add() Client uses remote object to add two numbers

Page 30: EMOS - Lecture 8.ppt

38

Simple Example - Server

Create/initialise ORB and BOA

Create implementation object and tell ORB about it

Save object reference as string in file for client

Run implementation

Page 31: EMOS - Lecture 8.ppt

39

Simple Example - Client

Create/initialise ORB

Read in IOR from file for add object

Convert string version of IOR to object reference

Read in two numbers

Invoke add operation on add object

Print result

Page 32: EMOS - Lecture 8.ppt

40

CORBA Services

Collection of system-level services with IDL specified interfaces.

Provide functionality required by most distributed applications. Effectively augment functionality of ORB.

Independent of application domain. Designed according to principle:

A service does only one thing but does it well!

Page 33: EMOS - Lecture 8.ppt

41

CORBA Services

Naming Service Allows local or remote objects to be located by name.

Event Service Allows objects to dynamically register/unregister their

interest in specified events. Object will be notified when event occurs.

Many more including: Trader, Life Cycle, Persistence, Transaction, Query,

Security

Page 34: EMOS - Lecture 8.ppt

42

Naming Services

Maps human readable names to object references. Given a name the service returns an object reference. Object reference can be used to invoke operations on

object. Objects referenced by compound name

Sequence of names forming a hierarchical naming tree Analogous to directory structure

Page 35: EMOS - Lecture 8.ppt

43

Naming Services

HumansAnimals

Canine

Alsatian

Students

context namesimple name

Animals Canine Alsatian

Compound Name

Page 36: EMOS - Lecture 8.ppt

44

Naming Services

Advantage over stringified references: Client uses meaningful names instead of stringified object

references. Old version of object can be replaced by new version by

updating Name Service entry IOR for object. Solves problem of getting initial references to objects.

Page 37: EMOS - Lecture 8.ppt

45

Event Services

Allows objects (consumer) to dynamically register and unregister interest in events occurring in an object

Event - occurrence in an object (supplier) of interest to one or more objects signal a change of state of object, typically data

Notification - message sent to notify event occurred Two ways of handling events:

Event channel - standard CORBA object Point-to-point

Two models - push and pull

Page 38: EMOS - Lecture 8.ppt

46

Push Style

EventChannel ConsumerSupplier Consumer

Push Push

Object Request Broker

Event:house is on fire

Event channel handles pushes to consumers

Oh the house is on fire

Page 39: EMOS - Lecture 8.ppt

47

Pull Style

EventChannel ConsumerSupplier Consumer

Pull Pull

Object Request Broker

Event:house is on fire

• Event channel handles pull from supplier.• Event manages suppliers & consumers.

What is happening?

Page 40: EMOS - Lecture 8.ppt

48

Point-to-Point

Supplier Consumer

Push

Object Request Broker

Disadvantage:• Supplier must keep track of all consumers.• Consumer must keep track of all supplier.