Corba 1

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 Server

Client

Java Object C++ Object Skeleton Stub

ORB

IIOP

Object Adapter

ORB 7

Stub   

Provides interface between client object and ORB Marshalling: client invocation Unmarshalling: server response Server

Client

Java Object C++ Object Skeleton Stub ORB

IIOP

Object Adapter ORB 8

Skeleton   

Provides iterface between server object and ORB Unmarshaling: client invocation Marshaling: server response Server

Client

Java Object C++ Object Skeleton Stub ORB

IIOP

Object Adapter 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 Server

Client

Java Object C++ Object Skeleton Stub ORB

IIOP

Object Adapter ORB 15

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

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 orb = objects org.omg.CORBA.ORB.init(); initialization, you register 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?

Java

Client

Java

?

IDL

C++

Object Implementation

C++ 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) Server

Client

Java Object C++ Object Skeleton Stub ORB

IIOP

Object Adapter 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 Object

Interoperable Object Reference Interface IDL

C++/Java Implementation

Servant

25

Interoperable Object Reference (IOR) •

Uniquely identifies an object (see object references)

Server CORBA Object

Interoperable Object Reference Interface IDL

C++/Java Implementation

Servant

26

Interface Definition Language (IDL)   

Describes interface Language independent Client and server platform independent

Server CORBA Object

Interoperable Object Reference Interface IDL

C++/Java 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

Client C++ Object

Implementation Interface repository repository

IDL

Server Java Object

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

Stub Object Adapter Implementation repository 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

4

IDL

3

idltojava

Client Application

2

Stub

Object Implementation

2

Skeleton

request

ORB

ORB response

steps: 1 2 3 4

write the IDL file compile with idltojava (stubs/skeleton generated automatically) write object implementation (servant) 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. 2. 3. 4. 5. 6. 7. 8.

Naming Service Event Management Service Life Cycle Service Persistent State Service Transaction Service Concurrency Service Relationship Service Externalization Service

1. 2. 3. 4. 5. 6. 7. 8.

Query Service Licensing Service Property Service Time Service Security Service Notification Service Trader Service 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 Platform independent Protocol independent (IIOP) Language independent (IDL) Objects by value (3.0)

RMI JVM specific Proprietary protocol (JRMP) Java specific Objects by value (serialization) 35

RMI Deployment

Interface Definition

Stubs

Client

Implementation Installation

Skeletons

Object Implementation

36

CORBA Deployment

Implementation Installation

IDL Definition

Interface Repository

Stubs

Client

Skeletons

Implementation Repository

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) { Activating the QuoteServer try { // 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. 2. 3. 4. 5. 6.

Common Enterprise Models Finance/Insurance Electronic Commerce Manufacturing Healthcare Telecommunications 47

Technical/Architectural Overview (cont.) 1. 2. 3. 4.

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

48

Technical/Architectural Overview (cont.)

No n-stand ardized ap pspec ific interfac es

App lication do ma inspec ific interfac es

App lica tion Interface s

C ommon Fa cilities CORBAfacilities

Horizo nta l fac ility interfac es 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  struct  const  boolean  char  wchar  octet  string  wstring 

interface class public static final boolean char wchar octet java.lang.String java.lang.String

short  unsigned short  long  unsigned long  long long  unsigned long long  float  double  fixed (not supported in idlj) sequence [] (array) Fig. 26.9 IDL keywords, types and

short short int int long long float double java.math.BigDecimal [] (array)  [] (array)  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

2.

Server

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. 2. 3. 4. 5.

Naming Service Security Service Object Transaction Service Persistent State Service 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. 2. 3.

• •

user authentication, invocation security, and 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. 2. 3. 4. 5. 6. 7. 8.

more fine-grained user authentication greater invocation security auditing finer control over secure invocations delegation administrators can set security policies discovery of security policies by security-aware applications 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

Eve nt

EventChannel

Eve nt

Co nsumer

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 Eve nt

ProxyConsumer 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  emits 

import  local 

setRaises supports

finder  multiple  getRaises  primaryKey  Fig. 27.4IDL keywords to support the C ORBA C omponent Model.

typeId typePrefix

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-tocomponent 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

Service 

Desc ription

• • •

•

Does not maintain state information (completely stateless) Does not have a unique id (primary key) Implements needed behavior calculateInterest, (e.g., 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. 2. 3. 4.

-

request arrives to ORB to invoke operation on object ORB sends request to POA POA sends request to container managing component 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 casesensitive. 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 RMIIIOP 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