Let’s talk about API specifications and model driven engineering. Central pillar is a domain model which describes the problem space in an abstract and logical manner. One central organization around “model driven” is the OMG, found i.e. the UML diagrams. UML diagrams distinguish between structural -and behavioural diagrams.
- Structural
- class diagram
- object diagram
- component diagram
- deployment diagram
- etc.
- Behavioral
- activity diagram
- state diagram
- timing diagram
- etc.
As soon it comes to interactions e.g.,, between components the integration can be (even more implementation specific) broken down according to the following criteria:
- Interaction parity (one-to-many, one-to-one, many-to-many)
- Interaction schema (synchronous, asynchronous)
- Interaction direction (one-way, two-way)
First kid on the street was OpenAPI (often known as under a specific application called “Swagger”). OpenAPI deals with
- one-to-one,
- primarily synchronous and
- two-way communication.
Since the introduction of web-sockets (two-way communication) and web-hooks (one-way communication) it also plays in the field of asynchronous interaction.
Web-sockets are duplex, this mean we do have a channel where both (well defined) parties can read and write in parallel to each other, but it is not publish and subscribe.
In comparison Web-hooks use request-response communication with usual HTTP GET and POST methods, but it is not polling. Polling is used to recurrently query a peer for new information. This is called a pull communication model, because the information is pulled. Web-hooks is a push communication model (e.g., like E-Mail). The information is delivered only if available.
Due to the scope of OpenAPI we have to introduce two additional integration criteria:
- Interaction behavior (pull, push)
- Interaction channeling (simplex, duplex)
In comparison to OpenAPI, the AsyncAPI specification takes care of
- one-to-many,
- asynchronous and
- one-way (maybe two-way) communication.
Those approaches are often called a message-driven- or even event-driven approach. From Interaction behavior this commonly follows a push principle and “logically” has a single channel (simplex).
When we compare OpenAPI and AsyncAPI peers are integrated via an kind of commonly agreed address-schema:
- OpenAPI via the URI path the provider offers and the call has to match
- AsyncAPI via the channel naming the peers agreed on (more or less formal) the exchanged message(s). Channel are equal to what is called “topic”.
Out of the required agreement between interacting peers the degree of coupling is often used equivalently. AsyncAPI is perceived as loosely coupled and OpenAPI as tightly coupled, but in all cases the host and ip address of the communication peer must be known – the broker thing!
But one kid in the block is usually missed out. What if the host and ip address of the peer is not mandatory known per interaction? Sure in such a case we often talk about broadcasts, the middle unreliable UDP stuff. Sorry, this is not generally true, because DDS bounds all these dressing topics to the so called “domain” definition. For example compare the Cyclone DDS options: https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/docs/manual/options.md
Let us have a look on OMGs DDS protocol. ell we could describe it via AsyncAPI, but it not fits with everything what is attached to the channel. Sure software components (AsyncAPI application and operations) at the end will handle the given messages, but DDS more focus on the payload/ message agreement. The topic is a local game of what the SDK require to make the internally given cache (also called “Global Data Space”, short GDS) accessible. Due to that,DDS has an own DSL (also called “interface definition language”, short IDL).
Lets have a look on the AsyncAPI “Hello World” example, as given here: https://www.asyncapi.com/docs/tutorials/getting-started/hello-world
Here the channel is “hello”. The ability to “publish” to the “Hello world application” is comparable with a DDS “writer” definition. If we just leave out the “server” section empty (lets ignore the warning) and it’s useable also for broker-less interaction.