Modelo Cliente / Servidor

M. en C. Juan Manuel Rosas Salazar

Qué es la arquitectura de una aplicación

• La arquitectura se refiere a la forma en la que es

diseñada tanto física como lógicamente una
aplicación.
• Diseño físico: Se refiere al lugar donde estarán
las piezas de la aplicación.
• Diseño lógico: Aquí se especifica la estructura de
la aplicación y sus componentes sin tener en
cuenta donde se localizara el Software ni el
Hardware ni la infraestructura.
¿Qué es Cliente-Servidor?
• Esta definición se usa para describir una
aplicación en la cual dos o mas procesos
separados trabajan juntos para completar una
tarea. El proceso Cliente solicita al proceso
Servidor la ejecución de una acción en
particular esta operación se conoce como
proceso cooperativo.
• Los procesos pueden o no estar en una sola
máquina.
Tipos de Arquitectura
• Arquitectura Centralizada

• Arquitectura de Servidor de archivos

• Arquitectura Cliente - Servidor

Arquitectura Centralizada
• Se basa en la existencia de una maquina
servidora que almacena los datos y las
aplicaciones que lo procesan.
• Los clientes se comportan como terminales y
solo sirven para introducir datos desde teclado.

Ventajas Desventajas
Gran nivel de seguridad Alto Costo
Fácil administración Maquina Servidora muy
cargada
Arquitectura Centralizada
Arquitectura Servidor de Archivos
• Se basa en la existencia de una o varias
maquinas servidoras que almacenan datos y
estaciones de trabajo que ejecutan aplicaciones
que los procesan.
• Los clientes en este tipo de arquitectura son
activos.

Ventajas Desventajas
Bajo Costo Clientes Potentes
Escalable Fuerte dependencia de las
Comunicaciones
Arquitectura de Servidor de Archivos
Arquitectura Cliente - Servidor
• Se basa en la existencia de dos tipos de
aplicaciones ejecutándose de forma
independiente.
• Una de las aplicaciones actúa como servidora y
la otra como cliente.

Ventajas Desventajas
Fácil de Escalar Nuevas Aplicaciones
Reparto de Carga Importancia de las Comunicaciones
Arquitectura Cliente - Servidor
Arquitectura Cliente - Servidor
Comparativa S. Archivos vs C/S
S. A. C/S
•El cliente pide los datos •El cliente pide los datos.
•Se envía una copia de •Se envía en forma de
los datos de la base de consulta al servidor.
datos. •El servidor procesa la
•Se ejecuta la consulta consulta y devuelve los
datos al cliente.
•Solo viajan los datos
pedidos.
Conceptos básicos
• Definición
▫ Un sistema cliente/servidor es aquel en el que dos
o mas procesos funcionan de forma independiente
pero de forma cooperativa.
▫ En un sistema cliente/servidor una aplicación pide
datos a otra, una vez realizada la petición elabora
una respuesta y la devuelve a la aplicación
demandante.
Conceptos básicos
• Componentes:
▫ Servicios de usuario
▫ Servicios de negocio
▫ Servicios de datos

• Se basa en la existencia de componentes de software

distribuidos de forma lógica del programa puede ser
localizada en servidores centralizados.
• Para que sea implantable hace falta la existencia de
una estructura de objetos que representen los
distintos componentes de una aplicación.
Modelo C/S de 2 capas
• El sistema se separa en dos partes fijas: el cliente y
el servidor.
• La lógica de las aplicaciones debe estar en el cliente
o en el servidor.
• La comunicación con el servidor es transparente
para el usuario.

• Limitaciones
▫ No es escalable
▫ No es manejable
▫ Bajo rendimiento
Modelo C/S de 2 capas
• Es una arquitectura constituida por 2 capas: Front-End
y Back-End.
▫ Front-End: consiste en la capa donde el usuario
interactúa con su PC.
▫ Back-End: es el servidor de bases de datos como
Oracle o SQL-Server.

Dificultades de la arquitectura de 2 capas

▫ Dificultad al realizar cambios en el Front-End
▫ Dificultad al compartir procesos comunes.
▫ Problemas de seguridad, etc.
Modelo C/S de 2 capas
Arquitectura de 3 capas
• Es el sucesor de la arquitectura de dos capas,
ésta implementa una ó n capas adicionales las
cuales se encargan de encapsular las reglas del
negocio asociadas con el sistema y las separa de
la presentación y del código de la D.B.
Comunicación entre las capas
• El modelo de 3 capas es una forma lógica de
agrupar los componentes que creamos.

• Está basado en el concepto de que todos los niveles

de la aplicación, son una colección de componentes
que se proporcionan servicios entre sí o a otros
niveles adyacentes. La única comunicación que no
está permitida es la de Frond-End con Back-End.

• Contrario al modelo de 2 capas donde cada capa solo

se comunica con su capa superior o inferior siendo
estas las capas de Front-End y Back-End.
Modelo de 3 capas
Niveles del modelo
• Nivel de Usuario
Los componentes del nivel de usuario, proporcionan
la interfaz visual que los clientes utilizarán para ver
la información y los datos.
En este nivel, los componentes son responsables de
solicitar y recibir servicios de otros componentes del
mismo nivel o del nivel de servicios de negocio.
Es muy importante destacar que, a pesar de que las
funciones del negocio residen en otro nivel, para el
usuario es transparente la forma de operar.
Niveles del modelo
• Nivel de Negocios
Como los servicios de usuario no pueden contactar
directamente con el nivel de servicios de datos, es
responsabilidad de los servicios de negocio hacer de puente
entre estos.
Los objetos de negocio proporcionan servicios que completan
las tareas de negocio tales como verificar los datos enviados
por el cliente. Antes de llevar a cabo una transacción en la
D.B.
Los componentes de los servicios de negocio también nos
sirven para evitar que el usuario tenga acceso directo a la base
de datos, lo cual proporciona mayor seguridad en la
integridad de ésta.
Niveles del modelo
• Nivel de Datos
El nivel de datos se encarga de las típicas tareas que
realizamos con los datos: Inserción, modificación, consulta
y borrado. La clave del nivel de datos es que los papeles de
negocio no son implementados aquí. Aunque un
componente de servicio de datos es responsable de la
gestión de las peticiones realizadas por un objeto de
negocio.

Un nivel de servicios de datos apropiadamente

implementado, debería permitir cambiar su localización
sin afectar a los servicios proporcionados por los
componentes de negocio.
Los servicios se forman de componentes
• El modelo de 3 capas está destinado a ayudarnos a
construir componentes físicos a partir de los niveles
lógicos.

• Así que podemos empezar tomando decisiones sobre

qué parte lógica de la aplicación vamos a encapsular en
cada uno de nuestros componentes de igual modo que
encapsulamos los componentes en varios niveles.

• Un nivel está conformado por varios componentes, por

tanto puede suplir varios servicios.
Ventajas
• Los componentes de la aplicación pueden ser
desarrollados en cualquier lenguaje.
• Los componentes son independientes.
• Los componentes pueden estar distribuidos en múltiples
servidores.
• La D.B. es solo vista desde la capa intermedia y no desde
todos los clientes.
• Los drivers del D.B. No tienen que estar en los clientes.
• Mejora la administración de los recursos cuando existe
mucha concurrencia.
• Permite reutilización real del software y construir
aplicaciones escalables.
Ejemplo 3 Capas “Proyecto Oness”
• La estrategia tradicional de utilizar aplicaciones compactas
causa gran cantidad de problemas de integración en sistemas
software complejos como pueden ser los sistemas de gestión
de una empresa o los sistemas de información integrados
consistentes en más de una aplicación. Estas aplicaciones
suelen encontrarse con importantes problemas de
escalabilidad, disponibilidad, seguridad, integración...

• Para solventar estos problemas se ha generalizado la división

de las aplicaciones en capas que normalmente serán tres: una
capa que servirá para guardar los datos (base de datos), una
capa para centralizar la lógica de negocio (modelo) y por
último una interfaz gráfica que facilite al usuario el uso del
sistema.
Fase 1
• Si establecemos una separación entre la capa de interfaz gráfica
(cliente), replicada en cada uno de los entornos de usuario, y la capa
modelo, que quedaría centralizada en un servidor de aplicaciones,
según el diagrama en la figura Fase 1, obtienen una potente
arquitectura que nos otorga algunas ventajas:
▫ Centralización de los aspectos de seguridad y transaccionalidad, que
serían responsabilidad del modelo.
▫ No replicación de lógica de negocio en los clientes: esto permite que las
modificaciones y mejoras sean automáticamente aprovechadas por el
conjunto de los usuarios, reduciendo los costes de mantenimiento.
▫ Mayor sencillez de los clientes.

• Si se intenta aplicar esto a las aplicaciones web, debido a la

obligatoria sencillez del software cliente que será un navegador web,
se encuentran con una doble posibilidad:

▫ Crear un modelo de 4 capas, tal y como puede aprecia en la Fase 2,

separando cliente, servidor web, modelo y almacén de datos. Esto nos
permite una mayor extensibilidad en caso de que existan también
clientes no web en el sistema, que trabajarían directamente contra el
servidor del modelo.
Fase 2
• Mantener el número de capas en 3, como se ve en la
Fase 2, integrando interfaz web y modelo en un
mismo servidor aunque conservando su
independencia funcional. Ésta es la distribución en
capas más común en las aplicaciones web.
Proyecto ONess
• http://oness.sourceforge.net/proyecto/html/ind
ex.html