You may easily specify and record your Kafka topics (event sources) in accordance with the open source AsyncAPI Specification by using IBM Event Automation’s event endpoint management feature.
What makes this significant? AsyncAPI is already a driving force behind things like standardisation, interoperability, real-time responsiveness, and more. Adding this to your environment through event endpoint management enables you to handle the intricacies of contemporary systems and apps with ease.
Since they make it possible for developers to work together efficiently and find, utilise, and expand upon preexisting solutions, Application Programming Interfaces (APIs) and API management are already immensely valuable. Formalising event-based interfaces can provide the same advantages as events, which are used to facilitate communication between applications:
- Standardised event description that makes it easy for developers to comprehend what events are and how to use them
- Discovering events: Catalogues allow for the addition of interfaces, making them searchable and marketed.
- Dispersed access Interface owners can employ self-service access that can be tracked.
- Life cycle supervision: Interface versioning helps prevent teams from being unintentionally destroyed by updates.
It is more crucial than ever for organisations to become event driven because consumers want prompt service and they need to be able to quickly adjust to shifting market conditions. Events must therefore be distributed throughout the entire organisation and fully utilised in order for enterprises to act truly agilely. The importance of event endpoint management becomes clear at this point: event sources can be found and used by any user across your teams, and they can be managed simply and uniformly like APIs to securely reuse them across the company.
The ability to describe events in a standardised manner in accordance with the AysncAPI definition is one of the main advantages of event endpoint management. For any Kafka cluster or system that complies with the Apache Kafka protocol, it is simple to create a valid AsyncAPI document thanks to its user-friendly UI.
IBM implementation is expanding the application of AsycnAPI. With the most recent release of their event endpoint management system, client apps can now use the event gateway to publish to an event source. It is now possible for an application developer to create an event source that is added to the catalogue instead of only consuming events. Furthermore, in order to govern the type of data a client can publish to your subject, IBM have included controls like schema enforcement.
IBM provide those more fine-grained approval restrictions in addition to self-service access to these event sources listed in the catalogue. The function of the event gateway controls access to the event sources. It receives requests from applications to access a topic and securely routes traffic between the application and the Kafka cluster.
Open innovation is quickly becoming a key driver of increased revenue and improved company success. Businesses who adopt open innovation saw a 59% greater rate of revenue growth than those that don’t. The IBM Institute of Business Value
AsyncAPI is the industry standard for defining asynchronous APIs, and Event Endpoint Management has accepted and promoted it from its creation.
Following the December release of AsyncAPI version 3, IBM began to enable the creation of v3 AsynchAPI documentation for event endpoint management in a matter of weeks. To further support the most recent version 3 improvements, IBM upgraded the open-source AsyncAPI generator templates as part of their giving back to the community. See how to use the AsyncAPI generator templates with ease in IBM discussion on AsyncAPI v3. IBM’s mission to improve the manageability, usability, and accessibility of asynchronous APIs is still being pursued by IBM, which continues to sponsor and support the AsyncAPI community.
AsyncAPI 3.0.0 Release Notes
The AsyncAPI specification has just released version 3.0.0, which is jam-packed with features! Some increase maintainability, some add features, and yet others clarify things.
IBM have divided the information into easily understood sections in order to make it as clear as possible.
If you would like a summary of:
- With all of the changes made in version 3, you’re in the correct spot!
- A migration guide covering all the significant changes from version 2 to version 3.
Summary
An overview of all the v3 changes is provided in this post.
Decoupling of the operation, channel, and message
Reusing channels was never an option in v2 since it was inextricably linked to application functions.
With the idea that a channel and message should be independent of the actions carried out, this is now feasible in v3. This implies that channels for any message broker, like Kafka, can now just specify topics and the messages they contain. It includes all pathways and associated messages for all request types in the case of REST APIs. It’s all of the messages passing via the WebSocket server in the case of WebSocket. It describes every room and message in Socket.Io.
The channels are now reusable amongst AsyncAPI documents thanks to this modification.
Messages Instead of message
Messages in channels are no longer solitary, as you have likely observed above; instead, with oneOf, messages are defined as key/value pairs in the Messages Object. This was a feature of the request-reply function that made it easy to refer to messages.
Confusion between publish and subscribe
The keywords for the publish and subscribe operations in version 2 have always been unclear. Does this imply that the channel has published my application? Do you mean to post on my behalf? Within this setting, who are you?
IBM attempt to clarify this in v3. All that matters is how your application behaves. No more misunderstandings about who does what or what. IBM accomplish this by introducing two new Operation Object keywords: send and receive. This means that anything can be sent or received by your application.
Naturally, this definition varies slightly depending on the protocol; in the case of generic message brokers, you generate or consume messages, but from an abstract AsyncAPI standpoint, you continue to send and receive messages.
Request/Answer
Request and reply has been a long-awaited feature, and it’s now available!
The publish and subscribe misunderstanding has always been a pain in the neck for this function, making it difficult to come up with a practical solution. But since that’s out of the way, IBM have a solution.
The following use scenarios have been considered in the design of this feature:
- Broker-based messaging that includes “correlationId” and a well defined response topic.
- Broker-based messaging using “correlationId” + “replyTopic” with individual inboxes for each process.
- Broker-based messaging where each individual response has a temporary reply topic.
- WebSocket, where messages are sent via a TCP connection and it lacks subjects.
