Add support for message exchange patterns such as request-reply

[GeraldLoeffler]

Currently, AsyncAPI models individual message types exchanged via operations with channels. There is no way to formally bind different messages together (other than by adding human-readable documentation to the messages).

For example, currently this common message exchange pattern cannot be expressed in AsyncAPI documents:

• A client application sends request messages with a unique message ID to channel 1
• and expects response messages with a correlation ID equal to the request message ID on another channel 2

Or this variation thereof:

• A client application sends request messages with a unique message ID and a reply channel to channel 1
• and expects response messages with a correlation ID equal to the request message ID on that reply channel

In these examples, in an AsyncAPI document, the relationship between request and reply messages and their header/payload values for message ID, correlation ID, and reply channel cannot be expressed.

This RFC is about adding support for higher-level message exchange patterns of this kind to AsyncAPI. See also https://www.enterpriseintegrationpatterns.com/patterns/conversation/BasicIntro.html

[derberg]

might be related with https://github.com/asyncapi/spec/issues/94

[crussell52]

Most of the async work I do is request-response. Is there anything community members like me can do to help advance this?

[derberg]

@crussell52 definitely, have a look at the contribution guide that explains the spec contribution stages. Also, look at the related issue that I linked before, where few people already shared possible solutions. Definitely feel free to suggest solutions with proper examples.

[olamiral]

@GeraldLoeffler Could you please take a look at my comment? I'd like to hear from you and see how we can evolve the proposed model in order to support your requirements. Thank you!

[jonaslagoni]

Is there any of you who wants to champion this? 🙂 Or can we consider this issue as needs champion? 🤔

[Hassen-BENNOUR]

Hi folks, Unfortunately it seems to need many time to find the right solution.

We have many amqp request reply communication between services as many people today. We do it with spring integration and spring cloud stream. Without support of request reply i think there is no reason or possibility to use asyncapi now 😔

Keep in touch and hope a support for this soon.

So thank you for your amazing stuff.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[jfallows]

@GeraldLoeffler Could you please take a look at my comment? I'd like to hear from you and see how we can evolve the proposed model in order to support your requirements. Thank you!

@olamiral did you get any response perhaps in another forum about your question and feedback?

[olamiral-mulesoft]

@jfallows Not yet. I saw there were some discussions around the spec in issue #520, but I'm not sure if we could come to a conclusion about it yet.

Regarding how messages / events could be tracked and related to each other, one option would be defining a message as an entity composed by:

• a section for tracking / correlation: list of fields that will be used to track the message. Correlation can be made at several contexts:
  • request context: would primarily be used to correlate replies and events to the corresponding request
  • transaction context: correlate a set of operations required to fulfill a request / transaction
  • session context: correlate a set of transactions that can be executed in a given session.
• a section for metadata / headers: list of fields containing metadata (except tracking / correlation information). Technically, correlation identifiers could go in the headers section of the message, but it's important to make a clear distinction between tracking metadata and other metadata at least at the spec level because it explicitly states which fields should be used for message tracking / correlation)
• a section for message body / payload: business data used in operations requests / replies or to describe events.

@GeraldLoeffler has a very good point, and the spec should take this into account (for standardization and documentation at spec level, avoiding relying on human readable docs only).

[derberg]

For request/reply I definitely encourage you to join https://github.com/asyncapi/spec/issues/94

For now @GreenRover decided to champion that and get it into the spec. Work is done as part of AsyncAPI 3.0 work so the official PR with proposal could not be opened as some fundamental changes in the spec were missing yet. Also holidays usually slow down any work.

Some discussion also happened on public meetings, first 3 from the list -> https://www.youtube.com/c/AsyncAPI/search?query=request%2Freply

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[jonaslagoni]

Can someone close this issue as complete?

[derberg]

closing as already done details https://eventstack.tech/posts/asyncapi-v3-request-reply will be released with v3 soon