1.- Nivel físico: Determina el tipo de hardware a emplear, su interfaz y cómo llega a transmitir bits a través de un "enlace".

Solo participa el hardware.

2.- Nivel de enlace: Se preocupa por la transmisión de información entre dos máquinas entre las que físicamente solo existe un "enlace" que permita
En una arquitectura estructurada en niveles , cada nivel
8.2 - comunicarlas. Los mensajes se dividen en tramas y este nivel se encarga de la adecuada gestión de estos elementos.
se responsabiliza de unas tareas determinadas y
3.- Nivel de red: Se preocupa del encaminamiento de los mensajes. Necesita establecer una ruta entre dos nodos que no están directamente
Arquitectura proporciona una interfaz bien definidaa su nivel superior,
interconectados. Ya debe intervenir el "software". El protocolo que se usa es "Internet Protocol" del que existen dos variantes IPv4 e IPv6.
en Niveles asumiendo a su vez lo mismo de su nivel
4.- Nivel de transporte: Gestiona la fiabilidad en la entrega de los mensajes, así como su ordenación. También establece y gestiona las conexiones. Los
inmediatamente inferior. La mayoría de los sistemas de
(TCP/IP) dos protocolos mas utilizados son TCP y UDP
comunicaciones han optado por la utilización de la
5.- Nivel de aplicación: Gestión de los protocolos propios de cada aplicación. Ejemplos: FTP para la transmisión de ficheros, HTTP para acceder a las
arquitectura TCP/IP, centrada en 5 niveles:
páginas web.

1.- El proceso cliente invoca al procedimiento.

2.- El stub cliente recoge los argumentos de entrada de esa
llamada y los empaqueta en un mensaje de petición.
3.- Tras el ?marshalling? ya tendremos un mensaje de petición
construido y se envía al proceso servidor. Si dicho proceso no
está en la máquina local, habrá que emplear comunicación a El proceso cliente queda suspendido tras haber realizado el envio del
Facilita una imagen local cuando se realiza una través de la red. Paso de argumentos por valor:El procesamiento invocado - RCP Convencional mensaje de peticion la cual concluye al recibir el mensaje de
invocación a un procedimiento remoto. Cuando se 4.- El mensaje de petición llega a un stub servidor. Éste lo recibe una copia del valor actual de la variable que se suministra
como argumento. Cualquier modificación realizada en el respuesta. El servidor permanece suspendido hasta algn mensaje de
desarrolla una aplicación informática, el diseño Se diseñó un mecanismo para invocar de manera 8.3.1 desempaqueta para extraer los argumentos de entrada del petición (Linea Continua).
transparente a un procedimiento remoto, este procedimiento que debe invocarse. procedimiento invocado alterará esa copia, pero no la variable
estructurado recomienda que ésta se organice en una pasos original. Es lo habitual en una llamada a procesamiento remoto.
procedimiento paso a conocerse como Llamada a 5.- Con esta información se realiza la llamada propiamente 8.3.2
8.3 - serie de módulos o procedimientos. en dicha.
procedimiento Remoto (RPC). Paso de Paso por referencia:Se facilita al procedimiento invocado la 8.3.3
LLamada a Cada procedimiento implanta una tarea determinada y una 6.- El procedimiento servidor es ejecutado.
Para implantar lo anterior, se ocupará el principio de posición de la variable y no se necesita copiar dicha variable. Con
es independiente ´del resto del código de la aplicación. 7.- Se retorna el control y los argumentos de salida al stub argumentos Tipos - RCP El proceso servidor retorna un mensaje de confirmación, tan rapido se
procedimiento ocultación o encapsulación: el programador que utilice un RPC servidor. ello, cualquier modificación realizada en el procedimiento invocado
Los procedimientos tienen una signatura determinada, procedimiento debe conocer su interfaz pero no necesita resultará visible a todos los demás procedimientos en los que de Asincróna reciba el mensaje de petición Esto reduce el intervalo de suspensión
remoto 8.- El stub servidor empaqueta los argumentos de salida y el
donde se especifica cuales son sus argumentos de conocer cómo está implantado. pueda accederse a esa misma variable. Para similar el paso por RCP del proceo cliente y avanzan paralelamente,
resultado para construir un mensaje de respuesta.
RPC entrada y salida. Con ello actúan como una caja negra, 9.- Se transmite el mensaje de respuesta al stub del proceso referencia se podría indicar que un determinado argumento debe
ocultando cómo están implantados y permitiendo que su pasarse en los dos sentidos: tanto en el de entrada como en el de
cliente. Esto reactiva al proceso cliente.
código pueda modificarse. Para invocar un procedimiento salida.
10.- El stub cliente desempaqueta los argumentos de salida y
Este proceso tiene la imposibilidad de devolver argumentos de salida
basta con coonocer su identificador y facilitar los el resultado. - RCP Asincróna
11.- Con esta información devuelve el control al procedimiento en un mensaje respuesta, para obtenerrlo realiza una segunda RCP
argumentos que espera. diferida
invocador, terminando así la llamada. asincróna la cual retorna los argumentos de salida, El proceso cliente
dispone de algun mecanismo para recoger resultados. Este proceso
icombina las caracteristicas de las dos variantes anteriores
1.Se asume que el proceso cliente habra?obtenido previamente un
La infraestructura de objetos remotos proporciona transparencia proxy que permita realizar la invocación remota (ROI).
de acceso y ubicacio? n. Oculta parte de los detalles de 2.El ORB recibe esa peticio? n por parte del proxy.
8.4.1 8.4.3
distribucion pero no todos. 3.Cuando el esqueleto reciba este mensaje de peticio? n, lo procesara?
- Encapsula datos y operaciones Visión La interfaz se puede especificar mediante IDL (Interface Detalles de en funcio?n del identi?cador de me? todo incluido en e?
l. Una alternativa más simple para las aplicaciones distribuidas con
la componentes implantados en diferentes lenguajes de programación
de Definition Languaje) Por una parte se utiliza para especificar La 4.El esqueleto queda momenta? neamente bloqueado, esperando que
en entornos de middleware de comunicación orientada a objetos
- Implementa las operaciones mediante metodos infraestructura de objetos remotos proporciona transparencia de invocación ?nalice la ejecucio?n del me?todo invocado.
ROI Segun el que sesultan accesibles a través de mensajes.
Usuario tradicionales es implementarlo sobre un único lenguaje orientado a
Comunicaciones acceso y ubicacio? n. remota 5.El ORB recoge el mensaje de respuesta y lo transmite al nodo objetos, pero es importante que garantice portabilidad. Un ejemplo
paradigma cliente, para entrega?rselo al proxy. es Java RMI el cual implementa en la invocación de objetos remotos
Orientado a Objetos - Responde a las invocaciones efectuadas desde 6.El proxy del nodo cliente hab? ?a quedado esperando tal respuesta para java.
8.4.5 RMI.
otros módulos clientes desde el ?nal del paso 1. Existen reglas para programar con objetos remotos:
(Método
·Para declarar la interfaz del O.R. (Objeto Remoto) se define
de como cualquier interfaz en java extendiéndola con
- Capacidad de abstracción y flexibilidad del - Invocaciones concurrentes. Varios clientes pueden invocar invocación java.rmi.Remote
8.4 paradigma OO simulta?neamente operaciones sobre un mismo objeto. La Remota)
- La encapsulación permite transparencia de implementacio? n del objeto servidor debe aplicar las te?
cnicas de ·Al invocar un método sobre un O.R. es necesario indicar la
Invocacion a Ventajas del modelo programacio? n concurrente descritas en las pri- meras unidades de posible excepción java.rmi.RemoteException
ubicación. Esto permite ubicar los objetos de
Objeto de objetos
acuerdo a distinstos criterios Los objetos se crean en una aplicacio? n distribuida de igual manera que este texto.
Remoto distribuidos 8.4.2 en las aplicaciones no distribuidas. - Migracio?n. En sistemas que soporten migracio? n de objetos, debe ·La clase que mantenga el código server debe extender la clase
- Es posible reutilizar aplicacion heredadas, 8.4.4 Otros java.rmi.server.UnicastRemoteObject
encampusalndo objetos Creacion La referencia proporciona acceso a un objeto. Como solo se puede garantizarse que las referencias apunten al objeto correcto con
aspectos
- Se garantiza escalabilidad, distribuyendo los objetos y acceder a un objeto a trave? s de su interfaz, la referencia debe independencia de su ubicacio? n. Una primera medida para
sobre una red proporcionar este soporte consiste en utilizar referencias con
registro proporcionar acceso a dicha interfaz. En caso de un objeto remoto, la
localizador.
de referencia debe proporcionar toda la informacio? n de acceso necesaria
- Replicacio? n. En sistemas que soporten replicacio? n de objetos debería
objetos (ubicacio?
n de red y protocolo de acceso). proporcionarse transparencia de replicacio? n y alguna gestio? n que
- Invocación Local: Invocador e invocado son dos garantice la consistencia entre el estado de las diferentes réplicas.
Tipos de objetos que pueden aparecer en un sistema.
Invocación
- Invocación Remota: Invocador e invocado son dos
objetos que residen en procesos distintos Comunicación asincrónica: No se bloquea el emisor, el
mensaje se envía y continua inmediatamente con su
ejecución.
Toma en cuenta el intervalo de
8.5.1 espera que soporta el emisor para Comunicación sincrónica: El emisor llega a bloquearse esperando alguna confirmación. Existen tres tipos de comunicación
dar por confirmada la transmisión sincrónica:
Sincronizacion del mensaje. Los tipos son: 1.Envió: la confirmación es muy rápida y en ella solo intervienen procesos locales. El mensaje todavía no ha llegado a salir del
nodo emisor.
2.Entrega en el receptor: Tras hacer la entrega, el middleware de intercomunicación será el que retorne la confirmación al emisor
para reactivarlo. Este tipo de gestión coincide con la utilizada en las RPC asincrónicas.
No toda la comunicacion en una aplicacion distribuida se basa en el mecanismo de 3.Procesamiento por el receptor: Cuando el proceso receptor envía un nuevo mensaje indicando que ya ha completado el
llamada a procedimiento remoto. Entre los distintos modulos de la aplicacion se procesamiento del mensaje recibido.
8.5
pueden intercambiar mensajes sin necesidad de hacerlo mediante RPC. Se asume
Comunicación que los modulos a intercomunicar pertenecen al nivel de aplicacion ademas que Comunicación persistente: Es cuando middleware de intercomunicación es capaz de mantener el mensaje hasta que el proceso receptor este en condiciones
basada en tambien existe un middlewarre que implanta esa comunicacion entre modulos. Cabe de recibirlo.Los nodos que deban recorrerse para trasmitir el mensaje hacia su destino podrán guardar dicho mensaje durante el tiempo que sea necesario.
destacar que los roles de cliente y servidor se cambian por emisor y receptor de un
Esto es importante en caso de fallos en alguno de los servidores intermedios. Se permite que:
mensajes oEl receptor no este activo cuando el emisor inicie la transmisión del mensaje
mensaje
oEl emisor no este activo cuando se le entregue el mensaje al receptor.
8.5.2 El correo electrónico puede ser un ejemplo de comunicación persistente.
Persistencia
Comunicación no persistente: el middleware no es capaz de mantener los mensajes que deben
transmitirse. Si el destinatario no está activo o abortara, la comunicación se rompería. Los ejemplos
serian UDP y TCP.