SensediaSensediaSensediaSensedia
  • API Products
    • API Platform
    • API Governance
    • Event-Driven Architecture
    • PCI
    • Flexible Actions
  • API Services
    • Sensedia Professional Services
  • Solutions
    • APIs para Aseguradoras​
    • Open Banking
    • Retail & E-commerce
  • Blog
  • Contacto
    • Contacto
    • Clientes
  • Carrera
  • Español
    • Portugués, Brasil
    • Inglés

Entendiendo Sobre Event Driven Standards

    Home APIs Entendiendo Sobre Event Driven Standards

    Entendiendo Sobre Event Driven Standards

    By Ana Paula Borges | APIs | 0 comment | 30 septiembre, 2019 | 0

    De la misma forma que cuando trabajamos con cualquier arquitectura tenemos algunos estándares, en la Arquitectura Dirigida para Eventos no sería diferente. Así, tenemos 3 estándares principales, que son: Event Notification, Event Carried State Transfer y Event Source. ¿Vamos a conocer un poco más sobre ellos? 

     

    Event Notification

    Cuando trabajamos utilizando Event Notification, el sistema enviará notificaciones para otros sistemas sobre una modificación que ocurrió en su dominio, en el caso que alguno de los sistemas que recibieron la notificación tenga interés en saber más sobre la modificación, él deberá ir a una interfaz suministrada por el proveedor para captar más informaciones. 

    También usaremos el ejemplo del artículo anterior (Si no lo leíste, corre que aún da tiempo, él está disponible en este enlace), que es el cambio de dirección de un cliente, pero ahora, piense conmigo en un caso hipotético de mercado (que puede ser real, acepto royalties), un marketplace de ventas compartirá los datos de registro de sus clientes con colaboradores de mercado, entre ellos, bancos, esto será útil principalmente para actualizaciones relacionadas a informaciones de dirección, una vez que es más fácil actualizar mi dirección en un marketplace donde recibiré el nuevo producto que compré, en lugar de acordarme de actualizar el banco. Con este ejemplo en mente, vamos para nuestro caso de uso utilizando Event Notification:

     

     

    El cliente modificará su dirección, el Servicio de clientes será responsable de actualizar las informaciones en la base de datos y de disparar una notificación de evento con el mensaje “Cliente 43F31A1 actualizó los datos” para el broker, los servicios que están interesados en informaciones de aquel sistema específico estarán escuchando y si, por ejemplo, el servicio bancario reconoce al cliente y tiene interés en sus datos actualizados, él hará una llamada al servicio de clientes, como GET/clientes/43F31A1 para recuperar las informaciones y actualizar sus datos. En el caso que el servicio bancario no conozca al cliente en cuestión, él simplemente ignorará el mensaje. 

    Al utilizar este estándar, tenemos la ventaja del bajo acoplamiento, pues separamos al receiver del sender y, como desventaja, podemos tener la sobrecarga del productor, una vez que puede haber N sistemas que están interesados en la actualización y pueden ir al mismo tiempo a buscar más informaciones sobre la misma en el productor.

     

    Event Carried State Transfer 

    Utilizaremos Event Carried State Transfer cuando tengamos la necesidad de enviar la información completa en el mensaje, de esta forma los procesadores no deberán consultar al productor para saber cuáles fueron los cambios. 

    En nuestro ejemplo, el cliente modificará su dirección y el Servicio de clientes será responsable de actualizar las informaciones en la base de datos y de disparar una notificación de evento, pero en lugar de decir solamente que el cliente 43F31A1 actualizó los datos, él enviará el mensaje con los datos completos, como en el caso del cambio del Código Postal, el mensaje debe ser “Cliente 43F31A1 actualizó el Código Postal para 29580000”, y con esto, los procesadores tendrán la información completa para realizar su trabajo. El procesador puede almacenar las informaciones en una base de datos local, para que, al realizar procesamientos futuros, no necesite consultar informaciones en el productor, que en nuestro caso es el servicio de clientes.

     

    Al utilizar este estándar, ganamos resiliencia, una vez los procesadores serán capaces de funcionar, aunque el productor esté indisponible, reduciremos también la latencia, ya que no tendremos la necesidad de ir al productor para obtener más informaciones, y como ustedes ya deben haber percibido, una de las ventajas también es que ya no sobrecargaremos el sistema productor, pues el mensaje contiene toda la información necesaria. 

    Como desventajas podemos citar la replicación de las informaciones, y el hecho de que el procesador debe preocuparse con la consistencia de los datos, ya que ahora él también es poseedor de la información.

     

    Event Source

    Utilizamos Event Source cuando tenemos la necesidad de almacenar los cambios que ocurren en el estado de un sistema, en cada modificación almacenaremos la modificación como un evento, y cuando sea necesario será posible reconstruir el estado del sistema con confianza, realizando la reprocesamiento de los eventos. 

    Siguiendo nuestro ejemplo, el cliente modificará su dirección y el Servicio de clientes será responsable de actualizar las informaciones en la base de datos y de enviar el evento de cambio de dirección, que será almacenado juntamente con los datos que fueron modificados, en un repositorio o base de datos. Si en algún momento nuestro servicio de clientes es borrado, por ejemplo, tendremos el Event Data Source que nos posibilitará la reconstrucción hasta el momento en que estaba.

     

    Al utilizar Event Source, ganamos el audit, en el caso que yo necesite saber qué ocurrió y cuándo ocurrió, puedo hacer una consulta en mi repositorio y descubrirlo. También tenemos el beneficio de poder realizar el debug, que es un punto delicado cuando estamos trabajando con orientación para eventos, si surge la necesidad de realizar el debug del sistema, podemos apuntar nuestro ambiente de pruebas para el repositorio y realizar todas las validaciones que son necesarias. 

    Como desventajas podemos citar que Event Source aún no es muy utilizado en el mercado, lo que puede dificultar a la hora de encontrar materiales que aborden el tema, y tenemos también Event Schema, que se refiere a lo que almacenaremos en el repositorio. ¿Será todo evento que ocurra? ¿Solamente los eventos que llegan? Debemos escoger bien cuál esquema seguiremos en el momento de almacenar las informaciones. 

    Bien, estos son 3 de los estándares que tenemos en la arquitectura dirigida para eventos, ¿usted ya trabajó con alguno de ellos? ¿Cuál fue tu experiencia? ¡Cuéntanos!

    Y estén atentos, muy pronto tendremos un artículo hablando sobre la documentación de las interfaces asíncronas, AsycAPI.

     

    Event-driven, Eventos, Notificacion
    Ana Paula Borges

    Ana Paula Borges

    Analista, apaixonada por café, música, livros, seriados e claro, tecnologia.

    More posts by Ana Paula Borges

    Related Post

    • Aumento sazonal na prática

      Capilaridad: el secreto del e-commerce de éxito

      By Nicholas Gimenes | 0 comment

      Para poder hacer que su negocio crezca, es necesario poder alcanzar el máximo de nuevos clientes posibles, además de fidelizar a los clientes antiguos. Este es el primer paso para ser exitoso. En este aspecto,Read more

    • 6 Pasos para definir los KPIs de las APIs

      By Vinicius Balbino | 0 comment

      *actualizado el: 22 de marzo de 2020 Después que su API esté activa, diversas llamadas de varios usuarios ocurren en pequeños períodos de tiempo. ¿Cómo definir el alcance de sus aplicaciones? ¿Cómo definir el éxito?Read more

    • Sensedia API Management como Strong-Performer en Forrester Wave

      Sensedia API Management en el Forrester Wave como Strong Performer

      By Luiz Piovesana | 0 comment

      El 2016 fue de gran expansión para la Plataforma de APIs de Sensedia. No solo por el fortalecimiento de la base de clientes, con la incorporación de nombres como TV Globo, Natura, Azul, Marisa, Netshoes,Read more

    • Sensedia API Management en Gartner Magic Quadrant

      Sensedia como Visionaria en el Gartner API Management Magic Quadrant

      By Lucas Tempestini | 0 comment

      El 2016 fue realmente un año distintivo para la llamada «API Economy». Vimos la consolidación de las APIs como fundamentales para toda Estrategia Digital. En abril de ese año, Rob van der Meulen, en unRead more

    • Open Banking

      ¿Qué es el Open Banking? Promoviendo el futuro de los bancos con APIs

      By Lucas Tempestini | Comments are Closed

      ¿Qué es Open banking y por qué marcará la diferencia? Recuérdate los principales bancos cuando comenzaron a ofrecer servicios digitales, como Internet Banking y las aplicaciones… ¿Cómo se sintió? ¿Fue cómodo, se sintió moderno, conRead more

    • O que é Open Insurance e quais as vantagens de adoção de um Estratégia de APIs no mercado de Seguros

      ¿Qué es Open Insurance?

      By Eduardo Arantes | 0 comment

      *texto contribución de Rafael Rocha – Consultor Sensedia La revolución que las APIs traen para los mercados es bastante grande. Nuevos modelos de negocios, servicios y aplicaciones surgen en una velocidad mucho más rápida deRead more

    • Top 10 Riesgos de Seguridad en la Web (OWASP) y como atenuarlos con API Management

      By Nicholas Gimenes | 0 comment

        Seguridad de APIs y de Apps Datos críticos en la nube, acceso móvil desde todas partes, IoT, Open Banking, plataformas digitales habilitadas por APIs ̶ ¿y la seguridad?, ¿cómo es? Las APIs son laRead more

    • Lo que los CIOs deben saber sobre Ecosistema de Socios

      By Eike Malavasi | 0 comment

        Imagina si todo lo que su empresa necesita crear fuera una plataforma, sirviendo de medio de comunicación para que un puñado de usuarios ingresen contenidos y creen valor para su negocio, constituyendo un ecosistemaRead more

    Leave a Comment

    Cancelar la respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Categorías

    • Analytics
    • APIs
    • Eventos
    • Negocios Digitales
    • Publicaciones Externas
    • Sin categorizar

    Etiquetas

    API API Economy API Gateway API Management APIs Architecture Arquitectura design de APIs DevOps Ecosistema de Socios ESB estrategias digitales Estratégia Digital estratégias digitals Event-driven Eventos Exposición de APIs Gestión de APIs graphql gRPC Iinnovación Innovacion Abierta Innovación Insurtech Integraciones Integración MicroServices Microservicios Modelo de Negocio Monetización Negocios Digitales Notificacion omnicanalidad Open APIs open banking open insurance Plataforma REST RESTful seguridad Seguridad de APIs Service Mesh SOA Transformación Digital Transformación Digitale

    Entradas recientes

    • Black Friday Post – La experiencia de Via Varejo
    • Intégrese con VR Beneficios de forma ágil, simple y segura
    • La importancia de una buena atención de soporte
    • Optimizando Arquitectura Event Driven en Java (desde el bajo nivel)
    • La importancia del uso de métricas en APIs
    • Política de Privacidad
    Copyright © 2020 Sensedia | All Rights Reserved
    • API Products
      • API Platform
      • API Governance
      • Event-Driven Architecture
      • PCI
      • Flexible Actions
    • API Services
      • Sensedia Professional Services
    • Solutions
      • APIs para Aseguradoras​
      • Open Banking
      • Retail & E-commerce
    • Blog
    • Contacto
      • Contacto
      • Clientes
    • Carrera
    • Español
      • Portugués, Brasil
      • Inglés
    Sensedia