2002 Prentice Hall. All rights reserved. Chapter 27: Common Object Request Broker Architecture(CORBA): Part 2 Outline 27.1 Introduction 27.2 Static Invocation

2002 Prentice Hall. All rights reserved.

Chapter 27: Common Object Request Broker Architecture(CORBA): Part 2

Outline27.1 Introduction27.2 Static Invocation Interface (SII), Dynamic Invocation Interface (DII) and Dynamic Skeleton Interface (DSI)27.3 BOAs, POAs and TIEs27.4 CORBAservices

27.4.1 Naming Service27.4.2 Security Service27.4.3 Object Transaction Service27.4.4 Persistent State Service27.4.5 Event and Notification Services

27.5 EJBs and CORBAcomponents27.6 CORBA vs. RMI

27.6.1 When to Use RMI27.6.2 When to Use CORBA27.6.3 RMI-IIOP


Chapter 27: Common Object Request Broker Architecture(CORBA): Part 2

27.7 RMIMessenger Case Study Ported to RMI-IIOP27.7.1 ChatServer RMI-IIOP Implementation27.7.2 ChatClient RMI-IIOP Implementation27.7.3 Compiling and Running the ChatServer and

ChatClient27.8 Future Directions27.9 Internet and World Wide Web Resources


27.1 Introduction

• JavaIDL is the first step into the world of CORBA and distributed systems.

• Understanding of CORBA concepts at both the low level (i.e., object adapters) and high level (i.e., CORBAservices and CORBAcomponents) is important.


27.2 Static Invocation Interface (SII), Dynamic Invocation Interface

(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 in a stub

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

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



(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 object

2. Look up desired method in Interface Repository

3. Build argument list using IR’s OperationDef

4. Create and initialize Request object

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

6. Get results



(DII) and Dynamic Skeleton Interface (DSI) (cont.)

• Java 1.3 does not ship with an Interface Repository

• Steps needed to make DII call (without using Interface Repository):

1. Obtain object reference to server object

2. Create and initialize a Request object

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

4. Get results

2002 Prentice Hall.All rights reserved.

Outline

Fig. 27.1 SystemClockClient modified to support DII

Line 20

Line 21

Line 26

1 // SystemClockClient.java2 // Client that uses DII to request the system time from a servant.3 package com.deitel.advjhtp1.idl.dii;4 5 // Java core packages6 import java.text.DateFormat;7 import java.util.*;8 9 // Java extension packages10 import javax.swing.JOptionPane;11 12 // OMG CORBA packages13 import org.omg.CORBA.ORB;14 import org.omg.CosNaming.*;15 import org.omg.CosNaming.NamingContextPackage.*;16 17 public class SystemClockClient implements Runnable {18 19 // object reference to desired server20 private org.omg.CORBA.Object timeServer;21 private ORB orb;22 23 // initialize client24 public SystemClockClient( String[] params ) throws Exception25 {26 connectToTimeServer( params );27 startTimer();28 }29

holds reference to remote serverused to connect client to server and to create

support objects for invocation to server

obtains reference to server


Outline


30 // use NameService to connect to time server31 private void connectToTimeServer( String [] params )32 throws org.omg.CORBA.ORBPackage.InvalidName,33 org.omg.CosNaming.NamingContextPackage.InvalidName,34 NotFound, CannotProceed35 {36 // Connect to the SystemClock server37 orb = ORB.init( params, null );38 39 org.omg.CORBA.Object corbaObject =40 orb.resolve_initial_references( "NameService" );41 NamingContext naming =42 NamingContextHelper.narrow( corbaObject );43 44 // Resolve the object reference in naming45 NameComponent nameComponent =46 new NameComponent( "TimeServer", "" );47 NameComponent path[] = { nameComponent };48 timeServer = naming.resolve( path );49 }50 51 // start timer thread52 private void startTimer()53 {54 Thread thread = new Thread( this );55 thread.start();56 }57 58 // talk to server on a regular basis and display the results59 public void run()60 {61 long time = 0;62 Date date = null;63 DateFormat format =64 DateFormat.getTimeInstance( DateFormat.LONG );


Outline


Lines 68-69

Line 77

Line 78

Line 81

65 String timeString = null;66 int response = 0;67 68 org.omg.CORBA.Request request =69 timeServer._request( "currentTimeMillis" ); 70 request.set_return_type( orb.get_primitive_tc(71 org.omg.CORBA.TCKind.tk_longlong )72 );73 74 while( true ) {75 76 // invoke method currentTimeMillis using the request object77 // time = timeServer.currentTimeMillis();78 request.invoke();79 80 // get time value from request object81 time = request.result().value().extract_longlong();82 date = new Date( time );83 timeString = format.format( date );84 85 response = JOptionPane.showConfirmDialog( null, timeString,86 "SystemClock Example", JOptionPane.OK_CANCEL_OPTION );87 88 if ( response == JOptionPane.CANCEL_OPTION )89 break;90 }91 92 System.exit( 0 );93 }94

original method invocation

Request object used by client to call server

invoke request on server

obtain server response


Outline


95 // main method to execute client application96 public static void main( String args[] )97 {98 // create client99 try {100 new SystemClockClient( args );101 }102 103 // process exceptions that occur while client executes104 catch ( Exception exception ) {105 System.out.println(106 "Exception thrown by SystemClockClient:" );107 exception.printStackTrace();108 }109 }110 }


27.2 Static Invocation Interface (SII, Dynamic Invocation Interface (DII)

and Dynamic Skeleton Interface (DSI) (cont.)

• Using Interface Repository enables flexibility at runtime to discover more about types available in a distributed system.

• IR functions as a distributed version of the Java reflection mechanism.

• JavaIDL is not a complete implementation of CORBA.– when designing a distributed system with CORBA, use a

third party implementation:• commercial vendors implementations

• open-source implementations


27.3 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:– 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


27.3 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



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



• 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


27.4 CORBAservices

• 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


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


27.4.2 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


27.4.2 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


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


27.4.3 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


27.4.3 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


27.4.4 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


27.4.4 Persistent State Service (cont.)

– contains two definition types:• abstract definition

– define portable definition of the persistable state of a CORBA object

• concrete definition


Outline

Fig. 27.2 Persistent State Definition Language example.

Line 3

Line 5

Line 6 Line 12

1 // The schema for a domain object. This is the abstract definition2 // needed by the PSS. The concrete definition of Customer is below.3 abstract storagetype Customer {4 // The accountNumber is our primary key5 readonly state string accountNumber;6 state string name;7 };8 9 // The factory to be used to retrieve Customer objects10 abstract storagehome CustomerHome of Customer {11 // The creation method will create persistent Customers12 Customer create( in string accountNumber );13 };14 15 // Our factory finder. Use the CustomerDirectory to16 // find any factories used by the system to create17 // domain objects like Customer18 catalog CustomerDirectory {19 provides CustomerHome customerHome;20 };21 22 // This is the concrete declaration of the Customer defined23 // above. These declarations are empty as we are not adding24 // any addition structure to Customer or its factory.25 storagetype CustomerImpl implements Customer {};26 27 storagehome CustomerHomeImpl of CustomerImpl 28 implements CustomerHome {};

declares abstract storagetypedeclares a read-only accountNumberdeclares readable/writable

name using keyword state to notify PSDL compiler of

which fields to persistcreates Customers using method

create, each with accountNumber as primary key


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


27.4.5 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



• Standard flow of a StructuredEvent:1. finding object reference to Notificaion Service (instance of

EventChannelFactory)

2. EventChannelFactory creates an EventChannel

3. supplier asks EventChannel to return SupplierAdmin object

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

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



ProxySupplier

Consumer

EventChannel

ProxyConsumer

Supplier

ConsumerSupplier

Consumer

Supplier

EventChannel

Event

Event

Event

Event

Event

Event

Event

C onceptua lly, a Supplie r sends an Event to a C onsumer.

An EventChannel decouples the Supplier from the Consumer.

Adding a ProxyConsumer and ProxySupplier enables further decoupling and makes it possible to support both the push and pull models.

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


27.5 EJBs and CORBAcomponents

• 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


27.5 EJBs and CORBAcomponents (cont.)

IDL keywords to support the CORBA Component Model (CCM)

component home provides

consumes import setRaises emits local supports

finder multiple typeId getRaises primaryKey typePrefix Fig. 27.4 IDL keywords to support the CORBA Component Model.



• 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



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



• Four areas make up CCM container programming model:

1. External types• interfaces seen by client wanting to communicate with

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



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



• 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



Component Type Description 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.5 CORBA component types and descriptions.



• Activation and passivation are actions around invocation boundaries of an object operation.

– activation lifecycle1. 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



• 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



• 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



– 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


Outline

Fig. 27.6 Customer component IDL definition demonstrating keywords publishes and emits for issuing events.

Line 6

Line 7

1 // Our Customer can send two events:2 // creditEvent if the customer's credit limit has been exceeded3 // and internalStateEvent if the some data in the customer4 // has not been updated properly5 component Customer {6 publishes PropertyEvent creditEvent;7 emits InvariantEvent internalStateEvent;8 };

allows any number of subscribers to an event

allows one subscriber to an event



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


27.6 CORBA vs. RMI

• CORBA is comprehensive view of distributed systems architecture.

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


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


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


27.6.2 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


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


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


27.6.3 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


27.7 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


27.7.1 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


Outline

Fig. 27.7 ChatServerImpl implements the Deitel messenger ChatServer using RMI-IIOP.

Line 20

Line 21

1 // ChatServerImpl.java2 // ChatServerImpl implements the ChatServer and StoppableChatServer3 // remote interfaces using RMI over IIOP.4 package com.deitel.messenger.rmi_iiop.server;5 6 // Java core packages7 import java.io.*;8 import java.util.*;9 import java.net.MalformedURLException;10 import java.rmi.*;11 12 // Java extension packages13 import javax.rmi.*;14 15 // Deitel packages16 import com.deitel.messenger.rmi.ChatMessage;17 import com.deitel.messenger.rmi.client.ChatClient;18 import com.deitel.messenger.rmi.server.*;19 20 public class ChatServerImpl extends PortableRemoteObject 21 implements ChatServer, StoppableChatServer {22 23 // Set of ChatClient references24 private Set clients = new HashSet();25 26 // construct new ChatServerImpl27 public ChatServerImpl() throws RemoteException28 {29 super();30 }31

subclass of javax.rmi.PortableRemoteObject, which is base class for RMI-IIOP remote objects

interfaces remain unchanged for implementation


Outline


32 // register new ChatClient with ChatServer33 public void registerClient( ChatClient client ) 34 throws RemoteException 35 {36 // add client to Set of registered clients37 synchronized( clients ) {38 clients.add( client );39 }40 41 System.out.println( "Registered Client: " + client );42 43 } // end method registerClient44 45 // unregister client with ChatServer46 public void unregisterClient( ChatClient client ) 47 throws RemoteException 48 {49 // remove client from Set of registered clients50 synchronized( clients ) {51 clients.remove( client );52 }53 54 System.out.println( "Unregistered Client: " + client );55 56 } // end method unregisterClient57 58 // post new message to ChatServer59 public void postMessage( ChatMessage message ) 60 throws RemoteException 61 { 62 Iterator iterator = null;63 64 // get Iterator for Set of registered clients65 synchronized( clients ) {66 iterator = new HashSet( clients ).iterator();


Outline


67 }68 69 // send message to every ChatClient70 while ( iterator.hasNext() ) {71 ChatClient client = ( ChatClient ) iterator.next();72 client.deliverMessage( message );73 }74 75 } // end method postMessage76 77 // notify each client that server is shutting down and 78 // terminate server application79 public void stopServer() throws RemoteException80 {81 System.out.println( "Terminating server ..." );82 83 Iterator iterator = null;84 85 // get Iterator for Set of registered clients86 synchronized( clients ) {87 iterator = new HashSet( clients ).iterator();88 }89 90 // send serverStopping message to every ChatClient91 while ( iterator.hasNext() ) {92 ChatClient client = ( ChatClient ) iterator.next(); 93 client.serverStopping();94 System.err.println( "Disconnected: " + client );95 } 96 97 // create Thread to terminate application after 98 // stopServer method returns to caller99 Thread terminator = new Thread(100 new Runnable() {101


Outline


102 // sleep for 5 seconds, print message and terminate103 public void run()104 {105 // sleep106 try {107 Thread.sleep( 5000 );108 }109 110 // ignore InterruptedExceptions111 catch ( InterruptedException exception ) {}112 113 System.err.println( "Server terminated" );114 System.exit( 0 );115 }116 }117 );118 119 terminator.start(); // start termination thread120 121 } // end method stopServer122 }


27.7.1 ChatServer RMI-IIOP Implementation (cont.)

• ChatServerAdministrator– utility program for starting and stopping RMI-IIOP ChatServer implementation


Outline

Fig. 27.8 ChatServerAdministrator application for starting and stopping RMI-IIOP ChatServer.

Line 27

Lines 30 and 35

1 // ChatServerAdministrator.java2 // ChatServerAdministrator is a utility for starting and stopping3 // the RMI-IIOP ChatServer implementation.4 package com.deitel.messenger.rmi_iiop.server;5 6 // Java core packages7 import java.rmi.*;8 import java.rmi.activation.*;9 import java.util.*;10 11 // Java extension packages12 import javax.rmi.*;13 import javax.naming.*;14 15 // Deitel packages16 import com.deitel.messenger.rmi.server.StoppableChatServer;17 18 public class ChatServerAdministrator {19 20 // set up ChatServer object21 private static void startServer()22 {23 // register ChatServer in Naming Service24 try {25 26 // create ChatServerImpl object27 ChatServerImpl chatServerImpl = new ChatServerImpl();28 29 // create InitialContext for naming service30 Context namingContext = new InitialContext();31 32 System.err.println( "Binding server to naming service.." );33 34 // bind ChatServerImpl object to naming service35 namingContext.rebind( "ChatServer", chatServerImpl );

creates instance of ChatServerImpl

register ChatServer with naming service


Outline


Line 62

Lines 65-66

36 37 System.out.println( "Server bound to naming service" );38 39 } // end try40 41 // handle exception registering ChatServer42 catch ( NamingException namingException ) {43 namingException.printStackTrace();44 System.exit( 1 );45 }46 47 // handle exception creating ChatServer48 catch ( RemoteException remoteException ) {49 remoteException.printStackTrace();50 System.exit( 1 );51 }52 53 } // end method startServer54 55 // terminate server56 private static void terminateServer()57 {58 // look up and terminate ChatServer59 try {60 61 // create naming Context for looking up server62 Context namingContext = new InitialContext();63 64 // find ChatServer remote object65 Object remoteObject = 66 namingContext.lookup( "ChatServer" );67

create InitialContext

obtain remote reference


Outline


Lines 69-71

Line 77

68 // narrow remoteObject to StoppableChatServer69 StoppableChatServer chatServer = 70 ( StoppableChatServer ) PortableRemoteObject.narrow(71 remoteObject, StoppableChatServer.class );72 73 // stop ChatServer74 chatServer.stopServer(); 75 76 // remove ChatServer from Naming Service77 namingContext.unbind( "ChatServer" );78 79 } // end try80 81 // handle exception looking up ChatServer82 catch ( NamingException namingException ) {83 namingException.printStackTrace();84 } 85 86 // handle exception communicating with ChatServer87 catch ( RemoteException remoteException ) {88 remoteException.printStackTrace();89 }90 91 } // end method terminateServer92 93 // launch ChatServerAdministrator application94 public static void main( String args[] )95 {96 // check command-line arguments and start or stop server97 if ( args[ 0 ].equals( "start" ) )98 startServer();99 100 else if ( args[ 0 ].equals( "stop" ) )101 terminateServer();102

use method narrow to cast reference to StoppableChatServer type

remove from Naming Service


Outline


103 // print usage information104 else105 System.err.println( 106 "Usage: java ChatServerAdministrator start | stop" );107 108 } // end method main109 }

Binding server to naming service...Server bound to naming serviceRegistered Client: IOR:0000000000000040524d493a636f6d2e64656974656c2e6d657373656e6765722e726d692e636c69656e742e43686174436c69656e743a3030303030303030303030303030303000000000010000000000000054000101000000000d3139322e3136382e312e3435000005e000000018afabcaff00000002243bba8f0000000800000001000000000000000100000001000000140000000000010020000000000001010000000000Registered Client: IOR:0000000000000040524d493a636f6d2e64656974656c2e6d657373656e6765722e726d692e636c69656e742e43686174436c69656e743a3030303030303030303030303030303000000000010000000000000054000101000000000d3139322e3136382e312e3435000005e500000018afabcaff00000002243bbbed0000000800000001000000000000000100000001000000140000000000010020000000000001010000000000Registered Client: IOR:0000000000000040524d493a636f6d2e64656974656c2e6d657373656e6765722e726d692e636c69656e742e43686174436c69656e743a3030303030303030303030303030303000000000010000000000000054000101000000000d3139322e3136382e312e3435000005ea00000018afabcaff00000002243bbd5c0000000800000001000000000000000100000001000000140000000000010020000000000001010000000000


Outline


Unregistered Client:IOR:0000000000000040524d493a636f6d2e64656974656c2e6d657373656e6765722e726d692e636c69656e742e43686174436c69656e743a3030303030303030303030303030303000000000010000000000000054000101000000000d3139322e3136382e312e3435000005e000000018afabcaff00000002243bba8f0000000800000001000000000000000100000001000000140000000000010020000000000001010000000000Terminating server ...Disconnected: IOR:0000000000000040524d493a636f6d2e64656974656c2e6d657373656e6765722e726d692e636c69656e742e43686174436c69656e743a3030303030303030303030303030303000000000010000000000000054000101000000000d3139322e3136382e312e3435000005e500000018afabcaff00000002243bbbed0000000800000001000000000000000100000001000000140000000000010020000000000001010000000000Disconnected: IOR:0000000000000040524d493a636f6d2e64656974656c2e6d657373656e6765722e726d692e636c69656e742e43686174436c69656e743a3030303030303030303030303030303000000000010000000000000054000101000000000d3139322e3136382e312e3435000005ea00000018afabcaff00000002243bbd5c0000000800000001000000000000000100000001000000140000000000010020000000000001010000000000Server terminated


27.7.2 ChatClient RMI-IIOP Implementation

• implement ChatClient RMI-IIOP messenger:– provide RMI-IIOP implementation of interface MessageManager

– create new DeitelMessenger application for launching ClientGUI with new MessageManager implementation


Outline

Fig. 27.9 RMIIIOPMessage Manager implements the ChatClient and MessageManager interfaces using RMI-IIOP.

Line 24

1 // RMIIIOPMessageManager.java2 // RMIIIOPM22essageManager implements the ChatClient remote 3 // interface and manages incoming and outgoing chat messages 4 // using RMI over IIOP.5 package com.deitel.messenger.rmi_iiop.client;6 7 // Java core packages8 import java.awt.*;9 import java.awt.event.*;10 import java.rmi.*;11 import java.rmi.server.*;12 import java.util.*;13 14 // Java extension packages15 import javax.rmi.*;16 import javax.naming.*;17 18 // Deitel packages19 import com.deitel.messenger.*;20 import com.deitel.messenger.rmi.client.ChatClient;21 import com.deitel.messenger.rmi.ChatMessage;22 import com.deitel.messenger.rmi.server.ChatServer;23 24 public class RMIIIOPMessageManager extends PortableRemoteObject 25 implements ChatClient, MessageManager {26 27 // listeners for incoming messages and disconnect notifications28 private MessageListener messageListener;29 private DisconnectListener disconnectListener;30 31 // ChatServer for sending and receiving messages32 private ChatServer chatServer;33 34 // RMIMessageManager constructor35 public RMIIIOPMessageManager() throws RemoteException {}

extends PortableRemoteObject


Outline


Lines 38-57

36 37 // connect to ChatServer38 public void connect( MessageListener listener ) 39 throws Exception40 { 41 // create naming Context for looking up server42 Context namingContext = new InitialContext();43 44 // find ChatServer remote object45 Object remoteObject = 46 namingContext.lookup( "ChatServer" );47 48 chatServer = ( ChatServer ) PortableRemoteObject.narrow(49 remoteObject, ChatServer.class );50 51 // register client with ChatServer to receive messages52 chatServer.registerClient( this ); 53 54 // set listener for incoming messages55 messageListener = listener;56 57 } // end method connect58 59 // disconnect from ChatServer60 public void disconnect( MessageListener listener ) 61 throws Exception62 {63 if ( chatServer == null ) 64 return; 65 66 chatServer.unregisterClient( this );67 messageListener = null;68 69 // notify listener of disconnect70 fireServerDisconnected( "" );

obtain remote reference to RMI-IIOP ChatServer


Outline


71 72 } // end method disconnect73 74 // send ChatMessage to ChatServer75 public void sendMessage( String fromUser, String message ) 76 throws Exception77 {78 if ( chatServer == null )79 return;80 81 // create ChatMessage with message text and user name82 ChatMessage chatMessage = 83 new ChatMessage( fromUser, message );84 85 // post message to ChatServer86 chatServer.postMessage( chatMessage );87 88 } // end method sendMessage 89 90 // process delivery of ChatMessage from ChatServer91 public void deliverMessage( ChatMessage message ) 92 throws RemoteException93 {94 if ( messageListener != null )95 messageListener.messageReceived( message.getSender(), 96 message.getMessage() );97 } 98 99 // process server shutting down notification100 public void serverStopping() throws RemoteException 101 {102 chatServer = null;103 fireServerDisconnected( "Server shut down." );104 }105


Outline


106 // register listener for disconnect notifications107 public void setDisconnectListener( 108 DisconnectListener listener )109 {110 disconnectListener = listener;111 }112 113 // send disconnect notification114 private void fireServerDisconnected( String message )115 {116 if ( disconnectListener != null )117 disconnectListener.serverDisconnected( message );118 }119 }


Outline

Fig. 27.10 DeitelMessenger creates a ClientGUI and RMIIIOPMessageManager to launch the RMI-IIOP messenger client.

Line 18

Line 21

1 // DeitelMessenger.java2 // DeitelMessenger uses ClientGUI and RMIIIOPMessageManager to3 // implement an RMI over IIOP chat client.4 package com.deitel.messenger.rmi_iiop.client;5 6 // Java core packages7 import java.rmi.RMISecurityManager;8 9 // Deitel packages10 import com.deitel.messenger.*;11 12 public class DeitelMessenger {13 14 // launch DeitelMessenger application15 public static void main( String args[] ) throws Exception 16 { 17 // create RMIIIOPMessageManager for communicating with server18 MessageManager messageManager = new RMIIIOPMessageManager();19 20 // configure and display chat window21 ClientGUI clientGUI = new ClientGUI( messageManager );22 clientGUI.setSize( 300, 400 );23 clientGUI.setResizable( false );24 clientGUI.setVisible( true ); 25 }26 }

Create instance of class RMIIIOPMessageManager

create GUI instance using RMIIIOPMessageManager instance


27.7.3 Compiling and Running the ChatServer and ChatClient

• Using java compiler compile– ChatServerImpl, – ChatServerAdministrator,– RMIIIOPMessageManager, and – DeitelMessenger.

• Using rmic tool and –iiop command-line option generate RMI-IIOP stub classes – ChatServerImpl

• rmic –iiop com.deitel.messenger.rmi_iiop.server.ChatServerImpl

– RMIIIOPMessageManager • rmic –iiop

com.deitel.messenger.rmi_iiop.server.RMIIOPMessageManager


27.7.3 Compiling and Running the ChatServer and ChatClient (cont.)

• Start tnameserv– tnameserv –ORBInitialPort 1050

• Start ChatServerAdministrator– java –Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory

–Djava.naming.provider.url=iiop://localhost:1050 com.deitel.messenger.rmi_iiop.server.ChatServerAdministrator start

• Start ChatServer– java –Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory

–Djava.naming.provider.url=iiop://localhost:1050 com.deitel.messenger.rmi_iiop.client.DeitelMessenger


27.8 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

Documents

2002 Prentice Hall. All rights reserved. Chapter 27: Common Object Request Broker Architecture(CORBA): Part 2 Outline 27.1 Introduction 27.2 Static Invocation