ClienteServidor

31
Modelo Cliente / Servidor M. en C. Juan Manuel Rosas Salazar

description

Cliente Servidor en Base de Datos. Tema visto en la carrera de Informática de la Universidad del Mar, campus Puerto Escondido.

Transcript of ClienteServidor

Page 1: ClienteServidor

Modelo Cliente / Servidor

M. en C. Juan Manuel Rosas Salazar

Page 2: ClienteServidor

Qué es la arquitectura de una aplicación

• La arquitectura se refiere a la forma en la que esdiseñada tanto física como lógicamente unaaplicación.

• Diseño físico: Se refiere al lugar donde estaránlas piezas de la aplicación.

• Diseño lógico: Aquí se especifica la estructura dela aplicación y sus componentes sin tener encuenta donde se localizara el Software ni elHardware ni la infraestructura.

Page 3: ClienteServidor

¿Qué es Cliente-Servidor?

• Esta definición se usa para describir unaaplicación en la cual dos o mas procesosseparados trabajan juntos para completar unatarea. El proceso Cliente solicita al procesoServidor la ejecución de una acción enparticular esta operación se conoce comoproceso cooperativo.

• Los procesos pueden o no estar en una solamáquina.

Page 4: ClienteServidor

Tipos de Arquitectura

• Arquitectura Centralizada

• Arquitectura de Servidor de archivos

• Arquitectura Cliente - Servidor

Page 5: ClienteServidor

Arquitectura Centralizada

• Se basa en la existencia de una maquinaservidora que almacena los datos y lasaplicaciones que lo procesan.

• Los clientes se comportan como terminales ysolo sirven para introducir datos desde teclado.

Ventajas Desventajas

Gran nivel de seguridadFácil administración

Alto Costo Maquina Servidora muy cargada

Page 6: ClienteServidor

Arquitectura Centralizada

Page 7: ClienteServidor

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 CostoEscalable

Clientes PotentesFuerte dependencia de las Comunicaciones

Page 8: ClienteServidor

Arquitectura de Servidor de Archivos

Page 9: ClienteServidor

Arquitectura Cliente - Servidor

• Se basa en la existencia de dos tipos deaplicaciones ejecutándose de formaindependiente.

• Una de las aplicaciones actúa como servidora yla otra como cliente.

Ventajas Desventajas

Fácil de EscalarReparto de Carga

Nuevas AplicacionesImportancia de las Comunicaciones

Page 10: ClienteServidor

Arquitectura Cliente - Servidor

Page 11: ClienteServidor

Arquitectura Cliente - Servidor

Page 12: ClienteServidor

Comparativa S. Archivos vs C/S

S. A. C / S•El cliente pide los datos •Se envía una copia de los datos de la base de datos. •Se ejecuta la consulta

•El cliente pide los datos.•Se envía en forma de consulta al servidor.•El servidor procesa la consulta y devuelve los datos al cliente.•Solo viajan los datos pedidos.

Page 13: ClienteServidor

Conceptos básicos

• Definición▫ Un sistema cliente/servidor es aquel en el que dos

o mas procesos funcionan de forma independientepero de forma cooperativa.

▫ En un sistema cliente/servidor una aplicación pidedatos a otra, una vez realizada la petición elaborauna respuesta y la devuelve a la aplicacióndemandante.

Page 14: ClienteServidor

Conceptos básicos• Componentes:▫ Servicios de usuario▫ Servicios de negocio▫ Servicios de datos

• Se basa en la existencia de componentes de softwaredistribuidos de forma lógica del programa puede serlocalizada en servidores centralizados.

• Para que sea implantable hace falta la existencia deuna estructura de objetos que representen losdistintos componentes de una aplicación.

Page 15: ClienteServidor

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

Page 16: ClienteServidor

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.

Page 17: ClienteServidor

Modelo C/S de 2 capas

Page 18: ClienteServidor

Arquitectura de 3 capas

• Es el sucesor de la arquitectura de dos capas,ésta implementa una ó n capas adicionales lascuales se encargan de encapsular las reglas delnegocio asociadas con el sistema y las separa dela presentación y del código de la D.B.

Page 19: ClienteServidor

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 nivelesde la aplicación, son una colección de componentesque se proporcionan servicios entre sí o a otrosniveles adyacentes. La única comunicación que noestá permitida es la de Frond-End con Back-End.

• Contrario al modelo de 2 capas donde cada capa solose comunica con su capa superior o inferior siendoestas las capas de Front-End y Back-End.

Page 20: ClienteServidor

Modelo de 3 capas

Page 21: ClienteServidor

Niveles del modelo• Nivel de Usuario

Los componentes del nivel de usuario, proporcionanla interfaz visual que los clientes utilizarán para verla información y los datos.En este nivel, los componentes son responsables desolicitar y recibir servicios de otros componentes delmismo nivel o del nivel de servicios de negocio.Es muy importante destacar que, a pesar de que lasfunciones del negocio residen en otro nivel, para elusuario es transparente la forma de operar.

Page 22: ClienteServidor

Niveles del modelo• Nivel de Negocios

Como los servicios de usuario no pueden contactardirectamente con el nivel de servicios de datos, esresponsabilidad de los servicios de negocio hacer de puenteentre estos.Los objetos de negocio proporcionan servicios que completanlas tareas de negocio tales como verificar los datos enviadospor el cliente. Antes de llevar a cabo una transacción en laD.B.Los componentes de los servicios de negocio también nossirven para evitar que el usuario tenga acceso directo a la basede datos, lo cual proporciona mayor seguridad en laintegridad de ésta.

Page 23: ClienteServidor

Niveles del modelo• Nivel de Datos

El nivel de datos se encarga de las típicas tareas querealizamos con los datos: Inserción, modificación, consultay borrado. La clave del nivel de datos es que los papeles denegocio no son implementados aquí. Aunque uncomponente de servicio de datos es responsable de lagestión de las peticiones realizadas por un objeto denegocio.

Un nivel de servicios de datos apropiadamenteimplementado, debería permitir cambiar su localizaciónsin afectar a los servicios proporcionados por loscomponentes de negocio.

Page 24: ClienteServidor

Los servicios se forman de componentes

• El modelo de 3 capas está destinado a ayudarnos aconstruir componentes físicos a partir de los niveleslógicos.

• Así que podemos empezar tomando decisiones sobrequé parte lógica de la aplicación vamos a encapsular encada uno de nuestros componentes de igual modo queencapsulamos los componentes en varios niveles.

• Un nivel está conformado por varios componentes, portanto puede suplir varios servicios.

Page 25: ClienteServidor

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.

Page 26: ClienteServidor

Ejemplo 3 Capas “Proyecto Oness”• La estrategia tradicional de utilizar aplicaciones compactas

causa gran cantidad de problemas de integración en sistemassoftware complejos como pueden ser los sistemas de gestiónde una empresa o los sistemas de información integradosconsistentes en más de una aplicación. Estas aplicacionessuelen encontrarse con importantes problemas deescalabilidad, disponibilidad, seguridad, integración...

• Para solventar estos problemas se ha generalizado la divisiónde las aplicaciones en capas que normalmente serán tres: unacapa que servirá para guardar los datos (base de datos), unacapa para centralizar la lógica de negocio (modelo) y porúltimo una interfaz gráfica que facilite al usuario el uso delsistema.

Page 27: ClienteServidor

Fase 1

Page 28: ClienteServidor

• Si establecemos una separación entre la capa de interfaz gráfica(cliente), replicada en cada uno de los entornos de usuario, y la capamodelo, que quedaría centralizada en un servidor de aplicaciones,según el diagrama en la figura Fase 1, obtienen una potentearquitectura 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 elconjunto de los usuarios, reduciendo los costes de mantenimiento.

▫ Mayor sencillez de los clientes.

• Si se intenta aplicar esto a las aplicaciones web, debido a laobligatoria 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 nospermite una mayor extensibilidad en caso de que existan tambiénclientes no web en el sistema, que trabajarían directamente contra elservidor del modelo.

Page 29: ClienteServidor

Fase 2

Page 30: ClienteServidor

• Mantener el número de capas en 3, como se ve en laFase 2, integrando interfaz web y modelo en unmismo servidor aunque conservando suindependencia funcional. Ésta es la distribución encapas más común en las aplicaciones web.

Page 31: ClienteServidor

Proyecto ONess

• http://oness.sourceforge.net/proyecto/html/index.html