Remote Method Invocation (RMI)

1. Remote Method Invocation (RMI) Paul C. Barr The Mitre Corporation 145 Wyckoff Road Eatontown, NJ 07724 Prof. Steven A. Demurjian, Sr. Computer Science & Engrg. Dept. The University of Connecticut Storrs, CT 06269-3155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

2. Introduction • The Core Java Classes That Made the Success of Java Provides the Basic Building Blocks for Creating Robust Networked Applications. • Those Classes Are All the Ones Included in the Following Packages: • java.applet, • java.awt, • java.io, • java.lang, • java.net and • java.util. • They Form the Base of the Java Framework That Was Shipping in the Java Development Kit, Version 1.0.

3. Introduction • The 1.1 Version of the JDK, Was an Essential Improvement As the Kit Contained a Set of New API’s Specific to Distributed Computing: • java.security, • java.sql with sun.jdbc, • java.beans, and • java.rmi.

4. Introduction (Concluded) • The Next Version JDK 1.2 Extends the Set of New API's Specific to Distributed Computing: • Enterprise Java Beans (EJB), • javaRMI Extensions • java Naming and Directory Interface (JNDI), • java IDL, • java Transaction Systems (JTS), • java Messaging Systems (JMS)

5. RMI defined • Java Remote Method Invocation (RMI) Is an Inter-process Protocol for Java, Allowing Java Objects Living in Different Java Virtual Machines to Invoke Transparently Each Other's Methods. • Since These Virtual Machines Can Be Running on Different Computers Anywhere on the Network, RMI Enables Object-oriented Distributed Computing. • Java RMI Provides the Java Programmers With an Efficient, Transparent Communication Mechanism That Frees Them of All the Application-level Protocols Necessary to Encode and Decode Messages for Data Exchange.

6. RMI CORBA metaphor • Remote Objects Written in Java RMI Interact Approximately in Much the Same Way CORBA Objects Do: • Server Objects Publish Their Interfaces to Make Them Available to RMI Clients; • Stub Classes Deal With Binding to the Remote Objects and Do the Client-side Data Marshaling; • Skeleton Classes on the Server-side Handle Incoming Calls. • The Communication Mechanism Is Shown in the Next Slide . Without Any Surprise, This Looks Very Much Like the Elementary ORB Structure of CORBA.

7. RMI CORBA Block Diagrams RMI Block Diagram CORBA Block Diagram

8. Extensions included in RMI • Java RMI Introduces a New Object Model to Programmers: • The Java Distributed Object Model, Which Naturally Extends the Pre-JDK1.1 Object Model. • A Few New Features or Divergence's Were Added. • The Results of a Remote Invocation, As Well As the Arguments That Came Along With the Initial Request, Are Passed by Value Rather Than Reference. • This Is Because Object References Are Only Useful Within the Same Virtual Machine.

9. Extensions included in RMI • New Features (Continued) • Instead, Ordinary Objects Are Passed by Value, by Copy, Between Two Different Virtual Machines. To Do This Copy Operation, RMI Uses the New Object Serialization Service, Which Flattens a Local Java Object's State Into a Serial Stream That It Can Then Pass As a Parameter Inside a Message. • A Remote Object, an Object That Implements the java.rmi.Remote Interface, Can Nevertheless Be Passed by Reference and Not by Copying the Actual Implementation. Clients of Remote Objects Interact With Remote Interfaces, Never With the Implementation Classes of Those Interfaces.

10. Extensions included in RMI (Concluded) • Clients That Invokes Methods on Remote Objects Have to Deal With Additional Interfaces and Classes, but Also With a Whole New Set of Exceptions. • Extra Security Mechanisms Are Now Introduced to Reinforce the Control of the Behavior of Java Classes, and Most of All Stubs Classes. • If a SecurityManager Is Not Explicitly Installed by Server Objects, No Remote Invocation Will Be Possible.

11. RMI Presentation • Remote Method Invocation Is the Action of Invoking a Method of a Remote Interface on a Remote Object. Therefore, We Must Provide Our Server Object With the Interface Implementation and Class Inheritance It Needs. We Must Also Obtain the Stubs and Skeleton Classes Needed for the Communication Between Remote Objects • The Development Process Is Show in Next Slide Where Bob Is the Server Developer and Alice the Client One.

12. RMI Block Diagram for HelloWorld Application Client Server Hello HelloApplet HelloImpl rmic HelloImpl.java 3 5 1 2 Stub Stub Skel Skel Unmarshall Marshall Unmarshall Marshall RMI Layer NDR NDR NDR NDR Transport Transport Transport Transport 4 Start rmiregistery

13. Hello.java package examples.hello; import java.rmi.Remote; import java.rmi.RemoteException; public interface Hello extends Remote { String sayHello() throws RemoteException; }

14. HelloImpl.java

15. HelloApplet.java

16. RMI Steps • The Different Steps That Must Follow to Get a Server Implemented and Running Are: • 1. Define the Server Interface. The Server Object Declares Its Service Via a Remote Interface, That Must Therefore Extends the java.rmi.Remote Interface. • 2. Write the Server Code. HelloImpl Must Provide the Java File Containing the Server Class That Implements Its Server Interface, and That Inherits From the java.rmi.UnicastRemoteObject Class.

17. RMI Steps • Different Step (Continued) • 3. You Need to Also Include the Code That Will Install a SecurityManager and That Will Register the Server Interface Within the RMI Naming Context Using the Naming.Bind (or Rebind) Method. The Daemon Program That Is in Charge of the Naming Service Is RMIregistry, and It Must of Course Be Running for the Interface Registration to Succeed.

18. RMI Steps (Concluded) • Different Step (Continued) • 4. Compile the Server Class. First, Uses the Javac Compiler to Produce the Server .class File, and Secondly, Run the rmic Compiler to Obtain the Stub and Skeleton .class Files. • 5. Execute the Server Program. If the RMIRegistry Daemon Is Not Already Running, It Must Be Launched. He Can Then Run the Java Interpreter With His Server .class File. • 6. Distribute the Stub Class. In Order to Get Clients Calling the Methods of the Server, the Stub Class That Has Been Generated Needs to be Provided . This Will Enable Client Code to Make Successful Requests to Server Object.

19. Java, JavaBeans and Java RMI • Java Is "A Simple, Object Oriented, Distributed, Interpreted, Robust, Secure, Architecture Neutral, Portable, High-performance, Multithreaded and Dynamic Language". • Javabeans Is the Specification for Building Reusable Software Components (on the Client Side) Using Java. • Java-RMI Ensures Communication Between Distributed Program-level Java Objects Residing in Different Address Spaces by Assuming a Homogeneous Java Virtual Machine Environment. • It Thus Takes Advantage of the Java Object Model Whenever Possible to Support Distributed Objects in the Java Environment.

20. Enterprise Java Beans • Enterprise Javabeans (EJB) (for the Server Side) Provides a Fully-scaleable, Distributed, and Cross-platform Architecture That Makes the Most of Your Business Resources. • Not Only Can These Components Run on Any Platform, but They Are Also Completely Portable Across Any Vendor's EJB Component Execution System. • The EJB Environment Automatically Maps the Component to the Underlying Vendor-specific Execution Services.

21. Java Remote Method Invocation • Remote Method Invocation (RMI) Is the Object Equivalent of Remote Procedure Calls (RPC). • While RPC Allows You to Call Procedures Over a Network, RMI Invokes an Object's Methods. • In the RMI Model, • The Server Defines Objects That the Client Can Use Remotely. • The Clients Can Now Invoke Methods of This Remote Object As If It Were a Local Object Running in the Same Virtual Machine As the Client. • RMI Hides the Underlying Mechanism of Transporting Method Arguments and Return Values Across the Network.

22. Java Remote Method Invocation • In Java-RMI, an Argument or Return Value Can Be of Any Primitive Java Type or Any Other Serializable Java Object. Works Over a Network.

23. Java-RMI and comparison with otherMiddleware Specifications • Java-RMI Is a Java-specific Middleware Spec That Allows Client Java Programs to Invoke Server Java Objects As If They Were Local. • Java-RMI Is Tightly Coupled With the Java Language. There Are No Separate IDL Mappings That Are Required to Invoke Remote Object Methods. • This Is Different From DCOM or CORBA Where IDL Mappings Have to Be Created to Invoke Remote Methods.

24. Java-RMI and comparison with otherMiddleware Specifications • Since Java-RMI Is Tightly Coupled With the Java Language, Java-RMI Can Work With True Sub-classes. • Neither DCOM nor CORBA Can Work With True Subclasses Since They Are Static Object Models. • Because of This, Parameters Passed During Method Calls Between Machines Can Be True Java Objects. • This Is Impossible in DCOM or CORBA at Present.

25. Java-RMI and comparison with otherMiddleware Specifications (Concluded) • If a Process in an RMI System Receives an Object of a Class That It Has Never Seen Before, It Can Request That Its Class Information Be Sent Over the Network. • Over and Above All This, Java-RMI Supports Distributed Garbage Collection That Ties Into the Local Garbage Collectors in Each JVM.

26. Workings of Java-RMI • Since Both the Client and the Server May Reside on Different Machines/processes, There Needs to Be a Mechanism That Can Establish a Relationship Between the Two. • Java-RMI Uses a Network-based Registry Program Called RMIRegistry To Keep Track of the Distributed Objects. • (Note: The RMI Registry Is an RMI Server Itself!!!)

27. The RMI Registry • The Server Object Makes Methods Available for Remote Invocation by Binding It to a Name in the RMI Registry. • The Client Object, Can Thus Check for the Availability of a Certain Server Object by Looking up Its Name in the Registry. • The RMI Registry Thus Acts As a Central Management Point for Java-RMI. • The RMI Registry Is Thus a Simple Name Repository. It Does Not Address the Problem of Actually Invoking Remote Methods.

28. Stubs and Skeletons • Since the Two Objects May Physically Reside on Different Machines, a Mechanism Is Needed to Transmit the Client's Request to Invoke a Method on the Server Object to the Server Object and Provide a Response. • Java-RMI Uses an Approach Similar to RPC in This Regard. • The Code for the Server Object Must Be Processed by an RMI Compiler Called rmic, Which is Part of the JDK.

29. Rmic Compiler • The rmic Compiler Generates Two Files: • A Stub and a Skeleton. • The Stub Resides on the Client Machine and the Skeleton Resides on the Server Machine. • When a Client Invokes a Server Method, the JVM Looks at the Stub to Do Type Checking. • The Request Is Then Routed to the Skeleton on the Server, Which in Turn Calls the Appropriate Method on the Server Object. In Other Words, the Stub Acts As a Proxy to the Skeleton and the Skeleton Is a Proxy to the Actual Remote Method.

30. Java RMI Internals • The RMI Server Creates an Instance of the 'Server Object' Which Extends UnicastRemoteObject • The Constructor for UnicastRemoteObject "exports" the Server Object - Basically Making It Available to Service Incoming RMI Calls. • A TCP Socket Which Is Bound to an Arbitrary Port Number Is Created and a Thread Is Also Created That Listens for Connections on That Socket.

31. Java RMI Internals • The Server Registers the Server Object With the Registry • This Operation Actually Hands the Registry the Client-side "Stub" for That Server Object. • This Stub Contains the Information Needed to "Call Back" to the Server When It Is Invoked (Such As the Hostname/port of the Server Listening Socket).

32. Java RMI Internals (Continued) • A Client Obtains This Stub by Calling the Registry, Which Hands It the Stub Directly. • (This Is Also Where the “codebase” Comes In: If the Server Specified a “codebase” to Use for Clients to Obtain the Class File for the Stub, This Will Be Passed Along to the Client Via the Registry. • The Client Can Then Use the codebase to Resolve the Stub Class - That Is, to Load the Stub Class File Itself). • The RMIRegistry Holds Onto Remote Object Stubs Which It Can Hand off to Clients When Requested.

33. Java RMI Internals (Continued) • When the Client Issues a Remote Method Invocation to the Server, the Stub Class Creates a "RemoteCall" Which Basically • (A) Opens a Socket to the Server on the Port Specified in the Stub Itself, and • (B) Sends the RMI Header Information As Described in the RMI Spec. • The Stub Class Marshals the Arguments Over the Connection by Using Methods on RemoteCall to Obtain the Output Stream Which Basically Returns a Subclass of ObjectOutputStream Which Knows How to Deal With Passing Objects Which Extend java.rmi.Remote, Which Serializes Java Objects Over the Socket

34. Java RMI Internals (Continued) • The Stub Class Calls RemoteCall.executeCall Which Causes the RMI to Happen. • On the Server Side, When a Client Connects to the Server Socket, a New Thread Is Forked to Deal With the Incoming Call. • The Original Thread Can Continue Listening to the Original Socket So That Additional Calls From Other Clients Can Be Made. • The Server Reads the Header Information and Creates a RemoteCall Of Its Own to Deal With Unmarshalling the RMI Arguments from the Socket.

35. Java RMI Internals (Concluded) • The Server Calls the “dispatch” Method of the Skeleton Class (the Server-side ”stub" Generated by rmic), Which Calls the Appropriate Method on the Object and Pushes the Result Back Down the Wire (Using the Same ‘RemoteCall Interface Which the Client Used to Marshall the Arguments). • If the Server Object Threw an Exception Then the Server Catches This and Marshals That Down the Wire Instead of the Return Value. • Back on the Client Side, the Return Value of the RMI Is Unmarshalled (Using the RemoteCall as Created Above) and Returned From the Stub Back to the Client Code Itself. • If an Exception Was Thrown from the Server that's Unmarshalled and Re-thrown From the Stub.

36. Java 1.1 Event Model Paul C. Barr poobarr@mitre.org

37. The Java 1.1 Event Model • Event-handling Code Is the Heart of Every Useful Application. • All Event-driven Programs Are Structured Around Their Event-processing Model. Java Events Are Part of the Java Abstract Windowing Toolkit Package (AWT for Short)

38. The Java 1.1 Event Model • People Who Are Familiar With the Ms-windows or X-windows SDK Programming, Remember That the Windows Procedure Was Braced Against a Flood of Events and Then a Giant ‘Switch’ Statement Was Used to Sort Through These Events. • Similarly, in The Microsoft Foundation Classes Programming Model or The Motif Programming Model, Each Component Has to Be Over-ridden to Make It Do What You Want It to Do - Something Similar to the Older Java 1.0 Inheritance Event Model.

39. The Java 1.1 Event Model (Continued) • The First Approach Is the Easiest to Implement, but Any Time You Use a Switch Statement, You Somehow Have This Nagging Feeling That Perhaps There Is Something Un-object-oriented in the Design or That a Different Class Hierarchy and Design Would Have Made This Go Away. • The Second Approach Is More Object-oriented, but Involves a Great Deal of Work. • With the New 1.1 Delegation Event Model, a Component Can Be Told Which Object or Objects Should Be Notified When the Component Generates a Particular Type of Event. • If a Component Is Not Interested in an Event Type, Then Events of That Type Will Not Be Propagated.

40. The Java 1.1 Event Model (According to Sun) • Simple and Easy to Learn • Support a Clean Separation Between Application and GUI Code • Flexible Enough to Enable Varied Application Models for Event Flow and Propagation • For Visual Tool Builders, Enable Run-time Discovery of Both Events That a Component Generates As Well As the Events It May Observe • Support Backward Binary Compatibility With the Old Model • Facilitate the Creation of Robust Event Handling Code Which Is Less Error-prone (Strong Compile-time Checking)

41. The 1.1 Delegation Event Model • The 1.1 Event Model Is Based on the Concept of an ‘Event Source’ and ‘Event Listeners’. • Any Object That Is Interested in Receiving Messages (or Events ) Is Called an Event Listener. • Any Object That Generates These Messages (or Events ) Is Called an Event Source.

42. The 1.1 Delegation Event Model(Pictorial Representation)

43. The 1.1 Delegation Event Model (Continued) • The Event Source Object Maintains a List of Listeners Who Are Interested in Receiving Events That It Produces. • The Event Source Object Provides Methods That Allow the Listeners to Add Themselves ( ‘Register’ ) or Remove Themselves From This List of ‘Interested’ Objects. • When the Event Source Object Generates an Event, or When a User Input Event Occurs on the Event Source Object, the Event Source Object Notifies All the Listeners That the Event Has Occurred.

44. Event Source Object Implementation //This is one typical Event Source Object implementation public class EventSource extends Applet { public Label m_Label; public Button m_Button; public int m_nCounter; public void init() { m_Label = new Label( "Go ahead and click away." ); m_Button = new Button( "Click Here" ); EventListener listenerObject = new EventListener( this ); //Register with event source using addXListener m_Button.addActionListener( listenerObject ); add( m_Label ); add( m_Button ); } }

45. Event Listener Object //This is one typical Event Listener Object implementation class EventListener implements ActionListener { private EventSource m_sourceObject; public EventListener( EventSource sourceObject ) { m_sourceObject = sourceObject; } //This method handles the EventObjects fired by the EventSource Object //Note: An ActionEvent is an EventObject public void actionPerformed( ActionEvent e ) { m_sourceObject.m_Label.setText( "That was click " + ( ++m_sourceObject.m_nCounter ) + " buddy." ); } }

46. Event Object Interactions • An Event Source Object Notifies an Event Listener Object by Invoking a Method on It and Passing It an EventObject ( An Instance of a Subclass of java.util.EventObject ). • In Order for the Source to Invoke a Method on a Listener, All Listeners Must Implement the Required Method. • This Is Ensured by Requiring That All Event Listeners for a Particular Type of Event Implement a Corresponding Interface.

47. Event Delegation Model • The Java 1.1 Event Delegation Model Is Based on Four Concepts: • The Event Classes • The Event Listeners • Explicit Event Enabling • Adapters

48. Event Classes

49. Event Class Specifics • Every Event Is a Subclass of java.util.EventObject. • It Is a Very General Class With Only One Method of Interest: • Object getSource() • This Method Returns the Object That Originated the Event. Every Event Has a Source Object, From Which the Event Originated. This Method Returns a Reference to That Source. • AWT Events, Which Is What We Are Concerned With Here, Are Subclasses of java.awt.AWTEvent. • This Is the Superclass of All the Delegation Model Event Classes. The Most Interesting Method in This Class is int getID() • This Method Returns the ID of the Event. An Event’s ID is an int That Specifies the Exact Nature of the Event. This Value is Used to Distinguish the Various Types of Events That Are Represented by Any Event Class.

50. AWT Events • java.awt.event - The Subclasses of java.awt.AWTEvent Represent The Various Event Types That Can Be Generated by the Various AWT Components. • All the Various Types of AWT Events, Are Placed in a Separate Package Called java.awt.event for the Sake of Convenience.