1 / 22

Java Remote Method Invocation

Java Remote Method Invocation. RMI. Idea. If objects communicate with each other on one JVM why not do the same on several JVM’s? Build on top of the Socket layer Break down objects into a string of bytes and send these over the wire Use Client/Server architecture.

colleen-lopez
Download Presentation

Java Remote Method Invocation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Java Remote Method Invocation RMI

  2. Idea • If objects communicate with each other on one JVM why not do the same on several JVM’s? • Build on top of the Socket layer • Break down objects into a string of bytes and send these over the wire • Use Client/Server architecture

  3. Client/Server Architecture • Client requests data from server • Server sends the data to the client (response) • Data is exchanged in standard format • RMI: Remote calls will go in both directions • Client Object: is the object one of whose methods issue a remote call • Remote Object is the object on the server whose method is called

  4. We need a Proxy Object • The client calls a method on a special type of interface that is implemented by the remote object • Call this interface a stub • We still have to deal with the parameters and return values, i.e. convert them into an appropriate format • Call this conversion marshalling

  5. Marshalling • Objects need to be disassembled to this format • Formatted object is sent over the wire • Object needs to be reassembled on the other side • Hence use character format: if the parameter of return value is a primitive type just copy it (as a sequence of bytes) • If it is an object then disassemble to a string • Call this last process serialization

  6. What is a Stub? • It defines a remote interface • Contains methods that will be eventually called remotely • It extends java.rmi.Remote • All its methods must throw a java.rmi.RemoteException

  7. The Stub Produces • An identifier of the remote object • A description of the method invoked • Marshalled parameters

  8. Server Side • There is another interface for the call (now local) that has to unmarshall the parameters and make the actual call with these • Called a skeleton (not needed by programmer) • Possible return value has to be marshalled and sent back to the client • Note the dynamic nature of marshalled objects must be accomodated • Skeleton resides on the server

  9. Stubs must be downloaded! • From server to client, since it is the remote object’s methods that must be called • If the client is to know about the stub, then the latter must be registered somewhere • The client must look the stub up • The server enters the stub into the registry with Naming.rebind() • The client looks it up with Naming.lookup()

  10. Naming Lookup • Stubs are normally downloaded when the client calls a remote method • What do you do when there is no remote interface to facilitate downloading? • Use the bootstrap registry service the first time round • This associates a name (string) to an object on the server.

  11. Naming Lookup (ctd) • The server Naming.rebind() accepts a (unique) name--a normal string, say xxx • The client accesses it by means of a so-called RMI URL, e.g. rmi://localhost:90/xxx • This is the argument to Naming.lookup() to obtain the remote reference.

  12. Defining the Remote Interface • It extends java.rmi.Remote • Must be public • Contains declarations of methods to be called remotely • Is the way to pass remote objects • All methods must declare java.rmi.RemoteException in their throws clause

  13. How to Generate Stubs • Stubs and skeletons are generated on the server from class files • Use the RMI compiler rmic • Format: rmic <full class name> <includes> • Generates both in same directory as the class file

  14. Naming Conventions • Assume the remote interface is called xxx • Then the stub is called xxx_Stub • The skeleton is called xxx_Skel • The original class file is called xxxImpl • The client’s class is called xxxClient

  15. Write the Implementation • Implement the remote interface • Extend java.rmi.server.UnicastRemoteObject • Implement the methods to be called remotely • Other medthods may be available only locally • Constructor must throw a remote exception

  16. UnicastRemoteObject • Objects of this type are accessible by the TCP/IP protocol • It automatically connects to the RMI runtime system • Can perform equality checks with other remote objects • You can also construct objects of this type with a specific port and,optionally, a SocketFactory on both server and client.

  17. Set Up the Server • Write a java main program • Instantiate classes to become remote objects • Put in a Security Manager • Bind the remote objects to a name in the registry (more later)

  18. Set Up a Client • Obtain references to remote objects from Naming.lookup() • Call methods on those remote objects • Should set up a Security Manager

  19. How to Proceed • Write the remote interface. This is shared between client and server • Write the remote object implementation • Write the client application that invokes methods of 2. • Compile all programs: javac xxx*.java -d classes 5. Write server program that creates the remote objects

  20. Running Your Program 1. Start the RMI registry: start rmiregistry 2. Locate classes to make stubs: run rmic 3. Start the server: java -Djava.security.policy = server.policy xxxServer 4. Run the client: java -Djava.security.policy = client.policy xxxClient

More Related