Remote Method Invocation Remote Method by vinsads1

VIEWS: 480 PAGES: 34

More Info
									Remote Method Invocation
Presented ByMohit Kumar

Remote Method Invocation
• Topics – The Principles behind RPC – What is RMI and how is it different from RPC – How RMI compares to socket based programming – RMI tools – The importance of marshalling and unmarshaling – The functions of stubs and skeletons – Creation of remote objects – Creation of clients – And some advanced RMI concepts implementations

RPC
• The concept of performing computation over the network has been around before java • A popular way to distribute work over the network through RPC • The implementation of RPC over the network was mostly procedural because of the restrictions on the Languages that implemented it. • And hence the implementation of RPC happened to be procedural

Comparing RPC/RMI to Socket based Programming
• Sockets over (TCP/UDP)/IP – Repetitive Code – Tedious for Complex distributed operations – Mutually agreed upon Communication protocol(http,ftp etc). – Any change in interaction between the client and server requires redesign of protocol

Comparing RPC/RMI to Socket based Programming
• Sockets over TCP/IP – Has to be custom coding and the communication protocol designed – Protocol must be redesigned implemented and tested – Can work on any socket based network – Protocol defined can have any custom behavior • RPC based Protocols(e.g. RMI ) – Generated code – If interface modified, regenerate – It can work even on non socket based support – Protocol always works in synchronous call-return manner

RPC
Distributed Computing using RPC
Line 1.. Line 2.. Call proc() Call remoteproc() Line n Line n+1

Begin remoteproc(){ Logic Return value End remoteproc

Marshalling and Un-marshalling
• RPC alleviates these pains by leveraging the procedure calling “built in” to most programming languages • The following happens if a procedure gets called – Packages up names of procedures and transmits them to the RPC server – Server picks and decodes the procedures and the parameters – The procedure is executed – Server packages the the return values and transmits them back • The act of packaging and transmitting is called marshalling and reverse is called un-marshalling

Marshalling and Un-marshalling
Call remoteproc(param1, param2)

Marshalling Code

Physical Network

UnMarshalling Code

remoteproc(a,b) Logic End

Marshalling and Unmarshalling

Important Roles of Interfaces
• RPC cannot work without prior agreement between client/server about transferred data and its usage. • Even though it may be expressed differently interfaces in RPC serve the same purpose as in Java • It is a programming contract between caller and the callee • Once the agreement is reached the RPC can generate the required marshalling and un-marshalling code • In essence interface defines the high level protocol and RPC generates the implementation. • Since RPC is a technology that works across variety of languages it is possible for the client and server to be in different Languages

Interface Description language
• To cater to code generation for different languages the description of an RPC interface is kept in a language independent format called IDL. • IDL Compiler then generates language specific marshalling code • It saves programmers lots of tedious work

Interface Description language
Interface Description IDL Format

IDL Compiler

Generates

Generates

Client Implementation Code

Client Side marshalling code Code

Server Server-Side remoteproc(a,b) Implementation marshalling Logic Code Code End

Interworking

RMI-More than object oriented RPC
• Like RPC ,RMI has the following similarities – Remote calls can be made – Client/server contract based on interface – Automated generation on marshalling/un-marshalling code • Unlike RPC RMI – 100% pure java, giving a performance benefit(IIOP is new) – No special IDL file – Extends java programming model across machine boundary – Enables transfer of behavior(code) with data

RMI –starting simple
• Remote Interface
public interface HelloInterface extends java.rmi.Remote { // This method is called by remote clients and is //implemented by the // remote object public String sayHello() throws java.rmi.RemoteException; }

RMI –starting simple
• Remote Server
public class HelloServer extends UnicastRemoteObject implements
HelloInterface{

public HelloServer() throws RemoteException{ super();// Call the super-class constructor to export this object } public String sayHello() throws RemoteException{ return "Hello World, the current system time is " + new Date(); }

}

RMI –starting simple
• Client Program
public class HelloClient { public static void main(String args[]) { if (System.getSecurityManager() == null) System.setSecurityManager(new RMISecurityManager()); try { HelloInterface obj = (HelloInterface) Naming.lookup("/HelloServer"); String message = obj.sayHello(); System.out.println(message); } catch (Exception e) { System.out.println("HelloClient exception: " +e); } } }

RMI –starting simple
• RegisterServer
public class RegisterServer { public static void main(String args[]) { try { // Instantiate the object HelloServer obj = new HelloServer(); System.out.println("Object instantiated" +obj); Naming.rebind ("/HelloServer", obj); System.out.println("HelloServer bound in registry"); } catch (Exception e) { System.out.println(e); } } }

RMI Architecture
• Specification says – In the java distributed object model , a remote object is one whose method can be invoked from another JVM potentially on a different host. • RMI’s design intends transparency. A method invocation on local object has the same syntax as on a remote object, though under the hood there is a lot going on.

RMI Architecture

Client Application

Remote Server

Application layer

Stub

Skeleton

Presentation layer

Remote Reference

Remote Reference

Session layer

TCP

TCP

Transport layer

IP

IP

Network layer

Hardware

Hardware

Datalink layer

Physical Layer

RMI Architecture
• Stubs/Skeletons – Initiates connection with remote vm – Marshals parameters to the remote vm – Waits for the results – Unmarshals the results – Returns the value to caller – It hides the serialization mechanism • Skeleton – It handles the “remoteness” for the actual server,in other words you can code a remote object as if it were local – Unmarshals the method and parameters and marshals the results

RMI Architecture
• Remote Reference – This layer handles the details relating to interpreting and managing the references by the client – This layer defines and supports the semantics of RMI Connection – It provides a JRMP specific java.rmi.server.RemoteRef object that represents a handle to the remote object.A Remote-Stub uses a RemoteRef to carry out a remote method invocation

RMI Architecture
• Transport layer – Provides the basic connectivity – Even if two JVMs are on the same machine they connect through the host computer’s TCP/IP network protocol stack . – Java uses a wire level protocol JRMP on top of TCP/IP( an analogy is http over tcp/ip) – The protocol JRMP is specific to Sun Microsystems. – Other companies have other proprietary protocol – Current implementation is TCP based but in future it may be UDP based also.

Locating Remote Object
• How does a client find the Object • Well ! It find it through rmiregistry • RmiRegistry runs on a well defined port(1099) and is located on the same node as the Server • RMI can transparently look up the rmiregistry. (JNDI will be covered with EJBs). • A registry is a remote object that serves as a directory service for clients by keeping a hash-table like mapping of names to remote objects • An object is free to start its own registry and the behavior is defined in java.rmi.registry.Registry • One such implementation is RMIRegistry

Locating Remote Object
• Simply a remote object is associated with a name in the registry • When a client searches a name it is returned the stub of the object. • RMI provides java.rmi.Naming class that serves that serves as the client interaction point

Locating Remote Object

Registry

Registry.lookup Naming Naming.lookup

Client

Parameter passing in RMI
• Primitives – Passed by value • Object – A reference to an object across different JVMs don’t make sense – It is because reference points to heap and two JVMs don’t share heap memory – It is the object that is passed by value/copy not the reference. – This is done through serialization

Parameter passing in RMI
• Remote Parameters – RMI does not send a copy of the remote object – It substitutes the stub for the remote object serializes it and send it to the client – Remote parameters are important in callbacks – If a client sends a remote object back to the server as another argument it is still treated as remote object and not as a local object(even though it actually is local). – It may seem to be a performance overhead but it is essential to conserve the integrity of the semantics

Parameter passing in RMI
• Consider the case
public HelloServer() throws RemoteException{ super();// Call the superclass constructor //to export this object } public HelloInterface amethod() throws RemoteException{ return this; }

Parameter passing in RMI
• The clients have no direct contact with the remote JVM and they deal with Remote objects proxy,the stub. • Behind the scene, RMI checks the i/o parameters from a remote method to see if they implement Remote, if they do it replaces transparently with the corresponding stubs . This is important for the illusion that the clients are working with local object.

Parameter passing in RMI
• This means the following is true – Arguments to any remote method and return values must implement Serializable – Any field and members of the object arguments must also be serializable – The class file representing the serialized object must be present at the receiving end.

Distributed Garbage Collection
• If the client has to be under the illusion of “remote for local” the distributed object has to be subjected to garbage collection • It has a reference counting distributed garbage collection algorithm • It keeps track of which clients have requested access. • If and when the reference is made the object is marked dirty and when the client has dropped reference it marks it as clean

Distributed Garbage Collection
• In addition when a client obtains a reference it actually has a lease to the object for a specified time. If the client does not refresh the connection, the lease term expires, the DGC assumes that the remote object is no longer referenced and the object it marked for garbage collection. • Java.rmi.dgc.leaseValue system property controls the lease time in milisecond

Dynamic Loading Classes
• We have talked about transferring stubs, objects, references being transferred over the wire, but not classes. • Dynamic loading address this problem • Dynamic class loading is the ability of an RMI client(not necessary a client application) to work with classes that it does not know about ahead of time. • They may be dynamically loaded across the network when needed.

Dynamic Loading Classes
• Object marshalling – A marshalled object is a binary stream of data that represents an object – One may think of it as a miniature persistent store. – Special Properties • Same semantics and format as used for marshalling RMI parameters • The stream may optionally contain a URL annotation. This allows the un-marshaller of the object to load the class file if not available in the local classpath. • As the clients need to figure out where to load the class information from, the marshalled object’s URL annotation provides the answer.

Dynamic Loading Classes
A MARSHALLED OBJECT
CONTENT 1:a codebase URL http://ipaddress/classvr

CONTENT 2: Serialized state of some object


								
To top