Understanding CORBA: SII, DII, and DSI

1. 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 Service 27.4.2 Security Service 27.4.3 Object Transaction Service 27.4.4 Persistent State Service 27.4.5 Event and Notification Services27.5 EJBs and CORBAcomponents27.6 CORBA vs. RMI 27.6.1 When to Use RMI 27.6.2 When to Use CORBA 27.6.3 RMI-IIOP

2. Chapter 27: Common Object Request Broker Architecture(CORBA): Part 2 27.7 RMIMessenger Case Study Ported to RMI-IIOP 27.7.1 ChatServer RMI-IIOP Implementation 27.7.2 ChatClient RMI-IIOP Implementation 27.7.3 Compiling and Running the ChatServer and ChatClient27.8 Future Directions27.9 Internet and World Wide Web Resources

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

4. 27.2 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.

5. 27.2 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

6. 27.2 Static Invocation Interface (SII), Dynamic Invocation Interface (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): • Obtain object reference to server object • Create and initialize a Request object • Invoke Request and wait for call to unblock (return) • Get results

7. holds reference to remote server used to connect client to server and to create support objects for invocation to server obtains reference to server 1 // SystemClockClient.java 2 // Client that uses DII to request the system time from a servant. 3 package com.deitel.advjhtp1.idl.dii; 4 5 // Java core packages 6 import java.text.DateFormat; 7 import java.util.*; 8 9 // Java extension packages 10 import javax.swing.JOptionPane; 11 12 // OMG CORBA packages 13 import org.omg.CORBA.ORB; 14 import org.omg.CosNaming.*; 15 import org.omg.CosNaming.NamingContextPackage.*; 16 17 publicclass SystemClockClient implements Runnable { 18 19 // object reference to desired server 20 private org.omg.CORBA.Object timeServer; 21 private ORB orb; 22 23 // initialize client 24 public SystemClockClient( String[] params ) throws Exception 25 { 26 connectToTimeServer( params ); 27 startTimer(); 28 } 29 Fig. 27.1 SystemClockClient modified to support DIILine 20Line 21Line 26

8. 30 // use NameService to connect to time server 31 privatevoid connectToTimeServer( String [] params ) 32 throws org.omg.CORBA.ORBPackage.InvalidName, 33 org.omg.CosNaming.NamingContextPackage.InvalidName, 34 NotFound, CannotProceed 35 { 36 // Connect to the SystemClock server 37 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 naming 45 NameComponent nameComponent = 46 new NameComponent( "TimeServer", "" ); 47 NameComponent path[] = { nameComponent }; 48 timeServer = naming.resolve( path ); 49 } 50 51 // start timer thread 52 privatevoid startTimer() 53 { 54 Thread thread = new Thread( this ); 55 thread.start(); 56 } 57 58 // talk to server on a regular basis and display the results 59 publicvoid run() 60 { 61 long time = 0; 62 Date date = null; 63 DateFormat format = 64 DateFormat.getTimeInstance( DateFormat.LONG ); Fig. 27.1 SystemClockClient modified to support DII

9. Request object used by client to call server original method invocation invoke request on server obtain server response 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 object 77 // time = timeServer.currentTimeMillis(); 78 request.invoke(); 79 80 // get time value from request object 81 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 Fig. 27.1 SystemClockClient modified to support DIILines 68-69Line 77Line 78Line 81

10. 95 // main method to execute client application 96 publicstaticvoid main( String args[] ) 97 { 98 // create client 99 try { 100 new SystemClockClient( args ); 101 } 102 103 // process exceptions that occur while client executes 104 catch ( Exception exception ) { 105 System.out.println( 106 "Exception thrown by SystemClockClient:" ); 107 exception.printStackTrace(); 108 } 109 } 110 } Fig. 27.1 SystemClockClient modified to support DII

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

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

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

14. 27.3 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.

15. 27.3 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

16. 27.4 CORBAservices • CORBAservices define base services and a support structure useful to a wide range of applications. • Five most commonly used services: • Naming Service • Security Service • Object Transaction Service • Persistent State Service • Event and Notification Services

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

18. 27.4.2 Security Service • Consists of two levels • Level 1 • provides basic security for • 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

19. 27.4.2 Security Service (cont.) • Level 2 • is everything level 1 provides in addition to: • 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

20. 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: • Atomic – completion of numerous steps must be conducted as one, otherwise each step must be undone. • Consistent – effects of transaction are repeatable and predictable. • Isolated – transaction not interrupted from outside and gives no indication if execution is proceeding serially or concurrently. • Durable – transaction results are persistent.

21. 27.4.3 Object Transaction Service (cont.) • transactions complete in one of two ways: • committed • changes are made to persist • rolled back • changes made to data are discarded • POAs dictate transaction types supported by servants • shared transactions • unshared transactions • shared and unshared transactions

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

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

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

25. declares abstractstoragetype declares readable/writable name using keyword state to notify PSDL compiler of which fields to persist declares a read-only accountNumber creates Customers using method create, each with accountNumber as primary key 1 // The schema for a domain object. This is the abstract definition 2 // needed by the PSS. The concrete definition of Customer is below. 3 abstractstoragetype Customer { 4 // The accountNumber is our primary key 5 readonlystatestring accountNumber; 6 statestring name; 7 }; 8 9 // The factory to be used to retrieve Customer objects 10 abstractstoragehome CustomerHome of Customer { 11 // The creation method will create persistent Customers 12 Customer create( instring accountNumber ); 13 }; 14 15 // Our factory finder. Use the CustomerDirectory to 16 // find any factories used by the system to create 17 // domain objects like Customer 18 catalog CustomerDirectory { 19 provides CustomerHome customerHome; 20 }; 21 22 // This is the concrete declaration of the Customer defined 23 // above. These declarations are empty as we are not adding 24 // any addition structure to Customer or its factory. 25 storagetype CustomerImpl implements Customer {}; 26 27 storagehome CustomerHomeImpl of CustomerImpl 28 implements CustomerHome {}; Fig. 27.2 Persistent State Definition Language example.Line 3Line 5Line 6 Line 12

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

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

29. 27.4.5 Event and Notification Services (cont.) Fig. 27.3 Supplier-to-consumer flow using the Event/Notification Service.

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

31. 27.5 EJBs and CORBAcomponents (cont.)

32. 27.5 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

33. 27.5 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.

34. 27.5 EJBs and CORBAcomponents (cont.) • Four areas make up CCM container programming model: • External types • interfaces seen by client wanting to communicate with component • Container types • API component uses to communicate with runtime container • Container Implementation types • different containers have different relationships with surrounding system. Three types: stateless, conversational, and durable. Each type defines its system support • Component Category • where a component fits in overall framework

35. 27.5 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.

36. 27.5 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

37. 27.5 EJBs and CORBAcomponents (cont.)

38. 27.5 EJBs and CORBAcomponents (cont.) • Activation and passivation are actions around invocation boundaries of an object operation. • activation lifecycle • 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

39. 27.5 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

40. 27.5 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

41. 27.5 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

42. allows any number of subscribers to an event allows one subscriber to an event 1 // Our Customer can send two events: 2 // creditEvent if the customer's credit limit has been exceeded 3 // and internalStateEvent if the some data in the customer 4 // has not been updated properly 5 component Customer { 6 publishes PropertyEvent creditEvent; 7 emits InvariantEvent internalStateEvent; 8 }; Fig. 27.6 Customer component IDL definition demonstrating keywords publishes and emits for issuing events.Line 6Line 7

43. 27.5 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.

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

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

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

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

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

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

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