On 23/02/16 19:56, Gordon Sim wrote:
I like both your and Alan's attempts to simplify/unify the
configuration. I do think 'provisioned' is too opaque a name though.
What about 'route' with types 'simple', 'link' or 'path'?
Or thinking about it a little more:
route: {
type: broadcast | anycast | link | detour | mixed,
address: the address or prefix,
bias: spread | close (not relevant for 'broadcast' routes)
connector: connection details for establishing connection
to external process; specifying this implies that
the router should establish a connection and links
when needed to route messages/links for this
address (multiple connectors can be sepcified),
container: AMQP container-id of external process to which links
should be established as necessary in order to route
links/messages,
ingress_type: broadcast | anycast | link //relevant only for
'detour' and 'mixed' routes
egress_type: broadcast | anycast | link //relevant only for
'detour' and 'mixed' routes
ingress_source: address to which messages entering the
router network are routed;
egress_target: address used for messages which should be
exiting the router network
}
So simple, message routed, direct routes would be e.g.
route: {
type: anycast,
address: foo
}
Meaning messages addressed to 'foo' (whether by the target address of
the link on which they arrived or the to field in the body itself) would
be distributed between links whose source address is also 'foo'.
route: {
type: broadcast,
address: bar
}
Meaning messages addressed to 'bar' (whether by the target address of
the link on which they arrived or the to field in the body itself) would
be forwarded to all links whose source address is also 'bar'.
Link routing would be configured like this:
route: {
type: link,
address: abc
connector: mybroker
}
connector: {
name: mybroker,
host: myhost.acme.com,
port: 5678
}
Meaning any link established with target or source address abc, will be
link routed to the broker identified by 'mybroker', with the router
establishing a connection for the link as needed. An alternative would
be e.g.:
route: {
type: link,
address: abc
container: mybroker
}
Meaning any link established with target or source address abc, will be
link routed over any existing connection whose container-id is
'mybroker'. If no such connection existed, then the 'upstream' link
would be detached.
A simple 'queue' address might be:
route: {
type: detour,
address: myqueue,
connector: mybroker
}
connector: {
name: mybroker,
host: myhost.acme.com,
port: 5678
}
Meaning messages addressed to 'myqueue' (whether by the target address
of the link on which they arrived or the to field in the body itself),
when entering the router network, will be routed to 'myqueue' on
'mybroker', and consumers with 'myqueue' as their source address will be
routed messages from 'myqueue' on 'mybroker'. The router will establish
links to and from the broker, as well as a connection over which these
links are established, as necessary to achieve this.
You could also have simply:
route: {
type: detour,
address: myqueue
}
Messages addressed to 'myqueue' when entering the router network, would
be routed to any link whose source address was myqueue-ingress. Messages
addressed to myqueue-egress would be distributed between links whose
source was myqueue. This would allow for the case where links were
established by the broker.
More control over 'detour' routes could be achieved by specifying some
of the other attributes e.g.:
route: {
type: detour,
address: mytopic,
egress_type: broadcast,
connector: mybroker
}
connector: {
name: mybroker,
host: myhost.acme.com,
port: 5678
}
Which would route all messages addressed to 'myqueue' when entering the
router network to mytopic on mybroker. Messages received from mytopic on
mybroker would however be delivered over all links whose source address
was mytopic.
Or:
route: {
type: detour,
address: myplace,
ingress_source: to_myplace,
egress_target: from_myplace
}
Which would route all messages addressed to 'myplace' when entering the
router network, to any link whose source address was 'to_myplace'.
Messages addressed to 'from_myplace' would be distributed between links
whose source address was 'myplace'.
You could also define 'mixed' routes, e.g.
route: {
type: mixed,
address: my_sharded_queue,
ingress_type: link,
egress_type: anycast,
egress_target: xyz
connector: [broker1, broker2]
}
connector: {
name: broker1,
host: host1.acme.com,
}
connector: {
name: broker2,
host: host2.acme.com,
}
Here, any link established to the router network with target address
'my_sharded_address' would be link routed to one or other of the brokers
defined by the two connectors. Messages addressed to 'xyz' would be
distributed between any links whose source was 'my_sharded_queue' (i.e.
message routed)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]