corba 1

8/8/2019 Corba 1

1/96

8/8/2019 Corba 1

2/96

2

Early Distributed Computing

Language specific remote procedure calls

- Tightly coupled to protocol

- Tightly coupled to language semantics

- Often highly proprietary Homogenous environment

Typically one to one cardinality

- Not highly scalable

8/8/2019 Corba 1

3/96

3

What is CORBA?

Architecture for interoperable distributed computing

- Based on the OMGs Object Management Architecture

Internet Interoperability Protocol (IIOP)

Language mappings (OMG IDL)

Integrated and reusable services

8/8/2019 Corba 1

4/96

4

Distributed Object-based Systems

Goal: transparently access remote objects in a distributedsystem

Challenges:

- Ensure semantics of invoking a local object

- Accommodate heterogeneity, e.g., multiple languages, OSes,

Middleware

Object

Client Server

Object

8/8/2019 Corba 1

5/96

5

Two Examples

Common Object Request Broker Architecture (CORBA)

- International standard: multiple languages, OSes, vendors

Distributed Common Object Model (DCOM)- MS standard: only MS OSes

8/8/2019 Corba 1

6/96

6

CORBA

CORBA is similar in high level concepts to RMI

RMI is basically a simplified form ofCORBA

It Adds:

Cross-platform

Multiple language interfaces

Widely used standard

Allows programs written in various languages to communicate

with each other as would two processes in the same address space.

Features leveraged by clients:

- Invocation transparency- Implementation transparency

- Location transparency

8/8/2019 Corba 1

7/96

7

CORBA Architecture

ORB

C++ Object

Client Server

Java Object

IIOPORB

Stub ObjectAdapter

Skeleton

Remote-object: object implementation resides in serversaddress space

8/8/2019 Corba 1

8/96

8

Stub

Provides interface between client object and ORB

Marshalling: client invocation

Unmarshalling: server response

ORB

C++ Object

Client Server

Java Object

IIOPORB

Stub ObjectAdapter

Skeleton

8/8/2019 Corba 1

9/96

9

Skeleton

Provides iterface between server object and ORB

Unmarshaling: client invocation

Marshaling: server response

ORB

C++ Object

Client Server

Java Object

IIOPORB

Stub ObjectAdapter

Skeleton

8/8/2019 Corba 1

10/96

10

Object Adapters

8/8/2019 Corba 1

11/96

11

Object Adapters

Generate and interpret object references

Activate and deactivate object implementations

Handle method invocations via skeletons

Basic Object Adapter (BOA)

Portable ObjectAdapter (POA)

8/8/2019 Corba 1

12/96

12

Object Adapters

8/8/2019 Corba 1

13/96

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 BOA/ORB to begin listening for requests

Basic Object Adapter (BOA)

8/8/2019 Corba 1

14/96

14

Portable Object Adapter (POA)

Replaces BOA

- Most commercial implementations still use BOA

Expanded scope of OA to include

- Activation policies

- Threading models

- Object life cycle (transient/persistent)

- Pre/post invocation capabilities

8/8/2019 Corba 1

15/96

15

(Portable) Object Adapter(POA)

Register class implementations

Creates and destroys objects

Handles method invocation

Handles client authentication and access control

ORB

C++ Object

Client Server

Java Object

IIOPORB

Stub ObjectAdapter

Skeleton

8/8/2019 Corba 1

16/96

16

What 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

8/8/2019 Corba 1

17/96

17

Object Request Broker (ORB)

Enables object to transparently make and receive requests andresponses

...like a telephone exchange, providing the basic

mechanism for making and receiving calls

ORB

8/8/2019 Corba 1

18/96

18

Object Request Broker (ORB)

Abstracts remote request and response mechanisms

Transport fordistributingmethod invocations

ORB

Object ImplementationClient

RequestRequest

8/8/2019 Corba 1

19/96

19

ORB Usage

ORB is a singleton

ORB initialization

- Single static call to init() an ORB

- After initialization, you register objectswith the ORB using an Object Adapter

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

8/8/2019 Corba 1

20/96

20

Proxy-based Invocation

ORB

SkeletonStub

RequestRequest

Client Object Implementation

RequestRequest

8/8/2019 Corba 1

21/96

21

ORBAbstraction

How is this possible in a heterogeneous environment?

ORB

Object ImplementationClient ??JavaJava C++C++

IDLIDL

JavaJava C++C++

IDLIDL

8/8/2019 Corba 1

22/96

22

Object Request Broker ...

Communication infrastructure sending messages betweenobjects

Communication type:

- GIOP (General Inter-ORB Protocol)

- IIOP (Internet Inter-ORB Protocol) (GIOP on TCP/IP)

ORB

C++ Object

Client Server

Java Object

IIOPORB

Stub ObjectAdapter

Skeleton

8/8/2019 Corba 1

23/96

23

ORB and IIOP

The IIOP is a protocol by which ORBs communicate

8/8/2019 Corba 1

24/96

24

Internet Inter ORBProtocol (IIOP)

Transport protocol

- Defines inter ORB communication

- Runs on top of TCP/IP

- Defines CORBA messages

IIOP is a specification

- Vendors must implement to be CORBA-compliant

- Allows for multi-vendor interoperability

8/8/2019 Corba 1

25/96

25

CORBA Object

Server

Interface

IDL

C++/Java

Implementation

Interoperable Object ReferenceCORBA

Object

Servant

8/8/2019 Corba 1

26/96

26

Interoperable Object Reference (IOR)

Uniquely identifies an object (see object references)

Server

InterfaceIDL

C++/JavaImplementation


Object

Servant

8/8/2019 Corba 1

27/96

27

Interface Definition Language (IDL)

Describes interface

Language independent

Client and server platform independent

Server

Interface

IDL

C++/Java

Implementation


Object

Servant

8/8/2019 Corba 1

28/96

28

IDL (cont)

In RMI we had an RMI compiler run on the .class file wewanted to be remote. Its more complex underCORBA

The interface is written in Interface Definition Language,IDL. IDL is language-neutral (by being a different languagethan anything else) though highly reminiscent of C++(multiple inheritance, similar syntax, etc.)

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

8/8/2019 Corba 1

29/96

29

Overall CORBA Architecture

ORB

Client Server

IIOPORB

Stub ObjectAdapter

Skeleton

C++ Object IDL Java Object

Implementation

repository

Interface

repository

Implementation repository

activates registered servers on demand and locates running servers

uses the object adapter name to register and activate servers

Interface repositoryinterface repository provides information about registered IDL interfaces to clientsand servers that require it.

8/8/2019 Corba 1

30/96

8/8/2019 Corba 1

31/96

31

Development Steps

1 write the IDL file

2 compile with idltojava (stubs/skeleton generated automatically)

3 write object implementation (servant)

4 write client application

steps:

1

Stub Skeleton

Client Application Object Implementation

ORB ORB

request

response

IDL

idltojava

2

3

2

4

8/8/2019 Corba 1

32/96

32

Example ofCORBA Services

Naming: Keeps track of association between objectnames and their reference. Allows ORB to locatereferenced objects

Life Cycle: Handles the creation, copying, moving,and deletion of objects

Trader:A yellow pages for objects. Lets you findthem by the services they provide

Event: Facilitates asynchronous communicationsthrough events

Concurrency: Manages locks so objects can s

hareresources

Query: Locates objects by specified search criteria

8/8/2019 Corba 1

33/96

33

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

1. Naming Service

2. Event Management Service

3. Life Cycle Service

4. Persistent State Service

5. Transaction Service

6. Concurrency Service

7. Relationship Service

8. Externalization Service

9. Query Service

10. Licensing Service

11. Property Service

12. Time Service

13. Security Service

14. Notification Service

15. Trader Service

16. Collections Service

8/8/2019 Corba 1

34/96

34

Corba Services

Service Description

Collection Facilities for grouping objects into lists, queue, sets, etc.

Query Facilities for querying collections of objects in a declarative manner

Concurrency Facilities to allow concurrent access to shared objects

Transaction Flat and nested transactions on method calls over multiple objects

Event Facilities for asynchronous communication through events

Notification Advanced facilities for event-based asynchronous communication

Externalization Facilities for marshaling and unmarshaling of objects

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

Licensing Facilities for attaching a license to an object

Naming Facilities for systemwide name of objects

Property Facilities for associating (attribute, value) pairs with objects

Trading Facilities to publish and find the services on object has to offer

Persistence Facilities for persistently storing objects

Relationship Facilities for expressing relationships between objects

Security Mechanisms for secure channels, authorization, and auditing

Time Provides the current time within specified error margins

8/8/2019 Corba 1

35/96

35

CORBA vs. RMI

CORBA RMIPlatform independent JVM specific

Protocol independent

(IIOP)

Proprietary protocol

(JRMP)

Language

independent (IDL)

Java specific

Objects by value

(3.0)

Objects by value

(serialization)

8/8/2019 Corba 1

36/96

36

RMI Deployment

Object Implementation

Stubs Skeletons

Interface

DefinitionImplementation

Installation

Client

8/8/2019 Corba 1

37/96

8/8/2019 Corba 1

38/96

38

CORBA Features

Language independence

Location transparency

Reuse of facilities & services

OMG IDL defined interfaces

Stub & Skeleton generation

Server activation

8/8/2019 Corba 1

39/96

39

CORBAResources

Object Management Group (OMG)- www.omg.org

- www.corba.org

Discussion groups- comp.object.corba

- comp.lang.java.corba

Implementers- Inprise: www.inprise.com

- Iona: www.iona.com

- Sun: java.sun.com/products/jdk/1.2/

8/8/2019 Corba 1

40/96

40

Creating a CORBAObject

Initialize ORB and BOA

Instantiate the object

Export the object

- BOA.obj_is_ready()

Optionally register the object

- NamingContext.rebind()

Tell the ORB to begin receiving requests

- BOA.impl_is_ready()

bli t ti id i (St i [] ) {

8/8/2019 Corba 1

41/96

41

Activating the QuoteServerpublic static void main(String[] args) {

try {// Initialize object request brokerORB orb = ORB.init(args, null);

// Initialize basic object adapterBOA boa = orb.BOA_init();

// Create a new QuoteServer ...QuoteServer quoteServer = new QuoteServer();

// ... and export the objectboa.obj_is_ready(quoteServer);

// Object Request Broker InitializedSystem.out.println (QuoteServer ORB

initialized");

// Wait for incoming requestsboa.impl_is_ready();

} catch (SystemExcpetion e) {

8/8/2019 Corba 1

42/96

42

Accessing a CORBAObject

ORB uses Interoperable Object References (IORs)

Object might be local, client usesproxy

Client must acquire first object reference- Naming/Trading service

- Proprietary bind

- Proprietary URL service

- Some other proprietary means

8/8/2019 Corba 1

43/96

8/8/2019 Corba 1

44/96

44

Using a CORBAObject

Initialize the ORB on the client

Get a reference to the remote object

- IOR

-A

ctual reference (e.g. from bind()) Invoke methods

8/8/2019 Corba 1

45/96

45

Accessing the QuoteServer

// Create an object request brokerORB orb = ORB.init(args, null);// Obtain object reference for name service ...org.omg.CORBA.Object object =

orb.resolve_initial_references("NameService");// ... and narrow it to a NameContextNamingContext namingContext = NamingContextHelper.narrow(object);// Create a name component array

NameComponent name[] = { new NameComponent(QuoteServer","") };// Get a QuoteServer object reference ...org.omg.CORBA.Object objectReference = namingContext.resolve(name);// ... and narrow it to get a QuoteServerQuoteServer quoteServer = QuoteServerHelper.narrow(objectReference);// invoke methods on referenceQuote noveraQuote = quoteServer.getQuote(MCTR);

8/8/2019 Corba 1

46/96

46

Technical/Architectural Overview

CORBA facilities come in two groups:

1. horizontal facilities

target client-side functionality

2. vertical facilities

target domain-specific functionality

T h i l/A hit t l O i

8/8/2019 Corba 1

47/96

47

Technical/Architectural Overview(cont.)

Horizontal facilities specifications:

1. Mobile Agents Facility

2. Printing Facility

3. Internationalization Facility

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

1. Common Enterprise Models

2. Finance/Insurance

3. Electronic Commerce4. Manufacturing

5. Healthcare

6. Telecommunications


8/8/2019 Corba 1

48/96

48


7. Transportation

8. Life Science Research

9. Utilities

10. C4I (Command, Control, Communications, Computers, and

Intelligence)

11. Space


8/8/2019 Corba 1

49/96

49


CORBAfacilities

Obj

Obj

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 Architecture reference

model.

8/8/2019 Corba 1

50/96

50

CORBA Basics

I( )

J0

1

0

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

in te r a ce in te r a ce

s t ruc t c l ass

cons t pub l i c s t a t ic i na l

boolean boolean

c 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

sh o r t sh o r t

u n s i g n e d sh o r t sh o r t

l o n g i n t

u n s i g n e d l o n g i n t

l o n g l o n g l o n g

u n s i g n e d l o n g l o n g l o n g

loat loat

d o u b l e d o u b l eixed ( o t s p p orte i i d l j ) j a v a . m a t h . B i g D e c i m a l

se q u e n c e [] (array )

[ ] (array ) [] (array )

Fi . 6 .9 I2 3

k4 5

6

7

r8

s, t5 9 4

s@ A 8

t h4

irB @ 9 9

iA C

s t7

J@

D

@

k4 5

6

7

r8

s.

8/8/2019 Corba 1

51/96

51

CORBA Basics (cont.)

Method call types:

- synchronous

client makes call on remote blocking method

standard method call on remote service

client makes call on remote non-blocking method

remote method qualified withoneway modifier in IDL file

remote method receives only in arguments

- asynchronous

client makes synchronous call on remote method, remoteservice responds at a later time by calling method on client

must be qualified withoneway to prevent deadlock

8/8/2019 Corba 1

52/96

52

CORBA Basics (cont.)

E

liF G

tH

F

rI F

r

P . registerClient( this )

2. clent.endMessage()Q

liR S

tT S

U

sR

rV R

rT

rR

S W X

U

R T

U

lW

ckR

U

.

Deadlock caused by client calling a server that calls the client.

8/8/2019 Corba 1

53/96

53

Distributed Exceptions

CORBA specifies two exception types:

1. System Exceptions

defined for use by CORBA infrastructure

2. User Exceptions

defined using IDL by developers

Standard CORBA exceptions map to Java exceptions asfinal classes.

8/8/2019 Corba 1

54/96

54

Case Study: Chat

Chat is a basic network application using a centralbroadcasting point where a collection of clients pushes inmessages and the middleware pushes out messages.

Following use cases:

1. Connect: A client finds and connects to a chat server.

2. Disconnect: A client completes a chat session bydisconnecting from the chat server.

3. Send message: A connected client creates a chat messageand gives the message to the chat server.

4. Receive message: A connected client receives messagesdelivered by the chat server.

8/8/2019 Corba 1

55/96

55

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

Two ways to invoke a request:

1. statically using Static Invocation Interface (SII)

relies on creating a request through invoking a static method ina stub

stub generated from compile-time definition of an object type(IDL interface) and object operations (methods within IDLinterface)

2. dynamically using Dynamic Invocation Interface (DII)

programmatically creates and send invocation request directlyto ORB without assistance of stub

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

Server unaware of process that created the request.

Static Invocation Interface (SII) Dynamic Invocation

8/8/2019 Corba 1

56/96

56

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

(cont.)

Interface Repository (IR)

- contains descriptive information about distributed objects:

modules available

interfaces defined

names of operations defined within interfaces argument types

return types

exceptions raised

Steps needed to make DII call:

1. Obtain object reference to server object2. Look up desired method in Interface Repository

3. Build argument list using IRs OperationDef

4. Create and initialize Request object

5. Invoke Request and wait for call to unblock (return)

6. Get results

8/8/2019 Corba 1

57/96

57

BOAs, POAs and TIEs

Object adapter- stands between a distributed object and its ORB

- enables clients to access ORB services:

IOR generation

security activation/deactivation

OMG specified two adapter types: Object Management Group The OMG was formed in 1989 by a group of

vendors with the aim of creating a standard architecture for distributed objectsin networks.

- Basic Object Adapter (BOA)

vague definition of an adapter which led to inconsistenciesbetween different vendors implementations

- Portable Object Adapter (POA)

more widely used, even though more complex than BOAs

8/8/2019 Corba 1

58/96

58

BOAs, POAs and TIEs (cont.)

POA connects an object reference to developer-writtencode using code found in IDL generated skeleton.

- allow fine-grained control

Distributed objects inherit from a POA base definitiongenerated by IDL compiler

- enables distributed object to be usable by a POA,

- enables POA to control all access to servant through policies

8/8/2019 Corba 1

59/96

59


POA policies:

- ImplicitObjectActivation ,

tells POA outside object created servant and activated it

- IDAssignmentPolicy, and

determines who is responsible for assigning a unique ID to agiven servant

- RequestProcessingPolicy.

uses object id either to find matching servant or invoke defaultservice that uses object id to perform lookup in database

Policy combinations provide POAs with fine-grained controlover one or many servants.

8/8/2019 Corba 1

60/96

60


Another way for developer to us a POA is to wrap theirservants in a TIE.

- enables interaction with a POA without having servants objectimplementation inherit structure from POAImpl.

- servant can inherit from other base classes freely

8/8/2019 Corba 1

61/96

61

CORBA services

CORBAservices define base services and a supportstructure useful to a wide range of applications.

Five most commonly used services:

1. Naming Service

2. Security Service

3. Object Transaction Service

4. Persistent State Service

5. Event and Notification Services

8/8/2019 Corba 1

62/96

62

Naming Service

Associates name objects with arbitrary value (known asname bindings).

A path to a name binding consists of zero or more namingcontexts (a collection of unique name bindings).

Resolvinga name binding returns object associated withname.

Bindinga name creates association between a name andan object.

Multiple name bindings can point to a single object.

8/8/2019 Corba 1

63/96

63

Security Service

Consists of two levels

- Level 1

provides basic security for

1. user authentication,

2. invocation security, and

3. availability of authentication principals to security-awareapplications

allows applications to ignore system-security requirements

requires support forno delegation and single delegation

models

8/8/2019 Corba 1

64/96

8/8/2019 Corba 1

65/96

65

Object Transaction Service

Enables CORBA objects to execute as parts of distributedtransactions.

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

acronym ACID describes four standard requirements forreliable transactions:

1. Atomic completion of numerous steps must be conductedas one, otherwise each step must be undone.

2. Consistent effects of transaction are repeatable andpredictable.

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

4. Durable transaction results are persistent.

8/8/2019 Corba 1

66/96

66

Object Transaction Service (cont.)

- transactions complete in one of two ways:

1. committed

changes are made to persist

2. rolled back

changes made to data are discarded

- POAs dictate transaction types supported by servants

shared transactions

unshared transactions

shared and unshared transactions

8/8/2019 Corba 1

67/96

67

Object Transaction Service (cont.)

Concepts of transactional clients, transactional objects andrecoverable objects define the OTS.

- transactional clients interact with OTS to create and commit orrollback a transaction

- transaction objects behaviors vary when invoked within atransaction (objects data not recoverable)

- recoverable object is a transactional object in which data isrecoverable (maintain their data and capable of restoring their loststate)

Java Transaction Service (JTS) is Java implementation ofdistributed transaction service

- uses CORBA OTS specification to define protocol

8/8/2019 Corba 1

68/96

68

Persistent State Service

PersistentState Service (PSS) stores and retrievesobjects.

Abstracts interaction between objects and datastores.

PersistentState Definition Language (PSDL) defines adistributed object schema in a portable fashion.

- PSDL is a superset of IDL

defines two new constructs

storagetype

storagehome

8/8/2019 Corba 1

69/96

69

Persistent State Service (cont.)

- contains two definition types:

abstract definition

define portable definition of the persistable state of a CORBAobject

concrete definition

8/8/2019 Corba 1

70/96

70

Event and Notification Services

EventService defines mechanism that decouples deliveryof events (messages) from source of events.

- no predefined event types in specification

- keeps track of action events and event listeners

Suppliercreates events that are processed by a consumer.

Inpush model, supplier sends event messagesasynchronously to all consumers registered to receivemessages.

Inpull model, consumer polls supplier for events.


8/8/2019 Corba 1

71/96

71

Event and Notification Services(cont.)

Notification Service is a direct extension of the EventService.

- objects can create and destroy event channels arbitrarily, and canfilter output using Filter Objects and Object Constraint Language


8/8/2019 Corba 1

72/96

72


Standard flow of a StructuredEvent:

1. finding object reference to Notificaion Service (instance ofEventChannelFactory)

2. EventChannelFactory creates an EventChannel

3. supplier asks EventChannel to return SupplierAdminobject

4. SupplierAdmin returns a Consumer proxy (such asStructuredProxyPushConsumer) to an event channel

5. access to distributed events (through push or pull models) is

accessible throug

hproxy


8/8/2019 Corba 1

73/96

73


ProxySupplier

Co nsum er

EventChannel

ProxyConsumer

Supp lier

Co nsum erSupp lier

Co nsum er

Supp lier

EventChannel

Even t

Eve nt

Even t

Even t

Event

Event

Even t

C onc ep tually, a Sup plie r send s a n Event to a C onsume r.

An EventChannel dec o up les the Supp lier from the Consum er.

Adding a ProxyConsumera nd ProxySupplier ena bles further dec ouplinga nd m akes it p ossible to sup po rt bo th the push and pull models.

Supplier-to-consumer flow using the Event/Notification Service.

8/8/2019 Corba 1

74/96

74

EJBs and CORBA components

CORBA Component Model (CCM) Request for Proposal(RFP) recommends the JavaBeans component model asbasis of a server-side framework.

CORBAcomponents based on Component Implementation

Framework (CIF) architecture.

CIF defines superset ofPersistent State DefinitionLanguage called Component IDL (CIDL)

CIDL is component model forCORBA objects and a

container-programming model where CORBA componentsexist at runtime

EJBs and CORBAcomponents

8/8/2019 Corba 1

75/96

75

EJBs and CORBAcomponents(cont.)

ID L key w ords to sup p or t t h e C O RBA

C o m p o n e n t M o d e l ( C C M )

component home provides

consumes import setRaises

emits local supports

finder mu ltiple typeId

getRaises primaryKey typePrefix

Fig. 27.4 IDL keyw ords to sup p ort th e C O RBA C o m p o n e n t M o d e l.


8/8/2019 Corba 1

76/96

76

EJBs and CORBAcomponents(cont.)

Component Interface Definition Language (CIDL) is asuperset ofPersistent State Definition Language.

- defines

components in a way that enables automatic generation of

components persistence code. component implementation

state management

- compiled with a CIDL compiler

Developers organize components as an assembly with adescriptor.

- describes how components are deployed

- extension ofOpen Software Description (OSD) Format

8/8/2019 Corba 1

77/96


8/8/2019 Corba 1

78/96

78

p(cont.)

Four areas make up CCM container programming model:

1. External types

interfaces seen by client wanting to communicate withcomponent

2. Container types API component uses to communicate with runtime container

3. Container Implementation types

different containers have different relationships with surroundingsystem. Three types: stateless, conversational, and durable.Each type defines its system support

4. Component Category

where a component fits in overall framework


8/8/2019 Corba 1

79/96

79

p(cont.)

Using a containers internal interfaces, a component hasfull access to services a container supports

- Container defines APIs for:

component security

persistence

transactions

events

lifecycle

- Component implements call-back interfaces to allow container-to-component communication.

8/8/2019 Corba 1

80/96


8/8/2019 Corba 1

81/96

81

p(cont.)

Y

a b

c

d

c t Te

b

d

fd

sc r i b t i

c

S e r v i c e g

o e s n o t m a i n t a in s t a t e i nh

o r m a t io n ( c o m p l e t e l y s t a t e le s s )

g

o e s n o t h a v e a u n i q u e i d ( p r i m a r y k e y )

I m p l e m e n t s n e e d e d b e h a v io r

( e . g . , c a l c u l a t e I n t e r e s t ,

a d d I t e m T o S h o p p in g C a r t , e t c . )

i

a n u s e t r a n s a c t i o n s , i s n o t i n c l u d e d i n t h e c u r r e n tt r a n s a c t i o n

S e s s i o n p

a i n t a i n s i n t e r n a l - s t a t e inh

o r m a t i o n

q

a s a u n i q u e i d t h a t i s u s a b l e o n l y b y i ts c o n t a i n e r

I m p l e m e n t s n e e d e d b e h a v i o r

i

a n u s e t r a n s a c t i o n s , b u t i s n o t i n c l u d e d i n t h e c u r r e n t t r a n s a c t io n

p

a p s t o S e s s io n E Jr

s

E n t i t y i

o n t a i n e r - o r c o m p o n e n t - m a n a g e d p e r s i s t e n t s t a t e

q

a s a u n i q u e i d ( p r im a r y k e y )

I m p l e m e n t s n e e d e d b e h a v i o r t h a t i s o p t i o n a l l y t r a n s a c t i o n a l

p

a p s t o E n t i t y E Jr

s

s

r o c e s s i

o n t a i n e r - m a n a g e d o r c o m p o n e n t - m a n a g e d p e r s i s t e n t s ta t e th a t is i n a c c e s s i b l e t o

c l i e n t s

i

o n t a in e r - m a n a g e d o r c o m p o n e n t - m a n a g e d p e r s is t e n c e oh

t h e c o m p o n e n t s

p r i m a r y k e y ( i d e n t i t y) t i t h v i s i b i l i t y o h t h e p r im a r y k e y t h r o u g h u s e r - d e h i n e dm e t h o d s

I m p l e m e n t s n e e d e d b e h a v i o r a n d t h e b e h a v i o r i s o p t i o n a l l y t r a n s a c t io n a l

Fi . .5 C O R B A c u v w u x y x t t w y s x

y

s c r iw

t iu x

s.


8/8/2019 Corba 1

82/96

82

p(cont.)

Activation andpassivation are actions around invocationboundaries of an object operation.

- activation lifecycle

1. request arrives to ORB to invoke operation on object

2. ORB sends request to POA3. POA sends request to container managing component

4. container activates object

- passivation policies defined by components deploymentinformation


8/8/2019 Corba 1

83/96

83

p(cont.)

In distributed systems, clients dont create remote objects.Clients discoverremote objects.

- discovery through file containing objects IOR

- discovery throughNaming Service

Factories (ComponentHome instances) of remote systemscreate objects for their corresponding systems.

- component definition must define component factory

- if component persistent, must define findmethod usingcomponents primary key


8/8/2019 Corba 1

84/96

84

p(cont.)

CORBAcomponents use subset ofCORBAservices forComponentImplementation Framework.

- Security Service

every component may have own security requirement

defined in components deployment descriptor

container must keep track of active policies and apply them

- Object Transaction Service (lite version)

container can control transaction boundaries

component can control transaction boundaries

- Persistent State Service

container-managed persistence, PSS transparent to component

not ideal for all situations

component-managed persistence, should still use PSS to save state


8/8/2019 Corba 1

85/96

85

(cont.)

- Notification Service

accessed indirectly

container mediates use of event service by component

container does not preclude direct use ofNotification Service

component developers are encouraged to define events in IDL asway of keeping components functional description in one location

keywords:

publishes

any number of consumers can subscribe to an event

methods declared with publishes expected to be part ofshared interface of component

emits

only one consumer can subscribe to an event

expected to be private channel used internally by system


8/8/2019 Corba 1

86/96

86

(cont.)

CCM and EJB models are similar.

CCM specification defines two component levels

- basic

mirrors EJB model almost exactly

single threaded

uses security, transaction and persistence services only

exposes only single interface

- extended

can expose multiple interfaces advanced store types allows components to be properly

persisted

supports use of Event Services

Sun and OMG worked closely to ensure EJB model is

CCM architecture subset.

8/8/2019 Corba 1

87/96

87

CORBA vs. RMI

CORBA is comprehensive view of distributed systemsarchitecture.

RMI describes only communication proxies and protocolsbetween client object and server object.

8/8/2019 Corba 1

88/96

88

When to Use RMI

RMI suitable for smaller distributed applications in whichscalability, architecture, heterogeneity, and extensibility arenot major concerns.

Mapping of RMI and RMI capabilities to OMA

encompasses only Applications Objects and the ORB. RMI does not define Quality of Service or asynchronous

invocations.

RMI does not offerPOA or range of control offered byP

OA. RMI has dynamic class loading. CORBA places

implementation burden on clients.

8/8/2019 Corba 1

89/96

89

When to Use RMI (cont.)

RMI allows objects to participate in distributed systemsconsistently and predictably.

RMI is a natural choice for distributed systems built inJava.

A pure Java-distributed system needs to be consideredfrom an architectural perspective where distributed issuescan be discovered and resolved before the implementationissues are decided.

8/8/2019 Corba 1

90/96

90

When to Use CORBA

CORBA defines and provides implementations to manycommon requirements for most complex distributedsystems:

- architecture

- Quality of Service (QoS)- Scalability

- Heterogeneity

- Extensibility

8/8/2019 Corba 1

91/96

RMI IIOP ( )

8/8/2019 Corba 1

92/96

92

RMI-IIOP(cont.)

- runtime limitations:

sending a tree graph from ORB to ORB may be problematic ifmultiple nodes point to one object

CORBA does not define distributed garbage collection

Casting stubs may not work properly, so using the static methodnarrow of class java.rmi.PortableRemoteObject isencouraged.

RMI downloads the stubs needed by client, CORBA does not.

RMI IIOP ( t )

8/8/2019 Corba 1

93/96

93

RMI-IIOP(cont.)

- steps involved in writing distributed application using RMI-IIOP:

use javax.rmi.PortableRemoteObject instead of usingjava.rmi.UnicastRemoteObject

use JNDI (Java Naming andDirectory Interface) instead of RMIRegistry

do not downcast remote objects to subclass types; use methodnarrow of class PortableRemoteObject to cast distributedobjects as subclass types

RMIMessengerCase Study Portedt RMI IIOP

8/8/2019 Corba 1

94/96

94

to RMI-IIOP

Porting RMI messenger example (Chapter 13) to RMI-IIOP is easier than porting application to CORBA.

- remote interfaces remain same

- support classes remain same

- new implementations for

ChatServer remote interface (ChatServerImpl),

ChatServerAdministrator

MessageManager interface (RMIIIOPMessageManager)

DeitelMessenger

ChatServer RMI-IIOPI l t ti

8/8/2019 Corba 1

95/96

95

Implementation

ChatServerImpl

- implements ChatServer remote interface

subclass of class javax.rmi.PortableRemoteObject

- does not implement method register

- handles registration with name services

F t Di ti

8/8/2019 Corba 1

96/96

Future Directions

OMA guiding document forCORBA systems

- falls short in average-size systems

CORBA Component Model

- abstracts system issues through programming constructs:

containers

subsystems

CORBA working on architectural process

- Model Driven Architecture (MDA)

Expansion of OMGs architecture- maintains compatibility with previous embodiments

- gives new vitality to OMG

corba 1

Documents