Integration with Event-driven Architectures and Asynchronous API

Introduction:

The key factor to integrate business processes and data is effective communication. Without effective communication, business processes and data cannot be properly integrated. Depending on an enterprise’s particular needs, communication can be either synchronous, asynchronous, or some combination of the two.

When designing applications integration solutions, asynchronous communication offers a number of advantages over synchronous communication, especially when it comes to services in Service Oriented Architecture (SOA). ). In this blog we will discuss how asynchronous communication fits into event driven architecture and how to design it using MuleSoft Anypoint platform.

Event-driven Architectures with Eventful APIs:

It is common practice to consider an API to be JSON-based, synchronous API over HTTP – a RESTful API. This type of API has existed for the past 20 years and can be found throughout virtually all Integration solutions. However, now a days Integration Architects are becoming more appreciative of Event-driven architectures because of the benefits of such solutions. Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events (source: Wikipedia).This has increased the use of asynchronous APIs which provides specific capabilities not fulfilled by traditional RESTful APIs.

An Eventful API (asynchronous API) does not require a synchronous response to a request. The API request is effectively fired off and then forgotten about. There is no waiting for a response, and a response is unnecessary.

There are two primary use cases for this approach.

• There’s an extremely high number of requests (such as a data stream entering a trading platform), where processing and returning responses are of little consequence.
• The transaction is long-lived (possibly updating multiple systems in the process), so waiting for a response is not practical.

The diagram below covers a high-level view of Event-Driven architecture. Here, Producers publish Events (messages) to particular Channels (queues) that are defined within an Event Broker. Consumers subscribed to certain Channels will then pick up these messages from those queues.

Asynchronous API is a way to describe event-driven APIs:

Asynchronous API is based on an Open API specification that defines interfaces for asynchronous APIs. The specification is protocol-agnostic so that it can support Web Sockets, Kafka, HTTP streams etc.  Complete documentation can be found on the AsyncAPI portal. Advantages of Async API are outlined below:

• Similar to Open API and RAML specifications
• Protocol-agnostic (amqp, anypointmq, http, https, jms, kafka etc.)
• Support in Design Center and Anypoint Exchange
• Human and Machine readable

MuleSoft Anypoint Platform & Async API:

It’s now possible to create AsyncAPI specifications within Anypoint Platform. This feature is integrated into the Design Center functionality. Creating an AsyncAPI interface is no different than creating a RAML(RESTful API Modeling Language).

This has an all-in build feature like RAML. See below:

• The API documentation is rendered in real-time to match the code just like RAML.
• Reuse existing Datatypes and import them into new interfaces,
• API interface specifications can also be published as an Asset to Anypoint Exchange

Example Async API for Payment Service

The Order Service API example below is exposing three queues. In the servers’ part, we have connectivity details for different environments. In the channels section, we have:

1. Order -failed – to receive event notifications about failed Orders.
2. Order -approved – to receive event notification about approved Orders.
3. Order – to push message to initiate Order process

With each channel, we have associated data type like OrderApproved. It gives consumers clear information on what structure is expected.

Conclusion

Async API is dedicated to describing event-driven APIs. As a result, the learning curve is lower for people having experience with either RAML or Open API specification. Giving Architects and Developers a more seamless method of embedding Eventful APIs into their Integration Solutions. However, the implementation for Eventful APIs does not yet provide the whole suite of tools that are currently available to RESTful APIs (such as oversight from API Manager). We can expect further development and features that MuleSoft will provide.

For more information about how Apps Associates Business Integration and Automation Practice can help you – click here.