Here's what I'm using in the tross-DISPATCH_179-1 development branch.
Like you suggest, this combines multiple legacy entities into a single
entity. In this case, the new entity type replaces "fixedAddress",
"linkRoutePattern", and "waypoint". Fixed address and link route
pattern will remain supported in the config file for backward
compatibility. It's likely that waypoint will also remain backward
compatible, but I'm not sure yet.
I didn't attempt to provide a meaningful name like "relay" and just
called it "provisioned" as it will the primary entity type for
provisioning the wiring inside the router.
"router.provisioned" {
"description": "Provisioned component within the router: Address
configuration, waypoint, or link-route destination"
"attributes": {
"objectType": {"type": ["address", "linkDestination", "waypoint"]}
"address": {},
"connector": {},
"direction": {},
"semantics": {},
"ingressAddress": {},
"egressAddress": {},
"ingressSemantics": {},
"egressSemantics": {}
}
Affect on waypoint configuration:
The legacy way to configure a simple waypoint is:
waypoint {
address: my_queue
connector: my_broker
inPhase: 0
outPhase: 1
}
fixedAddress {
prefix: my_queue
phase: 0
fanout: single
bias: spread
}
fixedAddress {
prefix: my_queue
phase: 1
fanout: single
bias: spread
}
The new way is:
provisioned {
objectType: waypoint
address: my_queue
connector: my_broker
}
For more advanced options (different semantics for different phases of
the transfer; daisy-chained waypoints; etc.), the other optional
attributes can be used.
-Ted
On 02/23/2016 10:40 AM, Alan Conway wrote:
I have updated my thoughts on waypoint/link-route config, here's a
sketch. I'm proposing to replace waypoint and linkRoutePattern with a
single "relay" entity. I suggested "bridge" before but I like "relay"
better. It is less over-used and I think it is clearer to say we
"relay" messages or links to/from external AMQP entities than to say we
"bridge" them. It is part of a larger address-rewriting scheme I have
in mind but is useful independnetly for improving waypoint
configuration. I'm still not happy I have address-rewriting figured
out, I will post something soon.
"relay" {
"description": "Relay messages to an external entity using
either link or message routes. Replaces waypoint and linkRoutePattern."
"attributes": {
"relayType": {
type: ["link", "message"]
}
# Following have same meaning as linkRoutePattern
"prefix": {...}
"dir": {...}
"connector": {...}
}
}
NOTES:
With "relayType"="link" this is exactly the same as present
linkRoutePattern config.
With "relayType"="bridge" we are using the a 'prefix' for waypoints
just like for link-routes. There's no reason to use different solutions
for each.
I will expand on prefix matching in my address-rewriting proposal to
allow more complex forms of pattern matching (e.g. wildcard, regex) and
substitution to generate replacement addresses. Whatever match/replace
features we implement will apply uniformly to link and message relays
as well as enabling multi-tennant and general purpose network-internal
redirects.
We have lost waypoint phases: There isn't a real use-case for them
phases yet and address-rewriting will provide a better solution. Also
"dir" would be ignored by message-relays for now, but will have meaning
with rewriting to restore the phase functionality.
(Hint: internally waypoint phases *are* simple address rewriting rules.
They effectively add a hidden "phase" prefix to the address. However
that prefix is hidden as "special waypoint magic" and can't be used for
anything else. I propose to make it part of a uniform address-rewriting
mechanism that can be used by any of our routing modes as well as for
multi-tennant and other types internal redirection. When we do that,
the "dir" parameter combined with rewrite rules will give us back
"inPhase" and "outPhase" but in a uniform way that can be used by any
type of routing, not just waypoints.)
The relay config is just a subset of existing linkRoutePattern/waypoint
config, so it will be easy to maintain the old config for backwards
compat for a while. The new address rewriting features would be added
to relay, so users would need to update their config to use them, which
shouldn't be too hard.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
