SDI - Parte I

Introducción
La presente documentación recopila toda la información necesaria para el correcto

desempeño en el curso Sistemas Distribuidos en la Escuela Tecnológica Superior de la
Universidad de Piura.
El objetivo de la presente documentación es ofrecer todos aquellos conceptos necesarios para

la comprensión de arquitecturas cliente / servidor n capas para el desarrollo de aplicaciones
informáticas.
Erick Arauco Moreno

Escuela Tecnológica Superior - Universidad de Piura. 1
Capítulo I
Introducción
1.1. Definiciones.
Comenzaremos a definir algunos términos indispensables para la correcta ejecución del curso:
Computación temprana: Computación Monolítica – Uni Procesador; Concebida

inicialmente bajo el uso de un simple procesador. Dicho procesador era utilizado para
la ejecución de una o más aplicaciones.
Sistema Distribuido: Concebido como una colección de computadoras

independientes, interconectadas a través de una red con la capacidad de colaborar en
la realización de una tarea. Es importante tener en cuenta que las computadoras serán
consideradas “independientes” sólo si no comparten memoria o espacio de ejecución
para los programas. En la siguiente figura observamos una representación de este tipo
de sistemas.
work
stations a local network
The Internet
a network host
Figura 1.1 Sistema Distribuido.
Computación Distribuida: La cual podemos enfocar de dos maneras:

o Servicio de red: Identificamos un elemento conocido como servidor en una
red de computadores. Ejemplo: World Wide Web.
o Aplicación de red: Aquella aplicación que normalmente se ejecuta en un
entorno de red y está destinada a usuarios finales.
En la siguiente figura observaremos una descripción del presente concepto:
Erick Arauco Moreno

Figura 1.2 Computación Distribuida.
1.2. Formas de Computación.
A continuación analizaremos las diferentes formas de computación usadas por los

computadores:
Computación Monolítica.
Es la forma de computación más básica. Una simple computadora (normalmente un
computador personal) es utilizada para el procesamiento. El equipo no necesita estar
conectado a alguna red. Es utilizada por un usuario al mismo tiempo.
Múltiple usuarios pueden alinearse al concepto de computación monolítica. Esta

forma de computación implica que los recursos de un simple computador (llamado
normalmente mainframe) pueden ser compartidos por los diferentes usuarios usando
una técnica conocida como “timesharing”. En la siguiente figura observamos una
representación gráfica de este tipo de computación:
Figura 1.3 Computación monolítica.
Erick Arauco Moreno

Computación Distribuida.
En contraste con la definición anterior, la computación distribuida implica un
procesamiento a través de varios computadores conectados a una red, en la cual,
cada computador posee sus propios recursos. La figura 1.2, muestra claramente la
representación de este concepto.
Computación Paralela.
Conocida normalmente como “computación paralela” ó “procesamiento paralelo”, en
la cuál más de un procesador simultáneamente ejecuta un simple programa.
Teóricamente, el procesamiento paralelo implica que una aplicación se ejecute más

rápidamente debido a que existen varios motores (CPUs) ejecutándose. En la práctica
existe la complejidad de dividir una aplicación de tal manera que pueda ser ejecutada
de manera separada en diferentes CPUs sin interferir entre cada porción de la
aplicación.
En la actualidad el procesamiento paralelo puede ser utilizado para solventar

problemas que pueden ser imposibles de resolver con un solo computador.
Típicamente este tipo de computación es usada en proyectos de larga escala
científicos en áreas como biología, aeroespacial, etc.
1.3. Ventajas y Desventajas de la Computación Distribuida.
Entre las principales ventajas podemos mencionar:
Poder de computación y disponibilidad de la red. Actualmente el poder de un

computador personal es superior al poder computacional de un mainframe de
aquellos días; lo mismo en relación al tamaño y costo. El acceso a la red en la
actualidad se ha convertido en un elemento básico para cualquier computador.
Compartir recursos. Los equipos, al estar conectados a través de una red, pueden
acceder a los recursos de otros equipos.
Escalabilidad. En la computación monolítica, los recursos estaban limitados a la

capacidad de un solo computador. En cambio, en la computación distribuida ante la el
incremento de demanda de recursos, los mismos pueden ser anexados adicionando
simplemente más computadores a la red.
Tolerancia a fallos. Comparada con la computación monolítica, la computación

distribuida provee la oportunidad a fallos, debido a que si un nodo falla, el resto de
nodos del sistema pueden seguir funcionando. Ejemplo: Replicación de una base de
datos en otro servidor.
Entre las principales desventajas podemos mencionar:
Erick Arauco Moreno

Múltiples puntos de fallos. Existen números elementos que pueden fallar como: los
computadores, la red, saturación de la red, etc.
Seguridad. En este tipo de sistemas, existen muchas más probabilidades de recibir un

ataque informático.
1.4. Conceptos Básicos – Aplicaciones.
A continuación analizaremos los siguientes conceptos ligados al desarrollo de aplicaciones

informáticas.
1.4.1. Aplicaciones y Procesos.
Cuando una aplicación informática es ejecutada en un computador normalmente se

representa como un proceso. Un proceso, puede ser considerado como una entidad
dinámica que existe sólo cuando el programa está en ejecución.
En la siguiente figura encontraremos los estados implicados en el ciclo de vida de un

proceso.
terminated
start
queued
exit
dispatch running
ready
event completion waiting

for event
blocked
Simplifed finite state diagram for a process's lifetime
Figura 1.4 Estados de un proceso.
En esta parte del curso utilizaremos el lenguaje de programación java con todos sus tipos
existentes. Es necesario tener en cuenta simple los tipos de aplicaciones java existentes
en el mercado, las cuáles pasaremos a representar de la siguiente manera:
En la siguiente figura observaremos la representación gráfica de una aplicación “stand-

alone” desarrollada utilizando la edición estándar de java; podemos observar que la
aplicación es ejecutada en un computador personal, el cuál debe poseer una máquina
virtual para la correcta ejecución de la clase java.
Erick Arauco Moreno

Figura 1.5 Aplicación de escritorio.
Otro tipo de aplicación java es la concerniente a los “applets”, la cuál reside en un

servidor web y sólo es ejecutada cuando la página web que hace referencia al applet es
llamada desde un navegador web. Es importante tener en cuenta que la ejecución del
applet se realiza en la máquina cliente, primero se descarga todo el contenido web y
luego se procede a descargar el archivo binario correspondiente al applet,
posteriormente, se inicia la ejecución del mismo.
En la siguiente figura encontaremos una representación gráfica del concepto de applet:
Figura 1.6 Applet.
El tercer tipo de aplicación java es la concerniente a los servlets, los cuáles forman parte
de la plataforma j2ee (java empresarial) y que gracias a su ejecución se conocen como
“aplicaciones de lado servidor”. Una representación gráfica de este tipo de aplicaciones la
observamos en la siguiente figura:
Figura 1.7 Servlet java.
1.4.2. Programación Concurrente.
A continuación vamos a observar tipos de programación concurrente:
Proceso concurrente ejecutado en múltiples computadores. La programación

concurrente en este caso implica varios computadores interactuando entre sí. Por
Erick Arauco Moreno

ejemplo, un cuando accedemos a una página web, un proceso en nuestro
navegador interactúa con otro proceso residente en el servidor web.
Proceso concurrente ejecutado en un simple computador. Algunos

computadores modernos soportan sistemas operativos multitarea, lo que implica
que muchos procesos pueden ser ejecutados concurrentemente. Esto es posible
en computadores que posean varios CPUs, donde cada CPU puede ejecutar un
proceso en forma separada.
Processes
P1
P2
P3
P4
time
Timesharing of a resource
Figura 1.8 Proceso concurrente.
Programación concurrente en un proceso. A veces es necesario para un simple

programa iniciar y ejecutar tareas concurrentemente. Ejemplo, una aplicación
realiza otras tareas mientras espera indefinidamente la confirmación del usuario.
Erick Arauco Moreno

Capítulo II
Comunicación entre procesos
La parte principal de los sistemas distribuidos es la comunicación entre procesos, lo cual

podemos definir como la habilidad que tienen los diferentes procesos para comunicarse entre
ellos colaborando en la ejecución de una tarea.
En este punto, identificamos dos conceptos claros: Solicitante y Receptor. La siguiente figura
representa la comunicación entre estos dos procesos:
Process 1 Process 2
data
sender receiver
Figura 2.1 Comunicación entre procesos.
En sistemas distrbuidos dos o más procesos pueden comunicarse entre sí tomando algunas
veces el rol del solicitante y otras el rol del receptor. Cuando la comunicación se realiza desde
un simple proceso hacia otro se conoce como Unicast, pero cuando la comunicación se realiza
desde un simple proceso hacia varios procesos, la misma es conocida como Multicast. La
siguiente figura muestra una representación de dichos conceptos:
P2 P2 P3 ... P4
m
m m m
P1 P1
unicast multicast
Figura 2.2 Unicast – Multicast.
2.1. Operaciones contempladas en una Comunicación entre procesos.
Las operaciones contempladas en la comunicación entre procesos pueden ser explicadas en

cuatro conceptos:
Enviar. Esta operación es utilizada por un proceso que desee transmitir datos a
otro proceso.
Recibir. Esta operación es utilizada por un proceso que desee aceptar datos desde
otro proceso.
Erick Arauco Moreno

Conectar. Operaciones que permiten establecer una conexión lógica entre dos
procesos. Uno de los procesos deberá enviar una solicitud de conexión y el otro
deberá aceptar dicha solicitud.
Disconectar. Esta operación permite cerrar una conexión lógica creada

previamente.
Las operaciones mencionadas anteriormente pueden ser visualizadas en situaciones tan

comunes como el protocolo HTTP (Hypertext Transfer Protocol), utilizando tan ampliamente
en el World Wide Web. A continuación observaremos la siguiente figura que representa el uso
de las cuatro operaciones:
Web server
S1 S2 S3 S4
ope rations:
HTTP S1: acce pt conne ction
a proce ss S2: re ce ive (re que st)
re que st
S3: se nd (re sponse )
an ope ration S3: disconne ct
HTTP
C1: make conne ction
re sponse
C2: se nd (re que st)
data flow C3: re ce ive (re sponse )
C1 C2 C3 C4
C4: disconne ct
Web browser
Figura 2.3 Operaciones utilizadas en una comunicación HTTP.
2.2. Sincronización de eventos.
Una de las principales dificultades de la comunicación entre procesos es aquella que define el
orden en que deben ejecutarse cada una de las tareas implicadas. Por ejemplo, en una
comunicación HTTP debemos tener en cuenta que la operación relacionada con el envío de
datos hacia el receptor no se dará si es que previamente no se ha concretado la operación de
conexión entre ambos procesos.
La manera más simple de lograr una sincronización de eventos es a través del uso de
“bloqueos”, lo que significa la suspensión de la ejecución de un proceso hasta que otro se
haya completado.
Las operaciones de bloqueo pueden ser asimismo clasificadas como Operaciones Síncronas u
Operaciones Asíncronas. Las operaciones síncronas son aquellas que utilizan el bloqueo para
asegurar el orden de cada operación, mientras que las asíncronas son aquellas en las que el
proceso es libre de continuar su ejecución.
Erick Arauco Moreno

En la siguiente figura observaremos una sincronización entre las operaciones de envío y
recepción:
process 1 process 2
running on host 1 running on host 2
blocking receive starts
blocking send starts an operation
execution flow
acknowledgement of data received suspended period
blocking send returns provided by the IPC facility blocking receive ends
Synchronous Send and Receive
Figura 2.4 Envío y Recepción Síncrona.
En la figura anterior, observamos que la operación de recepción en el proceso 2 espera a que

todos los datos sean recibidos, lo mismo sucede en el proceso 1. Una vez recibidos estos datos,
el proceso 2 envía una confirmación de ello al proceso 1, lo que permite que el mismo sea
desbloqueado.
En la siguiente figura observaremos una representación de un envío asíncrono y una recepción

síncrona:
Process 2
Process 1
blocking receive starts
nonblocking send
operation
execution flow
suspended period
blocking receive returns
Asynchronous Send and

Synchronous Receive
Figura 2.5 Comunicación asíncrona.
Erick Arauco Moreno

En la figura anterior observamos que la operación ligada con la recepción de datos es
suspendida hasta que los datos que llegan son recibidos en su totalidad. En caso contrario,
observamos que la operación de envío no causa en ningún momento alguna suspensión en el
proceso 1. Si se da el caso que el proceso de envío envía datos antes que el proceso de
recepción esté listo esto produciría que la información enviada no sea recibida o que parte de
ella se pierda.
En la siguiente figura observaremos una representación de un envío síncrono y una recepción

asíncrona:
Process 2
Process 1
blocking send issued
nonblocking receive issued

transparent acknowledgement
provided by the IPC facility execution flow
suspended period
Synchronous Send and

Asynchronous Receive
Scenario A
Figura 2.6 Envío síncrono y recepción asíncrona.
En la figura anterior, observaremos que la operación de recepción asíncrona no origina ningún

bloqueo en el proceso. Consideramos tres escenarios que podrían suceder:
Escenario 1. Los datos solicitados han sido recibidos a tiempo por el proceso 2, lo que
origina el envío de una confirmación al proceso 1 facilitando su desbloqueo. (Figura
2.6)
Escenario 2. Los datos solicitados aún no han sido recibidos por el proceso 2, por lo
tanto es su responsabilidad establecer un ciclo repetitivo con la finalidad de asegurar
que los datos sean recibidos correctamente. El proceso 1 estará bloqueado
indefinidamente hasta que el proceso 2 confirme la recepción correcta de los datos.
A continuación, observaremos la siguiente figura que representa lo mencionado:
Erick Arauco Moreno

Process 2
Process 1

and returned immediately
indefinite
blocking execution flow
suspended period
Process 2
Process 1 Synchronous Send and
Scenario B
Figura 2.7 Envío síncrono y recepción asíncrona (Escenario 2)
Escenario 3. Los datos solicitados aún no han sido recibidos. El proceso 2 puede ser
notificado (listeners) una vez que los datos han llegado con la finalidad de notificar al
proceso 1 la recepción correcta de los datos. En la siguiente figura se observará el
escenario 3.
Process 2
Process 1

process is notified
transparent acknowledgement of the arrival of
provided by the IPC facility data
execution flow
suspended period
Synchronous Send and

Scenario C
Figura 2.8 Envío síncrono y recepción asíncrona (Escenario 3)
En la siguiente figura observaremos un envío asíncrono y una recepción asíncrona:
Erick Arauco Moreno

Process 2
Process 1

process is notified
of the arrival of
data
execution flow
suspended period
Asynchronous Send and

Scenario C
Figura 2.9 Envío y recepción asíncrona.
En la figura anterior podemos observar que sin la presencia de bloqueos en ningún proceso, la
única manera de asegurar la recepción de datos es tener en cuenta que el proceso 2 estará en
espera siempre de la recepción de datos.
2.3. Deadlocks.
Bloqueos indefinidos pueden causar un “deadlock”. Un deadlock es el resultado de

operaciones usadas de manera incorrecta. En la siguiente figura observamos dos procesos
bloqueados de manera indefinida debido a que ambos están esperando datos del proceso
contrario.
Process 1 Process 2
receive from process 2 issued

process 1 blocked pending data
from process 2.
received from process 1 issued
process 2 blocked pending data
from process 1.
Figura 2.10 Deadlocks.
¿Es la suspensión indefinida? La suspensión de cada proceso se mantendrá hasta que suceda
un “timeout” o hasta que el sistema operativo aborte los procesos.
Erick Arauco Moreno

2.4. Representación de Datos.
En la capa física perteneciente a una red de computadores, los datos son transmitidos bajo la
representación de “binary stream” (0001001…10101); pero en la capa de aplicación la
transmisión de datos es mucho más compleja debido a que se hace necesario representar
tipos de datos ó estructuras de datos que típicamente son soportadas por los lenguajes de
programación (int, float, arrays, etc).
Consideremos el caso de dos aplicaciones heterogéneas, un proceso 1 ubicado en una

máquina A intenta enviar un entero a un proceso 2 una máquina B. El proceso 1 se encuentra
ejecutándose en una máquina de 32 bits mientras que el otro se encuentra en una máquina de
16 bits; por lo tanto consideremos las siguientes situaciones:
El proceso 1 necesita convertir el valor a transmitir teniendo en cuenta que el proceso

2 está siendo ejecutado en una máquina de 16 bits.
El proceso 1 envía el entero en 32 bits, una vez recibido por el proceso 2 es convertido
a una representación en 16 bits.
El proceso 1 transforma el dato a enviar a una representación externa, luego el

proceso 2 realiza la transformación a su representación nativa.
Ahora, consideraremos definir el término “Marshaling”, a través de la definición de dos pasos

necesarios para la transmisión de datos: 1) serializando las estructuras de datos y 2)
convirtiendo los datos bajo la modalidad de representación externa.
Erick Arauco Moreno

Capítulo III
Paradigmas de la Computación Distribuida
Podemos definir el concepto de paradigma con los términos “patrón”, “modelo”, etc. A
continuación comenzaremos a definir los más conocidos:
3.1. Message Passing (Paso de Mensajes)
El objetivo básico de la comunicación entre procesos es el paso de mensajes. En este

paradigma, los datos representan mensajes que son intercambiados entre procesos (Envío y
Receptor).
Las operaciones básicas para este tipo de paradigma son “enviar” y “recibir”; si la
comunicación es orientada a conexión, podríamos agregar también las operaciones de
“conexión” y “desconexión”. Las aplicaciones basadas en el uso de sockets (UDP, TCP) son un
claro ejemplo de este paradigma.
A continuación, observaremos una representación gráfica del presente paradigma.
Process A
Process B
a message
Message passing
Figura 3.1 Paso de mensajes.
3.2. Cliente / Servidor.
El paradigma más conocido y más utilizado es el cliente / servidor, el cuál asigna roles a cada
uno de los procesos. Por un lado tenemos el servidor, quién espera pasivamente por la llegada
de requerimientos, y por otro lado tenemos el cliente quién especifica los requerimientos y
espera por la respuesta del servidor.
En la siguiente figura podemos observar una representación del presente paradigma:
Erick Arauco Moreno

service request
a client process
a server process
Server host a service
Client host
...
The Client-Server Paradigm, conceptual
Figura 3.2 Cliente / Servidor.
3.3. Peer-to-Peer (Punto a Punto).
En el paradigma cliente / servidor, los procesos participantes juegan diferentes roles: El cliente
envía requerimientos mientras el servidor espera pasivamente por ellos, y proporciona una
respuesta una vez recibidos.
En el paradigma “peer-to-peer”, los procesos participantes tienen el mismo rol en el proceso

de comunicación con equivalentes capacidades y responsabilidades. Cada participante puede
solicitar un requerimiento al otro partcipante y esperar una respuesta por ello. Ejemplo:
Napster.
En la siguiente figura encontraremos una representación gráfica del paradigma:
process 1
request request
response
response
process 2
Figura. 3.3 Peer-to-peer.
Erick Arauco Moreno

El paradigma cliente / servidor es un modelo ideal para aplicaciones centralizadas bajo la
modalidad de servicios, mientras que el paradigma “peer-to-peer” es más apropiado para
aplicaciones como mensajería instántanea, transmisión de archivos, videoconferencia, etc.
El paradigma peer-to-peer puede ser implementado a través de protocolos como JXTA ó

Jabber.
3.4. Sistema de Mensajes.
El Sistema de Mensajes es una variación del paradigma basado en el paso de mensajes. En este
paradigma, un sistema de mensajería funciona como intermediario entre un remitente y un
destinatario en el intercambio de mensajes.
El remitente deposita el mensaje en el sistema, el cual esta asociado a un destinatario. Una vez
depositado dicho mensaje, el remitente está en la libertad de ejecutar otras tareas.
En la siguiente figura observaremos la representación del paradigma:
receivers
message system sender
...
...
Figura. 3.4 Sistema de Mensajes.
3.5. Llamada a Procedimientos Remotos.
En el modelo “Llamada a Procedimientos Remotos” la comunicación entre dos procesos

separados físicamente se convierte en una comunicación local, lo cual es bastante familiar a
los programadores.
En la siguiente figura observamos la representación del modelo:
Process B
Process A
proc1(arg1, arg2)
proc2(arg1)
proc3(arg1,arg2,arg3)
Figura. 3.5 RPC (Remote Procedure Call).

Erick Arauco Moreno
3.6. Objetos Distribuidos.
La idea de aplicar el concepto de objetos distribuidos nace de la aplicación de la metodología

orientada a objetos como aplicación al desarrollo de software. El objetivo: Las aplicaciones
pueden acceder a objetos que se encuentren distribuidos sobre la red. Sabemos que los
objetos contienen métodos, por lo tanto, su invocación también será factible.
Entre los paradigmas basados en este concepto podemos encontrar:
1. Remote Method Invocation. Equivalente a RPC, pero basado en el acceso remoto

de objetos. En el presente modelo, un proceso puede invocar los métodos de un
objeto que se puede residir en una máquina remota.
La representación de este paradigma lo observamos en la siguiente figura:
Process 2
Process 1
remote method invocation method1
method2
a remote object
The Remote Method Call Paradigm

Figura. 3.6 RMI.
2. Mobile Agent (Agentes Móviles). Un agente móvil es un programa u objeto

transportable, el cuál es lanzado desde un equipo origen. El agente viaja
autónomamente de host en host de acuerdo con un itinerario. En cada parada, el
agente puede acceder a los recursos o servicios necesarios completando de esta
manera su misión.
En la siguiente figura, encontramos una representación del paradigma:

Host 2
Host 1
Host 3
agent
Host 4
Figura. 3.7 Agentes Móviles.
Erick Arauco Moreno

3. Network Services. Los proveedores de servicios se registran en un directorio de
servidores en una red determinada. Un proceso que desee un particular servicio,
contacta al directorio y si el servicio está disponible se le proveerá entonces una
referencia al servicio. Con esta referencia, el proceso inicia la interacción.
La diferencia con RMI es que la ubicación de los servicios es transparente, por lo

tanto los programadores no necesitan conocer previamente la ubicación de los
mismos. Ejemplo: Jini.
Directory service
service object
Service requestor
Figura. 3.8 Network Services.
Erick Arauco Moreno

Capítulo IV
Invocación Remota de Métodos (RMI)
4.1. Arquitectura de los Objetos Distribuidos.
La premisa de los objetos distribuidos es minimizar la diferencia entre invocación remota de

métodos e invocación local de métodos. En la actualidad, las diferencias existentes entre
ambas formas de invocar métodos están ligadas a la comunicación entre procesos.
La siguiente figura representa la arquitectura a tener en cuenta que facilita el trabajo con
objetos distribuidos.
object
registry
object client object server
client server
proxy proxy
runtime runtime
support support
network network
support support
physical data path
logical data path

Figura. 4.1 Arquitectura Objetos Distribuidos.
De la figura anterior podemos resumir lo siguiente:
Un objeto distribuido es ofrecido, ó exportado por un proceso llamado “Servidor de

Objetos”.
Para acceder a un objeto distribuido, el proceso (objeto cliente), debe buscar primero
en el registro por una referencia al objeto. Esta referencia es utilizada por el objeto
cliente para realizar llamadas a métodos (métodos remotos).
Lógicamente el objeto cliente realizar llamadas directas al método remoto. En

realidad, la llamada es gestionada por un componente de software denominado
“cliente proxy” quién interactúa con el “runtime support” quién es el responsable de la
comunicación entre procesos (serialización/deserialización, transmisión de datos, etc).
Erick Arauco Moreno

4.2. Arquitectura RMI.
La invocación remota de métodos (RMI) es una implementación basada en objetos del modelo
“Llamada a Procedimientos Remotos”. Es importante mencionar que su implementación es
sólo bajo el lenguaje de programación Java.
En la presente arquitectura encontramos claramente tres capas que veremos a continuación:
Arquitectura Lado Cliente.

o Stub Layer. La petición de un proceso cliente es dirigida a un objeto
denominado “stub”, quien es el encargado de interceptar la llamada al objeto
remoto.
o Remote Reference Layer. Interpreta y gestiona las referencias hacia los

objetos remotos.
o Transport Layer. Orientada a conexión. Transmite los datos.
Arquitectura Lado Servidor.

o Skeleton Layer. Homólgos de los stubs en el servidor. Indispensable para
versiones anteriores a 1.2. Envía las llamadas a la actual implementación del
objeto remoto.
o Remote Reference Layer. Gestiona y transforma las referencias originadas

desde el cliente a referencias locales comprendidas por la capa Skeleton.
o Transport Layer. Orientada a conexión. Transmite los datos.
Registro de Objetos. El registro RMI (rmiregistry), es un directorio simple; un servicio

en el cual un servidor registra todo aquel objeto que podrá ser accedido remotamente.
En la siguiente figura, podemos visualizar la arquitectura Java RMI:
Directory service
object object
client server
supports the interface with
the application program
maps the platform-independent stub/skeleton stub skeleton

layer to the platform-dependent transport
layer; carries out remote reference protocols remote reference layer remote reference layer
transport layer transport layer
sets up, maintains, and shuts down
connections; and carries out the
transport protocol
logical data path
physical data path
Figura. 4.2. Arquitectura RMI.

Erick Arauco Moreno
4.3. API Java para RMI.
Para la implementación de la arquitectura RMI, es necesario definir tres áreas importantes, a

saber:
Remote Interface.
El punto de inicio para la creación de objetos distribuidos es la definición de la
interface Remota. Una interface, es una clase que sirve de plantilla para otras clases,
contiene: Métodos vacíos que deben ser implementados por aquellas clases que
implementen la interface.
Una interface remota es una interface que hereda de la clase Remote. Todo método
definido en esta interface representará el médoto remoto que podrá ser accedido
usando RMI.
A continuación un ejemplo de una interface:
import java.rmi.*;
public interface CalculoServer extends Remote {
public Integer Multiplicar(Integer num1, Integer num2) throws RemoteException;
}
Figura. 4.3. Interface remota.
En la figura anterior, observamos un método llamado “Multiplicar” que acepta dos

parámetros de entrada de tipo “Integer” y que devolverá un valor del mismo tipo
(Integer).
Remote Interface Implementation.

Representa aquella clase que implementa la interface remota. En esta clase
encontraremos el método “Multiplicar” implementado.
import java.rmi.*;
import java.rmi.server.*;
import java.util.*;
import java.io.*;
import java.net.*;
public class CalculoServerImpl extends UnicastRemoteObject implements

CalculoServer {
public CalculoServerImpl() throws RemoteException {

}
Figura. 4.4. Implementación de la interface remota (Parte I).

Erick Arauco Moreno
public Integer Multiplicar(Integer num1, Integer num2) {
Integer resultado = new Integer(num1.intValue() * num2.intValue());
return resultado;
}
public static void main ( String args[] ) {

try {
System.out.println("Inicializando servidor ...");
CalculoServerImpl objServ = new CalculoServerImpl();
String serverObjectName = "//localhost/CalcServer";
Naming.rebind(serverObjectName, objServ);
System.out.println("El servidor esta ejecutándose ...");
} catch (RemoteException re) {
re.printStackTrace();
} catch (MalformedURLException murl) {
murl.printStackTrace();
}
}
Figura. 4.4. Implementación de la interface remota. (II Parte).

En la figura anterior, observamos el registro del objeto remoto en el RMI Registry.
Cliente RMI.
Cualquier clase java que necesita obtener acceso a un método remoto. Previamente, la
clase deberá obtener una referencia a objeto remoto antes de interactuar con el
método.
import java.awt.*;
import java.awt.event.*;
import java.rmi.*;
public class CalculoClient {

public CalculoClient ( String ip ) {
System.out.println("arrancando cliente ...");
getRemoteCalculo ( ip );
}
private void getRemoteCalculo ( String ip ) {
try {
String serverObjectName = "//" + ip + "/CalcServer";
System.out.println(serverObjectName);
CalculoServer mycalc =
(CalculoServer)Naming.lookup(serverObjectName);
Figura. 4.5. Cliente RMI (I Parte).
Erick Arauco Moreno

Integer resultado = mycalc.Multiplicar ( 10, 2) ;
System.out.println("El resultado es: " + resultado);
} catch ( java.rmi.ConnectException ce ) {
ce.printStackTrace();
} catch ( Exception e ) {
e.printStackTrace();
}
}
public static void main ( String args [] ) {

CalculoClient cc = new CalculoClient("127.0.0.1");
}
}
Figura. 4.5. Cliente RMI (II Parte).
4.4. Pasos para construir una aplicación RMI.
En el Servidor.
o Colocar en una carpeta la interface remota y la clase que implementa dicha
interface.
o Compilar ambos archivos.
o Utilizar el comando “rmic” para generar el stub correspondiente.
rmic CalculoServerImpl
El archivo generado normalmente será “CalculoServerImpl_Stub.class”. Estos
pasos deben ser repetidos ante cualquier cambio en la implementación de los
métodos remotos.
o Iniciar el registro RMI.
Rmiregistry <port number>
Si no especificamos el puerto, por defecto será el puerto 1099.
o Iniciar el servidor de objetos.
java CalculoServerImpl
En el cliente.
o Colocar en una carpeta el archivo “CalculoClient.java” y compilarlo.
o Obtener una copia de la interface remota (“CalculoServer.class”).
o Obtener una copia del stub generado (CalculoServerImpl_Stub.class”).
o Ejecutar el cliente.
A continuación observaremos las salidas correspondientes:
Erick Arauco Moreno

Figura. 4.6. Iniciando el registro rmi.
Figura. 4.7. Registrando e iniciando el Servidor de Objetos.
Figura. 4.8. Iniciando el cliente RMI
Erick Arauco Moreno

En la siguiente figura resumimos los archivos necesarios tanto en el servidor y cliente RMI.
Object Client host Object Server host

object server directory
object client directory
SomeInterface.class
SomeInterface.class SomeServer.class
SomeImpl.class
SomeClient.class
SomeImpl_Skel.class
SomeImpl_Stub.class
Figura. 4.9. Cliente y Servidor RMI.
4.5. RMI Avanzado.

Una vez visto el funcionamiento RMI, pasemos a tener en cuenta las siguientes características
avanzadas:
Descarga de Stub.
Gestión de la seguridad.
Estas características no son inherentes de la arquitectura RMI, sino más bien las
consideraremos como mecanismos extras que pueden complementar el desarrollo de este tipo
de aplicaciones.
4.6. Descarga de Stub.

En la arquitectura RMI, hemos observado que la clase “Stub” debe estar presente junto con el
cliente para su correcta ejecución. En el ejercicio anterior, la copia de este “Stub” fue manual,
por lo que podría traernos problemas si la implementación del método remoto cambia
frecuentemente.
Java RMI provee un mecanismo que permite que un “stub” esté disponible dinámicamente
para el cliente. Usando un “stub dinámico”, una copia del mismo no es necesaria en el cliente,
debido a que la misma puede ser transmitida directamente desde un servidor web.
En la figura que mostramos a continuación, observaremos que el cliente descarga

automáticamente el stub requerido para su funcionamiento:
Erick Arauco Moreno

Server host
Client host
1
Client.class 2 RMI registry
HTTP host
3
SomeInterface_stub.class
SomeInterface_stub.class
4
X
SomeInterface_skel.class
SomeServer.class
1. Client looks up the interface object in the RMIregistry on the server host.
2. The RMIRegistry returns a remote reference to the interface object.
3. If the interface object's stub is not on the client host and if it is so arranged by the
server, the stub is downloaded from an HTTP server.
4. Via the server stub, the client process interacts with the skeleton of the interface object
to access the methods in the server object.
Figura. 4.10. Descarga de stub.
4.7. Gestión de la Seguridad.

La descarga de stubs utilizando un servidor web es una característica importante, pero trae
como consecuencia un problema de seguridad. Cuando un objeto RMI es descargado desde un
equipo remoto, su ejecución puede representar un ataque maligno.
Para ello RMI provee una clase java llamada RMISecurityManager. Un programa RMI puede
instanciar esta clase, lo cual trae como beneficio que todas las acciones a ejecutar se ajusten a
patrones de seguridad. Por ejemplo, el acceso a archivos locales, establecimiento de
conexiones de red, etc.
Erick Arauco Moreno

Capítulo V
XML
Extensible Markup Language
5.1. Introducción
HTML es un lenguaje de marcado. Es usado normalmente para formatear texto e información.

En este lenguaje encontramos elementos denominados “tags”. Podemos decir que HTML es
una aplicación del Standard Generalized Markup Language (SGML), el cual es considerado un
meta lenguaje (lenguaje para crear otros lenguajes) el cuál es usado para crear lenguajes como
HTML ó XML.
XML es una tecnología que permite describir los datos virtualmente, quién a diferencia de
HTML que limita al autor a un conjunto fijo de “tags”, XML permite crear documentos donde
nuevos “tags” puedan ser definidos.
A continuación un ejemplo de un documento XML:
Figura 5.1. Documento XML.
5.2. Definición de Tipo de Documento (DTD).
Una DTD es un documento que permite definir la estructura del documento XML a crear (qué
elementos, atributos, etc serán permitidos en el documento).
La estructura de un documento XML puede ser observada gráficamente de acuerdo a la

siguiente figura:
Erick Arauco Moreno

Figura 5.2. Estructura de un documento XML.
Basándonos en lo observado en la figura 5.2, y tomando dicha estructura como base de un

documento XML podríamos decir que el documento XML a crear podría tener la siguiente
apariencia:
<Weather-report>
<date>
<day></day>
<month></month>
<year></year>
</date>
<time></time>
<area>
<city></city>
<region></region>
<country></country>
</area>
<measurements>
<sky></sky>
<temperature></temperature>
<wind></wind>
<humidity></humidity>
</measurements>
</Weather-report>
Figura 5.3. Documento XML
Erick Arauco Moreno

A continuación observaremos en la siguiente figura un documento DTD representando la
misma estructura de la figura 5.2.
<!ELEMENT Weather-report (date, time, area, measurements)>

<!ELEMENT date (day, month, year)>
<!ELEMENT day (#PCDATA)>
<!ELEMENT month (#PCDATA)>
<!ELEMENT year (#PCDATA)>
<!ELEMENT time (#PCDATA)>
<!ELEMENT area (city, region, country)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT region (#PCDATA)>
<!ELEMENT country (#PCDATA)>
<!ELEMENT measurements (sky, temperature, wind, humidity)>
<!ELEMENT sky (#PCDATA)>
<!ELEMENT temperature (#PCDATA)>
<!ELEMENT wind (#PCDATA)>
<!ELEMENT humidity (#PCDATA)>
Figura 5.4. Definición de Tipo de Documento (DTD).
Asimismo, es importante tener en cuenta que la declaración de una DTD puede ser interna ó
externa, a continuación observaremos las imágenes correspondientes:
Figura 5.5. DTD externa.
En la figura anterior observamos que la DTD se encuentra definida en un archivo externo

denominado “person.dtd”, al cual se hace referencia desde el documento XML en la línea
<!DOCTYPE person SYSTEM “person.dtd”>.
A continuación observaremos la definición de una DTD interna:
Erick Arauco Moreno

Figura 5.6. DTD interna.
Ahora que conocemos el concepto de una DTD es necesario definir dos términos importantes:
Documentos Bien Formados. Son aquellos documentos XML que respetan un conjunto
de reglas propias de los documentos de marcado, como: Debe existir un único
elemento raíz, balance de etiquetas, elementos anidados correctamente, etc.
Documentos Válidos. Son aquellos documentos XML que poseen una estructura y se
encuentran definidos en base a ella.
Una DTD es expresada como un conjunto de declaraciones de:
Elementos. Los elementos en una DTD son declarados a través del siguiente formato:
<!ELEMENT nombre_elemento modelo_contenido>
Donde el nombre del elemento debe ser único en todo el documento y asimismo debe
iniciar con una letra o carácter underscore.
El modelo de contenido a su vez, puede ser catalogado en función de los siguientes

tipos:
o Elemento Hoja. Los elementos hojas son aquellos elementos que contienen
sólo texto y que no poseen ningún elemento hijo. El formato de un elemento
hoja se presenta de la siguiente manera:
<!ELEMENT autor (#PCDATA)>
Su representación en formato XML sería de la siguiente manera:
<autor>Pedro</autor>
Erick Arauco Moreno

o Elemento con subelementos. Son aquellos elementos que contienen uno o
muchos elementos hijos. El formato de este tipo de elementos se presenta de
la siguiente manera:
<!ELEMENT autor (nombre, apellidos)>
<autor>
<nombre>Pedro</nombre>
<apellidos>Perez</apellidos>
</autor>
o Elementos con contenido mixto. Son aquellos elementos que pueden contener
texto ó elementos hijos al mismo tiempo.
<!ELEMENT autor (#PCDATA|nombre|apellidos)>
<autor>
Estos son los datos de un autor
<nombre>Pedro</nombre>
<apellidos>Perez</apellidos>
</autor>
Atributos. Los atributos son aquellos objetos que proveen información sobre los
elementos. El formato para la definición de un atributo se presenta de la siguiente
manera:
<!ATTLIST nombre_elemento nombre_atributo valor_defecto>
Una ejemplo que permita la declaración de un atributo, sería de la siguiente manera:
<!ATTLIST libro
nivel (inicial | medio | avanzado) “inicial”>
Aplicando el atributo a un documento XML podremos encontrarlo de la siguiente

manera:
<libro nivel =”inicial”></libro>
Si no se especifica el atributo declarado, el mismo tendrá un valor por defecto

equivalente a la cadena “inicial”.
Número de ocurrencias. El número de ocurrencias significa las veces que un elemento

puede aparecer en un documento XML. Para ello podemos optar por el uso de los
siguientes símbolos:
o ? (Indica que el elemento ocurre 0 ó 1 vez – opcional).

o + (Indica que el elemento ocurre 1 ó más veces).
Erick Arauco Moreno

o * (Indica que el elemento ocurre 0 ó más veces).
Observemos el siguiente ejemplo:
<?xml version="1.0"?>
<!ELEMENT direccion (#PCDATA)>
<!ELEMENT email (#PCDATA)>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT nacionalidad (#PCDATA)>
<!ELEMENT organizacion (#PCDATA)>
<!ELEMENT persona (nombre, apellidos, organizacion*, direccion+, email*,
nacionalidad+)>
<!ELEMENT apellidos (#PCDATA)>
Figura 5.7. DTD
En la figura anterior podemos observar que los elementos “nombre” y “apellidos” son
elementos obligatorios que deben estar en el documento XML, mientras que “organizacion”, y
“email” son elementos que pueden estar presentes 0 ó más veces, y el elemento “direccion” y
“nacionalidad” son elementos que pueden estar presentes 1 ó más veces.
Si construimos un documento XML basado en la estructura anterior, podemos

observar lo siguiente:
<?xml version="1.0"?>
<persona>
<nombre></nombre>
<apellidos></apellidos>
<organizacion></organizacion>
<organizacion></organizacion>
<direccion></direccion>
</direccion></direccion>
</direccion></direccion>
<nacionalidad></nacionalidad>
</persona>
5.3. Ejercicios – DTD.
De los documentos XML que se presentan a continuación, se solicita extraer su DTD.
Erick Arauco Moreno

<planner>
<year value = "2000">
<date month = "7" day = "15">
<note time = "1430">cita con el Doctor</note>
<note time = "1620">clase de SDI</note>
</date>
<note>reunion familiar</note>
</date>
<note time = "0900">reunion en la Universidad</note>
</date>
<note time = "1900">fiesta con los amigos de la Universidad</note>
</date>
<note time = "1300">exposición sobre Grid Computing</note>
</date>
</year>
</planner>
<inventory>
<book isbn = "0-13-012507-5" inStock = "yes">
<name>Java How to Program 3</name>
<price>68.00</price>
<quantity>200</quantity>
</book>
<book isbn = "0-13-028418-1" inStock = "no">

<name>Perl How to Program</name>
<price>68.00</price>
<available>2000-12-15</available>
</book>
</inventory>
Asimismo, se solicita definir mediante una DTD y aplicar la estructura a un documento XML
para una presentación de diapositivas en base a los siguientes términos:
Una presentación consta de una o más diapositivas.

Atributos: identificador y número de la diapositiva.
Erick Arauco Moreno

Elementos: título, subtítulo, fecha, autor(es), ítem(s). Definir el nivel de ocurrencia
para cada elemento.
El elemento autor(es) es un elemento basado en los siguientes elementos: nombre,
apellidos, email, direccion.
Erick Arauco Moreno


SDI - Parte I

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SDI - Parte I

Cargado por

Copyright:

Formatos disponibles

Introducción

La presente documentación recopila toda la información necesaria para el correcto

El objetivo de la presente documentación es ofrecer todos aquellos conceptos necesarios para

Erick Arauco Moreno

Computación temprana: Computación Monolítica – Uni Procesador; Concebida

Sistema Distribuido: Concebido como una colección de computadoras

Figura 1.1 Sistema Distribuido.

Computación Distribuida: La cual podemos enfocar de dos maneras:

En la siguiente figura observaremos una descripción del presente concepto:

Erick Arauco Moreno

1.2. Formas de Computación.

A continuación analizaremos las diferentes formas de computación usadas por los

Múltiple usuarios pueden alinearse al concepto de computación monolítica. Esta

Figura 1.3 Computación monolítica.

Erick Arauco Moreno

Teóricamente, el procesamiento paralelo implica que una aplicación se ejecute más

En la actualidad el procesamiento paralelo puede ser utilizado para solventar

1.3. Ventajas y Desventajas de la Computación Distribuida.

Entre las principales ventajas podemos mencionar:

Poder de computación y disponibilidad de la red. Actualmente el poder de un

Escalabilidad. En la computación monolítica, los recursos estaban limitados a la

Tolerancia a fallos. Comparada con la computación monolítica, la computación

Entre las principales desventajas podemos mencionar:

Erick Arauco Moreno

Seguridad. En este tipo de sistemas, existen muchas más probabilidades de recibir un

1.4. Conceptos Básicos – Aplicaciones.

A continuación analizaremos los siguientes conceptos ligados al desarrollo de aplicaciones

1.4.1. Aplicaciones y Procesos.

Cuando una aplicación informática es ejecutada en un computador normalmente se

En la siguiente figura encontraremos los estados implicados en el ciclo de vida de un

event completion waiting

Simplifed finite state diagram for a process's lifetime

Figura 1.4 Estados de un proceso.

En la siguiente figura observaremos la representación gráfica de una aplicación “stand-

Erick Arauco Moreno

Otro tipo de aplicación java es la concerniente a los “applets”, la cuál reside en un

En la siguiente figura encontaremos una representación gráfica del concepto de applet:

Figura 1.6 Applet.

Figura 1.7 Servlet java.

1.4.2. Programación Concurrente.

A continuación vamos a observar tipos de programación concurrente:

Proceso concurrente ejecutado en múltiples computadores. La programación

Erick Arauco Moreno

Proceso concurrente ejecutado en un simple computador. Algunos

Programación concurrente en un proceso. A veces es necesario para un simple

Erick Arauco Moreno

La parte principal de los sistemas distribuidos es la comunicación entre procesos, lo cual

Figura 2.1 Comunicación entre procesos.

2.1. Operaciones contempladas en una Comunicación entre procesos.

Las operaciones contempladas en la comunicación entre procesos pueden ser explicadas en

Erick Arauco Moreno

Disconectar. Esta operación permite cerrar una conexión lógica creada

Las operaciones mencionadas anteriormente pueden ser visualizadas en situaciones tan

Figura 2.3 Operaciones utilizadas en una comunicación HTTP.

2.2. Sincronización de eventos.

Erick Arauco Moreno

blocking receive starts

blocking send starts an operation

Synchronous Send and Receive

Figura 2.4 Envío y Recepción Síncrona.

En la figura anterior, observamos que la operación de recepción en el proceso 2 espera a que

En la siguiente figura observaremos una representación de un envío asíncrono y una recepción

blocking receive starts

Asynchronous Send and