CORBA

1
 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

2
 What is CORBA?

 Architecture for interoperable distributed computing

- Based on the OMG’s Object Management Architecture
 Internet Interoperability Protocol (IIOP)
 Language mappings (OMG IDL)
 Integrated and reusable services

3
 Distributed Object-based Systems
 Goal: transparently access remote objects in a distributed
system
 Challenges:
- Ensure semantics of invoking a local object
- Accommodate heterogeneity, e.g., multiple languages, OSes, …

Client Server

Object Object

Middleware 4
 Two Examples

 Common Object Request Broker Architecture (CORBA)

- International standard: multiple languages, OSes, vendors

 Distributed Common Object Model (DCOM)

- MS standard: only MS OSes

5
 CORBA
 CORBA is similar in high level concepts to RMI
 RMI is basically a simplified form of CORBA
 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

6
 CORBA Architecture
 Remote-object: object implementation resides in server’s
address space

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB
7
 Stub
 Provides interface between client object and ORB
 Marshalling: client invocation
 Unmarshalling: server response

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB

8
 Skeleton
 Provides iterface between server object and ORB
 Unmarshaling: client invocation
 Marshaling: server response

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB

9
Object Adapters

10
 Object Adapters

 Generate and interpret object references

 Activate and deactivate object implementations
 Handle method invocations via skeletons
 Basic Object Adapter (BOA)
 Portable Object Adapter (POA)

11
Object Adapters

12
 Basic Object Adapter (BOA)

 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

 Underspecified
- Initially unclear which features would be required on various
platforms

13
 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

14
 (Portable) Object Adapter (POA)
 Register class implementations
 Creates and destroys objects
 Handles method invokation
 Handles client authentication and access control

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB

15
 What is an ORB?

 A distributed object bus

 Hides transport mechanisms
- Location
- Method invocation
- Marshalling
ORB
 OMG Interface Definition Language
(IDL) provides the language
independent semantics

16
 Object Request Broker (ORB)

 Enables object to transparently make and receive requests and

responses

“...like a telephone exchange, providing the basic

mechanism for making and receiving calls…”

ORB

17
 Object Request Broker (ORB)

 Abstracts remote request and response mechanisms

 Transport for distributing method invocations

Client Object Implementation

Request

ORB

18
 ORB Usage

 ORB is a singleton
 ORB initialization
- Single static call to init() an ORB

- Afterorg.omg.CORBA.ORB
initialization, you register
orb = objects
org.omg.CORBA.ORB.init();
with the ORB using an Object Adapter

19
Proxy-based Invocation

Client Object Implementation

Request
Request

Stub Skeleton

Request

ORB

20
 ORB Abstraction

 How is this possible in a heterogeneous environment?

Client

Java
Java
? C++ Object Implementation

C++

IDL IDL

ORB

21
 Object Request Broker ...
 Communication infrastructure sending messages between
objects
 Communication type:
- GIOP (General Inter-ORB Protocol)
- IIOP (Internet Inter-ORB Protocol) (GIOP on TCP/IP)

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB

22
 ORB and IIOP

The IIOP is a protocol by which ORBs communicate

23
 Internet Inter ORB Protocol (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

24
 CORBA Object

Server

CORBA
Interoperable Object Reference
Object
Interface C++/Java
IDL Implementation Servant

25
 Interoperable Object Reference (IOR)

• Uniquely identifies an object (see object references)

Server

CORBA
Interoperable Object Reference
Object
Interface C++/Java
IDL Implementation Servant

26
 Interface Definition Language (IDL)

 Describes interface
 Language independent
 Client and server platform independent

Server

CORBA
Interoperable Object Reference
Object
Interface C++/Java
IDL Implementation Servant

27
 IDL (cont…)

 In RMI we had an RMI compiler run on the .class file we

wanted to be remote. It’s more complex under CORBA

 The interface is written in Interface Definition Language,

IDL. IDL is language-neutral (by being a different language
than anything else) though highly reminiscent of C++
(multiple inheritance, similar syntax, etc.)

 IDL has a set of primitive data types similar to most

languages—integer, float, string, byte, etc.

28
 Overall CORBA Architecture

Implementation Interface
repository repository Server
Client

C++ Object IDL Java Object

Interface repository
interface repository provides information about registered IDL interfaces to clients
and servers that require it.
Skeleton

Stub
Implementation repository Object Adapter
IIOPon demand and locates running servers
activates registered servers
ORB ORB
uses the object adapter name to register and activate servers

29
 CORBA Process

 Write an IDL file which describes the interface to the distributed object.
 Run idlj on the IDL file. This generates Java code that implements the
proxy code
 Compile the java proxy code
 Run nameserver
 Implement the server
 Implement the client
 Start the applications

30
 Development Steps

1 IDL

4 3
idltojava
Client Application Object Implementation

Stub 2 2 Skeleton
request
ORB ORB
response

steps:
1 write the IDL file
2 compile with idltojava (stubs/skeleton generated automatically)
3 write object implementation (servant)
4 write client application

31
 Example of CORBA Services

 Naming: Keeps track of association between object

names and their reference. Allows ORB to locate
referenced objects
 Life Cycle: Handles the creation, copying, moving,
and deletion of objects
 Trader: A “yellow pages” for objects. Lets you find
them by the services they provide
 Event: Facilitates asynchronous communications
through events
 Concurrency: Manages locks so objects can share
resources
 Query: Locates objects by specified search criteria
 …

32
 CORBAservices are the baseline services available to all
objects sitting on the ORB communication bus.

1. Naming Service 1. Query Service

2. Event Management Service 2. Licensing Service
3. Life Cycle Service 3. Property Service
4. Persistent State Service 4. Time Service
5. Transaction Service 5. Security Service
6. Concurrency Service 6. Notification Service
7. Relationship Service 7. Trader Service
8. Externalization Service 8. Collections Service

33
 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

34
 CORBA vs. RMI

CORBA RMI
Platform independent JVM specific
Protocol independent Proprietary protocol
(IIOP) (JRMP)
Language Java specific
independent (IDL)
Objects by value Objects by value
(3.0) (serialization)
35
 RMI Deployment

Interface Implementation
Definition Installation

Stubs Skeletons

Client Object Implementation

36
 CORBA Deployment

IDL Definition Implementation

Installation

Interface Implementation
Stubs Skeletons
Repository Repository

Client Object Implementation

37
 CORBA Features

 Language independence
 Location transparency
 Reuse of facilities & services
 OMG IDL defined interfaces
 Stub & Skeleton generation
 Server activation

38
 CORBA Resources

 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/

39
 Creating a CORBA Object

 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()

40
public static void main(String[] args) {
try { Activating the QuoteServer
// Initialize object request broker
ORB orb = ORB.init(args, null);

// Initialize basic object adapter

BOA boa = orb.BOA_init();

// Create a new QuoteServer ...

QuoteServer quoteServer = new QuoteServer();

// ... and export the object

boa.obj_is_ready(quoteServer);

// Object Request Broker Initialized

System.out.println (”QuoteServer ORB
initialized");

// Wait for incoming requests

boa.impl_is_ready();

} catch (SystemExcpetion e) { 41
 Accessing a CORBA Object

 ORB uses Interoperable Object References (IORs)

 Object might be local, client uses proxy
 Client must acquire first object reference
- Naming/Trading service
- Proprietary bind
- Proprietary URL service
- Some other proprietary means

42
 Registering the QuoteServer
// Create a new QuoteServer ...
QuoteServer quoteServer = new QuoteServer();
.
.
.
// Obtain reference for our nameservice
org.omg.CORBA.Object object =
orb.resolve_initial_references("NameService");
// Since we have only an object reference, we must
// cast it to a NamingContext. We use a helper
// class for this purpose

NamingContext namingContext = NamingContextHelper.narrow(object);

// Add a new naming component for our interface

NameComponent name[] = { new NameComponent(”QuoteServer", "") };

// Now notify naming service of our new interface

namingContext.rebind(name, quoteServer);

43
 Using a CORBA Object

 Initialize the ORB on the client

 Get a reference to the remote object
- IOR
- Actual reference (e.g. from bind())
 Invoke methods

44
 Accessing the QuoteServer
// Create an object request broker
ORB 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 NameContext
NamingContext 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 QuoteServer
QuoteServer quoteServer = QuoteServerHelper.narrow(objectReference);
// invoke methods on reference
Quote noveraQuote = quoteServer.getQuote(“MCTR”);

45
 Technical/Architectural Overview

 CORBA facilities come in two groups:

1. horizontal facilities
– target client-side functionality
2. vertical facilities
– target domain-specific functionality

46
 Technical/Architectural Overview
(cont.)

 Horizontal facilities specifications:

1. Mobile Agents Facility
2. Printing Facility
3. Internationalization Facility
 Vertical facilities domain-specific services are being
developed for various business areas:
1. Common Enterprise Models
2. Finance/Insurance
3. Electronic Commerce
4. Manufacturing
5. Healthcare
6. Telecommunications

47
 Technical/Architectural Overview
(cont.)

1. Transportation
2. Life Science Research
3. Utilities
4. C4I (Command, Control, Communications, Computers, and
Intelligence)
5. Space

48
Technical/Architectural Overview
(cont.)

No n-stand ardized ap p- App lication do ma in- Horizo nta l fac ility

spec ific interfac es spec ific interfac es interfac es
App lica tion Interface s C ommon Fa cilities
CORBAfacilities Domain Inte rfa ces
CORBAfacilities

Ob je ct Request Bro ker

Ob ject Servic es
General service inte rfaces

Object Management Architecture reference

model.

49
 CORBA Basics
IDL J ava
module  package
interface  interface
struct  class
const  public static final
boolean  boolean
char  char
wchar  wchar
octet  octet
string  java.lang.String
wstring  java.lang.String
short  short
unsigned short  short
long  int
unsigned long  int
long long  long
unsigned long long  long
float  float
double  double
fixed (not supported in idlj) java.math.BigDecimal
sequence [] (array) 
[] (array) [] (array) 
Fig. 26.9 IDL keywords, types and their mappings to J ava keywords.

50
 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 with oneway modifier in IDL file
❢ remote method receives only in arguments
- asynchronous
• client makes synchronous call on remote method, remote
service responds at a later time by calling method on client
• must be qualified with oneway to prevent deadlock

51
CORBA Basics (cont.)

1. registerClient( this )

Client Server

2. clent.endMessage()
C lient a nd server are now d ead lo cked .

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

52
 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 as
final classes.

53
 Case Study: Chat

 Chat is a basic network application using a central

broadcasting point where a collection of clients pushes in
messages 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 by
disconnecting from the chat server.
3. Send message: A connected client creates a chat message
and gives the message to the chat server.
4. Receive message: A connected client receives messages
delivered by the chat server.

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

 Two ways to invoke a request:

– statically – using Static Invocation Interface (SII)
– relies on creating a request through invoking a static method
in a stub
❢ stub generated from compile-time definition of an object type
(IDL interface) and object operations (methods within IDL
interface)
– dynamically – using Dynamic Invocation Interface (DII)
– programmatically creates and send invocation request directly
to ORB without assistance of stub
– developers responsible for guaranteeing sending proper type
and number of arguments to invocation
 Server unaware of process that created the request.

55
 Static Invocation Interface (SII), Dynamic Invocation
Interface (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:
• Obtain object reference to server object
• Look up desired method in Interface Repository
• Build argument list using IR’s OperationDef
• Create and initialize Request object
• Invoke Request and wait for call to unblock (return)
• Get results 56
 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 objects
in networks.
- Basic Object Adapter (BOA)
• vague definition of an adapter which led to inconsistencies
between different vendors’ implementations
- Portable Object Adapter (POA)
• more widely used, even though more complex than BOAs
57
 BOAs, POAs and TIEs (cont.)

 POA connects an object reference to developer-written

code using code found in IDL generated skeleton.
- allow fine-grained control
 Distributed objects inherit from a POA base definition
generated by IDL compiler
- enables distributed object to be usable by a POA,
- enables POA to control all access to servant through policies

58
 BOAs, POAs and TIEs (cont.)

 POA policies:
- ImplicitObjectActivation,
• tells POA outside object created servant and activated it
- IDAssignmentPolicy, and
• determines who is responsible for assigning a unique ID to a
given servant
- RequestProcessingPolicy.
• uses object id either to find matching servant or invoke default
service that uses object id to perform lookup in database
 Policy combinations provide POAs with fine-grained control
over one or many servants.

59
 BOAs, POAs and TIEs (cont.)

 Another way for developer to us a POA is to wrap their

servants in a TIE.
- enables interaction with a POA without having servant’s object
implementation inherit structure from POAImpl.
- servant can inherit from other base classes freely

60
 CORBA services

 CORBAservices define base services and a support

structure 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

61
 Naming Service

 Associates name objects with arbitrary value (known as

name bindings).
 A path to a name binding consists of zero or more naming
contexts (a collection of unique name bindings).
 Resolving a name binding returns object associated with
name.
 Binding a name creates association between a name and
an object.
 Multiple name bindings can point to a single object.

62
 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-aware
applications
• allows applications to ignore system-security requirements
• requires support for no delegation and single delegation
models

63
 Security Service (cont.)

- Level 2
• is everything level 1 provides in addition to:
1. more fine-grained user authentication
2. greater invocation security
3. auditing
4. finer control over secure invocations
5. delegation
6. administrators can set security policies
7. discovery of security policies by security-aware applications
8. discovery of security policies by ORBs and other services

64
 Object Transaction Service

 Enables CORBA objects to execute as parts of distributed

transactions.
- a transaction describes a collection of interactions where multiple
users may access and/or modify data.
• acronym ACID describes four standard requirements for
reliable transactions:
1. Atomic – completion of numerous steps must be conducted
as one, otherwise each step must be undone.
2. Consistent – effects of transaction are repeatable and
predictable.
3. Isolated – transaction not interrupted from outside and gives
no indication if execution is proceeding serially or
concurrently.
4. Durable – transaction results are persistent.

65
 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

66
 Object Transaction Service (cont.)

 Concepts of transactional clients, transactional objects and

recoverable objects define the OTS.
- transactional clients interact with OTS to create and commit or
rollback a transaction
- transaction objects’ behaviors vary when invoked within a
transaction (object’s data not recoverable)
- recoverable object is a transactional object in which data is
recoverable (maintain their data and capable of restoring their lost
state)
 Java Transaction Service (JTS) is Java implementation of
distributed transaction service
- uses CORBA OTS specification to define protocol

67
 Persistent State Service

 Persistent State Service (PSS) stores and retrieves

objects.
 Abstracts interaction between objects and datastores.
 Persistent State Definition Language (PSDL) defines a
distributed object schema in a portable fashion.
- PSDL is a superset of IDL
• defines two new constructs
❢ storagetype
❢ storagehome

68
 Persistent State Service (cont.)

- contains two definition types:

• abstract definition
❢ define portable definition of the persistable state of a CORBA
object
• concrete definition

69
 Event and Notification Services

 Event Service defines mechanism that decouples delivery

of events (messages) from source of events.
- no predefined event types in specification
- keeps track of action events and event listeners
 Supplier creates events that are processed by a consumer.
 In push model, supplier sends event messages
asynchronously to all consumers registered to receive
messages.
 In pull model, consumer polls supplier for events.

70
 Event and Notification Services
(cont.)

 Notification Service is a direct extension of the Event

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

71
 Event and Notification Services
(cont.)

 Standard flow of a StructuredEvent:

• finding object reference to Notificaion Service (instance of
EventChannelFactory)
• EventChannelFactory creates an EventChannel
• supplier asks EventChannel to return SupplierAdmin
object
• SupplierAdmin returns a Consumer proxy (such as
StructuredProxyPushConsumer) to an event channel
• access to distributed events (through push or pull models) is
accessible through proxy

72
Event and Notification Services
(cont.)
C oncep tua lly, a Sup plie r send s a n Eve nt to a C onsume r.

Supp lier Co nsumer

Eve nt

An EventChannel deco up les the Supp lier from the Consumer.

Supp lier EventChannel Co nsumer

Eve nt Eve nt

Ad ding a ProxyConsumer a nd ProxySupplier enables further d ecoupling

a nd make s it p ossible to sup po rt bo th the p ush and pull mod els.

Supp lier ProxyConsumer

Eve nt

Event

EventChannel

Event

ProxySupplier Co nsumer
Eve nt

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

73
 EJBs and CORBA components

 CORBA Component Model (CCM) Request for Proposal

(RFP) recommends the JavaBeans component model as
basis of a server-side framework.
 CORBAcomponents based on Component Implementation
Framework (CIF) architecture.
 CIF defines superset of Persistent State Definition
Language called Component IDL (CIDL)
 CIDL is component model for CORBA objects and a
container-programming model where CORBA components
exist at runtime

74
 EJBs and CORBAcomponents
(cont.)
IDL keywords to support the C O RBA
C omponent Model (C C M)
component  home  provides
consumes  import  setRaises
emits  local  supports
finder  multiple  typeId
getRaises  primaryKey  typePrefix
Fig. 27.4IDL keywords to support the C ORBA C omponent Model.

75
 EJBs and CORBAcomponents
(cont.)

 Component Interface Definition Language (CIDL) is a

superset of Persistent State Definition Language.
- defines
• components in a way that enables automatic generation of
component’s persistence code.
• component implementation
• state management
- compiled with a CIDL compiler
 Developers organize components as an assembly with a
descriptor.
- describes how components are deployed
- extension of Open Software Description (OSD) Format

76
 EJBs and CORBAcomponents
(cont.)

 A Container class creates a containment hierarchy

grouping components and other containers together.
 Container programming model is a runtime environment in
which component implementations use their enclosing
containers to access various services the container
provides.

77
 EJBs and CORBAcomponents
(cont.)

 Four areas make up CCM container programming model:

1. External types
• interfaces seen by client wanting to communicate with
component
2. Container types
• API component uses to communicate with runtime container
3. Container Implementation types
• different containers have different relationships with surrounding
system. Three types: stateless, conversational, and durable.
Each type defines its system support
4. Component Category
• where a component fits in overall framework

78
 EJBs and CORBAcomponents
(cont.)

 Using a container’s internal interfaces, a component has

full 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.

79
 EJBs and CORBAcomponents
(cont.)

 Components can be either

- transient, or
• can only be created by factories
• do not have primary keys
- persistent
• can be created by factories and located by finders
• have primary keys
• support two forms of persistence
❢ container managed
❢ component managed

80
 EJBs and CORBAcomponents
(cont.)
C omp onent Type Desc ription
Service  • Does not maintain state information (completely stateless)
• Does not have a unique id (primary key)
• Implements needed behavior
(e.g., calculateInterest,
addItemToShoppingCart, etc.)
• Can use transactions, is not included in the current
transaction

Session  • Maintains internal-state information

• Has a unique id that is usable only by its container
• Implements needed behavior
• Can use transactions, but is not included in the current transaction
• Maps to Session EJBs

Entity  • Container- or component-managed persistent state

• Has a unique id (primary key)
• Implements needed behavior that is optionally transactional
• Maps to Entity EJBs

Process  • Container-managed or component-managed persistent state that is inaccessible to

clients
• Container-managed or component-managed persistence of the component’s
primary key (identity) with visibility of the primary key through user-defined
methods
• Implements needed behavior and the behavior is optionally transactional

Fig. 27.5C O RBA c omponent types a nd d esc riptions.

81
 EJBs and CORBAcomponents
(cont.)

 Activation and passivation are actions around invocation

boundaries of an object operation.
- activation lifecycle
1. request arrives to ORB to invoke operation on object
2. ORB sends request to POA
3. POA sends request to container managing component
4. container activates object
- passivation policies defined by component’s deployment
information

82
 EJBs and CORBAcomponents
(cont.)

 In distributed systems, clients don’t create remote objects.

Clients discover remote objects.
- discovery through file containing object’s IOR
- discovery through Naming Service
 Factories (ComponentHome instances) of remote systems
create objects for their corresponding systems.
- component definition must define component factory
- if component persistent, must define find method using
component’s primary key

83
 EJBs and CORBAcomponents
(cont.)

 CORBAcomponents use subset of CORBAservices for Component

Implementation Framework.
- Security Service
• every component may have own security requirement
❢ defined in component’s 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

84
 EJBs and CORBAcomponents
(cont.)

- Notification Service
• accessed indirectly
• container mediates use of event service by component
• container does not preclude direct use of Notification Service
❢ component developers are encouraged to define events in IDL as
way of keeping component’s functional description in one location
• keywords:
❢ publishes
» any number of consumers can subscribe to an event
» methods declared with publishes expected to be part of
shared interface of component
❢ emits
» only one consumer can subscribe to an event
» expected to be private channel used internally by system

85
 EJBs and CORBAcomponents
(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. 86
 CORBA vs. RMI

 CORBA is comprehensive view of distributed systems

architecture.
 RMI describes only communication proxies and protocols
between client object and server object.

87
 When to Use RMI

 RMI suitable for smaller distributed applications in which

scalability, architecture, heterogeneity, and extensibility are
not 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 offer POA or range of control offered by
POA.
 RMI has dynamic class loading. CORBA places
implementation burden on clients.

88
 When to Use RMI (cont.)

 RMI allows objects to participate in distributed systems

consistently and predictably.
 RMI is a natural choice for distributed systems built in
Java.
 A pure Java-distributed system needs to be considered
from an architectural perspective where distributed issues
can be discovered and resolved before the implementation
issues are decided.

89
 When to Use CORBA

 CORBA defines and provides implementations to many

common requirements for most complex distributed
systems:
- architecture
- Quality of Service (QoS)
- Scalability
- Heterogeneity
- Extensibility

90
 RMI-IIOP

 SUN and IBM implemented RMI-over-IIOP (RMI-IIOP) to replace RMI’s

underlying communication protocol (Java Remote Method Protocol or
JRMP).
 Inprise, Netscape, Oracle, Sun and IBM specified reverse mapping of
Java-to IDL.
- Mapping limitations:
• Constants can be of primitive types or of class java.lang.String
only
• IDL normally does not support overloading of method names.
• A class cannot inherit a method with same signature from two different
interfaces.
• Interfaces and value types must be public.
• Compiler considers packages and interface names are not case-
sensitive.

91
 RMI-IIOP (cont.)

- runtime limitations:
• sending a tree graph from ORB to ORB may be problematic if
multiple nodes point to one object
• CORBA does not define distributed garbage collection
• Casting stubs may not work properly, so using the static
method narrow of class
java.rmi.PortableRemoteObject is encouraged.
• RMI downloads the stubs needed by client, CORBA does not.

92
 RMI-IIOP (cont.)

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

• use javax.rmi.PortableRemoteObject instead of using
java.rmi.UnicastRemoteObject
• use JNDI (Java Naming and Directory Interface) instead of RMI
Registry
• do not downcast remote objects to subclass types; use method
narrow of class PortableRemoteObject to cast distributed
objects as subclass types

93
 RMIMessenger Case Study Ported
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

94
 ChatServer RMI-IIOP
Implementation

 ChatServerImpl
- implements ChatServer remote interface
• subclass of class javax.rmi.PortableRemoteObject
- does not implement method register
- handles registration with name services

95
 Future Directions

 OMA guiding document for CORBA 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 OMG’s architecture
- maintains compatibility with previous embodiments
- gives new vitality to OMG

96