SwiftMQ is a standalone JMS messaging system and completely implements the publish/subscribe as well as the point-to-point message model of the JMS 1.1 specification.
The SwiftMQ design resembles to a "hub-and-spoke" formulation with central message routers as "hubs" and JMS Clients as "spokes".
The connection between JMS clients and a message router takes place by sockets created by configurable socket factories. Every messagerouter is able to manage any number of JMS listeners on different ports and so e.g. simultaneously provide connections by plain sockets, SSL and HTTP-Tunneling with only one router.
Connections between a JMS Client and a SwiftMQ messagerouter are requested by the client via JMS connection factories. These separate the real physical features of the connection like intra-VM or host/port, SSL, HTTP-Tunneling etc. and avoid that data applying to the topology or the connection need to be defined within the JMS Clients. Connection factories and other entities indicated in JMS terminology as "administered objects" are registered automatically by SwiftMQ in a JNDI repository and are read there by JMS Clients via a logical name (so-called JNDI lookup). Hereby, SwiftMQ does not use third-party products, but puts an own JNDI implementation (based on JNDI 1.2.1) at your disposal which is part of every messagerouter.
SwiftMQ 4.0.0 introduces intra-VM connections where JMS clients are running within the same virtual machine of the router and connecting via a virtual intra-VM connection (without sockets) to the router. It provides JMS application containers where you can configure, start and stop any JMS application within SwiftMQ's virtual machine. It provides hot deploy JMS application containers to hot deploy any JMS application during runtime, without stopping SwiftMQ. This works even with version upgrades of the JMS application!
Transacted queues are the basis of SwiftMQ's point-to-point and publish/subscribe implementation. These are first-in-first-out messagestores, which offers fully transactional (including XA) and concurrent read-write-access with optional SQL92 messageselectors.
Persistent messages are stored in a super-fast, transactional and XA-capable Store Swiftlet with write-ahead-logging and group commit. Access is covered by read/write store transactions, supported by a page-oriented read/write cache. Message and index data are stored in a fast random access file with a 2 KB page size. Synchronization between this database and the transaction log is made during checkpoints. Recovery after system crash is performed by a recovery manager during startup, so the database is always consistent.
SwiftMQ is designed entirely as a federated router network, whereby the router network represents a single router to the JMS client.
Every messagerouter possesses a build-in routing engine to administer any incoming or outgoing routing connection of various configuration.
Routes are exchanged automatically; no complicated configurations are necessary. As soon as a router establishes a connection to another router, all routers are available, the ones which are connected directly as well as all the routers reachable by this router. No direct peering is necessary between the participating routers.
The routing engine 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.
The exchange of messages between routers is made with XA transactions (2-phase-commit) and automatic revovery through the SwiftMQ transaction manager. Due to configurable XA transaction and window sizes, SwiftMQ is able to generate an XA troughput of multiple thousands of message per second on routing connections.
In the case of a router failure and consequently a dropped route, the next best route is chosen. If there is no existing route to a destination, the messages stay at the respective router until a route is activated again (store-and-forward).
Because of these mechanisms, SwiftMQ guarantees a high-grade fail-safety as well as a once-and-only-once message delivery beyond the router networks.
To reduce route announcements, filters may be defined which visualize only parts of a network or particular hops for other routers. Furthermore, it is possible to define static routes which make sure that destinations may be addressed without being currently reachable.
Java I/O is always blocking. Every connection needs a separate thread placed at the connection's input stream to read data. This leads to an extensive thread/OS resource utilization and a performance slow-down due to thread context switching and OS process consumption. Usually, a Java based implementation is able to handle up to approx. 500 concurrent connections with an acceptable performance.
To extend this number to several thousands or tens of thousands, SwiftMQ supports the new nonblocking I/O features of JDK 1.4 through a separate Network NIO Swiftlet.
SwiftMQ supports reliable IP multicast for the publish/subscribe domain. If enabled, multicast of publish/subscribe messages is proceeded between the topic managers of the respective routers. Hence, multicast is an alternative to routing connections and makes SwiftMQ able to build up very large publish/subscribe domains with thousands of clients.
With this feature, subnets may be set up with nearly an unlimited number of routers which exchange pub/sub messages via multicast. Each router serving many JMS clients. There is no need to configure network routers to support multicast, because one SwiftMQ router can be configured as a gateway with a routing connection to another SwiftMQ router, residing in a different subnet. Thus, all multicast messages received within one subnet will be transferred from this gateway via a TCP routing connection to the gateway in another subnet which publishes it as a multicast in that subnet.
JMS clients are connected to their local routers via normal TCP connections and, hence, have full JMS transactional capability including durable subscribers. This is a big advantage over so-called serverless JMS multicast implementations which are not able to provide JMS transactions or durable subscribers.
Publish/subscribe multicast is supported by the Multicast Extension Swiftlet.
SwiftMQ offers you the possibility to have your JMS applications run within a SwiftMQ router. Intra-VM. You can even hot deploy your application. This not only increases the performance, it also makes all reconnect code absolutely superfluous, because SwiftMQ is always "up and running" for your application. And all that without any need for proprietary code. No vendor lock-in!
SwiftMQ integrates a job scheduler to run jobs at a specific time of a day or in repeatable intervals, based on stackable calendars. You can schedule a backup of your message store every day at 11pm or move the content of a queue every 2 hours on business days, except company holidays, to a remote queue on another router. Define a job to start a routing connector at a specific day time for 30 minutes. You can even run your own jobs. SwiftMQ provides an application invoker job that invokes an embedded JMS application on your schedule. This enables you to create schedulable jobs without the need to implement any proprietary interface. It's just a JMS application. Again: No vendor lock-in! Of course, each JMS client can use the Scheduler Swiftlet to schedule messages for delivery in the same manner (e.g. schedule to deliver a message at a specific time, in intervals, etc).
SwiftMQ distinguishes between the following security domains: user, resources and connections.
Every router contains a component by which it authenticates the logins as well as the accesses to resources. Usergroups are defined by this component, the Authentication Swiftlet. Resources like queues and topics with specified grants are assigned to these groups with specified grants (send grant, receive grant etc.). Users are defined by their name and password and are allocated to a group. Thereby, the user receives all the rights of this group. With the login, the password verification is made by means of the Challenge/Response method. So the password is never sent by line. Per user, one host access list may be created that contains the hosts (resp. wildcard pattern) by which he may log in. All users automatically belong to the predefined group "public". So it is much simpler to allocate one right to all users. A user "anonymous" is predefined which matches if no username is given.
The authenticity may be switched on or off as a whole. Latter is useful in a test environment or within secure areas.
Connections are offered by listeners. This listeners exist for JMS and Routing connections. For every listener a host access list can be assigned that determines which remote host is permitted to connect.
A socket factory may be defined for every listener that provides the socket to the connection. SwiftMQ offers SSLv3 connections via Java Secure Socket Extension (JSSE) that are generated by a socket factory "com.swiftmq.net.JSSESocketFactory". This socket factory is included in the distribution.
The SwiftMQ distribution includes the JSSE classes with 128 bit encryption (JSSE version 1.0.2, global version). Recent modifications to the United States export regulations now allows Sun to include stronger cryptographic algorithms in their global version of JSSE.
The JSSE socket factory of this version uses anonymous SSL certificates per default. Apart from the definition of the JSSE socket factory no other configurations are necessary to use SSL. It runs out-of-the-box. The use of self-generated certificates is supported.
The configured socket factory is transmitted transparently to a JMS client via the connection factory. Therefore, on the part of the client, no further settings are necessary (in fact, a client does not know if it uses SSL or not). Concerning routing connections, the same socket factory needs to be set on both sides of the peer.
SwiftMQ supports versioned protocol stacks for JMS, routing, publish/subscribe subscription exchange, and management. Starting with SwiftMQ 4.0.0, it is possible to connect with an older versioned client, router or management tool to a higher versioned router. Therefore, a smooth upgrade to new SwiftMQ releases is possible without the need to shutdown all clients or a whole router network. This feature is unique in the whole JMS world!
SwiftMQ provides 5 ways for configuration and administration:
A graphical administration console with maximum comfort for remote administration, configuration and monitoring of any router in a connected router network.
A command line interface with nearly the same functionality as SwiftMQ Explorer plus scripting capabilities.
router1/sys$queuemanager/queues> new srvinbound cache.size 200
router1/sys$queuemanager/queues> lc srvinbound
Entity: Queue Properties
Description: Properties for each Queue
Properties for this Entity:
Name Current Value
--------------------------------------------------------------
cache.size 200
cleanup.interval -1
Entity contains no Sub-Entities.
router1/sys$queuemanager/queues> lc
Entity List: Queues
Description: Queue definitions
Entities in this List:
----------------------
srvinbound
testqueue
timeQueue
router1/sys$queuemanager/queues>_
A simple but very powerful administration API based on CLI to administer whole router networks from Java programs.
cli.waitForRouter("router1");
try {
cli.executeCommand("sr router1");
cli.executeCommand("cc /sys$queuemanager/queues");
cli.executeCommand("new mynewqueue cache.size 1000");
cli.executeCommand("save");
} catch (CLIException e)
{
processError(e);
}
SwiftMQ wraps its internal management tree with JMX MBeans so you can use your favorite JMX administration tool to administer a SwiftMQ Router.
A simple XML file for each router, containing the router configuration.
<swiftlet name="sys$queuemanager" collect-interval="1000">
<queues>
<queue name="BuyQueue"/>
<queue name="SellQueue"/>
<queue name="mailout"/>
<queue name="testqueue" cleanup-interval="1000" persistence-mode="non_persistent"/>
</queues>
</swiftlet>
It's up to the administrator which way he will use. SwiftMQ Explorer, CLI, and the JMX MBeans save their configuration in the router's XML configuration file.
SwiftMQ is based on a microkernel architecture. The main controller of this kernel is called Swiftlet Manager. Components of SwiftMQ are called Swiftlets(TM).
The Swiftlet Manager knows a group of Swiftlets which are building the kernel. The Kernel Swiftlets are building the base functionality of a SwiftMQ router.
Extension Swiftlets are providing optional functionality for hot plug-in into a router. These Extension Swiftlets are released separately. They can be hot deployed without stopping a router.
