Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for message exchange patterns such as request-reply #558

Closed
GeraldLoeffler opened this issue Jun 11, 2021 · 13 comments
Closed
Labels
💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md)

Comments

@GeraldLoeffler
Copy link
Contributor

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
Copy link
Member

derberg commented Jun 14, 2021

might be related with #94

@crussell52
Copy link

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

@derberg
Copy link
Member

derberg commented Jul 26, 2021

@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
Copy link

olamiral commented Nov 22, 2021

@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
Copy link
Member

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

@Hassen-BENNOUR
Copy link

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
Copy link

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

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 ❤️

@github-actions github-actions bot added the stale label May 24, 2022
@github-actions github-actions bot removed the stale label Jul 29, 2022
@jfallows
Copy link

jfallows commented Sep 1, 2022

@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
Copy link

olamiral-mulesoft commented Sep 6, 2022

@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
Copy link
Member

derberg commented Sep 6, 2022

For request/reply I definitely encourage you to join #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
Copy link

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

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 ❤️

@github-actions github-actions bot added the stale label May 20, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 17, 2023
@jonaslagoni
Copy link
Member

Can someone close this issue as complete?

@derberg derberg reopened this Nov 14, 2023
@derberg derberg removed the stale label Nov 14, 2023
@derberg
Copy link
Member

derberg commented Nov 14, 2023

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

@derberg derberg closed this as completed Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md)
Projects
None yet
Development

No branches or pull requests

9 participants