java - ¿Qué es stub en el "servidor" y qué significa esqueleto?
networking network-programming (6)
Trozo y esqueleto ocultan cierta complejidad.
El código oculta la serialización de parámetros y la comunicación a nivel de red para presentar un mecanismo de invocación simple al llamante.
El esqueleto es responsable de enviar la llamada a la implementación del objeto remoto real.
http://docs.oracle.com/javase/7/docs/platform/rmi/spec/rmi-arch2.html
¿Qué hace el stub en el lado del servidor? ¿Y qué es un esqueleto ?
Este es un diagrama de wikipedia. Instalé stub tanto en la máquina del servidor como en la máquina del cliente. Entiendo que el apéndice ayuda en la creación de redes en el lado del cliente, pero ¿qué hace el apéndice en el lado del servidor?
También en la figura anterior, ¿qué significa esqueleto?
Lo primero que debes hacer es olvidarte de los esqueletos. Han estado obsoletos durante 13 años.
El stub es creado por el objeto remoto cuando se exporta. A continuación, se vincula al Registro y el cliente lo obtiene a través de una búsqueda, o bien se devuelve directamente al cliente como resultado de otro método remoto.
El cliente luego usa el stub como una implementación de la interfaz remota en cuestión, para realizar la parte de red de RMI, interactuando con la JVM del servidor para eventualmente invocar el mismo método en el objeto remoto que el cliente está invocando en el stub.
mira la imagen siguiente:
Para ser corto, stub y skeleton son contrapartes en una configuración de servicio web. Skeleton belongs to service provider side y el stub belongs to receiver side . En el nivel inferior, el tocón y el esqueleto se comunican entre sí.
Desde el lado del cliente, los objetos de negocio se comunican con los objetos de código y el talón toma la responsabilidad del mensaje e invoca el servicio web. Una vez que se realiza la invocación, en el lado del proveedor de servicios, skeleton es el objeto paralelo para el código auxiliar y recibe el mensaje de solicitud, lo comprende y pasa la información a los objetos comerciales del lado del servicio.
La clave para entender "stubs" y "skeletons" es entender el concepto de "marshalling":
http://docs.oracle.com/cd/E13203_01/tuxedo/tux80/atmi/intatm23.htm
http://en.wikipedia.org/wiki/Marshalling_%28computer_science%29
http://technet.microsoft.com/en-us/library/cc738291%28WS.10%29.aspx
El "rmiregistry" es solo una función de búsqueda: nada más. Cuando un servidor hace un "bind ()", se "registra" a sí mismo con el rmiregistry. Cuando un cliente hace una "búsqueda ()", él verifica lo que está registrado en el servidor. Nada más y nada menos.
No creo que tenga sentido discutir sobre terminología como "esqueletos". Si lo prefiere, puede llamar a todo un "resguardo". El punto es que ambos son PROXIES, ambos MARSHALLING, un lado existe bajo el cliente (al que el cliente llama) y el otro lado existe en el servidor (el esqueleto llama al código del servidor real).
Afortunadamente mi explicación y ejemplo ayudaron en su otro enlace ayudado (al menos un poco).
Talón
Un stub para un objeto remoto actúa como un representante local del cliente o proxy para el objeto remoto. El código oculta la serialización de parámetros y la comunicación a nivel de red para presentar un mecanismo de invocación simple al llamante.
Alternativamente, considere un programa que se ejecuta en una máquina: cada método es una rama. Cuando mueve el método a una máquina remota, corta la rama y deja un trozo que contiene solo comunicaciones.
Fuente
Esqueleto
En la JVM remota, cada objeto remoto puede tener un esqueleto correspondiente. El esqueleto es responsable de enviar la llamada a la implementación del objeto remoto real.
Y un esqueleto que considero una primera implementación , algo que satisface la convención de llamadas, realiza una operación parcial y se completa satisfactoriamente.
Forma Oracle
Solo abordaré la pregunta de por qué el código debe estar del lado del servidor y del lado del cliente. La otra pregunta ya ha sido respondida.
Cuando un objeto remoto exportado se pasa a un objeto remoto, ya sea como un argumento de método o como un valor devuelto, sucede lo siguiente. Se crea un apéndice en la máquina del servidor. Luego se serializa, se envía a través de la red a la máquina cliente y se deserializa allí para hacer una copia idéntica del talón. Después de eso, ya no se necesita el código auxiliar en la máquina cliente.
Aquí hay un escenario típico.
- En la máquina S, se crea y exporta un objeto s.
- Parte de la exportación es crear un resguardo para s; la llamada es ss0.
- La máquina S llama a Naming.bind con s como argumento.
- El stub ss0 del lado del servidor se serializa y se envía a la máquina de registro R.
- La versión serializada de ss0 se usa para crear una copia de ss0 R; llámalo ss1.
- El registro en R mantiene un puntero a ss1.
De modo que un uso de tener un stub en el lado del servidor es para poder serializarlo y (una copia) enviarlo a otras máquinas, por ejemplo, como parte del enlace. De manera similar, cuando un cliente realiza una búsqueda, el registro serializa su copia (ss1) y la envía al cliente.