New Corba New

8/8/2019 New Corba New

1/62

1

CORBA


2/62

2

Early Distributed Comp uting

Language specific remote procedure calls- Tightly coupled to protocol- Tightly coupled to language semantics

- Often highly proprietaryHomogenous environmentTypically one to one cardinality- Not highly scalable


3/62

3

Wh at is CORBA?

A rchitecture for interoperable distributed computing- Based on the OMGs Object Management A rchitecture

Internet Interoperability Protocol (IIOP)

Language mappings (OMG IDL)Integrated and reusable services


4/62

4

Distributed Object-based Systems

Goal: transparently access remote objects in a distributedsystemCh allenges:

- Ensure semantics of invoking a local object

- Accommodate h eterogeneity, e.g., multiple languages, OSes,

Middleware

Object

Client Server

Object


5/62

5

Tw o Examples

C ommon Object Request Broker Arc h itecture ( C ORBA)- International standard: multiple languages, OSes, vendors

Distributed C ommon Object Model (D C OM)- MS standard: only MS OSes


6/62

6

CORBA

C ORBA is similar in h igh level concepts to RMIRMI is basically a simplified form of C ORBAIt Adds:

C ross-platformMultiple language interfaces

Widely used standard Allows programs written in various languages to communicatewith eac h oth er as would two processes in t h e same address space.Features leveraged by clients:

- Invocation transparency- Implementation transparency- Location transparency


7/62

7

CORBA Architecture

ORB

C++ Object

Client Server

Java Object

IIOPORB

Stub Object A dapter

Skeleton

Remote-object: object implementation resides in serversaddress space


8/62

8

Stub

P rovides interface between client object and ORBMars h alling: client invocationUnmars h alling: server response

ORB

C++ Object

Client Server

Java Object

IIOPORB


Skeleton


9/62

9

Skeleton

P rovides iterface between server object and ORBUnmars h aling: client invocationMars h aling: server response

ORB

C++ Object

Client Server

Java Object

IIOPORB


Skeleton


10/62

10

O bject Ada p ters


11/62

11

O bject Ada p ters

Object Adapters provide a layer between object met h odrequests and t h e servers t h at service t h e requests.Functions include:

Generate and interpret object referencesA ctivate and deactivate object implementationsStarting up t h e actual server program(s)

Handling securityHandle method invocations via skeletonsBasic Object A dapter (BO A )Portable Object A dapter (PO A )


12/62

12

O bject Ada p ters


13/62

13

Defines how objects are activated/deactivated- Initializing server objects:

BOA.obj_is_ready( /* the object ref */ );Registers the object with the ORB

BOA.impl_is_ready();Tells the BO A /ORB to begin listening for requests

Underspecified

- Initially unclear which features would be required on various platforms

Basic O bject Ada p ter ( BOA)


14/62

14

P ortable O bject Ada p ter ( P OA)

Replaces BO A- Most commercial implementations still use BO A

Ex panded scope of O A to include- A ctivation policies- Threading models- Object life cycle (transient/persistent)- Pre/post invocation capabilities


15/62

15

(P ortable) Object Adapter (P OA)

Register class implementationsC reates and destroys objectsHandles met h od invocationHandles client aut h entication and access control

ORB

C++ Object

Client Server

Java Object

IIOPORB


Skeleton


16/62

16

Wh at is an ORB?

A distributed object bus

Hides transport mechanisms- Location

- Method invocation- Marshalling

OMG Interface Definition Language(IDL) provides the language

independent semantics

ORB


17/62

17

O bject R equest Br ok er ( ORB)

E nables object to transparently make and receive requests andresponses

...like a telephone exchange, providing the b a sicmechani sm for making and receiving call s

ORB


18/62

18

O bject R equest Br ok er ( ORB)

A bstracts remote request and response mechanismsTransport for di stri bu ting method invocations

ORB

Object ImplementationClient

RequestRequest


19/62

19

ORB Usage

ORB is a singletonORB initialization

- Single static call to init() an ORB

- A fter initialization, you register objectswith the ORB using an Object A dapter

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();


20/62

20

P r oxy-based Inv ocati on

ORB

SkeletonStub

RequestRequest

Client Object Implementation

Request Request


21/62

21

ORB Abstracti on

How is this possible in a heterogeneous environment?

ORB

Object ImplementationClient ??JavaJava C++C++IDLIDL

JavaJava C++C++

IDLIDL


22/62

22

Object Request Broker ...

C ommunication infrastructure sending messages betweenobjectsC ommunication type:

- GIO P (General Inter-ORB P rotocol)- IIOP (Internet Inter-ORB P rotocol) (GIO P on T C P/ IP )

ORB

C++ Object

Client Server

Java Object

IIOPORB


Skeleton


23/62

23

ORB and IIO P

T he IIO P is a protocol by w hich ORBs communicate


24/62

24

Internet Inter ORB P r otocol (II O P )

Transport protocol- Defines inter ORB communication- Runs on top of TCP/IP- Defines CORB A messages

IIOP is a specification- Vendors must implement to be CORB A -compliant- A llows for multi-vendor interoperability


25/62

25

CORBA Object

Server

Interface

IDL

C++/Java

Implementation

Interoperable Object ReferenceCORB A

Object

Servant


26/62

26

Interoperable Object Reference (IOR)

Uniquely identifies an object (see object references)

Server

InterfaceIDL

C++/JavaImplementation

Interoperable Object ReferenceCORBA

Object

Servant


27/62

27

Interface Definition Language (IDL)

Describes interfaceLanguage independentC lient and server platform independent

Server

InterfaceIDL

C++/JavaImplementation

Interoperable Object ReferenceCORBA

Object

Servant


28/62

28

IDL (cont)

In RMI we h ad an RMI compiler run on t h e .class file wewanted to be remote. Its more complex under C ORBA

Th e interface is written in Interface Definition Language,IDL. IDL is language-neutral (by being a different languageth an anyt h ing else) t h oug h h igh ly reminiscent of C++(multiple in h eritance, similar syntax, etc.)

IDL h as a set of primitive data types similar to mostlanguagesinteger, float, string, byte, etc.


29/62

29


30/62

30


31/62

31

Overall CORBA Architecture

ORB

Client Server

IIOPORB


Skeleton

C++ Object IDL Java Object

Implementationrepository

Interfacerepository

Implementation repositoryactivates registered servers on demand and locates running serversuses t h e object adapter name to register and activate servers

Interface repositoryinterface repository provides information about registered IDL interfaces to clientsand servers t h at require it.


32/62

32

Devel opm ent Ste p s

1 write t h e IDL file2 compile wit h idltojava (stubs /skeleton generated automatically)3 write object implementation (servant)4 write client application

steps:

1

Stub Skeleton

Client Application Object Implementation

ORB ORBrequest

response

IDL

idltojava

2

3

2

4


33/62

33

Example of CORBA Services

N aming: Keeps track of association between objectnames and t h eir reference. Allows ORB to locatereferenced objectsLife C ycle: Handles t h e creation, copying, moving,and deletion of objectsTrader: A yellow pages for objects. Lets you findth em by t h e services t h ey provideEvent: Facilitates async h ronous communicationsth roug h eventsC

oncurrency: Manages locks so objects can sh

areresourcesQuery: Locates objects by specified searc h criteria


34/62

34

CORBAservices are the baseline services available to allobjects sitting on the ORB communication bus.

1. N aming Service2. Event Management Service3. Life C ycle Service4. P ersistent State Service5 . Transaction Service6 . C oncurrency Service7 . Relations h ip Service8 . Externalization Service

9 . Query Service10. Licensing Service11. P roperty Service12. Time Service13. Security Service14. N otification Service15 . Trader Service16 . C ollections Service


35/62

35

Corba Services

Service DescriptionC ollection Facilities for grouping objects into lists, queue, sets, etc.

Query Facilities for querying collections of objects in a declarative manner C oncurrency Facilities to allow concurrent access to s h ared objects

Transaction Flat and nested transactions on met h od calls over multiple objects

Event Facilities for async h ronous communication t h roug h eventsN otification Advanced facilities for event-based async h ronous communication

Externalization Facilities for mars h aling and unmars h aling of objects

Life cycle Facilities for creation, deletion, copying, and moving of objects

Licensing Facilities for attac h ing a license to an objectN aming Facilities for systemwide name of objectsP roperty Facilities for associating (attribute, value) pairs wit h objects

Trading Facilities to publis h and find t h e services on object h as to offer P ersistence Facilities for persistently storing objects

Relations h ip Facilities for expressing relations h ips between objects

Security Mec h anisms for secure c h annels, aut h orization, and auditing

Time P rovides t h e current time wit h in specified error margins


36/62

36

RM I De p loym ent

Object Implementation

Stubs Skeletons

InterfaceDefinition

ImplementationInstallation

Client


37/62

37

CORBA De p loym ent

Object Implementation

InterfaceRepository

ImplementationRepository

Stubs Skeletons

IDL Definition ImplementationInstallation

Client


38/62

38


39/62

39

CORBA Features

Language independenceLocation transparencyReuse of facilities & services

OMG IDL defined interfacesStub & Skeleton generationServer activation


40/62

40

T echnical/Architectural Overvie w

CORBA facilities come in two groups:1. h orizontal facilities

target client-side functionality2. vertical facilities

target domain-specific functionality


41/62

41

T echnical/Architectural Overvie w (cont.)

Horizontal facilities specifications:1. Mobile Agents Facility2. P rinting Facility3. Internationalization Facility

Vertical facilities domain-specific services are beingdeveloped for various business areas:

1. C ommon Enterprise Models2. Finance /Insurance

3. Electronic C ommerce4. Manufacturing5 . Healt h care6 . Telecommunications


42/62

42


7 . Transportation8 . Life Science Researc h9 . Utilities10. C 4I (C ommand, C ontrol, C ommunications, C omputers, and

Intelligence)11. Space


43/62

43


CORBAfacilities

Ob j

Ob j

i

li

i

i

CORBAfacilitiesC ! ili

i

N "

#

#

i$ #

"

i

i i

li

i #

i " i

i i

%

i$

l

ili

&

i

'

l i i

Object Management A rchitecture referencemodel.


44/62

44

CORBA BasicsI ( ) J 0 1 0

m o d u l e p a c k a g e

in te r a ce in te r a ces t ruc t c l a s scon s t pub l i c s t a t ic i na l

boo l ean b oo l ea nc h a r c h a r

c h a r c h a r oc t e t oc t e t

s tr in g a v a .l an g . t ri n gs tr in g a v a .l an g . t ri n g

s h o r t s h o r tu n s i g n e d s h o r t s h o r tl o n g i n tu n s i g n e d l o n g i n tl o n g l o n g l o n gu n s i g n e d l o n g l o n g l o n g

loa t loa td o u b l e d o u b l e

i x ed ( o t s p p o r te i i d l j ) j a v a . m a t h . B i g D e c i m a l s e q u e n c e [ ] ( a r r ay ) [ ] ( a r r ay ) [ ] ( a r r ay )

F i . 6 .9 I 2 3 k 4 5 6 7 r 8 s, t 5 9 4 s @ A 8 t h 4 ir B @ 9 9 i A C s t 7 J @ D @ k 4 5 6 7 r 8 s.


45/62

45

Static Invocation Interface (SII), Dynamic InvocationInterface (DII) and Dynamic Skeleton Interface (DSI)

Two ways to invoke a request:1. statically using S tatic Invocation Interface ( S II)

relies on creating a request t h roug h invoking a static met h od ina stub

stub generated from compile-time definition of an object type(IDL interface) and object operations (met h ods wit h in IDLinterface)

2. dynamically using Dy namic Invocation Interface ( DII) programmatically creates and send invocation request directly

to ORB with

out assistance of stub developers responsible for guaranteeing sending proper typeand number of arguments to invocation

Server unaware of process t h at created t h e request.


46/62


47/62

47

BOAs, P OAs

Object adapter - stands between a distributed object and its ORB- enables clients to access ORB services:

IOR generation

securityactivation /deactivation

OMG specified two adapter types:

- Basic Object Adapter (BOA)vague definition of an adapter w h ich led to inconsistenciesbetween different vendors implementations


48/62

48

BOAs, P OAs (contd)

- P ortable Object Adapter ( P OA) P rovides C ORBA objects wit h a common set of met h ods for accessing ORB functions, ranging from user aut h entication to

object activation and object persistence

Basic task is to create object references and to dispatc h ORBrequests aimed at target objects to t h eir respective servants


49/62

49

BOAs, P OAs (cont.)

P OA connects an object reference to developer-writtencode using code found in IDL generated skeleton.- allow fine-grained control

Distributed objects in h erit from a P OA base definitiongenerated by IDL compiler - enables distributed object to be usable by a P OA,- enables P OA to control all access to servant t h roug h policies


50/62

5 0

BOAs, P OAs (cont.)

P OA policies:- Im plicitObjectActivation ,

tells P OA outside object created servant and activated it- I DAssign m entPolicy , and

determines w h o is responsible for assigning a unique ID to agiven servant

- RequestProcessingPolicy .uses object id eit h er to find matc h ing servant or invoke defaultservice t h at uses object id to perform lookup in database

P olicy combinations provide P OAs wit h fine-grained controlover one or many servants.


51/62

5 1

BOAs, P OAs and T IEs (cont.)

Anot h er way for developer to us a P OA is to wrap t h eir servants in a TIE.- enables interaction wit h a P OA wit h out h aving servants object

implementation in h erit structure from POA Im pl .

- servant can in h erit from ot h er base classes freely


52/62

5 2

CORBA services

C ORBAservices define base services and a supportstructure useful to a wide range of applications.Five most commonly used services:

1. N aming Service2. Security Service3. Object Transaction Service4. P ersistent State Service5 . Event and N otification Services


53/62

5 3

N aming Service

Associates name objects wit h arbitrary value (known asname bindings ).

A pat h to a name binding consists of zero or more naming contexts (a collection of unique name bindings).Resolving a name binding returns object associated wit h name.Binding a name creates association between a name andan object.

Multiple name bindings can point to a single object.


54/62

5 4

Security Service

C onsists of two levels- Level 1

provides basic security for 1. user aut h entication,2. invocation security, and3. availability of aut h entication principals to security-aware

applications

allows applications to ignore system-security requirements


55/62

55

Security Service (cont.)

- Level 2is everyt h ing level 1 provides in addition to:

1. more fine-grained user aut h entication2. greater invocation security3. auditing4. finer control over secure invocations5 . delegation6 . administrators can set security policies7 . discovery of security policies by security-aware applications8 . discovery of security policies by ORBs and ot h er services


56/62

56

Object T ransaction Service

Enables C ORBA objects to execute as parts of distributedtransactions .

- a transaction describes a collection of interactions w h ere multipleusers may access and /or modify data.

acronym A C ID describes four standard requirements for reliable transactions:

1. Atomic completion of numerous steps must be conductedas one, ot h erwise eac h step must be undone.

2. C onsistent effects of transaction are repeatable andpredictable.

3. Isolated transaction not interrupted from outside and givesno indication if execution is proceeding serially or concurrently.

4. Durable transaction results are persistent.


57/62

57

Object T ransaction Service (cont.)

- transactions complete in one of two ways:1. committed

ch anges are made to persist

2. rolled backch anges made to data are discarded

- P OAs dictate transaction types supported by servantss h ared transactionsuns h ared transactionss h ared and uns h ared transactions


58/62

58

Object T ransaction Service (cont.)

C oncepts of transactional clients, transactional objects andrecoverable objects define t h e OTS.- transactional clients interact wit h OTS to create and commit or

rollback a transaction

- transaction objects be h aviors vary w h en invoked wit h in atransaction (objects data not recoverable)

- recoverable object is a transactional object in w h ich data isrecoverable (maintain t h eir data and capable of restoring t h eir loststate)

J ava Transaction S ervice ( J T S ) is Java implementation of distributed transaction service- uses C ORBA OTS specification to define protocol


59/62

59

P ersistent State Service

P ersistent S tate S ervice ( P SS ) stores and retrievesobjects.

Abstracts interaction between objects and datastores.P

ersistent S tate Definition Language ( P

SD L) defines adistributed object sc h ema in a portable fas h ion.- P SDL is a superset of IDL

defines two new constructsstoragetype

storage h ome


60/62

6 0

P ersistent State Service (cont.)

- contains two definition types:abstract definition

define portable definition of t h e persistable state of a C ORBAobject

concrete definition


61/62

6 1

Event and N otification Services

E vent S ervice defines mec h anism t h at decouples deliveryof events (messages) from source of events.- no predefined event types in specification- keeps track of action events and event listeners

S upplier creates events t h at are processed by a consumer .In push model , supplier sends event messagesasync h ronously to all consumers registered to receivemessages.

In pull model , consumer polls supplier for events.

Event and N otification Services


62/62

Event and N otification Services(cont.)

N otification Service is a direct extension of t h e EventService.- objects can create and destroy event c h annels arbitrarily, and can

filter output using F ilter Objects and Object Constraint Language

New Corba New

Documents

Transcript of New Corba New