Given a channel name, how do you know which broker (server) should be used?

[treeder]

Some things to consider:

• Multiple servers could have the same channel name - I subscribe to "orders" channel on server A and publish to "orders" on server B
• The websocket example from Create WebSocket example #253 , you the message has to pass the channel name along in the message, but which broker/server should it go to?
• A message provides a channel to reply (request/reply), again, which broker?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jmaister]

Same issue here.

The "channels" section has already a "channel.operation.bindings" field, which does not apply for this problem.

As I have to make the code work, for the moment I added a non-official property called "channel.operation.binder" to the channel to point to the ID of the server.

asyncapi: '2.0.0'
...

servers:
  nats1:
    url: nats://10.10.10.10:4222
    description: Primary NATS server
    protocol: nats
  kafka1:
    url: 10.10.10.10:9092
    description: Primary Kafka server
    protocol: kafka

channels:
  multi_convert_request:
    subscribe:
      binder: nats1
      message:
        ...

  multi_convert_response:
    publish:
      binder: kafka1
      message:
        ...

[fmvilas]

Yeah, we'll work it out in future versions. In the meantime, make sure you use compatible property names so your AsyncAPI document is still valid. You can just rename your binder property to x-binder and everything should be fine.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[rvowles]

yay this is being added, we just had a question about this in our team

[GeraldLoeffler]

Another use case are all kinds of "protocol adapter" apps, i.e., apps that read from server S1 using protocol P1 and forward messages to server S2 using protocol P2.

For example: Imagine an app that receives messages from an IBM MQ server and sends them to an MQTT server: it has a channel with a publish operation that must be linked to the IBM MQ server, and another channel with a subscribe operation that must be linked to the MQTT server. This should be expressed in one AsyncAPI document. Because if it were split into two separate AsyncAPI documents (one with IBM MQ as the server, the other with MQTT as the server) then the fact that the app essentially just routes incoming IBM MQ messages to an MQTT server is lost.

[smoya]

The concept behind #244 shows a more distributed-systems-oriented approach where servers can be grouped (e.g. clusters). Then Operations would just specify in which group(s) or cluster(s) can be found.

[derberg]

This is now supported by 2.2 release of the spec 🥳