{"id":7292,"date":"2021-12-15T08:10:47","date_gmt":"2021-12-15T08:10:47","guid":{"rendered":"https:\/\/modeling-languages.com\/?p=7292"},"modified":"2021-12-15T10:31:49","modified_gmt":"2021-12-15T10:31:49","slug":"asyncapi-modeling-editor-code-generator","status":"publish","type":"post","link":"https:\/\/modeling-languages.com\/asyncapi-modeling-editor-code-generator\/","title":{"rendered":"A Modeling Editor and Code Generator for message-driven architectures with AsyncAPI"},"content":{"rendered":"

IIoT (Industrial IoT) architectures are typically distributed and asynchronous, with communication being event-driven, such as the publication (and corresponding subscription) of messages.\u00a0These asynchronous architectures enhance scalability and tolerance to changes, but raise interoperability issues as the explicit knowledge of the internal structure of the messages and their categorization (topics) is diluted<\/strong> among the elements of the architecture.<\/p>\n

In fact, this was also a problem for REST APIs, until the industry came together and proposed a standard way to define the structure and schema of synchronous APIs: OpenAPI<\/a> (derived from Swagger<\/a>). For asynchronous architectures, and inspired by OpenAPI, the AsyncAPI<\/a> appeared to solve this problem:<\/p>\n

AsyncAPI provides a specification that allows you to define Message-Driven APIs in a machine-readable format. It’s protocol-agnostic, so you can use it for APIs that work over Kafka, MQTT, AMQP, WebSockets, STOMP, etc. The spec is very similar to OpenAPI\/Swagger so, if you’re familiar with it, AsyncAPI should be easy for you.<\/em><\/p><\/blockquote>\n

In AsyncAPI, the specifications of an API can be defined in YAML or JSON, which allows specifying, for example, the message brokers, the topics of interest, or the different message formats associated with each one of the topics, among other aspects. AsyncAPI is, however, in the early stages of development, and the AsyncAPI tool market is underdeveloped<\/strong>, mainly limited to the generation of documentation to be consumed by humans.<\/p>\n

Similarly to what we’ve done for OpenAPI (see our API Composer<\/a> or our API Discoverer<\/a>), we believe a model-based approach would facilitate the modeling of AsyncAPI specifications and the development of Message-Driven APIs from them.\u00a0<\/strong><\/p>\n

Our initial contribution was the approach presented in the featured image above. This work is presented in the video below where Abel <\/a>presents our work as part of our participation in the 1st AsyncAPI conference<\/a> and the Models’20 conference<\/a>. The title of the Models paper is A model-based approach for developing event-driven architectures with AsyncAPI<\/em><\/a> and provides additional details and motivation around our application of model-driven engineering techniques to the world of event-driven architectures and, in particular, to AsyncAPI.<\/p>\n