Modelos y arquitecturas Dr. David R. Sol Mart ínez, UDLAP, México [email protected]Dra. Genoveva Vargas Solar, CNRS-LSR, Francia [email protected]ht t ps:/ / www.udlap.mx/ ~genoveva/ is417 Gracias al Prof. L. García Bañuelos Universidad Aut ónoma de Tlaxcala
47
Embed
Modelosy arquitecturas · modelo cliente-servidor — Una aplicación cliente-servidor usa una arquitectura 2-tiers — La arquitectura promueve una jerarquía donde los componentes
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Gracias al Prof. L. García BañuelosUniversidad Autónoma de Tlaxcala
2
Arquitectura de sistemas� Define la est ructura y la organización del
sistema� Componentes del sistema� Funciones de cada componente� Interrelaciones e interacciones ent re los
componentes
3
Agenda� Modelo cliente –servidor
� Principio general� Consideraciones de diseño� Opciones de implementación� Variantes
� Modelo n-t ier� Modelo peer to peer� Modelo basado en intercambio de mensaj es
4
Modelo Cliente/ Servidor� Dos ent idades de ej ecución
� 6HUYLGRU� ofrece un servicio� &OLHQWH� ut iliza tal servicio
� Ambas ent idades son en general, pero no necesariamente, en dos sit ios dist intos
� La def inición de la interfaz de servicio ofrecido por el servidor, da independencia en la implementación
5
Modelo Cliente/ Servidor� Abst rae la relación ent re un cliente (consumidor) y un
proveedor de servicios� Las interacciones se dan baj o la forma de intercambio
de dos t ipos de mensaj es� Pet ición (UHTXHVW): especif icación del servicio requerido,
nombre de un procedimiento y sus parámet ros, código a ej ecutar, etc.
� Respuesta (UHSO\): resultado o indicador de algún eventual error
Modelo de ej ecución síncrona
6
Ej ecución (una vista abst racta)
Cliente Servidor
pet ición
respuesta (MHFXFLyQ
7
Puntos de interés� Est ructuración
� Funciones bien definidas� Separación de la interfaz de servicio/ realización� Cliente y servidor puede ser modif icados (reemplazados)
independientemente
� Protección� Cliente y servidor se ej ecutan dent ro de dominios de protección
diferentes
� Administ ración de recursos� El servidor puede estar compart ido por varios clientes
8
Consideraciones de diseño� Administ ración del estado
� del servidor (persistente o no)
� del cliente (memorizado por el servidor o no)
� Modelo del servicio de comunicaciones� Modo conectado
� Modo desconectado (GDWDJUDPV)� Modelos de ej ecución del servidor
� Uno o mas procesos
� 3RRO de procesos o creación a la demanda
9
Servidor sin datos persistentes� La ej ecución del servicio no ut iliza más que los parámetros de
ent rada� Situación ideal
� No hay una modif icación del estado del servidor
� Solución muy favorable� Para la tolerancia a fallas
� Para el cont rol de concurrencia
� Ej emplo� Servicio del cálculo de una función matemát ica
10
Servidor con datos persistentes� Las ej ecuciones sucesivas manipulan datos persistentes
� Modif icación del contexto de ej ecución sobre el sit io
� Problemas de cont rol de concurrencia
� Problemas para garant izar la tolerancia a fallas
� Ej emplos� Servidor de archivos dist ribuidos
� Servidor de bases de datos
11
Servicios sin estados memorizados (VWDWHOHVV VHUYLFH)� El servidor no memoriza las informaciones relat ivas al estado de
las pet iciones en curso
� Las pet iciones sucesivas son independientes� Aún si datos globales sean modif icados, la pet ición en curso no
mant iene relación con las precedentes
� No es necesario respetar el orden de las pet iciones
� Ej emplo� El servicio de reloj en una red (servicio NTP –1HWZRUN 7LPH�
3URWRFRO)
12
Servicio con estados memorizados (VWDWHIXO VHUYLFH)� Las pet iciones sucesivas se ej ecutan en función del estado dej ado
por pet iciones anteriores� La preservación del orden de las pet iciones es indispensable
� Ej emplos� Lectura de un regist ro de un archivo en acceso secuencial (que
depende de un apuntador a la posición actual)
� El llamado a un método en un obj eto (el resultado depende del estado del obj eto)
13
Modelos de comunicación� La principal diferencia es la f iabilidad en la ent rega
� Orientado a conexión� La ent rega es garant izada, respetando el orden del envío y libre de
error (con reenvío en caso necesario)
� Sin conexión (GDWDJUDPV)� La ent rega sigue una polít ica de ent rega “ mej or esfuerzo” : no hay
garant ía en la ent rega, los mensaj es pueden llegar duplicados y en desorden
14
Modelos de ej ecución� El servidor puede organizarse de la manera siguiente:
� Un solo proceso servidor (ej ecución iterat iva)
� Varios procesos o WKUHDGV por servidor (ej ecución concurrente)� Creación de procesos o WKUHDGV a la demanda
� 3RRO de procesos o WKUHDGV
15
¿Procesos o WKUHDGV?� Un programa puede ej ecutarse con varios procesos, que implican
YDULRV�HVSDFLRV�GH�HMHFXFLyQ�con sus respect ivos cont roles (hilos de ej ecución o WKUHDGV)
� Un WKUHDG es un proceso ligero, de manera que un proceso normal puede albergar varios WKUHDGV que comparte XQ�PLVPR�HVSDFLR�GH�HMHFXFLyQ cada uno con su respect ivo cont rol
16
Ej ecución con un solo procesowhile (t rue) {
receive(client_id, message);ext ract (message, service_id, params);result = do_service[service_id](params);send(client_id, result );
}
Cliente
Servidor
17
Creación de procesos a la demanda
� Vigilante
while (t rue) {receive(client_id, message);ext ract (message, service_id,
params);create_process(client_id, service_id,
params);}
� Servicio
/ / código a ej ecutarresult = do_service[service_id](params);send(client_id, result );exit ;
Servidor
Servidor’
Cliente
petición
respuestaejecución
creación
18
3RRO de procesos
� Vigilante
while (t rue) {receive(client_id, message);ext ract (message, service_id,
params);dispatch(client_id, service_id,
params);}
� Servicio
/ / código a ej ecutarresult = do_service[service_id](params);send(client_id, result );exit ;
Servidor
Servidor’
Cliente
petición
respuestaejecución
Servidor’
despacho
Servidor’Servidor’
19
Opciones de implementación� Opción de baj o nivel
� Ut ilización de primit ivas del sistema de comunicación� Programación por Sockets
� Abst racciones de alto nivel� Ut ilización de un PLGGOHZDUH de comunicaciones
� Llamado a procedimientos remotos (RPC)� Llamado a métodos distantes (obj etos comunicantes)
20
C/ S: primit ivas de baj o nivel
Cliente Servidor
pet ición
respuesta
-Protocolo de interacción-Empacado del mensaj e (PDUVKDOOLQJ)
-Protocolo de interacción-Desempacado del mensaj e (XQPDUVKDOOLQJ)
21
Stub Skeleton
¡Código generado automát icamente!
C/ S: Middleware RPC
Cliente Servidor
22
Variantes de arquitectura� Múlt iples clientes y un solo servidor� Múlt iples clientes con múlt iples servidores
23
Problemas con múlt iplesclientes/ un solo servidor� El servidor puede formar un “ cuello de
botella”� El servidor int roduce un punto de
vulnerabilidad en caso de fallas� El sistema puede estar limitado en
escalabilidad
24
Arquitectura múlt iples clientes y múlt iples servidores
Cliente
Cliente
Servidor
Servidor
Servidor
Proxy“ Balance de carga”
25
Agenda3 Modelo cliente –servidor� Modelo n-t ier
� Principio general� Patrones de arquitectura
� Modelo peer to peer� Principio general� Funcionamiento
� Modelo basado en intercambio de mensaj es� Topologías� Patrones de comunicación� Est rategias de ent rega
26
Arquitecturas Mult i-Tier� La arquitectura mult i-t ier es una generalización del
modelo cliente-servidor� Una aplicación cliente-servidor usa una arquitectura 2-t iers� La arquitectura promueve una j erarquía donde los
componentes en las capas superiores son clientes de los de la capa inmediatamente inferior
� Las aplicaciones en la WEB son un ej emplo del uso de esta arquitectura
27
$FFHVR�D�GDWRVSHUVLVWHQWHV
Sistemas mult i-t ier, un ej emplo
NavegadorWEB
ServidorWEB
Servlets
ServidorEJB
ServidorSABD
,QWHUID]�GH�XVXDULR /yJLFDDSOLFDWLYD
28
Pat rones de arquitectura� Tipos de código
� Presentación (P)� Lógica aplicat iva (A)� Acceso a datos persistentes (D)
� Variantes� Código monolít ico [PAD]� A dos niveles
� Modelo basado en intercambio de mensaj es� Topologías� Pat rones de comunicación� Est rategias de ent rega
32
Modelo 3HHU�WR�3HHU� 3HHU�WR�3HHU es un nombre nuevo para un viej o
paradigma de computación� P.e. la Internet surgió como un sistema 3HHU�WR�3HHU, pero
ot ros modelos de computación resultaron mas at ract ivos
� Este modelo promueve un sistema global que permite la colaboración directa ent re nodos, con énfasis en la capitalización de recursos
33
3HHU�WR�3HHU (cont inuación)� Todo nodo en este modelo puede ser a la vez cliente y
servidor de servicios� La conf iguración es generalmente dinámica e incluso
espontánea� El modelo reposa en la técnica de duplicación parcial
(o total) de servicios, lo cual conlleva los problemas de� Coherencia� Descubrimiento de servicios� Encaminado de pet iciones� Control
34
Sistemas Peer to Peer: Descripción
� Promueve un sistema global que permite:� la colaboración directa ent re nodos
� énfasis en la capitalización de recursos
� Permiten el acceso a grandes cant idades de datos y de recursos
� Todo nodo puede ser a la vez cliente y servidor de servicios
� Ut ilizan técnicas de duplicación parcial (o total) de servicios
35
Sistemas Peer to Peer: Clasif icación� Sistemas para Compart ir Archivos
� Asumen que hay suficientes peers en el sistema que ofrecen el recurso requerido
� Napster� Gnutella� Freenet
� Sistemas de mensaj ería instantánea� Cada peer guarda información única� Consultas son especif icas a un peer� MSN Messenger� AOL Instant Messenger� ICQ