Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 8 vistas

    7,8 E&p, E&p

    Cargado por

    cesar balladares quintana

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd

    7,8 E&p, E&p

    Cargado por

    cesar balladares quintana
    8 vistas59 páginas

    Título original

    7,8 E&P,E&P

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    8 vistas59 páginas

    7,8 E&p, E&p

    Cargado por

    cesar balladares quintana

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    de 59

    Estilos y

    patrones – III
    Pipe & Filter |
    Event driven
    IIC2173 - Arquitectura de sistemas de software
    Departamento de Ciencia de la Computación
    Escuela de Ingeniería – PUC
    Hans Findel - Nicolás Acosta
    Repaso
    • Main y subrutinas

    • Estilo capas

    • MicroKernel
    En máquina virtual

    • Crítico en proyecto e industria


    Devops

    • JVM y otras máquinas virtuales


    Flujo de datos: Pipe
    and filter

    • Estilo sumamente poderoso

    • Componentes con interfaces


    claras, uno tras de otro

    • Cada componente cumple una


    función encapsulada
    Flujo de datos: Pipe
    and filter - Ejemplos

    • Pipes en Linux

    • Pipes de procesamiento de
    objetos (e.g. machine learning
    en imagen)

    • Procesamiento de audio

    • ETLs
    Pipe and filter : Pros

    • Modular
    • Fácil de modificar módulos
    • Reusable
    • Cada componente puede ser
    escalable
    • Flexible
    • Testeabilidad
    Pipe and filter : Cons

    • Requiere un proceso organizado


    • No soporta aplicaciones interactivas
    • Complejidad
    • A medida que el sistema se extiende, se
    acopla más

    • No toda la data es compatible


    • Se puede acumular overhead
    • Mínimo común denominador en la
    transmisión de datos
    Invocación
    implícita
    Invocación implícita / Event driven architectures

    • Anuncio de eventos en lugar de invocación de métodos


    • Asincronía implícita
    • Componentes clave
    • “Listeners” registran el interés en algún componente y asocian métodos
    a eventos (subscribers, delegates)
    • Publishers producen contenido
    • Canales transmiten información entre productores y eventos
    • Los métodos se registran de manera implícita
    • Interfaces de componentes son métodos y eventos
    • Conectores
    • Invocación explícita e implícita en respuesta a eventos
    EDA: Características
    • Invariantes del estilo
    • “Publicadores” no conocen los
    efectos de los eventos
    • No se asume cómo se procesará la
    respuesta a eventos
    • No se responde a todo
    necesariamente
    EDA: Características
    • Datos
    • Suscripciones
    • Notificaciones
    • Push & Pull
    • Elementos transferidos
    • Según contrato
    • Llevan toda la data necesaria
    • Topología
    • Red
    • Broker
    • Mediador
    • Reuso de componentes, evolución del sistema
    • Puede pasar de una app pequeña a un gran
    sistema

    • Reducción de acoplamiento
    • Más compatible con agilidad
    • Flexible
    EDA: Pros •
    •
    Modularizable
    Compatible con microservicios

    • Manejo elevado de escalabilidad y distribución

    • Alto performance
    • No integración punto a punto: agregar
    consumidores es muy sencillo en cantidad y
    capacidad

    EDA: Pros • Muy compatible con tiempo real

    • Es posible flexibilizar y añadir request reply


    • Incluso añadir colas y flexibilizar capacidad de
    procesamiento
    • Estructura de sistema no es intuitiva
    • Se eleva la complejidad
    • Quien habla a quien?
    • Asincronía
    • Latencia
    EDA: Cons • Eventos complejos pueden elevar latencia
    • Eventualmente consistente
    • Olvidarse de ACID
    • Soporte y mantenibilidad
    • Debugging
    • Búsqueda de problemas
    • No hay conocimiento de la respuesta de los
    componentes al evento, ni del orden de las
    respuestas
    • Garantía de envío no asegurada
    EDA: Cons • E.g. IoT
    • Componentes no permiten control del sistema
    • Se necesitarían intermediarios caros
    • Dificil de restaurar operacion
    EDA:
    Consideraciones

    • Establecer buenos contratos

    • Monitorear eventos lo más


    posible

    • Idempotencia: Manejo de
    eventos
    duplicados/desordenados

    • Manejar errores: Responder


    EDA: Broker

    • Entidad dedicada a enviar


    mensajes y cumplir entregas

    • No orquesta eventos, solo los


    mueve

    • Intermediario necesario para


    sustentar muchas arquitecturas
    de eventos
    • Ojo con SPOF

    • Puede usar un protocolo (AMQP,


    XMPP)
    EDA: Broker - RabbitMQ
    EDA: Mediator
    • Ente centralizado capaz de movilizar un
    proceso dado

    • Toma los eventos y los mueve entre


    procesadores de eventos

    • E.g. Camel, BPEL, Django signals


    Apache camel
    EDA: Publisher /
    subscriber

    • Publishers envían mensajes sin


    necesariamente apuntar a suscriptores
    específicos
    • Suscriptores escuchan mensajes
    • No todos interesan
    • Puede ordenarse en tópicos para
    mejorar separación
    • Mensajes se envían de forma
    “indirecta”
    Pub/sub: Ejemplos

    • Publishers
    • RSS
    • Chats & gaming
    • XMPP
    • IoT
    • MQTT
    • Ecommerce
    • Eventos críticos
    • Stock
    • Envío de correos
    MQTT
    Pub/sub: Pros

    • Ventajas de EDA
    • Desacoplamiento
    • Cualquiera podría entrar a un
    tópico
    • Asincronía
    • Fire-and-forget
    • Podrías esperar un evento
    • Escalable
    • Aprovechamos broadcasting
    Pub/sub: Cons

    • Mensajería confiable
    • Como me aseguro de que llegue
    • Realmente los brokers son tan
    confiables?
    • QoS
    • Seguridad
    • Control de acceso (RBAC, CBAC)
    • Complejidad
    • Podrían enredarse muchos tópicos
    y contenidos
    Pub/sub: Otros ejemplos
    En su proyecto

    • Fácil agregar subscribers:


    Tenemos 165 suscriptores y
    podrían ser más

    • MQTT: MQ Telemetry transport


    • Fácil de escalar
    • Mínima configuración
    • Conexión simple y ligera,
    soporta QoS
    • Usado en IoT
    • Corre sobre TCP/IP

    https://commons.wikimedia.org/wiki/File:MQTT_protocol_example_without_QoS.svg#/media/File:M
    QTT_protocol_example_without_QoS.svg
    En su
    proyecto
    • Van a poder conversar de
    vuelta

    • Ojo con los errores y pérdida


    de datos

    • Redundancia en los
    subscribers?
    Sobre los debates

    • Podrán inscribir un grupo en una sección


    • Recibirán una especificación 2 semanas antes
    de exponer
    • Expondrán 2 grupos por clase
    • Cada semana se volverá más exigente la
    evaluación
    • 1 grupo en exposición, otro de stakeholders
    • Como cliente
    • Como arquitecto
    • Como desarrollador
    Estilos y
    patrones – IV
    Intérprete,
    código móvil
    IIC2173 - Arquitectura de sistemas de software
    Departamento de Ciencia de la Computación
    Escuela de Ingeniería – PUC
    Hans Findel - Nicolás Acosta
    Intérprete

    • El intérprete parsea y ejecuta


    comandos de entrada, actualiza el
    estado mantenido por el intérprete

    • Componentes
    • Intérprete de comandos, programa
    de interpretación del estado,
    interfaz de usuario
    Intérprete: Ejemplos

    • Usualmente visto en lenguajes de


    programación

    • Fácii de usar, flexible y portable


    • E.g. py lo usan en todos lados

    • Intérpretes de py/js
    • Bash
    Intérprete: Ejemplos

    • Usualmente visto en lenguajes de


    programación

    • Fácii de usar, flexible y portable


    • E.g. py lo usan en todos lados

    • Intérpretes de py/js
    • Bash

    https://www.researchgate.net/figure/Software-architecture-of-CPython-python-
    command_fig11_344044674
    Intérprete: Código
    móvil

    • Un elemento de datos se transforma


    dinámicamente en un componente de
    procesamiento de datos

    • Software que puede ejecutarse en


    múltiples nodos sin instalar o compilar
    (REF?)

    • Transmitido por red

    • Lenguajes que usan: JS, Java, Dart


    Código móvil

    • Datos: Código como datos (bundles, archivos)

    • Topología: Vía red

    • Variantes
    • Código bajo demanda
    • Evaluación remota
    • Agentes móviles (e.g. agentes de
    monitoreo)

    • Containers cuando se despliegan a varios tipos


    de sistemas

    https://medium.com/nerd-for-tech/v8-engine-explained-where-the-
    actual-fun-happens-cbb1662147d
    Flutter
    https://www.linkedin.com/pulse/jvm-architecture-how-internally-work-ali-as-ad
    WASM
    https://blog.logrocket.com/webassembly-how-and-why-559b7f96cd71/
    Código móvil: Pros

    • Portabilidad suprema

    • Contenido mejorado
    • Dinámico
    • Interactivo

    • Reduce carga de transmisión en ciertos


    escenarios

    https://www.alibabacloud.com/blog/using-webassembly-and-kubernetes-in-combination_596177
    Código móvil: Contras

    • Riesgo de seguridad: De donde viene ese código?


    • https://owasp.org/www-community/vulnerabilities/Unsafe_Mobile_Code

    • Privacidad

    • Trabajo en compatibilidades
    • 1 base en cada plataforma

    • Performance: Más intermediarios


    Máquinas virtuales y Código móvil

    • Puede pasar que el código móvil corre sobre alguna máquina virtual

    • Puede ayudar en seguridad

    • Ayuda aún más a portabilidad


    Memoria compartida

    • Un motor de inferencia parsea las


    entradas de los usuarios y determina si
    es un “hecho”, una “regla” (y los añade
    a la base de conocimiento) o una
    “consulta” ( y la resuelve)
    • Los hechos y reglas se añaden a la
    base de
    conocimiento
    • Las consultas se ejecutan sobre la base
    de conocimiento para evaluar las reglas
    que se puedan aplicar y resolver la
    consulta
    Memoria compartida: Basado en reglas

    • Componentes
    • Interfaz de usuario, Motor de inferencia, Base de conocimiento

    • Conectores
    • Componentes fuertemente interconectados vía llamadas a procedimientos y/o
    llamadas a memoria compartida
    • Elementos de datos
    • Hechos y consultas
    Estilo: Memoria Compartida

    Jess (Java
    Expert System
    Shell)
    Estilo: Memoria
    Compartida
    • La “conducta” de la aplicación se
    extiende mediante reglas
    • If/else, arboles de decisión, otros…
    • IPC mediante almacenes de
    datos o buffers
    • Riesgo: Al aumentar el número
    de reglas es muy dificil entender
    las interaccciones entre las reglas
    • Ejemplos
    • Sistemas de tráfico
    • Memoria compartida
    • Reglas de tránsito
    • Manejo de concurrencia
    • Sistemas de seguridad
    Estilo: Pizarra

    • Un espacio de datos central


    consultado y modificado por
    fuentes de conocimiento
    • Fuentes de conocimiento
    aportan solución a un
    problema tomando partes
    de este
    • Blackboard: se organiza la
    data para ser accesible
    • Control: supervisa el
    resultado
    • Análogo: Grupo de científicos
    modificando una pizarra
    • Riesgo: Al aumentar el número
    de reglas es muy dificil entender
    las interaccciones entre las reglas
    Estilo: Pizarra

    • Aplicaciones
    • Sistemas expertos
    • Ias
    • Problemas complejos evolutivos

    • Pros
    • Posibilidad de problemas
    complejos
    • Arquitectura colaborativa

    • Cons
    • Escaso uso
    • Complejo de implementar
    correctamente
    • P2P
    • Arqui internet
    Siguiente • Cloud computing
    • Comunicación y conectores
    Estrategias para varios patrones
    Bass, Kazman

    También podría gustarte