UNIDAD 1: INTRODUCCION A LA PROGRAMACION DISTRIBUIDA

1.1 ARQUITECTURA DEL MODELO CLIENTE/SERVIDOR

La tecnologa Cliente/Servidor es el procesamiento cooperativo de la
informacin por medio de un conjunto de procesadores, en el cual
mltiples clientes, distribuidos geogrficamente, solicitan
requerimientos a uno o ms servidores centrales.
Desde el punto de vista funcional, se puede definir la computacin
Cliente/Servidor como una arquitectura distribuida que permite a los
usuarios finales obtener acceso a la informacin de forma transparente
an en entornos multiplataforma. Se trata pues, de la arquitectura ms
extendida en la realizacin de Sistemas Distribuidos.
Un sistema Cliente/Servidor es un Sistema de Informacin distribuido
basado en las siguientes caractersticas:
Servicio: unidad bsica de diseo. El servidor los proporciona y el
cliente los utiliza.
Recursos compartidos: Muchos clientes utilizan los mismos
servidores y, a travs de ellos, comparten tanto recursos lgicos
como fsicos.
Protocolos asimtricos: Los clientes inician conversaciones. Los
servidores esperan su establecimiento pasivamente.
Transparencia de localizacin fsica de los servidores y clientes: El
cliente no tiene por qu saber dnde se encuentra situado el
recurso que desea utilizar.
Independencia de la plataforma HW y SW que se emplee.
Sistemas dbilmente acoplados. Interaccin basada en envo de
mensajes.
Encapsulamiento de servicios. Los detalles de la implementacin
de un servicio son transparentes al cliente.
Escalabilidad horizontal (aadir clientes) y vertical (ampliar
potencia de los servidores).
Integridad: Datos y programas centralizados en servidores facilitan
su integridad y mantenimiento.
En el modelo usual Cliente/Servidor, un servidor, (daemon en la
terminologa sajona basada en sistemas UNIX/LINUX, traducido como
"demonio") se activa y espera las solicitudes de los clientes.
Habitualmente, programas cliente mltiples comparten los servicios de
un programa servidor comn. Tanto los programas cliente como los
servidores son con frecuencia parte de un programa o aplicacin
mayores.

El Esquema de funcionamiento de un Sistema Cliente/Servidor sera:

El
El
El
El
El

cliente solicita una informacin al servidor.

servidor recibe la peticin del cliente.
servidor procesa dicha solicitud.
servidor enva el resultado obtenido al cliente.
cliente recibe el resultado y lo procesa.

COMPONENTES DE LA ARQUITECTURA CLIENTE/SERVIDOR

El modelo Cliente/Servidor es un modelo basado en la idea del servicio,
en el que el cliente es un proceso consumidor de servicios y el servidor
es un proceso proveedor de servicios. Adems esta relacin est
establecida en funcin del intercambio de mensajes que es el nico
elemento de acoplamiento entre ambos.
De estas lneas se deducen los tres elementos fundamentales sobre los
cuales se desarrollan e implantan los sistemas Cliente/Servidor: el
proceso cliente que es quien inicia el dilogo, el proceso servidor que
pasivamente espera a que lleguen peticiones de servicio y el
middleware que corresponde a la interfaz que provee la conectividad
entre el cliente y el servidor para poder intercambiar mensajes.
Para entender en forma ms ordenada y clara los conceptos y elementos
involucrados en esta tecnologa se puede aplicar una descomposicin o
arquitectura de niveles. Esta descomposicin principalmente consiste en
separar los elementos estructurales de esta tecnologa en funcin de
aspectos ms funcionales de la misma:
Nivel de Presentacin: Agrupa a todos los elementos asociados al
componente Cliente.
Nivel de Aplicacin: Agrupa a todos los elementos asociados al
componente Servidor.
Nivel de comunicacin: Agrupa a todos los elementos que hacen
posible la comunicacin entre los componentes Cliente y servidor.
Nivel de base de datos: Agrupa a todas las actividades asociadas
al acceso de los datos.
Este modelo de descomposicin en niveles, como se ver ms adelante,
permite introducir ms claramente la discusin del desarrollo de
aplicaciones en arquitecturas de hardware y software en planos.

ELEMENTOS PRINCIPALES
CLIENTE
Un cliente es todo proceso que reclama servicios de otro. Una definicin
un poco ms elaborada podra ser la siguiente: cliente es el proceso que
permite al usuario formular los requerimientos y pasarlos al servidor. Se
lo conoce con el trmino front-end.
ste normalmente maneja todas las funciones relacionadas con la
manipulacin y despliegue de datos, por lo que estn desarrollados
sobre plataformas que permiten construir interfaces grficas de usuario
(GUI), adems de acceder a los servicios distribuidos en cualquier parte
de la red.

Las funciones que lleva a cabo el proceso cliente se resumen en los

siguientes puntos:

Administrar la interfaz de usuario.

Interactuar con el usuario.
Procesar la lgica de la aplicacin y hacer validaciones locales.
Generar requerimientos de bases de datos.
Recibir resultados del servidor.
Formatear resultados.

La funcionalidad del proceso cliente marca la operativa de la aplicacin

(flujo de informacin o lgica de negocio). De este modo el cliente se
puede clasificar en:
Cliente basado en aplicacin de usuario. Si los datos son de baja
interaccin y estn fuertemente relacionados con la actividad de
los usuarios de esos clientes.
Cliente basado en lgica de negocio. Toma datos suministrados por
el usuario y/o la base de datos y efecta los clculos necesarios
segn los requerimientos del usuario.

SERVIDOR
Un servidor es todo proceso que proporciona un servicio a otros. Es el
proceso encargado de atender a mltiples clientes que hacen peticiones
de algn recurso administrado por l. Al proceso servidor se lo conoce

con el trmino back-end. El servidor normalmente maneja todas las

funciones relacionadas con la mayora de las reglas del negocio y los
recursos de datos. Las principales funciones que lleva a cabo el proceso
servidor se enumeran a continuacin:
Aceptar los requerimientos de bases de datos que hacen los
clientes.
Procesar requerimientos de bases de datos.
Formatear datos para trasmitirlos a los clientes.
Procesar la lgica de la aplicacin y realizar validaciones a nivel de
bases de datos.
Puede darse el caso que un servidor acte a su vez como cliente de otro
servidor. Existen numerosos tipos de servidores, cada uno de los cuales
da lugar a un tipo de arquitectura Cliente/Servidor diferente.

El trmino "servidor" se suele utilizar tambin para designar el

hardware, de gran potencia, capacidad y prestaciones, utilizado para
albergar servicios que atienden a un gran nmero de usuarios
concurrentes. Desde el punto de vista de la arquitectura cliente/servidor
y del procesamiento cooperativo un servidor es un servicio software que
atiende las peticiones de procesos software clientes.

1.2 MODELO DE DOS Y TRES CAPAS

MODELO DE DOS CAPAZ
En una arquitectura cliente/servidor clsica tenemos dos "capas" (twotier):
Una donde est el cliente que implementa la interface.
Otra donde se encuentra el gestor de bases de datos que trata las
peticiones recibidas desde el cliente.
La lgica de la aplicacin se encuentra por tanto repartida entre el
cliente y servidor.
Un ejemplo de esta configuracin podra ser un applet Java que se carga
en el navegador del cliente y trabaja directamente con la base de datos
mediante JDBC.

Fig.1 Esquema de arquitectura Cliente/Servidor clsica

Ventajas de este modelo:

Se mantiene una conexin persistente con la base de datos.
Se minimizan las peticiones en el servidor trasladndose la mayor
parte del trabajo al cliente.
Se gana en rendimiento gracias a la conexin directa y
permanente con la base de datos. A travs de una nica conexin
se realiza el envo y recepcin de varios datos.

Inconvenientes:
La ms importante desventaja, es que esta solucin es muy
dependiente del tipo controlador JDBC que se utilice para acceder
a la base de datos. El acceso se realiza desde el cliente y esto
significa que es l el que tiene que tener instalado en su sistema
los controladores necesarios para que se produzca la
comunicacin con la base de datos.
Adems hay que tener en cuenta que el modelo de seguridad de
Java impide que desde un applet sin validar (lo que se conoce

como untrusted applet), como lo son la mayora de los que se

ejecutan en un navegador, se puedan realizar las siguientes
operaciones:
1. El acceso general, y por supuesto mediante JDBC, a bases de datos
situadas en direcciones URL distintas a las que procede el mismo applet.
2. La configuracin de recursos locales como, por ejemplo, la informacin
de la fuente de datos ODBC para usar el puente JDBC-ODBC.
3. La descarga de clases nativas, es decir, aquellas cuyo nombre empieza
por Java. Esta restriccin afecta directamente a los navegadores que
utilizan JDK 1.0.2 o anterior, pues JDBC es posterior a esta versin, de
forma que las clases apropiadas no estarn instaladas localmente ni
podrn ser descargadas de Internet por el applet. Finalmente debemos
tener en cuenta que es bien conocido que los programas Java pueden
ser descompilados muy fcilmente con lo que introducir el acceso a
nuestras bases de datos mediante un applet Java conlleva un riesgo
considerable en cuanto a la seguridad.

Arquitectura en tres capas

Con la arquitectura cliente/servidor en tres capas (three-tier) aadimos
una nueva capa entre el cliente y el servidor donde se implementa la
lgica de la aplicacin. De esta forma el cliente es bsicamente una
interface, que no tiene por qu cambiar si cambian las especificaciones
de la base de datos o de la aplicacin; queda aislado completamente del
acceso a los datos.
As un applet de Java se carga en el navegador del cliente y se comunica
con un servlet que corre en la mquina servidor; o bien accedemos a la
base de datos a travs de un formulario HTML. El servlet establece una
conexin a la base de datos mediante JDBC.
En este caso se tiene total libertad para escoger dnde se coloca la
lgica de la aplicacin: en el cliente, en el servidor de base de datos, o
en otro(s) servidor(es). Tambin se tiene total libertad para la eleccin
del lenguaje a utilizar.
Se utiliza un lenguaje de tipo general (probablemente C) por lo que no
existen restricciones de funcionalidad.
Los programas sern ptimos desde el punto de vista de la performance.
Tambin deber implementarse especialmente el Call remoto, lo que
seguramente se har de una forma ms libre que los Remote Procedure
Call actualmente disponibles.

No existe compromiso alguno con el uso de lenguajes propietarios, por lo

que las aplicaciones sern totalmente portables sin cambio alguno.
Puede determinarse en qu servidor(es) se quiere hacer funcionar estos
procedimientos. En aplicaciones crticas se pueden agregar tantos
servidores de aplicacin como sean necesarios, de forma simple, y sin
comprometer en absoluto la integridad de la base de datos,
obtenindose una escalabilidad muy grande sin necesidad de tocar el
servidor de dicha base de datos.
El problema de esta arquitectura es cmo se implementa? Parece
ilusorio tratar de programar manualmente estos procedimientos,
mientras que, si se dispone de una herramienta que lo hace
automticamente, presenta ventajas claras sobre la alternativa anterior:

Fig.2 Arquitectura Cliente/Servidor en tres capas

Como se podra esperar cada uno de los componentes de la aplicacin

en una arquitectura three-tier se separa en una sola entidad. Esto te
permite implementar componentes de una manera ms flexible. Algo
que no creo que sorprenda es la afirmacin de que este tipo de
arquitectura es la ms compleja.
En esta Arquitectura todas las peticiones de los clientes se controlan en
la capa correspondiente a la lgica del negocio. Cuando el cliente
necesita hacer una peticin se la hace a la capa en la que se encuentra
la lgica del negocio. Esto es bastante importante pues eso quiere decir
que:
1. El cliente no tiene que tener drivers ODBCni la problemtica
consiguiente de instalacin de los drivers por tanto se reduce el
costo de mantener las aplicaciones cliente
2. El Cliente y el Gestor de Reglas de negocio tienen que hablar el
mismo lenguaje (en nuestro caso COM)
3. El Gestor de Reglas de Negocio y el Servidor de Datos tienen que
hablar el mismo lenguaje (en nuestro caso ODBC)

Lo ideal sera que el Gestor de Reglas de Negocio no slo OLE y ODBC

sino otros estandares como DBLib, OLI, DRDA, SQL/API y X/Open

Ventajas de este modelo:

No existe ningn problema con respecto al tipo de controlador
JDBC utilizado para acceder a la base de datos. Todos los recursos
necesarios para establecer la conexin con la base de datos se
encuentran en el servidor y por tanto, el cliente no necesita
instalar nada adicional en su mquina para poder acceder a la
base de datos.
Esta arquitectura proporciona considerables mejoras desde el
punto de vista de la portabilidad de la aplicacin, escalabilidad,
robustez y reutilizacin del cdigo. Asimismo facilita las tareas de
migracin o cambios en el sistema gestor de la base de datos.
Desaparecen las restricciones debidas a las limitaciones de los
applets impuestas por el modelo de seguridad de Java.

Inconvenientes:
Esta solucin es algo menos eficiente que la del modelo de dos
capas, ya que hemos aadido una capa intermedia ms de
software.

1.3 USOS Y APLIACIONES

Tipos de sistemas de los Cliente-Servidor dependiendo de las
aplicaciones que el servidor pone a disposicin de los clientes.
Servidores de Impresin, mediante el cual los usuarios comparten
impresoras.
Servidores de Archivos, con el cual los clientes comparten discos
duros.
Servidores de Bases de Datos, donde existe una nica base de
datos.
Servidores de Lotus Notes, que permite el trabajo simultneo de
distintos clientes con los mismos datos, documentos o modelos.
Servidores Web, tambin utilizan la tecnologa Cliente- Servidor,
aunque aaden aspectos nuevos y propios a la misma.

Algunos servidores esperan las solicitudes en puertos bien conocidos de

modo que sus clientes saben a qu zcalo IP deben dirigir sus
peticiones. El cliente emplea un puerto arbitrario para comunicarse. Los
clientes que se quieren comunicar con un servidor que no usa un puerto
bien conocido tienen otro mecanismo para saber a qu puerto dirigirse.
Este mecanismo podra usar un servicio de registro como Portmap, que
utiliza un puerto bien conocido.

1.4 COMUNICACIN ENTRE PROGRAMAS

El proceso para la creacin de un servicio siempre comienza con la
creacion del Soccer. As como el cliente necesita llamadas especficas en
determinados momentos, el servidor trabajo de modo similar pero aade
unas pocas llamadas extras al sistema. El servidor utiliza la llamada del
sistema Socket (), pero debe hacer un trabajo extra que era opcional
para el cliente,
El cliente siempre realiza una conexin activa porque la persigue
enrgicamente
los servidores por otro lado necesitan proporcionar un numero de puesto
especifico y consiste a los programas clientes si les va a prestar servicio.
El programa servido que escriba deber utilizar las llamadas de sistema
socker (), bind (), listen (), accept (). Y mientras el programa cliente es
una conexin activa, l servidor es una conexin pasiva. Las llamadas de
isistemas () y accept () crean una conexin solo cuando el cliente pide
una conexin (similar a la accin de responder al timbre de un telfono
El ejemplo de servidor escucha en un socket (puerto 8000) esperando
peticiones entrantes. Cualquier programa, como el client.c de ejemplo,
puede conectar con este servidor y pasarle hasta 16.384 hytes de datos
El servidor trata los datos como datos ASCII y los convierte en
maysculas antes de pasrselos a! programa cliente.
Estos dos sencillos programas se pueden volver a utilizar fcilmente
cuando se escriban programas cliente-servidor basados en socket
Los servidores que pueden recibir muchas peticiones simultneas
utilizan fork para crear un proceso separado para la administracin de

peticiones de servicio constitucionalmente caras.

server.c crea un socket permanente para la escucha de peticiones de
servicio; cuando un cliente conecta con el servidor, se crea un socket
temporal. Cada vez que un cliente conecta con un servidor, se abre un
nuevo socket temporal entre el cliente y el servidor.

1.5 MODELO DE COMPUTACION DISTRIBUIDA

1.5.1 RMI
RMI (Java Remote Method Invocation) es un mecanismo ofrecido
por Java para invocar un mtodo de manera remota. Forma parte del
entorno estndar de ejecucin de Java y proporciona un mecanismo
simple para la comunicacin de servidores en aplicaciones distribuidas
basadas exclusivamente en Java. Si se requiere comunicacin entre
otras tecnologas debe utilizarse CORBAo SOAP en lugar de RMI.
RMI se caracteriza por la facilidad de su uso en la programacin por
estar especficamente diseado para Java; proporciona paso de objetos
por referencia (no permitido por SOAP), recoleccin de basura distribuida
(Garbage Collector distribuido) y paso de tipos arbitrarios (funcionalidad
no provista por CORBA).
A travs de RMI, un programa Java puede exportar un objeto, con lo que
dicho objeto estar accesible a travs de la red y el programa
permanece a la espera de peticiones en un puerto TCP. A partir de ese
momento, un cliente puede conectarse e invocar los mtodos
proporcionados por el objeto.
La invocacin se compone de los siguientes pasos:
Encapsulado (marshalling) de los parmetros (utilizando la funcionalidad
de serializacin de Java).
Invocacin del mtodo (del cliente sobre el servidor). El invocador se
queda esperando una respuesta.
Al terminar la ejecucin, el servidor serializa el valor de retorno (si lo
hay) y lo enva al cliente.
El cdigo cliente recibe la respuesta y contina como si la invocacin
hubiera sido local.

1.5.2 CORBA

Common Object Request Broker Architecture (CORBA) es

un estndar definido por Object Management Group (OMG) que permite
que diversos componentes de software escritos en mltiples lenguajes
de programacin y que corren en diferentes computadoras, puedan
trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas
en entornos heterogneos.

CARACTERISTICAS
Entre las principales caractersticas de CORBA nos encontramos con:
Independencia en el lenguaje de programacin y sistema
operativo: CORBA fue diseado para liberar a los ingenieros de las
limitaciones en cuanto al diseo del software. Actualmente
soporta Ada, C, C++, C++11, Lisp, Ruby, Smalltalk, Java, COBOL, P
L/I y Python.
Posibilidad de interaccin entre diferentes tecnologas: uno de los
principales beneficios de la utilizacin de CORBA es la posibilidad
de normalizar las interfaces entre las diversas tecnologas y poder
as combinarlas.
Transparencia de distribucin: ni cliente ni servidor necesitan
saber si la aplicacin est distribuida o centralizada, pues el
sistema se ocupa de todo eso.
Transparencia de localizacin: el cliente no necesita saber dnde
ejecuta el servicio y el servicio no necesita saber dnde ejecuta el
cliente.
Integracin de software existente: se amortiza la inversin previa
reutilizando el software con el que se trabaja, incluso con sistemas
heredados.
Activacin de objetos: los objetos remotos no tienen por qu estar
en memoria permanentemente, y se hace de manera invisible
para el cliente.
Otras como: el tipado fuerte de datos, la alta capacidad de
configuracin, libertad de eleccin de los detalles de transferencia
de datos, o la compresin de los datos.
1.5.3 COM/DCOM
Microsoft Distributed COM (DCOM) extiende COM (Component Object
Model) para soportar comunicacin entre objetos en ordenadores
distintos, en una LAN, WAN, o incluso en Internet. Con DCOM una
aplicacin puede ser distribuida en lugares que dan ms sentido al
cliente y a la aplicacin.

Como DCOM es una evolucin lgica de COM, se pueden utilizar los

componentes creados en aplicaciones basadas en COM, y trasladarlas a
entornos distribuidos. DCOM maneja detales muy bajos de protocolos
de red, por lo que uno se puede centrar en la realidad de los negocios:
proporcionar soluciones a clientes.
Actualmente DCOM viene con los sistemas operativos Windows 2000,
NT, 98 y tambin est disponible una versin para Windows 95 en la
pgina de Microsoft. Tambin hay una implementacin de DCOM para
Apple Macintosh y se est trabajando en implementaciones para
plataformas UNIX como Solaris.

La arquitectura DCOM
DCOM es una extensin de COM, y ste define como los componentes y
sus clientes interactan entre s. Esta interaccin es definida de tal
manera que el cliente y el componente pueden conectar sin la necesidad
de un sistema intermedio. El cliente llama a los mtodos del
componente sin tener que preocuparse de niveles ms complejos
En los actuales sistemas operativos, los procesos estn separados unos
de otros. Un cliente que necesita comunicarse con un componente en
otro proceso no puede llamarlo directamente, y tendr que utilizar
alguna forma de comunicacin entre procesos que proporcione el
sistema operativo. COM proporciona este tipo de comunicacin de una
forma transparente: intercepta las llamadas del cliente y las reenva al
componente que est en otro proceso.
Cuando el cliente y el componente residen en distintas mquinas, DCOM
simplemente reemplaza la comunicacin entre procesos locales por
un protocolo de red. Ni el cliente ni el componente se enteran de que la
unin que los conecta es ahora un poco ms grande.
Las libreras de COM proporcionan servicios orientados a objetos a los
clientes y componentes, y utilizan RPC y un proveedor de seguridad para
generar paquetes de red estndar que entienda el protocolo estndar de
DCOM.

1.4 SERVICIOS
Un servicio web (en ingls, Web Service o Web services) es una
tecnologa que utiliza un conjunto de protocolos y estndares que sirven
para intercambiar datos entre aplicaciones. Distintas aplicaciones de
software desarrolladas en lenguajes de programacin diferentes, y
ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web
para intercambiar datos en redes de ordenadores como Internet.
La interoperabilidad se consigue mediante la adopcin de estndares
abiertos. Las organizaciones OASIS y W3C son los comits responsables
de la arquitectura y reglamentacin de los servicios Web. Para mejorar la
interoperabilidad entre distintas implementaciones de servicios Web se
ha creado el organismo WS-I, encargado de desarrollar diversos perfiles
para definir de manera ms exhaustiva estos estndares. Es una
mquina que atiende las peticiones de los clientes web y les enva los
recursos solicitados.