Programación Cliente-Servidor

Instituto Tecnológico Superior de Tequila

Ingeniería en Informática 6to
Abel Barajas Hernández
Numero Control: 10061171
19 Febrero 2013

1
INTRODUCCIÓN

La tecnología Cliente/Servidor es el procesamiento cooperativo de la información por medio de

un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente,
solicitan requerimientos a uno o más servidores centrales.

Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una
arquitectura distribuida que permite a los usuarios finales obtener acceso a la información de
forma transparente aún en entornos multiplataforma. Se trata pues, de la arquitectura más
extendida en la realización de Sistemas Distribuidos.

Un sistema Cliente/Servidor es un Sistema de Información distribuido basado en las siguientes

características:

 Servicio: unidad básica de diseño. El servidor los proporciona y el cliente los utiliza.
 Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a través de
ellos, comparten tanto recursos lógicos como físicos.
 Protocolos asimétricos: Los clientes inician “conversaciones”. Los servidores esperan su
establecimiento pasivamente.
 Transparencia de localización física de los servidores y clientes: El cliente no tiene por
qué saber dónde se encuentra situado el recurso que desea utilizar.
 Independencia de la plataforma HW y SW que se emplee.
 Sistemas débilmente acoplados. Interacción basada en envío de mensajes.
 Encapsulamiento de servicios. Los detalles de la implementación de un servicio son
transparentes al cliente.
 Escalabilidad horizontal (añadir 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 terminología sajona basada en

sistemas UNIX/LINUX, traducido como "demonio") se activa y espera las solicitudes de los
clientes. Habitualmente, programas cliente múltiples comparten los servicios de un programa
servidor común. Tanto los programas cliente como los servidores son con frecuencia parte de un
programa o aplicación mayores.

El Esquema de funcionamiento de un Sistema Cliente/Servidor sería:

1. El cliente solicita una información al servidor.

2. El servidor recibe la petición del cliente.
3. El servidor procesa dicha solicitud.
4. El servidor envía el resultado obtenido al cliente.
5. El cliente recibe el resultado y lo procesa.

2
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. Además esta
relación está establecida en función del intercambio de mensajes que es el único elemento de
acoplamiento entre ambos.

De estas líneas 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 diálogo, 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 más ordenada y clara los conceptos y elementos involucrados en esta
tecnología se puede aplicar una descomposición o arquitectura de niveles. Esta descomposición
principalmente consiste en separar los elementos estructurales de esta tecnología en función de
aspectos más funcionales de la misma:

 Nivel de Presentación: Agrupa a todos los elementos asociados al componente Cliente.

 Nivel de Aplicación: Agrupa a todos los elementos asociados al componente Servidor.
 Nivel de comunicación: Agrupa a todos los elementos que hacen posible la comunicación
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 descomposición en niveles, como se verá más adelante, permite introducir más
claramente la discusión 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 definición un poco más elaborada
podría ser la siguiente: cliente es el proceso que permite al usuario formular los requerimientos y
pasarlos al servidor. Se lo conoce con el término front-end.

Éste normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de
datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas
de usuario (GUI), además 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 lógica de la aplicación y hacer validaciones locales.

3
  Generar requerimientos de bases de datos.
 Recibir resultados del servidor.
 Formatear resultados.

La funcionalidad del proceso cliente marca la operativa de la aplicación (flujo de información o

lógica de negocio). De este modo el cliente se puede clasificar en:

 Cliente basado en aplicación de usuario. Si los datos son de baja interacción y están
fuertemente relacionados con la actividad de los usuarios de esos clientes.
 Cliente basado en lógica de negocio. Toma datos suministrados por el usuario y/o la base
de datos y efectúa los cálculos necesarios según los requerimientos del usuario.

SERVIDOR

Un servidor es todo proceso que proporciona un servicio a otros. Es el proceso encargado de

atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al
proceso servidor se lo conoce con el término back-end. El servidor normalmente maneja todas
las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos. Las
principales funciones que lleva a cabo el proceso servidor se enumeran a continuación:

 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 lógica de la aplicación y realizar validaciones a nivel de bases de datos.

Puede darse el caso que un servidor actúe 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 término "servidor" se suele utilizar también para designar el hardware, de gran potencia,
capacidad y prestaciones, utilizado para albergar servicios que atienden a un gran número 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.

MIDDLEWARE

El middleware es un módulo intermedio que actúa como conductor entre sistemas permitiendo a
cualquier usuario de sistemas de información comunicarse con varias fuentes de información que
se encuentran conectadas por una red. En el caso que nos concierne, es el intermediario entre el
cliente y el servidor y se ejecuta en ambas partes.

La utilización del middleware permite desarrollar aplicaciones en arquitectura Cliente/Servidor

independizando los servidores y clientes, facilitando la interrelación entre ellos y evitando
dependencias de tecnologías propietarias. El concepto de middleware no es un concepto nuevo.
Los primeros * monitores de teleproceso* de los grandes sistemas basados en tecnología

4
Cliente/Servidor ya se basaban en él, pero es con el nacimiento de la tecnología basada en
sistemas abiertos cuando el concepto de middleware toma su máxima importancia. El
middleware se estructura en tres niveles:

 Protocolo de transporte.
 Network Operating System (NOS).
 Protocolo específico del servicio.

Las principales características de un middleware son:

 Simplifica el proceso de desarrollo de aplicaciones al independizar los entornos

propietarios.
 Permite la interconectividad de los Sistemas de Información del Organismo.
 Proporciona mayor control del negocio al poder contar con información procedente de
distintas plataformas sobre el mismo soporte.
 Facilita el desarrollo de sistemas complejos con diferentes tecnologías y arquitecturas.

TIPOS DE ARQUITECTURA CLIENTE / SERVIDOR.

Uno de los aspectos claves para entender la tecnología Cliente/Servidor, y por tanto contar con la
capacidad de proponer y llevar a cabo soluciones de este tipo, es llegar a conocer la arquitectura
de este modelo y los conceptos o ideas asociados al mismo. Más allá de entender los
componentes cliente/middleware/servidor, es preciso analizar ciertas relaciones entre éstos, que
pueden definir el tipo de solución que se ajusta de mejor forma a las estadísticas y restricciones
acerca de los eventos y requerimientos de información que se obtuvieron en la etapa de análisis
de un determinado proyecto. De hecho el analista deberá conocer estos eventos o restricciones
del proyecto para que a partir de ahí, se puedan hacer las consideraciones y estimaciones de la
futura configuración, teniendo en cuenta aspectos como por ejemplo, la oportunidad de la
información, tiempo de respuesta, tamaños de registros, tamaño de bases de datos, estimaciones
del tráfico de red, distribución geográfica tanto de los procesos como de los datos, etc.

En tal sentido se presenta, en primer lugar, un esquema de clasificación basado en los conceptos
de Fat Client/Thin Client, Fat Server/Thin Server, es decir, basado en el tamaño de los
componentes. En segundo lugar tenemos una clasificación según la naturaleza del servicio que
nos ofrecen.

POR TAMAÑO DE COMPONENTES

Este tipo de clasificación se basa en los grados de libertad que brinda el modelo Cliente/Servidor
para balancear la carga de proceso entre los niveles de presentación, aplicación y base de datos.
Dependiendo de qué segmento de las capas de software tenga que soportar la mayor o menor
carga de procesamiento, se habla de Fat Client (Thin Server) o Fat server (Thin Client).
Consideraciones de este tipo son importantes en el momento de decidir una plataforma de
desarrollo, al mismo tiempo que pueden definir la viabilidad o no de las mismas para enfrentar

5
un cierto número de restricciones impuestas por una problemática a resolver.

FAT CLIENT (THIN SERVER)

En este esquema de arquitectura el peso de la aplicación es ejecutada en el cliente, es decir, el

nivel de presentación y el nivel de

aplicación corren en un único proceso cliente, y el servidor es relegado a realizar las funciones
que provee un administrador de base de datos.

En general este tipo de arquitectura tiene mejor aplicación en sistemas de apoyo de decisiones
(DSS: Decision Support System) y sistemas de información ejecutiva (EIS: Executive
Information System), y como se concluirá más adelante, tiene pocas posibilidades de aplicarse en
sistemas de misión crítica.

FAT SERVER (THIN CLIENT)

Este es el caso opuesto al anterior, el proceso cliente es restringido a la presentación de la

interfaz de usuario, mientras que el peso de la aplicación corre por el lado del servidor de
aplicación.

En general este tipo de arquitectura presenta una flexibilidad mayor para desarrollar una gran
variedad de aplicaciones, incluyendo los sistemas de misión crítica a través de servidores de
transacciones.

POR NATURALEZA DE SERVICIO

SERVIDORES DE FICHEROS

Con un servidor de archivos, un cliente lo que hace es requerimientos de los mismos sobre una
red. Esta es una forma muy primitiva de servicios de datos, la cual necesita intercambio de
muchos mensajes sobre una red para hallar el dato requerido. Los servidores de archivos usan
recursos compartidos sobre la red y son necesarios para crear repositorios de documentos,
imágenes y archivos grandes sobre la red.

SERVIDORES DE BASES DE DATOS

Este análisis está elaborado desde el punto de vista del modelo Cliente/Servidor, y está
directamente relacionado con la arquitectura en dos planos, que se describirá en el apartado
siguiente.

Obviamente la creación de aplicaciones Cliente/Servidor está asociada a la utilización de

servidores de bases de datos relacionales SQL, y dependiendo de los requerimientos y
restricciones se debe elegir entre una arquitectura dos o tres planos. Pero para una arquitectura
centrada en un servidor de bases de datos, cualquiera de las modalidades dos planos, permite que
6
un proceso cliente solicite datos y servicios directamente a un servidor de bases de datos. Según
las distintas normas de SQL (SQL-89, SQL-92, SQL3) el servidor debe proveer un acceso

compartido a los datos con los mecanismos de protección necesarios, así como proveer
mecanismos para seleccionar resultados dentro de un conjunto de datos, posibilitando un ahorro
en procesos de comunicación. El servidor debe también proveer mecanismos de concurrencia,
seguridad y consistencia de datos, basado principalmente en el concepto de transacción en el que
todo se realiza, y por lo tanto se hace permanente, o todo falla, anulándose la transacción en tal
caso.

Los servidores de bases de datos actuales son una mezcla de SQL estándar más otras extensiones
propias de

cada proveedor. Por ejemplo casi todas las bases de datos están provistas con:

 Procedimientos almacenados (stored procedures): Una de las posibilidades de

implementar de mejor forma un sistema Cliente/Servidor en dos planos (two-tier), sin
olvidar todas sus restricciones y limitaciones, es a través de procedimientos almacenados,
que son funciones que agrupan un conjunto de instrucciones y lógica de procedimientos
SQL, los cuales son compilados y almacenados en la misma base. El rol principal de los
procedimientos almacenados es proveer la parte servidora de la lógica de una aplicación
Cliente/Servidor, es decir vendría a reemplazar al servidor de aplicaciones en una
arquitectura tres planos (three-tier).
 Desencadenantes (triggers): Son mecanismos que permiten realizar acciones
automáticamente sobre los datos, las cuales están asociadas a algún evento definido.
Normalmente son implementados a través de procedimientos almacenados. Los eventos a
los cuales se hace referencia están asociados a las actualizaciones de tablas mediante
sentencias delete, insert o update, y son llamados implícitamente al suceder cualquiera de
estos eventos, a diferencia de los procedimientos almacenados que son llamados
explícitamente por un proceso cliente.
 Restricciones (constraints): Al igual que los desencadenantes, son acciones que se
realizan asociadas a algún evento determinado y están orientadas a llevar a cabo
validaciones más simples de datos. Los tipos de eventos son los mismos que para los
desencadenantes.

SERVIDORES DE TRANSACCIONES

Estos tipos de sistemas se pueden implementar con cualquiera de las modalidades

Cliente/Servidor en dos o tres planos, pero incorporan un elemento principal sobre el cual se
elabora y basa toda la fortaleza de este modelo, el concepto de transacción.

Con un servidor de transacciones el proceso cliente llama a funciones, procedimientos o métodos

que residen en el servidor, ya sea que se trate de un servidor de bases de datos o un servidor de
aplicaciones. Lo importante es que el intercambio a través de la red se realiza mediante un único
mensaje de solicitud/respuesta, es decir, independientemente de que se necesite ejecutar una o
más funciones, una o más instrucciones o sentencias SQL, éstas son agrupadas en una unidad

7
lógica llamada transacción; evitando así el intercambio a través de la

red de un mensaje solicitud/respuesta por cada sentencia SQL, el cual es el caso de los sistemas
Cliente/Servidor dos planos, implementados a través de SQL remoto. Estas aplicaciones
denominadas OLTP (On Line Transaction Proccesing) están orientadas a dar soporte a los
procedimientos y reglas de los sistemas de misión crítica.

En la actualidad muchas aplicaciones tienen la necesidad de ser desarrolladas con la ayuda de

transacciones, véase el ejemplo de los cajeros automáticos: imaginemos que queremos sacar
dinero. Introducimos la cantidad adecuada y pulsamos el botón de enviar. El cajero manda una
solicitud al banco para que descuente dicha cantidad de la cuenta del cliente, y recibe la
respuesta. Si diera la casualidad que la respuesta del banco se perdiera en medio de la red, el
cajero volvería a realizar la petición, por lo que el banco volvería a descontar dicha cantidad de
la cuenta bancaria asociada. Este problema tan común se soluciona con la ayuda de las
transacciones.

MODELOS CLIENTE/SERVIDOR

Una de las clasificaciones mejor conocidas de las arquitecturas Cliente/Servidor se basa en la

idea de planos (tier), la cual es una variación sobre la división o clasificación por tamaño de
componentes. Esto se debe a que se trata de definir el modo en que las prestaciones funcionales
de la aplicación serán asignadas, y en qué proporción, tanto al cliente como al servidor. Dichas
prestaciones se deben agrupar entre los tres componentes clásicos para Cliente/Servidor: interfaz
de usuario, lógica de negocios y los datos compartidos, cada uno de los cuales corresponde a un
plano. Ni que decir tiene que la mala elección de uno u otro modelo puede llegar a tener
consecuencias fatales.

Dentro de esta categoría tenemos las aplicaciones en dos planos (two-tier), tres planos (three-tier)
y multi-planos (multi-tier). Dado que este término ha sido sobrecargado de significados por
cuanto se lo utiliza indistintamente para referirse tanto a aspectos lógicos (Software) como
físicos (Hardware), aquí se esquematizan ambas acepciones.

A NIVEL DE SOFTWARE

Este enfoque o clasificación es el más generalizado y el que más se ajusta a los enfoques
modernos, dado que se fundamenta en los componentes lógicos de la estructura Cliente/Servidor
y en la madurez y popularidad de la computación distribuida. Por ejemplo, esto permite hablar de
servidores de aplicación distribuidos a lo largo de una red, y no tiene mucho sentido identificar a
un equipo de hardware como servidor, si no más bien entenderlo como una plataforma física
sobre la cual pueden operar uno o más servidores de aplicaciones.

MODELO CLIENTE/SERVIDOR 2 CAPAS

Esta estructura se caracteriza por la conexión directa entre el proceso cliente y un administrador
de bases de datos. Dependiendo de donde se localice el grupo de tareas correspondientes a la
lógica de negocios se pueden tener a su vez dos tipos distintos dentro de esta misma categoría:

8
IMPLEMENTADO CON SQL REMOTO

En este esquema el cliente envía mensajes con solicitudes SQL al servidor de bases de datos y el
resultado de cada instrucción SQL es devuelto por la red, no importando si son uno, diez, cien o
mil registros. Es el mismo cliente quien debe procesar todos los registros que le fueron devueltos
por el servidor de base de datos, según el requerimiento que él mismo hizo. Esto hace que este
tipo de estructura se adecue a los requerimientos de aplicaciones orientadas a los sistemas de
apoyo y gestión, pero resultan inadecuados para los sistemas críticos en que se requieran bajos
tiempos de respuesta.

Ventajas:

 Presenta una estructura de desarrollo bastante simple ya que el programador maneja un

único ambiente de desarrollo (es más simple respecto al Cliente/Servidor en tres planos,
puesto que reduce una capa de programación, como se verá más adelante).

Inconvenientes:

 La gran cantidad de información que viaja al cliente congestiona demasiado el tráfico de

red, lo que se traduce en bajo rendimiento.
 Por su bajo rendimiento esta estructura tiene un bajo espectro de aplicación, limitándose a
la construcción de sistemas no críticos.

MODELO CLIENTE/SERVIDOR 3 CAPAS

Esta estructura se caracteriza por elaborar la aplicación en base a dos capas principales de
software, más la capa correspondiente al servidor de base de datos. Al igual que en la
arquitectura dos capas, y según las decisiones de diseño que se tomen, se puede balancear la
carga de trabajo entre el proceso cliente y el nuevo proceso correspondiente al servidor de
aplicación.

En este esquema el cliente envía mensajes directamente al servidor de aplicación el cual debe
administrar y responder todas las solicitudes. Es el servidor, dependiendo del tipo de solicitud,
quien accede y se conecta con la base de datos.

Ventajas:

 Reduce el tráfico de información en la red por lo que mejora el rendimiento de los

sistemas (especialmente respecto a la estructura en dos planos).
 Brinda una mayor flexibilidad de desarrollo y de elección de plataformas sobre la cual
montar las aplicaciones. Provee escalabilidad horizontal y vertical.
 Se mantiene la independencia entre el código de la aplicación (reglas y conocimiento del
negocio) y los datos, mejorando la portabilidad de las aplicaciones.
 Los lenguajes sobre los cuales se desarrollan las aplicaciones son estándares lo que hace
más exportables las aplicaciones entre plataformas.

9
  Dado que mejora el rendimiento al optimizar el flujo de información entre componentes,
permite construir sistemas críticos de alta fiabilidad.
 El mismo hecho de localizar las reglas del negocio en su propio ambiente, en vez de
distribuirlos en la capa de interfaz de usuario, permite reducir el impacto de hacer
mantenimiento, cambios urgentes de última hora o mejoras al sistema.
 Disminuye el número de usuarios (licencias) conectados a la base de datos.

Inconvenientes:

 Dependiendo de la elección de los lenguajes de desarrollo, puede presentar mayor

complejidad en comparación con Cliente/Servidor dos planos.
 Existen pocos proveedores de herramientas integradas de desarrollo con relación al
modelo Cliente/Servidor dos planos, y normalmente son de alto costo.

A NIVEL DE HARDWARE

Esta clasificación del modelo Cliente/Servidor se basa igualmente en la distribución de los

procesos y elementos entre sus componentes, pero centrándose en la parte física del mismo, en el
que la administración de la interfaz gráfica se asocia a los clientes PC y la seguridad e integridad
de los datos quedan asociados a ambientes mainframe o por lo menos a servidores locales y/o
centrales.

MODELO CLIENTE / SERVIDOR 2 CAPAS

Los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual, dependiendo de
la aplicación puede dar acceso a los datos administrados por él.

MODELO CLIENTE / SERVIDOR 3 CAPAS

Los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual a su vez se
comunica con un servidor central de bases de datos. El servidor local tiene un comportamiento
dual, dado que actúa como cliente o servidor en función de la dirección de la comunicación.

10
¿Qué es JSTL y EL? (JSP Standard Tag Library)

Java Standard Tag Library (JSTL) es un conjunto de tags JSP que resuelven las situaciones más
comunes de presentación. JSTL provee tags para setear, obtener y mostrar variables del entorno,
iterar colecciones, crear condiciones lógicas y formatear fechas y números, entre otras cosas.

JSTL comienza a ser sumamente útil cuando se combina con un nuevo lenguaje de expresiones
para JSP: Expression Language (EL). EL es una nueva sintáxis para referenciar objetos, atributos
y crear expresiones lógicas. EL y JSTL en conjunto forman una solución muy simple y poderosa
para resolver la presentación en los JSP.

JSTL no es más que un conjunto de librerías de etiquetas simples y estándares que encapsulan la
funcionalidad principal que es usada comúnmente para escribir páginas JSP. Las etiquetas JSTL
están organizadas en 4 librerías:

 core: Comprende las funciones script básicas como loops, condicionales, y entrada/salida.

xml: Comprende el procesamiento de xml

 fmt: Comprende la internacionalización y formato de valores como de moneda y fechas.

 sql: Comprende el acceso a base de datos.

Conclusión

Al finalizar este trabajo llegamos a la conclusión de que el modelo cliente servidor es

modelo flexible adaptable al servicio que se quiera implementar lo que nos permite aumentar el
rendimiento, Cliente/Servidor puede envolver variadas plataformas, bases de datos, redes y
sistemas operativos que pueden ser de diferentes distribuidores, en arquitecturas propietarias y
no propietarias y funcionando todos al mismo tiempo.

Es un sistema ventajoso en cuanto a seguridad, ya que el servidor controla el acceso a sus

datos, se necesita que el servidor nos autorice a acceder a él. Es escalable y ante una gran
demanda el uso de balanceadores de carga en sistemas redundantes soluciona la congestión.

11
BIBLIOGRAFÍA

•John Wiley: Introduction to Client / Server Systems: A Practical Guide for Systems
Professionals

http://www.monografias.com/trabajos24/arquitectura-cliente-servidor/arquitectura-cliente-
servidor.shtml

www.alegsa.com.ar/.../**ventajas**_y_**desventajas**_del_**modelo**_**clienteservidor**.
htm

www.scribd.com/doc/272974/**Cliente**-**servidor**

12