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

Diagram taken from an article of Bogdan Sucaciu published at stackoverflow.blog

Wikipedia says:

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.

For example:

  • 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.

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.

Pre-built connectors to produce and consume events from a variety of event sources — Source

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.

Observability option of Micro Integrator — Source

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.

Internals of event mediation — Source

What’s next?

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.

Stay tuned!

References

--

--

--

EdU is a place where you can find quality content on event streaming, real-time analytics, and modern data architectures

Recommended from Medium

How My Team Implemented Agile Software Development Using Scrum

Many Faces of Event-driven Architecture

Using Drafts with NeoCities

DraftsxNeoCities

Add A New Dimension To Your Photos Using Python

Organization 4.0: Spindle

Gap Analysis: Execution Engines

My 26-hour journey to Google I/O 2018

Dockerizing a Node.js Web App

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store

Dunith Dhanushka

Editor of Event-driven Utopia(eventdrivenutopia.com). Technologist, Writer, Developer Advocate at StarTree. Event-driven Architecture, DataInMotion

More from Medium

Microservices: The Saga Pattern

Apache Kafka as cloud-native iPaaS Integration Middleware

In this blog, I am going to explain you how State store in Kafka streams is managed in…

Kafka Stream Business Logic Error Management