run - Java RMI-UnicastRemoteObject: ¿cuál es la diferencia entre UnicastRemoteObject.exportObject() y extiende UnicastRemoteObject?

run rmi java

Question

Me estoy preparando para un examen y tengo una pregunta que espero que alguien aquí pueda responderme.

Se trata de RMI y objetos remotos. Me pregunto por qué hay tanta diferencia entre estas dos implementaciones. uno está extendiendo el UnicastRemoteObject mientras que el otro está exportando el objeto como UnicastRemoteObject.

Realmente no entiendo la diferencia

Interfaz:

public interface EchoI extends Remote {
   public String echo() throws RemoteException
}

Este es el código del servidor (versión 1):

public class EchoImpl extends UnicastRemoteObject implements EchoI {
    public EchoImpl {
        super();
    }

    public static void main (String[] args) {
        try {
            LocateRegistry.createRegistry(Registry.REGISTRY_PORT);
            StoreHouse storehouseImpl = new StorehouseImpl();
            Naming.rebind("//localhost/StoreHouse.SERVICE_NAME", storehouseImpl);
            System.out.println("Server ready");
        } catch (RemoteException e) {
            e.printStackTrace();
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
    }

    public String echo() {
        return "echo";
    }
}

y esta sería la versión 2:

public class EchoImpl implements EchoI {
    public static void main (String[] args) {
        EchoI echoService = new EchoImpl();
        EchoI stub = (EchoI) UnicastRemoteObject.exportObject(echoService, 0);
        Registry registry = LocateRegistry.getRegistry();
        registry.bind("echoService", stub);
        ...
    }
}

Mi pregunta es: ¿cuál es la diferencia entre estos dos?

En la primera versión, el registro se crea explícitamente, además, ¿el objeto remoto se crea dentro de un nuevo enlace?

Tengo mucha curiosidad, ¿por qué en el primero necesito crear el registro yo mismo, pero no necesito exportar el objeto explícitamente y simplemente volver a enlazarlo usando Naming ? ¿Ese objeto ya está vinculado al registro antes, o podría usar bind en su lugar? ¿Y qué sucede si el objeto no estaba previamente atado y se ejecuta una revinculación?

En la segunda versión, el registro parece estar ya creado. ¿Por qué vincular a nombrar lo mismo que vincular a un registro directamente?

Esto es lo que creo:

• la primera clase direclty implementa la interfaz UnicastRemoteObject lo que significa que en el tiempo de ejecución se crea el registro y el objeto se exporta automáticamente al registro de RMI.
• como el objeto ya está vinculado al registro, debe producirse un nuevo enlace en lugar de un enlace normal.
• el último hace todo esto explícitamente.

Answer 1

En primer lugar, vincular y volver a vincular el objeto remoto utilizando la clase de Naming y la clase de Registry no es relevante para los escenarios de si una clase está extendiendo o no UnicastRemoteObject . Vea here para las diferencias.

En segundo lugar, la diferencia entre la clase que extiende UnicastRemoteObject es que si el objeto de ese tipo se usa como un stub, entonces no necesitará llamar a UnicastRemoteObject.exportObject para obtener el stub más para vincularlo con el registro. En su versión 1, StorehouseImpl debe haber extendido el UnicastRemoteObject , y de hecho, no es necesario que EchoImpl extienda UnicastRemoteObject para su versión 1, ya que no hay ninguna instancia de EchoImpl esté registrada como un objeto remoto en el registro.

En tercer lugar, menciona lo que sucedería si se ejecuta de antemano la rebind sin vinculación. Como se explica en el javadoc here , si no se ha insertado ningún nombre de clave, se comportará de la misma manera que si se ejecutara el primer bind .

Answer 2

Hay dos preguntas aquí.

1. Puede extender UnicastRemoteObject o llamar a UnicastRemoteObject.exportObject(). Lo que hagas depende de ti. El primero es simple y automático; El segundo significa que puedes extender otra clase.

2. Puede usar un registro de RMI externo o crearlo usted mismo dentro de la JVM de su servidor. Una vez más lo que haces depende de ti, hay ventajas en ambos sentidos.

   Estas dos preguntas no tienen interacción.

3. Si extend UnicastRemoteObject , también obtienes el beneficio de la ''semántica remota'' para los hashCode() y equals() , de modo que todos los stubs parecen ser idénticos al objeto remoto que los exportó, pero esto no tiene ningún uso práctico en el del lado del cliente, y realmente solo está ahí para soportar la implementación de RMI en sí.

Answer 3

Puede llamar a UnicastRemoteObject.exportObject() lugar de extender UnicastRemoteObject en un escenario en el que necesita extender cualquier otra clase. El efecto general es el mismo, creo.

Mira esto

Answer 4

java.rmi.server.UnicastRemoteObject se usa para exportar un objeto remoto con Java Remote Method Protocol (JRMP) y obtener un código auxiliar que se comunica con el objeto remoto.

Para los constructores y los métodos estáticos exportObject continuación, se exportObject el exportObject para un objeto remoto que se está exportando ...

Allí debes seguir el Javadoc