Programacin en ambiente cliente/servidor

Unidad 1
1. Contexto de la programacin cliente/servidor
1.1 Arquitectura del modelo cliente/servidor
1.2 Modelos de dos y tres capas
1.3 Usos y aplicaciones
1.4 Comunicacin entre programas
1.5 Modelos de computacin distribuida
1.5.1 RMI
1.5.2 DCOM
1.5.3 Web Services
Referencias

1. Contexto de la programacin cliente/servidor

1.1 Arquitectura del modelo cliente/servidor
En el mundo de TCP/IP las comunicaciones entre computadoras se rigen bsicamente
por lo que se llama modelo Cliente-Servidor, ste es un modelo que intenta proveer
usabilidad, flexibilidad, interoperabilidad y escalabilidad en las comunicaciones. El
trmino Cliente/Servidor fue usado por primera vez en 1980 para referirse a PC's en
red.
Este modelo Cliente/Servidor empez a ser aceptado a finales de los 80s. Su
funcionamiento es sencillo: se tiene una mquina cliente, que requiere un servicio de
una mquina servidor, y ste realiza la funcin para la que est programado (ntese
que no tienen que tratarse de mquinas diferentes; es decir, una computadora por s
sola puede ser ambos cliente y servidor dependiendo del software de configuracin ).
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 en forma transparente an en entornos multiplataforma.

En el modelo cliente servidor, el cliente enva un mensaje solicitando un determinado

servicio a un servidor (hace una peticin), y este enva uno o varios mensajes con la
respuesta (provee el servicio). En un sistema distribuido cada mquina puede cumplir
el rol de servidor para algunas tareas y el rol de cliente para otras.
La idea es tratar a una computadora como un instrumento, que por s sola pueda
realizar muchas tareas, pero con la consideracin de que realice aquellas que son ms
adecuadas a sus caractersticas. Si esto se aplica tanto a clientes como servidores se
entiende que la forma ms estndar de aplicacin y uso de sistemas Cliente/Servidor
es mediante la explotacin de las PCs a travs de interfaces grficas de usuario;
mientra que la administracin de datos y su seguridad e integridad se deja a cargo de
computadoras centrales tipo mainframe.
Usualmente la mayora del trabajo pesado se hace en el proceso llamado servidor y el
o los procesos cliente slo se ocupan de la interaccin con el usuario (aunque esto
puede variar). En otras palabras la arquitectura Cliente/Servidor es una extensin de
programacin modular en la que la base fundamental es separar una gran pieza de
software en mdulos con el fin de hacer ms fcil el desarrollo y mejorar su
mantenimiento.
Esta arquitectura permite distribuir fsicamente los procesos y los datos en forma ms
eficiente lo que en computacin distribuida afecta directamente el trfico de la red,
reducindolo grandemente.

Cliente
El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos
al servidor, se le conoce con el trmino front-end. El Cliente 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
una 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.

Servidor
Es el proceso encargado de atender a mltiples clientes que hacen peticiones de
algn recurso administrado por l. Al proceso servidor se le 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 funciones que lleva a cabo el proceso servidor se resumen en los siguientes
puntos:

Aceptar los requerimientos de bases de datos que hacen los clientes.

Procesar requerimientos de bases de datos.
Formatear datos para transmitirlos a los clientes.
Procesar la lgica de la aplicacin y realizar validaciones a nivel de bases de
datos.

Caractersticas de la arquitectura Cliente/Servidor

Las caractersticas bsicas de una arquitectura Cliente/Servidor son:

Combinacin de un cliente que interacta con el usuario, y un servidor que

interacta con los recursos compartidos. El proceso del cliente proporciona la
interfaz entre el usuario y el resto del sistema. El proceso del servidor acta
como un motor de software que maneja recursos compartidos tales como
bases de datos e impresoras.
Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto
a recursos de cmputo como velocidad del procesador, memoria, velocidad y
capacidades del disco y input-output devices.
Se establece una relacin entre procesos distintos, los cuales pueden ser
ejecutados en la misma mquina o en mquinas diferentes distribuidas a lo
largo de la red.
Existe una clara distincin de funciones basada en el concepto de "servicio",
que se establece entre clientes y servidores.
La relacin establecida puede ser de muchos a uno, en la que un servidor
puede dar servicio a muchos clientes, regulando su acceso a recursos
compartidos.
Los clientes corresponden a procesos activos en cuanto a que son stos los
que hacen peticiones de servicios a los servidores. Estos ltimos tienen un
carcter pasivo ya que esperan las peticiones de los clientes.
No existe otra relacin entre clientes y servidores que no sea la que se
establece a travs del intercambio de mensajes entre ambos. El mensaje es el
mecanismo para la peticin y entrega de solicitudes de servicio.
El ambiente es heterogneo. La plataforma de hardware y el sistema operativo
del cliente y del servidor no son siempre la misma. Precisamente una de las
principales ventajas de esta arquitectura es la posibilidad de conectar clientes y
servidores independientemente de sus plataformas.
El concepto de escalabilidad tanto horizontal como vertical es aplicable a
cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite agregar
ms estaciones de trabajo activas sin afectar significativamente el rendimiento.
La escalabilidad vertical permite mejorar las caractersticas del servidor o
agregar mltiples servidores.

Ventajas del esquema Cliente/Servidor

Entre las principales ventajas del esquema Cliente/Servidor estn:

Uno de los aspectos que ms ha promovido el uso de sistemas

Cliente/Servidor, es la existencia de plataformas de hardware cada vez ms
baratas. Esta constituye a su vez una de las ms palpables ventajas de este
esquema, la posibilidad de utilizar mquinas considerablemente ms baratas
que las requeridas por una solucin centralizada, basada en sistemas grandes.
Adems, se pueden utilizar componentes, tanto de hardware como de
software, de varios fabricantes, lo cual contribuye considerablemente a la
reduccin de costos y favorece la flexibilidad en la implantacin y actualizacin
de soluciones.
El esquema Cliente/Servidor facilita la integracin entre sistemas diferentes y
comparten informacin permitiendo, por ejemplo que las mquinas ya
existentes puedan ser utilizadas pero utilizando interfaces ms amigables al
usuario. De esta manera, podemos integrar PCs con sistemas medianos y
grandes, sin necesidad de que todos tengan que utilizar el mismo sistema
operacional.
Al favorecer el uso de interfaces grficas interactivas, los sistemas Construdos
bajo este esquema tienen mayor interaccin y ms intuitiva con el usuario. En
el uso de interfaces grficas para el usuario, el esquema Cliente/Servidor
presenta la ventaja, con respecto a uno centralizado, de que no es siempre
necesario transmitir informacin grfica por la red pues sta puede residir en el
cliente, lo cual permite aprovechar mejor el ancho de banda de la red.
Una ventaja adicional del uso del esquema Cliente/Servidor es que es ms
rpido el mantenimiento y el desarrollo de aplicaciones, pues se pueden
emplear las herramientas existentes (por ejemplo los servidores de SQL o las
herramientas de ms bajo nivel como los sockets o el RPC).
La estructura inherentemente modular facilita adems la integracin de nuevas
tecnologas y el crecimiento de la infraestructura computacional, favoreciendo
as la escalabilidad de las soluciones.
El esquema Cliente/Servidor contribuye adems, a proporcionar, a los
diferentes departamentos de una organizacin, soluciones locales, pero
permitiendo la integracin de la informacin relevante a nivel global.

Desventajas del esquema Cliente/Servidor

Entre las principales desventajas del esquema Cliente/Servidor estn:

El mantenimiento de los sistemas es ms difcil pues implica la interaccin de

diferentes partes de hardware y de software, distribuidas por distintos
proveedores, lo cual dificulta el diagnstico de fallas.
Se cuenta con muy escasas herramientas para la administracin y ajuste del
desempeo de los sistemas.
Es importante que los clientes y los servidores utilicen el mismo mecanismo
(por ejemplo sockets o RPC), lo cual implica que se deben tener mecanismos
generales que existan en diferentes plataformas.
Adems, hay que tener estrategias para el manejo de errores y para mantener
la consistencia de los datos.
La seguridad de un esquema Cliente/Servidor es otra preocupacin importante.
Por ejemplo, se deben hacer verificaciones en el cliente y en el servidor.
El desempeo es otro de los aspectos que se deben tener en cuenta en el
esquema Cliente/Servidor. Problemas de este estilo pueden presentarse por
congestin en la red, dificultad de trfico de datos, etc.

Ejercicios

1. Dibujar cmo consideras que sera un diagrama en el modelo cliente servidor

de una agencia de viajes. Se debe considerar que ofrece tanto boletos de avin
como reservaciones en hoteles.

1.2 Modelos de dos y tres capas

El trmino arquitectura cliente/servidor es utilizado comnmente para hablar de la
arquitectura del software. De igual forma, los trminos arquitectura en 2 y 3 capas se
aplican al mismo concepto. Debe distinguirse entre ambos.
Se entiende por arquitectura fsica a la topologa de la aplicacin. Independientemente
de sta, desde un punto de vista lgico, una aplicacin puede ser dividida en
componentes que denominamos capas.
Estas son unidades altamente cohesivas, con responsabilidades de alto nivel, bien
definidas y autocontenidas. A la organizacin del software en trminos de estos
componentes le llamamos arquitectura lgica.
Arquitectura cliente/servidor habla de la topologa del software, mientras que decir que
su arquitectura es en capas habla de su arquitectura lgica.

PLD
Las aplicaciones de software presentan tres aspectos fundamentales: debe hacer que
los datos sean persistentes (D), debe procesarlos en forma acorde a la lgica de
negocios (L), y debe presentarlos adecuadamente a los usuarios (P).
Las aplicaciones en 1 capa (P+L+D), donde no se distingue una separacin lgica de
estos tres aspectos, son muy grandes, difciles de mantener, de distribuir,
incompatibles con la arquitectura cliente/servidor, pesadas y con gran consumo de
recursos.
Un primer acercamiento a la distribucin de las responsabilidades de la aplicacin en
dos unidades lgicas fue la arquitectura en 2 capas.
Por ltimo, en la actualidad se tiende a desarrollar aplicaciones con arquitectura en 3
capas, donde cada uno de los aspectos se corresponde a una unidad lgica.

Arquitectura en 2 Capas
Un arquitectura en 2 capas distribuye la aplicacin en dos componentes lgicos. Las
responsabilidades de cada componente hacen a las variantes de esta arquitectura.
Surge la arquitectura en 2 capas como consecuencia de la arquitectura
cliente/servidor. Esta topologa permite distribuir la carga de la aplicacin a dos
computadores diferentes, lo que llev naturalmente a distribuir las responsabilidades
de la misma a dos unidades lgicas.
Arquitectura P+L/D
Una primer variante es retirar el manejo de datos de la aplicacin. Esto permite a
varios clientes utilizar el mismo juego de datos. P+L es una unidad lgica por s, donde
el manejo de interfaz de usuario y el manejo de la lgica no se los distingue como
mdulos independientes. Tpicamente P+L se encuentra en el cliente, mientras que D
se encuentra en el servidor.
Un ejemplo de aplicaciones con esta arquitectura es una aplicacin que delega la
persistencia a un manejador de base de datos.

Arquitectura P/L+D
El hecho de tener la misma lgica en cada cliente permiti factorizarla, llevando la
misma al servidor.
Aqu la lgica de la aplicacin se encuentra embebida al manejo de la persistencia de
datos. En este tipo de aplicaciones la lgica resuelve los problemas de persistencia
encargndose ella misma de dicha tarea, no necesariamente utilizando un manejador
de base de datos, o embebiendo toda la lgica de negocios en el mismo.

Arquitectura P+L/L+D

Una tercer variante es repartir la tarea de la lgica, una parte junto a la interfaz de
usuario, y otro junto al manejo de persistencia de datos.
Un ejemplo de aplicaciones con esta arquitectura son aplicaciones similares a las que
tienen arquitectura P+L/D, que tienen implementada parte de la lgica en
procedimientos almacenados en el manejador de la base de datos.

Desventajas de la Arquitectura en 2 capas

La lgica de la aplicacin no puede ser reusada ya que est ligada, ya sea a la

interfaz de usuario o al manejo de persistencia de datos.
Las estaciones de trabajo pueden tener serias restricciones de recursos. Los
desarrolladores deben estar entrenados para optimizar la aplicacin de forma
que pueda ser utilizada en dichos entornos.
Incremento de la carga de la red: dado que el procesamiento de los datos se
realiza en el cliente, gran cantidad de informacin debe ser transmitida desde
el servidor.
El PC procesa y presenta la informacin. Lleva a aplicaciones monolticas,
caras y difciles de mantener. (fat client).
La lgica de negocios est implementada en el PC. Notar que la lgica de
negocios nunca usa el sistema de ventanas.
Implica un procedimiento de distribucin complicado, ya que en caso de un
cambio todos los PCs deben ser actualizados. Es difcil garantizar que un
cliente est corriendo una versin anterior.

Ejercicios
1. Analiza y enlista cinco sistemas que conozcas que pudieran estar usando el
modelo de dos capas. Especfica segn tu punto de vista con cul de las tres
variantes de la arquitectura de dos capas est diseada cada una de las
aplicaciones listadas.
2. Segn tu criterio, enlistar tres desventajas de la arquitectura en 2 capas del
modelo cliente/servidor.

Arquitectura en 3 Capas

La arquitectura en 2 capas, con su variante P/L+D, dio lugar a la arquitectura en 3

capas. El hecho de que la lgica de negocios y el manejo de persistencia sean una
unidad presentaba desventajas importantes: el manejador de base de datos resultaba
pequeo y quera emigrar a otro, deba actualizarse la versin, o se deseaba
incorporar datos de nuevas fuentes.
En esta arquitectura la lgica de la aplicacin ocupa una capa intermedia; est
separada tanto de los datos como de la interfaz de usuario (P/L/D). Los procesos
pueden ser administrados y desplegados en forma autnoma, sin relacin con la
interfaz de usuario y el manejador de base de datos. En teora, los sistemas en 3
capas son de ms fcil ampliacin y ms robustos y flexibles. Adems, pueden
integrar datos de mltiples fuentes.
Es importante notar que los lmites entre las capas son lgicos, por lo que es posible
ejecutar las tres capas en la misma mquina. Lo importante es que el sistema est
claramente estructurado y que hay una buena planificacin de los lmites entre las
diferentes capas.

Responsabilidades de las capas

Capa de presentacin:

Es responsable de la presentacin de los datos, recibiendo los eventos de los

usuarios y controlando la interfaz de usuario.

Capa de lgica de negocios:

Esta capa es nueva, es decir, no est presente en la arquitectura en 2 capas en

forma explcita.
Los objetos de negocios que implementan las reglas de negocios viven aqu,
y estn disponibles para la capa de presentacin.
Esta capa es la clave para resolver los problemas de la arquitectura en 2
capas.
Protege del acceso directo a la informacin desde la capa de presentacin

Capa de persistencia:

Es responsable del almacenamiento de los datos

Es comn reusar sistemas existentes de bases de datos en esta capa
Actualmente se usan manejadores relacionales: son avanzados, permiten el
uso de triggers y paquetes. Existen manejadores Orientados a Objetos

Ventajas de la arquitectura en 3 capas

Separacin clara de la interfaz de usuario de la lgica de la aplicacin. Esta

separacin permite tener diferentes presentaciones accediendo a la misma
lgica.
La redefinicin del almacenamiento de informacin no tiene influencia sobre la
presentacin.
En contraste con una arquitectura en 2 capas, donde solamente datos estn
accesibles al pblico, los objetos de negocios pueden brindar servicios (lgica
de la aplicacin) por la red

Otras ventajas dependen de la distribucin de los componentes lgicos sobre los

nodos fsicos. Estas sern discutidas en el siguiente captulo.

Ejercicios
1. Escribe tres ventajas de la arquitectura en tres capas respecto a la arquitectura
con dos capas.
2. Retomando el sistema realizado en la materia de Desarrollo e Implementacin
de Sistemas de Informacin, especifica qu partes del sistema se tendran que
agrupar o separar para conformar una arquitectura cliente/servidor de tres
capas. Realiza un diagrama para ilustrarlo.

1.3 Usos y aplicaciones

Middleware

Sockets: Esta barrera puede ser cruzada a travs de RPCs y programacin

directa sobre la red. El uso de RPC presenta como desventaja que no es
orientado a objetos.
Object Request Broker: ORB acta como un middleware entre un objeto que
necesita un servicio de otro en una maquina diferente. En lugar de escribir
cdigo de socket para el cliente y el servidor, simplemente se deja que el ORB
se encargue de las tareas de comunicacin por la red.
HyperText Transfer Protocol: Es el protocolo subyacente al web. Define la
forma de transmisin y el formato de los mensajes, y las acciones que deben
realizar los browsers y servidores web ante cada comando.

Componentes Grficos

Control ActiveX: Un control ActiveX permite interaccin con los lenguajes de

scripting, como VBScript, JScript y JavaScript, que se utilicen en la pgina en la
que el control fu descargado.
Java Applet: Un applet puede ser entendido como una aplicacin Java que fue
concebida para ser descargada a travs del web e interpretada por la mquina
virtual de un cliente web.

Contenido Esttico

HyperText Markup Language: HTML es el lenguaje universal para la

publicacin de hipertexto en el World Wide Web. Tiene formato no-propietario

basado en SGML, aunque no es necesariamente un subconjunto estricto de

ste.
Formularios: Los formularios de HTML son una de las formas posibles de
permitir una interaccin entre un usuario y el servidor web. Estos formularios
permiten visualizar los widgets ms comunes en las interfaces de usuario de
los lenguajes de programacin.

Generacin de contenido dinmico

CGI Script: es una aplicacin escrita generalmente en un lenguaje de scripting,

aunque es posible usar lenguajes compilados tambin. Esta aplicacin es
lanzada por el servidor web recibiendo la informacin provista por el usuario en
un formato que respeta la interfaz CGI
Servlets: Un servlet es una clase de Java que usa el API (Application
Programming Interface) llamado Servlet. Este API consiste en un conjunto de
clases e interfaces que definen mtodos que permiten procesar solicitudes
HTTP en forma independiente al servidor web.
JavaServer Pages: JSP es una tecnologa para desarrollar pginas web que
incluyen contenido dinmico. A diferencia de una pgina HTML, cuyo contenido
es esttico, una pgina JSP puede cambiar su contenido en base a cualquier
nmero de tems variables.
Active Server Pages: Es una tecnologa de scripting que puede ser utilizada
para crear contenido dinmico e interactivo para el web. Una pgina ASP es
una pgina HTML que contiene scripts que son procesados por el servidor web
antes de ser enviada al cliente web.

1.4 Comunicacin entre programas

Los sockets (zcalos, referido a los enchufes de conexin de cables) son mecanismos
de comunicacin entre programas a travs de una red TCP/IP. De hecho, al establecer
una conexin va Internet estamos utilizando sockets: los sockets realizan la interfase
entre la aplicacin y el protocolo TCP/IP. Dichos mecanismos pueden tener lugar
dentro de la misma mquina o a travs de una red. Se usan en forma cliente-servidor:
cuando un cliente y un servidor establecen una conexin, lo hacen a travs de un
socket. Java proporciona para esto las clases ServerSocket y Socket. Los sockets
tienen asociado un port (puerto). En general, las conexiones va internet pueden
establecer un puerto particular (por ejemplo, en http://www.itsa.edu.mx:8080/ el puerto
es el 80). Esto casi nunca se especifica porque ya hay definidos puertos por defecto
para distintos protocolos:

20 para ftp-data
21 para ftp
79 para finger

Algunos servers pueden definir otros puertos, e inclusive pueden utilizarse puertos
disponibles para establecer conexiones especiales.

1.5 Modelos de computacin distribuida

1.5.1 RMI
El mecanismo RMI (Remote Method Invocation) permite que una aplicacin o applet
se comunique con objetos que residen en programas que se ejecutan en mquinas
remotas. En esencia, en lugar de crear un objeto, el programador liga el objeto remoto
con un representante local, conocido como stub. Los mensajes dirigidos al objeto
remoto se envan al stub local, como si fuera el objeto real. El stub acepta los

mensajes que se le enven y a su vez, los enva al objeto remoto, el cual invoca sus
mtodos apropiados. El resultado de la invocacin de los mtodos en el objeto remoto
se enva de regreso al stub local, que los remite al emisor original de la llamada.

1.5.2 DCOM
A principios de los aos 90, Microsoft realiz un gran esfuerzo en promover OLE en
sus siglas en ingls que se podra traducir como incrustacin y vinculacin de objetos.
La necesidad de hacer esto naci del deseo de los usuarios de computadoras
personales de elaborar documentos que incluyeran tanto texto como grficas y tablas.
Dado que cada programa es especialista en alguna tarea, por ejemplo un procesador
de texto sirve para manejar texto, los programas de hojas de clculo sirven para el
manejo de tablas y nmeros y los de diseo para grficas, etc.; era difcil incrustar los
resultados de uno en otro.
Rpidamente Microsoft reconoci la necesidad de un mecanismo estndar de
empaquetamiento de componentes si quera que OLE fuera exitoso. Era crucial que
estos componentes fueran independientes de lenguajes para que se pudieran
desarrollar con cualquier lenguaje e incrustarse en otro componente escrito en otro
lenguaje tal vez.
Microsoft cre COM (Component Object Model) modelo de objetos componentes, que
es un estndar para la creacin y comunicacin entre componentes pero dentro de la
misma mquina. Al final de 1996, Microsoft introdujo DCOM (La D es de distribuido) un
conjunto de extensiones a COM que permite distribuir a los objetos COM en varias
computadoras en la red,. Ha existido una lentitud en que aparezca COM en
plataformas diferentes a Windows, debido a esto, regularmente se identifica a COM
como una arquitectura de componentes en lugar de una arquitectura de componentes
remotos o distribuidos; sin embargo, COM tiene mucho que ofrecer en este sentido,
especialmente cuando se trabaja en ambientes Windows.

1.5.3 Web Services

Un servicio Web o WebService es un servicio ofrecido por una aplicacin que expone
su lgica a clientes de cualquier plataforma mediante una interfaz accesible a travs
de la red utilizando tecnologas (protocolos) estndar de Internet.
Por ejemplo, una aplicacin como Access est formada por un conjunto de
componentes que ofrecen una serie de servicios, como el acceso a datos, la impresin
de informes, el diseo de tablas.
La idea de los servicios es la misma, aunque stos no tienen porqu estar en el mismo
ordenador que el cliente y adems son accedidos a travs de un servidor Web y de un
modo independiente de la plataforma, utilizando protocolos estndar (HTTP, SOAP,
WSDL, UDDI).
Una vez creado el servicio, para conseguir que sea accesible por los consumidores, es
necesario describirlo utilizando un lenguaje estndar llamado WSDL (Web Service
Description Language).
Los clientes del servicio podrn estar creados en cualquier lenguaje y ejecutarse sobre
cualquier sistema operativo y hardware, lo nico necesario es que sean capaces de
obtener y entender la descripcin WSDL de un servicio.