Minor update attached - I included Gordon's point about indirect routes
being able to use a listener to accept an incoming broker connection as
well as a connector to make an outgoing one, the new part:
----
Indirect routes can use incoming connections from the external
application by specifying a `listener` instead of a `connector` and an
AMQP `container` name to identify the external application.
indirectRoute {
address: my_queue # TODO address patterns.
listener: secure_broker_listener
container: "mybroker-container-id"
mode="message"
}
----
Here's the full thing:
===========
Terminology
===========
AMQP messages are sent on *links*. A link that sends messages from an
application to a dispatch router is a *sender*. A link that receives
messages for an application from a dispatch router is a *receiver*.
Dispatch router configuration defines *routes*. A route has an
*address*. Addresses can be AMQP address strings or patterns (TODO)
Incoming client links (senders or receivers) are attached to the route
with a matching address. If a sender link has no address, messages are
routed individually using the *to* address. Receiver links with no
address are not allowed.
There are several types of route:
A *directRoute* accepts sender and receiver links and forwards messages
from senders to receivers. This allows clients to communicate directly
without the need for a broker.
Example: direct route "foo" with fanout (replaces fixedAddress)
"directRoute": { "address": "foo", "fanout": "multiple" }
An *indirectRoute* creates links to an external application (such as a
broker) and forwards messages from senders to the application, and
messages from the application to receivers. There are two modes:
- message routing: the route creates its own links to the external
application, there is no relationship with the sender/receiver links.
- link routing: the route creates external links that correspond
exactly with sender/receiver links. It forwards all link information
(name, flow control, properties etc.) to the external application.
Link routing preserves more AMQP context between the client and the
external application. Message routing offers more flexibility to modify
the message flow e.g. to load balance messages over multiple brokers.
An indirectRoute can initiate a connection to the external application
or accept an incoming connection from it.
Example: broker integration with link routing (replaces
linkRoutePattern)
indirectRoute {
address: my_queue # TODO address patterns.
connector: my_broker
mode="link"
}
Example: broker integration with message routing (replaces simple
waypoint)
indirectRoute {
address: my_queue # TODO address patterns.
connector: my_broker
mode="message"
}
Indirect routes can use incoming connections from the external
application by specifying a `listener` instead of a `connector` and an
AMQP `container` name to identify the external application.
indirectRoute {
address: my_queue # TODO address patterns.
listener: secure_broker_listener
container: "mybroker-container-id"
mode="message"
}
For more complex cases routes can create links to other routes. Routes
always allow internal links, but a route can be configured to allow
only senders, receivers, both or none from outside. An external link is
attached to the route that has the right its address *and* allows that
link type. A route with `"allow": "none"` is an internal routing detail
and cannot be accessed directly by clients.
Example: waypoint chaining
# Route for messages sent to my_queue, forward to broker1
indirectRoute {
address: my_queue
allow: sender
connector: broker1
mode: message
}
# Internal route for messages coming back from broker1, forward to
broker2
indirectRoute {
address: my_queue
allow: none # internal only
connector: broker1
internalSender: ["broker2"] # send to broker2
mode: message
}
# Route messages through broker2 and then back to receivers.
indirectRoute {
internalAddress: "broker2"
connector: broker2
allow: receiver
mode: message
}
Example: message-routing with load balancing over two brokers.
# Route for senders to my_queue.
directRoute {
address: my_queue
allow: sender
internalSenders: ["broker1_my_queue", "broker2_my_queue"]
fanout: multiple
}
# Route for receivers from my_queue.
directRoute {
address: my_queue
allow: receiver
internalReceivers: ["broker1_my_queue", "broker2_my_queue"]
}
# Internal route to broker1
indirectRoute {
internalAddress: broker1_my_queue
allow: none
connector: broker1
}
# Internal route to broker2
indirectRoute {
internalAddress: broker2_my_queue
allow: none
connector: broker2
}
TODO:
- indirect route with multiple listeners/connectors with/without
container name giving multiple choices of external apps. Policy
controol: link routes can't fan-out but they can load balance.
- mix link & message routes: "tap" messages from a link route and
message route them.
- pattern matching
- internal address rewriting?
- multi-tennant
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
