Building Event-driven Architectures with WSO2 Integration Platform — Part 1
How WSO2 platform components play event producer and consumer roles in an event-driven architecture
Event-driven Architecture is the de facto standard for building high performant, scalable, resilient, and loosely-coupled application architectures.
A typical event-driven architecture comprises loosely-coupled, self-contained components called event producers, consumers, and brokers. WSO2 Enterprise Integration Platform (EIP) brings in three products to help developers and architects design, build, and operate event-driven systems at scale. These products can play either producer, consumer, or both roles at the same time.
In this two-part article series, I will discuss how you can build distributed event-driven applications with the WSO2 Enterprise Integration Platform.
Part 1 discusses the nature of event-driven applications and why you should choose WSO2 EIP for the implementation.
In Part 2, we’ll discuss how different WSO2 EIP products play producer and consumer roles in a typical event-driven system.
So let’s dive in.
Event-Driven application architectures
Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events.
An event represents a fact that happened in the past. It is immutable and may carry a state change that occurred in a software or a hardware system.
- A user just signed up at a website.
- An item has been added to the user’s shopping cart.
- A temperature sensor measured the current temperature
Events are different from Commands where they carry intent and may expect a response in return. To understand their difference, you may refer to the following article that I wrote sometime back.
Using Commands, Events, and Queries in Microservices Communication
There are three distinct ways that Microservices can interact over a network: commands, events, and queries. Explore…
An event-driven system is composed of loosely-coupled, self-contained components that utilize events to communicate with each other. We can group these components and assign them the following roles based on how they interact with events.
- Event producers — Who produces events?
- Event consumers — Who consume events?
- Event brokers — Who store events until they are consumed
A producer publishes an event to the broker, which stores it until the consumer consumes it. Events are delivered in near real-time, so consumers can respond immediately to events as they occur.
The following figure illustrates this architecture better.
Unlike traditional request-response-driven systems, producer and consumer interactions are asynchronous and non-blocking. That means producers don’t wait for a response in return. Producers are decoupled from consumers — a producer doesn’t know which consumers are listening. Consumers are also decoupled from each other, and every consumer sees all of the events.
The critical thing is event producers, consumers, and brokers are decoupled, which allows them to be scaled, updated, and deployed independently.
Building an event-driven system means identifying what components will be playing the above roles and carefully modeling their asynchronous interactions using events.
Why WSO2 Enterprise Integration Platform?
When you think of building an event-driven architecture, there are many tools and frameworks to choose from in the market. That includes Spring Cloud Stream, Spring Integration, Quarkus, Dapr, Amazon Lambda, Azure Functions, etc.
When deciding upon a toolset, you can slice and dice your options across a few dimensions.
- Built-in features to produce and consume events from many event sources, robust failure handling and increase developer efficiency.
- Ability to support highly scalable deployments on the cloud, on-premise, or hybrid infrastructure.
- Rich observability for tracing events and the support for deployment automation.
- Ability to act as an Event Mediator.
From a strong background in the Enterprise Integration domain, the WSO2 Enterprise Integration Platform (EIP) can score high on the above analysis. WSO2 EIP offers three products for designing, building, and operating event-driven application architectures.
- Micro Integrator for asynchronous event-driven system integration.
- Streaming Integrator for building real-time stream processing appliances.
- API Manager for API lifecycle management.
In a typical event-driven system, WSO2 EIP components can play event producers and consumers’ roles or play both roles simultaneously.
Based on my experience with the platform, I’ll choose WSO2 EIP over the following facts.
Speeds up the application development
WSO2 EIP supports a wide range of messaging protocols and bundles a rich set of pre-built connectors to popular event sources for producing and consuming events. Protocols like JMS, AMQP, Kafka, MQTT, and WebSockets have first-class support. So you don’t have to code everything from scratch to connect your application to messaging systems.
Designed to handle highly scalable and resilient deployments
Event-driven applications demand on-demand scaling and high resiliency in the face of a failure. With modern cloud-native tools, these needs can be easily met.
WSO2 EIP products have been designed from the ground level to be lean, resource-efficient, and container-friendly. You can find many organizations deploying WSO2 products on Kubernetes, Docker Compose, and OpenShift to achieve on-demand scalability and resiliency.
Provides rich observability support
Event-driven applications are inherently loosely-coupled and distributed. The ability to trace the paths of events plays a crucial role in such a system.
WSO2 EIP products co-exist with industry-leading observability tools to help close that gap. They provide centralized logging with tools like ELK stack, distributed tracing with Jaeger and Zipkin, and support a wide variety of monitoring tools.
Built-in Event Mediation
WSO2 EIP products have been built on top of a powerful mediation engine called ‘Apache Synapse.’ It is a configuration-driven runtime that you can use to apply mediations on events such as transformations, filtering, and routing. These mediation capabilities are built into WSO2 EIP so that you don’t have to code them from scratch.
In summary, the products of WSO2 EIP are versatile, comprehensive, and flexible enough to play either producer or consumer roles in your event-driven application architecture. With few configurations, you can use them as it is without building everything from the ground up.
We’ll explore how WSO2 EIP products can play event producer and consumer roles in event-driven architectures with appropriate use cases and potential configurations in Part 2.
Event-driven architecture ( EDA) is a software architecture paradigm promoting the production, detection, consumption…