Ejemplo: Arq. de un Sistema Bibliotecario de Películas e Imágenes Cliente 1 Cliente 2 Cliente 3 Cliente 4 Ancho de Banda de la red Servidor de Catálogo
Catálogo Servidor de Vídeo
Archivos clip de Película Servidor de Fotografía Fotografía Digitalizada Servidor de Hipertexto
Hipertexto WEB (Gp:) Modelo Cliente-Servidor (2)
(Gp:) Modelo Cliente-Servidor (3)
Se puede ver desde el punto de vista del Software o del Hardware
Características del Modelo Cliente-Servidor Ventajas La distribución de datos es directa. Permite el uso efectivo de sistemas de red. Generalmente requiere hardware barato. Es fácil añadir nuevos servidores o actualizar los existentes. Desventajas El modelo no comparte datos con los diferentes subsistemas empleados en la organización. El intercambio de datos puede ser ineficiente. Si se intercambian grandes volúmenes de datos, quien más sufrirá será la performance. Hay administración redundante en cada servidor (trabajo solapado). No existen registros centrales de nombres y servicios, esto hace difícil encontrar los servidores y servicios disponibles. Es más dificil realizar datamining, o inteligencia de negocio.
Máquina Abstracta
Modelo de Máquina Abstracta (1) Este modelo también es conocido como el modelo de capas, o estratificado. Es utilizado para modelar las interfaces entre los subsistemas. El modelo organiza el sistema en base a un conjunto de capas (o máquinas abstractas), cada una de las cuales proporciona un conjunto de servicios. Soporta el desarrollo incremental de subsistemas en las diferentes capas. Cuando la interfaz de una capa cambia, solamente la capa adyacente se ve afectada. Sin embargo, es difícil estructurar los sistemas de esta manera.
Modelo de Máquina Abstracta (2) Ejemplo: La arquitectura de un sistema de administración de versiones, puede ser abordado utilizando el modelo de máquina abstracta. Suministra los recursos de administración de la configuración (releases) en general. Comprende la administración de versiones de objetos. Para ello utiliza un sistema de administración de objetos, que provee servicios de administración y almacenamiento de información para los objetos. Utiliza un SABD para proveer almacenamiento básico de datos y servicios (adm. de transac., confirmación y recuperación, control de acceso, etc.).
Modelo de Máquina Abstracta (3) Administrador de Releases (Gp:) Ejemplo: Sistema Administrador de Versiones
Sistema de Base de Datos Administrador de Objetos Administrador de Versiones de Objetos
Características del Modelo de Máquina Abstracta Ventajas: Permite el desarrollo incremental. Es más mantenible. Flexible y fácil de evolucionar. Desventajas: Estructurar un sistema en capas es difícil. Puede haber problemas de performance debido a los distintos niveles de interpretación de órdenes. Puede suceder que una capa dependa de otra, que no es su predecesor inmediato.
Ejemplo de Modelo de Máquina Abstracta
Ejemplo de Modelo de Máquina Abstracta ¿Cómo lo hacemos en nuestras organizaciones?¿Cuál es el nivel de integración de Datos y Servicios?
Arquitecturas de 2/3 Capas… para Web 3-Tiers Architecture
2-Tiers Architecture
Arquitecturas de 2/3 Capas… para Web
Arquitectura de 5 Capas… para Web
Data Access Interface (DAI) Una alternativa para implementar la DAI:
Arquitecturas de Objetos Distribuidos
Arquitecturas de Objectos Distribuidos (DOA) No existe la distinción entre clientes y servidores, ya que cada objeto es potencialmente cliente y servidor. Cada entidad dentro del sistema, provee servicios a sus compañeros y también recibe servicios de ellos. La comunicación entre objetos se realiza a través de un sistema de middleware llamado ORB (Object Request Broker), que es una especie de bus de software que comunica a los componentes. Al no tener un servidor, estos sistemas son menos vulnerables que los que implementan una arquitectura C/S. Por otra parte, las DOA son bastante más complejas de construir y mantener que los sistemas C/S. Generalmente, también son más lentas.
Arquitectura de Objectos Distribuidos (DOA) Bus de Software (ORB) o 1 o 2 o 3 o 4 o 5 o 6 S
( o 1 ) S
( o 2 ) S
( o 3 ) S
( o 4 ) S
( o 5 ) S
( o 6 )
Arquitectura de Objectos Distribuidos (DOA)
Ventajas de las DOA Permiten que los diseñadores de estos sistemas puedan demorar la toma de decisión respecto a dónde y cómo deberían ser provistos los servicios. Es una arquitectura muy abierta, ya que permite que nuevos recursos sean agregados en el momento que se necesite. Permite que los sistemas sean flexibles y escalables. Es posible reconfigurar el sistema dinámicamente. Para ello sólo hay que migrar los objetos del sistema a través de la red. …. las principales desventajas son su complejidad y su mal rendimiento. “… según el dicho popular, los sistemas de objetos distribuidos son dulces… y lentos como la miel”.
EJERCICIO
Ejemplo de ChileMetal Desarrollar un framework de software integrador de políticas de administración de sistemas: Adm. de Usuarios, Políticas de Seguridad y Respaldo, Datos, Servicios (unificación). (Gp:) Sistema 1 (Gp:) Sistema 2 (Gp:) Sistema 3 (Gp:) Sistema 4 (Gp:) Sistema 5 (Gp:) FRAMEWORK
Ejemplo de ChileMetal Requisitos Críticos:
¿Cuál(es) cree que es el modelo más apropiado para estructurar la solución de ChileMetal? ¿Qué inconvenientes tienen los otros modelos?
… Queremos que la solución propuesta tenga mínimo impacto sobre los sistemas existentes.Júntese en grupos de 2 o tres personas y determine ¿cuál es la mejor alternativa?. Sub Luego, comparta su propuesta con el resto de nosotros.
Sist 1 Sist 2 Sist 3 BD Sist 1 Servicios Estándares BD Sist 2 BD Sist N Modelo de Datos Virtual Sist Nuevo …¿Cuál es la mejor propuesta???
Sist 1 Sist 2 Sist 3 Traductor de Servicios BD Sist 1 Servicios Estándares BD Sist 2 BD Sist N Modelo de Datos Virtual Sist Nuevo
Ejemplo de ChileMetal Invocación (propietaria) de Servicios de Validación de Usuarios: Sist 1: Valid_User (login, password) -> True/False Sist 2: Login (login, password) -> Rol/False Sist 3: Acceso_User (login, password) -> OK/¬OK Servicios Estándares: Login (login, password)-> True/False Rol (login)-> Rol ¿Cómo se traduce la invocación de login de cada sistema?
¿Podría ser algo así? (Gp:) I D L
(Gp:) I D L
(Gp:) I D L
ORBs (Gp:) Serv n
(Gp:) Serv n-1
(Gp:) Serv n-2
Client Side (Gp:) Servicio 1
(Gp:) Serv 2
(Gp:) Serv 3
(Gp:) Serv 5
(Gp:) Serv 4
(Gp:) I D L
(Gp:) I D L
(Gp:) I D L
(Gp:) I D L
(Gp:) I D L
ORBs Servidor de Usuarios Servicios de Respaldo (Gp:) Sistema Contable
(Gp:) Sistema de Rec. Humanos
(Gp:) Sistema de Ventas
¿Podría ser algo así? (Gp:) I D L
(Gp:) I D L
(Gp:) I D L
ORBs (Gp:) Serv n
(Gp:) Serv n-1
(Gp:) Serv n-2
Client Side (Gp:) Servicio 1
(Gp:) Serv 2
(Gp:) Serv 3
(Gp:) Serv 5
(Gp:) Serv 4
(Gp:) I D L
(Gp:) I D L
(Gp:) I D L
(Gp:) I D L
(Gp:) I D L
ORBs Servidor de Usuarios Servicios de Respaldo (Gp:) Sistema Contable
(Gp:) Sistema de Rec. Humanos
(Gp:) Sistema de Ventas
¿y los datos?
Modelo de Control
Modelos de Control Estos modelos son complemetarios a los de estructuración de sistemas, ya que modelan el control de la ejecución del sistema. Se refieren al control de flujo entre subsistemas. Es diferente al modelo de descomposición de sistemas y al de estructuración. Entre los modelos de control más conocidos están: Control Centralizado Hay un subsistema que tiene la responsabilidad de controlar, iniciar y detener otros subsistemas. Control basado en Eventos Cada subsistema puede responder a eventos generados externamente por otros subsistemas o por el ambiente del sistema. Cada subsist. controla su propia operación.
Control Centralizado
Control Centralizado (1) Hay un subsistema que es el responsable del manejo de la ejecución de todos los otros subsistemas. Dependiendo de la forma de ejecución de los subsistemas controlados (en secuencia o en paralelo), el modelo de control puede seguir dos estrategias: Modelo Call-Return Es aplicable a sistemas secuenciales. Sigue un modelo de subrutina Top-down, donde el control inicia en lo más alto de la jerarquía de una subrutina y se mueve hasta la parte más baja en la jerarquía. Es aplicable a sistemas secuenciales (donde existe in hilo de ejecución). Modelo Administrador Es aplicable a sistemas concurrentes. Un componente del sistema controla el inicio, coordinación y la detención de procesos de otro subsistema. Puede ser implementado en sistemas secuenciales como una instrucción case.
Control Centralizado: llamada y retorno (Call-Return) Programa Principal Rutina 1 Rutina 2 Rutina 3 Rutina 1.1 Rutina 1.2 Rutina 3.1 Rutina 3.2 (Gp:) Bajo este esquema, cada invocación es bloqueante
Llamada y Retorno Es rígido, simple e intuitivo. Su naturaleza rígida y restringida puede verse como ventaja y como desventaja. Es una ventaja porque el sistema es predecible, es fácil seguir su ejecución y controlar su comportamiento. Además, facilita la depuración (debugging) y prueba del sistema (testing). Es una desventaja porque es difícil manejar las excepciones a las operaciones definidas, y porque limita el accionar de los usuarios.
Control Centralizado – Administrador Proceso de Sensor Proceso Actuador Controlador del Sistema Procesos de Computación Interfaz de Usuario Manejador de Fallas (Gp:) Acá las invocaciones no son bloqueantes
Modelo Administrador También es llamado modelo maestro-esclavo. Se utiliza generalmente en sistemas críticos, donde la velocidad de respuesta es importante. Donde hay mucho procesamiento descentralizado y se requiere coordinación. También en aquellos casos donde se quiere centralizar la inteligencia (por ej. coordinadores de workflows). Otros ejemplos son: sistemas de control aereo, sistemas de tiempo real, sistemas de defensa, y sistemas colaborativos sincrónicos, entre otros. El administrador se vuelve un punto vulnerable, pero por otra parte, sólo tengo que proteger un único administrador. El administrador se podría volver un cuello de botella.
Modelo Administrador Los sistemas de Workflow suelen seguir este modelo
Sistemas Manejadores de Eventos
Sistemas Manejadores de Eventos A diferencia de los anteriores, los SME proponen el modelamiento descentralizado del control. Son manejadores de eventos generados externamente, donde el tiempo del evento está fuera del control de los subsistemas que lo procesan. Dos de los principales modelos manejadores de eventos son:
Modelo de Transmisión (Broadcast). Un evento es transmitido a todos los subsistemas. Cualquier subsistema puede manejar el evento. Modelos Manejadores de Interrupciones. Utilizados en sistemas en tiempo real donde una interrupción es detectada por un manejador de interrupciones y es pasada a otros componentes para ser procesada.
Ejemplos de sist. que utilizan este enfoque son: hojas de cálculo, agentes inteligentes, sistemas colaborativos, etc.
Modelo de Transmisión o Broadcast (1) Este modelo es efectivo para integrar subsistemas que están distribuidos a lo largo de diversas computadoras en una red. Los subsistemas registran la petición de eventos específicos. Cuando esto ocurre, el control es transferido a los subsistemas que pueden manejar el evento. Las políticas de control no están contenidas dentro del evento o del manejador de eventos. Los subsistemas deciden cuáles eventos son de su interés. No obstante, los subsistemas no saben cuándo un evento será manejado, o si será manejado.
Modelo de Transmisión o Broadcast (2) Subsistema 1 Subsistema 2 Subsistema 3 Subsistema 4 Manejador de Eventos y Mensajes (Gp:) Ejemplo: Transmisión Selectiva
Esquema: Publisher-Subscriber
Los manejadores de eventos nunca son bloqueantes.
Los clientes que invocan servicios podrían bloquearse o no… Depende de cada aplicación.
Modelo de Transmisión o Broadcast (3) Ventajas: La evolución de estos sistemas es sencilla. Un nuevo sistema sólo tiene que registrar los eventos que son de su interés, y proveer un método de control de su ejecución. Cualquier sistema (o servicio) puede activar cualquier otro, sin conocer su nombre, ni su ubicación. Los subsistemas pueden alojarse en distintas máquinas, manteniendo transparente su forma de operación. Desventajas: Los subsistemas que emiten los eventos, no saben si estos se manejarán, ni tampoco cuándo se realizará esto. Puede haber más de un subsistema registrado para manejar un mismo evento. Esto puede generar problemas a la hora de retornar los resultados del procesamiento del evento, ante una invocación de servicio.
Sistemas Manejados por Interrupciones Arquitectura utilizada en sistemas de tiempo real, donde una respuesta rápida es esencial. Hay distintos tipos de interrupciones, con un manejador definido para cada tipo. Cada tipo está asociado con una ubicación de memoria, un switch de hardware dispara la ejecución del manejador cada vez que llega una señal. Proveen una respuesta rápida, pero que es compleja de programar y difícil de validar.
Sistemas Manejados por Interrupciones Interrupciones Vector de Interrupciones Manejador 1 Manejador 2 Manejador 3 Manejador 4 Proceso 1 Proceso 2 Proceso 3 Proceso 4 El vector de interrupciones no se bloquea con cada solicitud (es sólo un derivador). Permite la ejecución paralela de múltiples solicitudes. El manejador de eventos puede responder directamente al cliente…..
Variante del Manejador de Interrupciones Interrup. / Eventos Manejador 1 Manejador 2 Manejador 3 Manejador 4 Proceso 1 Proceso 2 Proceso 3 Proceso 4 Aunque no es la idea, el vector de interrupciones podría bloquearse con cada solicitud (en caso de ser necesario). Si se bloquea, la tasa de atención de solicitudes (transacciones) cae notablemente. El manejador de eventos puede responder directamente al cliente….. Cola de Solicitudes Vector de Interrupciones
Volvamos al Ejemplo de ChileMetal Desarrollar un framework de software integrador de políticas de administración de sistemas: Adm. de Usuarios, Políticas de Seguridad y Respaldo, Datos, Servicios (unificación) (Gp:) Sistema 1 (Gp:) Sistema 2 (Gp:) Sistema 3 (Gp:) Sistema 4 (Gp:) Sistema 5 (Gp:) FRAMEWORK
Volvamos al Ejemplo de ChileMetal Júntese en grupos de 2 o tres personas y determine ¿Qué modelo de control utilizaría para organizar el comportamiento de la estructura propuesta? Luego, comparta su propuesta con el resto de nosotros.
Estas son las Arquitecturas que teníamos ¿Cuál es el modelo de control de ellas?
Modelos de Control para la Opción 1 ¿Cuál es el mejor?
Modelos de Control para la Opción 2
Descomposición Modular (3)
Descomposición Modular Es otro nivel de estructura donde los subsistemas son descompuestos en módulos. Dos modelos de descomposición modular son: Modelo de Objetos. Donde el sistema es descompuesto en objetos relacionados. Modelo de Flujo de Datos. Donde el sistema es descompuesto en módulos funcionales, los cuales, transforman entradas en salidas. Esto es conocido como el modelo pipeline. Es posible tomar decisiones acerca del comportamiento del sistema antes de que los módulos sean implementados.
| Página siguiente |