The Routing Swiftlet provides unlimited connectivity to other SwiftMQ routers with transparent routing of point-to-point as well as publish/subscribe based messages to remote destinations.
Each SwiftMQ router is a full-fledged JMS server with its own resources (queues, topics, durable subscribers, connection factories, and so on). The Routing Swiftlet is able to connect single SwiftMQ routers together. Due to dynamic routing which doesn't require any configuration (it's automatically), all resources of those connected routers become globally available. For example, a message can be send to "testqueue@router7" from a JMS client connected to router1, a message published to topic "testtopic" from a JMS client connected to router7 will be send to a subscriber on "testtopic" which is connected to router88, and a JMS client is able to lookup a connection factory, registered on router10, from a JMS client connected to router11.
For this construct of connected routers with globally available but locally managed resources we have created the term FEDERATED ROUTER NETWORK. Each router is independent but they work together - federated. SwiftMQ includes federation support since its release 1.0 and it's very mature. In fact, there is no other JMS system in the world which implements it better than SwiftMQ, because it's SwiftMQ's core design.
There is no restriction in the number of routers you can connect nor in the form of the topology you like to build. You don't have to create a hub/spoke like topology with a main router in the middle. You can also build a ring. No matter whether a router is directly or intermediate connected (via other routers) - it is reachable. If a connection gets lost and there is another route to the destination, the message travels that way. If no more route is available, the message stays at the last router and will be forwarded once a route becomes available again.
The following example illustrates a possible router network topology:
The Routing Swiftlet routes the messages destination-based, by finding the shortest way. To balance a load or to increase the message throughput, round-robin scheduling can be selected. In this case, the messages are distributed to all routes of a destination evenly:
For maximum reliability and guaranteed delivery, 2-phase-commit (XA) is used to transfer messages in configurable transaction sizes (bulk) from one router to the other, fast. Recovery of in-doubt XA transactions (prepared but not committed) is automatically done during the connect phase from our transaction manager.