IBM Event Streams and IBM Event Automation

IBM Event Streams and IBM Event Automation

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Transforming to Event Driven Architectures from SOA

  • 1.  Transforming to Event Driven Architectures from SOA

    Posted 7 hours ago
    Edited by Adeoye Omoboya 7 hours ago

    The modern digital business works in near real-time; it informs interested parties of things of interest when they happen, makes sense of, and derives insight from an ever-growing number of sources. It learns, predicts, and is intelligent -- it is by nature Event-Driven.

    Event-driven architecture (EDA) is an architecture pattern that promotes the production, detection, consumption of, and reaction to events. This architectural pattern can be applied to the systems that transmit events among loosely coupled software components and services.

    Events are a way of capturing a statement of fact. Events occur in a continuous stream as things happen in the real and digital worlds. By taking advantage of this continuous stream, applications can not only react in near real-time, but also reason about the future based upon what has happened in the past.

    The business value of adopting this architecture is that you can easily extend EDA with new components that are ready to produce or consume events that are already present in the overall system. While events are more visible, new business capabilities are addressed, like near real-time insights. EDA helps also to improve the continuous availability of a micro service architecture.

    For enterprise IT teams, embracing event-driven development is foundational to the next generation of digital business applications. IT teams will need to be able to design, develop, deploy and operate event-driven solutions, in cloud-native styles.

    Event Driven Architecture

    Event-driven architecture is not something new, and it is not just about Kafka. EDA has to support asynchronous communication between application in two major semantics:

    • request/response with exactly one delivery with no data lost, when a component is asking another component to do something for it. This approach is to address long running transaction or business process and enforce using queuing technology.
    • deliver facts about its own data to an immutable log so other components can derive something about it. This is a pub/sub model with strong time decoupling.

    To support these EDA has a message as a service capability as cluster of message brokers. The brokers provides the connectivity between the other components. The diagram below depicts the reference architecture and integration patterns from an EDA



    ------------------------------
    Adeoye Omoboya
    ------------------------------