Kate Playground Sets Forum

RMI

The main documentation to know the RMI is: Oracle Java Tutorial

The main problems in the use of Socket for communication between client and server are related to:

1. You must establish a port on which the Server listens (and the Client somehow has to know).
2. It should establish a protocol between the two systems (and the implementation is left entirely to the programmer).
3. There is no logic of object-oriented programming: the reasons for sending data (primitive or string), if you want to implement an object-oriented programming (see Using the Command Design Pattern is to be encoded manually.
4. not exist controls to compile time, Client and Server are left to themselves in the management of a kind.

RMI (Remote Method Invocation) was established as a top layer based on Socket to provide programmers the ability to work in "objects" on remote systems.

The main drawback of MRI is related to the overhead implicit in its use:

• To make transparent the communication must go through Java classes generated by (so-called stubs , which slows performance.

classes and interfaces used for MRI are:

Let's see how you actually use:

RMI system from the standpoint Server
first step to do is to define an interface defining what we can do on our Server object: public interface
OurServerObject extends Remote {
public boolean isInsideServer () throws RemoteException ;
public Date getDate () throws RemoteException;}

important point to remember is that our interfaces must be Remote and that any method defined must be able to launch RemoteException; this exception (type checked) can happen if:

• Server is not active, unreachable, or communication with the client is finished
• errors occurred during the marshaling of parameters or return values \u200b\u200b

This creates a class (real, not abstract) that will be used on the Server, and implement our interfaccia:

public class  OurServerObjectImpl  extends  UnicastRemoteObject implements OurServerObject  {

    public OurServerObjectImpl()  throws RemoteException  {

    }

    public boolean isInsideServer()  throws RemoteException {

        return true;

    }

    public Date getDate()   throws RemoteException {

        return Calendar.getInstance().getTime();

    }

}

Importante il costruttore vuoto perché verrà utilizzato nella creazione dell'oggetto (e deve poter lanciare l'eccezione RemoteException ); la nostra classe verrà utilizzata per creare l'oggetto remoto che i Client utilizzeranno;

Creiamo infine una istanza di Server che si occuperà di avviare il registro RMI e di registrare il nostro oggetto:

public class  Server  {

    public static void main(String [] args) throws RemoteException, MalformedURLException {

        java.rmi.registry.LocateRegistry.createRegistry(1099); //porta di default

        OurServerObjectImpl obj = new OurServerObjectImpl();

        

        //registra l'oggetto nel registro

Naming.rebind (OurFirstObject ", obj);}

}

Class Server will be launched command line will create our object, place it in the RMI registry and then ... waiting for the system will free the resources (and therefore will not be completed successfully!)

RMI system in terms of Client
A client can be any computer (remote or not) that is considered in a separate JVM; requirements to be able to use our remote system:

1. know the address of the machine (such as IP or hostname)
2. STOP!

As you can see, use a remote object is virtually nothing, we see a real class how to access the server object: public class Client

{public static void main (String [] args) throws MalformedURLException , RemoteException, NotBoundException {

System.out.println ("I get a reference to the server");

/ / get reference

OurServerObject obj = (OurServerObject) Naming.lookup (OurFirstObject ");

System.out.println (" We are in a server? -> "+ obj.isInsideServer ());

System.out.println (" Here's the date of the server: "+ obj.getDate ());}

}

Other important information about RMI: RMI

The system is based on a multi-threaded servers, each call The Server returns the object instance memory location, which means that it is for the busy schedule to manage every aspect to make the system thread-safe.

Our object extended UnicastRemoteObject , if we have a remote object that can not be changed in this respect, we can use in the constructor of our object a method call UnicastRemoteObject.exportObject (this) and remember to implement correct methods Object.hashcode () , Object.Equals (Object o) and Object.toString () .

From Java 1.5 onwards there is no need to create, using rmic stubs and skeletons, the system handles them automatically, unfortunately, for the certification, they must be created with rmic .

We used remote methods without being aware of a particular important: the parameters for the remote methods and return values \u200b\u200bmust be of type Serializable , this leads to several consequences which will be discussed in the paragraph relating to the interface.

objects that we send (and receive) can be:

1. primitive types - in this case is made a copy ( pass-by-value )
2. items - if they are not Serializable verrà lanciato NotSerializableException ; viene passato per valore (come i tipi primitivi)
3. oggetti remoti - viene mandato lo stub (quindi per riferimento)

In generale gli oggetti che creiamo sul Server (e dentro gli oggetti remoti) possono essere:

• Remote
• UnicastRemoteObject
• Serializable

Gli oggetti Remote sono oggetti che vengono considerati remoti; gli unici metodi che possono essere chiamati da un client sono i metodi definiti in un interfaccia Remote .

Gli oggetti UnicastRemoteObject sono tutti oggetti che vivono sul server; sono gli unici oggetti che rimangono sul server, e che restituiscono un riferimento quando ci viene restituita una istanza dell'oggetto.

Ecco anche il codice relativo all'esempio di RMI.
Ecco anche il codice relativo all'esempio di RMI usando un Factory Method.