Cliente Servidor

Modelo de capas

Cliente Servidor

introducción

antecedentes

evolución

características

Descripción del concepto

Modelo cliente servidor

Representación

ventajas

desventajas

Inicio

ARQUITECTURA POR CAPAS

introducción

Top -Down

Button - Up

Bidireccional

Ventajas y Desventajas

Descripción del concepto

Arquitectura dos capas

Arquitectura tres capas

Arquitectura cuatro capas

Inicio

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

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.

EVOLUCION

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 SERVIDOREs 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

ClienteCliente

Cliente

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.

VENTAJAS

DESVENTAJASDesbalance 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.

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).

Arquitectura dos capas

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 capasLos 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).