Cliente Modelo de

Servidor capas
 Inicio
Inicio

Cliente Descripción del

Servidor concepto
Modelo cliente
servidor
introducción
Representación
antecedentes

evolución ventajas

características desventajas
 Inicio
Inicio

Ventajas y
ARQUITECTURA Desventajas
POR CAPAS
Descripción del
concepto
introducción Arquitectura dos
capas
Top -Down Arquitectura tres
Button - Up capas
Arquitectura
Bidireccional cuatro capas
 Introducción
Es una arquitectura que en este momento es una
de las más importantes y utilizadas en el ámbito
de enviar y recibir información, también es una
herramienta potente para almacenar datos en
una base de datos como servidor
 ANTECEDENTES

Cliente / Servidor nació por la necesidad que tienen las

organizaciones, de realizar sus operaciones mas
eficientemente lo cual se reduce a que el su personal sea
mas productivo y reduzcan los costos y gastos de operación
y mantenimiento

Al mismo que se generan productos y servicios mas

rápidamente y con mejor calidad
 EVOLUCION

1960: Se tenia mainframes y terminales de caracteres

orientada a comandos.
1970: Aplicaciones interactivas y transaccionales.
1980: Aparición de las pc’s y redes de área local.
1990: Combinación del poder de las mainframes y pc’s:
cliente/servidor tradicional.
2000: Objetos distribuidos y web servicies.
 Características
Servicio: Cliente/Servidor es una relación entre procesos
que se ejecutan en maquinas independientes.
– Proceso Servidor: Proveedor de servicios
– Proceso Cliente: Consumidor de servicios

Recursos Compartidos: Un servidor puede servir a varios

clientes al mismo tiempo y regular su acceso a los recursos.
Escalabilidad: Cliente/Servidor pueden escalarse en forma
vertical y horizontal

– Escalamiento Horizontal: Que al quitar o agregar

estaciones de trabajo clientes solo se produce un
pequeño efecto de desempeño.

– Escalamiento Vertical: Significa Migrar (Mudar) a una

máquina servidor más grande y rápida, o distribuir la
carga de procesamiento entre varios servidores
Encapsulado de Servicios: A través de un mensaje se
le indica al servidor que servicio es solicitado, y
depende de él la forma en que satisface tal solicitud.
Los servidores pueden actualizarse sin afectar a los
clientes.

Integridad: Código y la información se administra de

manera central, lo que da como resultado un
mantenimiento más barato y resguardo de
información compartida, al mismo tiempo los clientes
permanecen independientes
 Descripción del concepto
QUE ES UN CLIENTE
Es el que inicia un requerimiento de servicio.
El requerimiento inicial puede convertirse en múltiples
requerimientos de trabajo a través de redes LAN o WAN. La
ubicación de los datos o de las aplicaciones es totalmente
transparente para el cliente.

QUE ES UN SERVIDOR
Es cualquier recurso de cómputo dedicado a responder a los
requerimientos del cliente. Los servidores pueden estar
conectados a los clientes a través de redes LAN o WAN, para
proveer de múltiples servicios a los clientes y ciudadanos tales
como impresión, acceso a bases de datos, fax, procesamiento
de imágenes, etc.
 El Modelo Cliente-Servidor
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 en forma transparente aún en entornos
multiplataforma. En el modelo cliente servidor, el cliente envía
un mensaje solicitando un determinado servicio a un servidor
(hace una petición), y este envía uno o varios mensajes con la
respuesta.

En un sistema distribuido cada máquina puede cumplir el rol

de servidor para algunas tareas y el rol de cliente para otras.
 Servidor

Cliente
Cliente

Cliente
 VENTAJAS

Aumento del poder de las PCS disminuyendo el

costo.
Permite que el procesamiento resida cerca de la
fuente de datos reduciendo el tráfico de la red.
Facilita el uso de las GUI.
Favorece el diseño modular.
 DESVENTAJAS
Desbalance en el procesamiento de tareas entre cliente y
servidor.
El desarrollo de aplicaciones es más complejo.
Falta de control centralizado.
Cuello de botella debido al sinnúmero de conexiones a la
base de datos.
Lógica del negocio codifica en lenguaje propietario.
Mayor esfuerzo en el proceso de administración de
cambios.
 Arquitectura de Capas
Nos limitaremos a manejar la noción de
arquitectura como una forma de estructurar
los elementos de un software.

En toda arquitectura de capa los elementos

agrupados en una misma capa pueden
comunicarse entre si; pero existen variantes
en cuanto a las comunicaciones permitidas
entre elementos de capas diferentes:
Arquitectura top-down de capas:

Los elementos de una capa i+1 pueden enviar solicitudes

de servicio a elementos de la capa inferior i.
Típicamente se produce una cascada de solicitudes, es
decir para satisfacer una solicitud a una capa i+2, ésta
requiere enviar varias solicitudes a la capa i+1; cada una
de estas solicitudes a la capa i+1 genera a su vez un
conjunto de solicitudes a la capa i y así sucesivamente.
Una arquitectura top-down es laxa (o no estricta) si los
elementos de una capa i+1 pueden enviar solicitudes de
servicio directamente a un elemento de cualquiera de las
i capas inferiores.
Arquitectura bottom-up de capas:

Cada elemento de una capa i puede notificar a

elementos de la  capa superior i+1 de que ha ocurrido
algún evento de interés (ej. manejadores de
dispositivos). La capa i+1 puede juntar varios eventos
antes de notificar a su vez a un elemento de la capa i+2.
Una arquitectura bottom-up también puede ser no
estricta si el elemento de la capa i puede notificar a
cualquier elemento de cualquier capa superior a la capa
i.
Arquitectura bidireccional de capas

En su forma más común involucra dos pilas de N

capas  que se comunican entre si. El ejemplo más
conocido es el de los protocolos en Redes de
Computadores.
 VENTAJAS

Reutilización de capas;
Facilita la estandarización
Dependencias se limitan a intra-capa
Contención de cambios a una o pocas capas
 DESVENTAJAS

A veces no se logra la contención del cambio y

se requiere una cascada de cambios en varias
capas;
Pérdida de eficiencia;
Trabajo innecesario por parte de capas más
internas o redundante entre varias capas;
Dificultad de diseñar correctamente la
granularidad de las capas.
DESCRIPCION DEL CONCEPTO
Existen tres propuestas de arquitecturas de
capas para Sistemas de Información, donde
las capas a veces reciben el nombre de
niveles (en Inglés tiers):
• Arquitectura de dos capas;
• Arquitectura de tres capas;
• Arquitectura de cuatro capas.
 Arquitectura dos
capas
En la actualidad muchos sistemas de información están basados en
arquitecturas de dos capas, denominadas:

• Nivel de aplicación;
• Nivel de la base de datos.

Existen herramientas de amplio uso que presuponen esta estructura

(p. ej. Visual Basic + Access/SQL server). Estas arquitecturas
fueron las primeras en aprovecharse de la estructura cliente-
servidor (aplicación en los clientes, base de datos como servidor).
 Desventajas
El nivel de las aplicaciones se recargan, entremezclando
aspectos típicos del manejo de la interfaz con las reglas del
negocio;
Las reglas del negocio quedan dispersas entre el nivel de
aplicación y los "stored procedures" de la base de datos;
La aplicación queda sobrecargada de información de bajo
nivel si hay que extraer los datos de varias bases de datos,
posiblemente con estructuras diferentes.
El nivel de aplicación puede ser demasiado pesado para el
cliente.
 Arquitectura tres capas

Por estas razones, existe una fuerte y bien avanzada tendencia a

adoptar una arquitectura de tres capas:
• Aplicación
• Dominio de la aplicación;
• Repositorio.

La mayoría de estos sistemas buscan conservar la tecnología de

BD relacional para la capa del repositorio e introducir la
tecnología OO para el dominio de la aplicación. Para la capa de
presentación existe una pelea entre tecnología HTML (Java-
enabled) vs. generadores GUI.
 ¿Qué contiene el dominio de la aplicación? En
terminología más clásica de BD los tres niveles
pueden equipararse, a grosso modo, con:
• Esquema externo;
• Esquema conceptual;
• Esquema interno o de almacenamiento.
La ventaja es que ahora la aplicación puede
describirse  únicamente en relación a la
semántica de la aplicación, sin tener que
preocuparse sobre cómo está implementado ese
dominio (ubicación y estructura física de la
data).
 Cuatro capas
Los desarrollos más recientes empiezan a experimentar con una capa
adicional
• Presentación;
• Aplicación;
• Dominio de la aplicación;
• Repositorio

La idea básica es separar todo lo que es programación GUI de la aplicación

per se (y por ende tiende a usar Frameworks para GUI como MFC).
El nivel de la presentación no hace cálculos, consultas o actualizaciones sobre
el dominio --de hecho ni siquiera tiene visibilidad sobre la capa del dominio.
La capa de la aplicación es la encargada de acezar la capa del dominio,
simplificar la información del dominio convirtiéndolo a los tipos de datos que
entiende la interfaz: enteros, reales, cadenas de caracteres, fecha y clases
contenedoras (container, collection).