Introduction to SwiftMQ

 
 

Online Documentation    Introduction to SwiftMQ

 
 

[Overview]     [Persistence Mechanism]     [Federated Router Network]     [Security]     [Administration & Monitoring]     [Software Architecture]    
[Document Index]

 
     
 
  Overview

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.0.2 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 host, port, compression, 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.

Persistence Mechanism

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 and concurrent read-write-access with optional SQL92 messageselectors.

Because of the transaction functionality already implemented in the transacted queues, SwiftMQ does not need a database system to store persistent messages and does not need any third-party products either, because it uses the much more efficient filesystem as persistent messagestore .

Every persistent message is saved in a file by means of a highly optimized serialization protocol, whereby the messagekey is coded in the file name. After starting a queue this reconstructs itself with just the file names and only needs access to the original message when it is read. So, the separate storage of a mostly multilevel message index and the latent danger of inconsistency concerning a system crash is completely eliminated.

Federated Router Network

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 transaction oriented. So, 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.

Security

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 AuthenticationSwiftlet. 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. 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 will be supported in future versions.

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.

Administration & Monitoring

SwiftMQ provides 4 ways for configuration and administration:

SwiftMQ Explorer

A graphical administration console with maximum comfort for remote administration, configuration and monitoring of any router in a connected router network.



CLI

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>_

Programmatic administration via CLI Admin API

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);
 }

Property Configuration File

A simple property file for each router, containing the router configuration.


 swiftlet.sys$queuemanager.backstore.directory=../../store/router1/
 swiftlet.sys$queuemanager.queues.names=testqueue,timeQueue
 swiftlet.sys$queuemanager.queues.testqueue.cache.size=100
 swiftlet.sys$queuemanager.queues.testqueue.cleanup.interval=-1
 swiftlet.sys$queuemanager.queues.timeQueue.cache.size=100
 swiftlet.sys$queuemanager.queues.timeQueue.cleanup.interval=120000

It's up to the administrator which way he will use. Both, the SwiftMQ Explorer and CLI, save their configuration in the router's property file.

Software Architecture

The base of SwiftMQ is a component framework called Swiftlet Framework that is completely abstract and independent of a message server implementation. The framework is controlled by a SwiftletManager and contains a number of Swiftlets.

The SwiftletManager knows a group of Swiftlets that 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.



Kernel Swiftlets are:

TraceSwiftlet

The TraceSwiftlet provides a central trace facility for all Swiftlets and the SwiftletManager. All kernel Swiftlets are tracing in so called trace spaces. The trace spaces can be configured to filter the trace stream by SQL-Like predicates and so distribute the output to specified locations (trace files, console).

LogSwiftlet

The LogSwiftlet provides a central facility for logging information-, warning-, and error-messages into log files.

TimerSwiftlet

The TimerSwiftlet provides a central facility for registering and re-using timers.

ThreadpoolSwiftlet

The ThreadpoolSwiftlet is a central point of control for thread resources. It provides configurable threadpools to which every SwiftMQ thread is dispatched.

QueueManagerSwiftlet

The QueueManagerSwiftlet provides transacted message queues with persistent message stores. It works as a factory for queue sender, receiver and browser, and creates and deletes temporary queues.

RoutingSwiftlet

The RoutingSwiftlet provides server-to-server-connections, automatic route exchange, failover handling, round robin scheduling.

TopicManagerSwiftlet

The TopicManagerSwiftlet provides location independent, network federated topic management with a hierarchical addressing scheme and automatic exchange of local subscriptions with other TopicManagers on remote routers.

AuthenticationSwiftlet

The AuthenticationSwiftlet provides a central authentication facility with user/group/resource authentication.

JNDISwiftlet

The JNDISwiftlet provides a router-local but network federated registry for administered JMS objects, JNDI object aliases, delivers administered objects on lookups and binds/rebinds/unbinds such objects on JNDI requests.

JMSSwiftlet

The JMSSwiftlet provides a JMS 1.0.2 compatible message server.

MgmtSwiftlet

The MgmtSwiftlet provides a remote administration server for SwiftMQ Explorer and CLI.

Extension Swiftlets:

JMS Bridge Extension Swiftlet

Provides a bridge from a SwiftMQ router to every JMS 1.0.2 compliant system such as Weblogic JMS or MQSeries JMS. The bridge is able to bridge queues to queues, topics to topics, queues to topics and topics to queues.

Mailer Extension Swiftlet

Swiftlet to send eMails via SMTP. It listens on a queue, receives requests and send them as eMail via a configured SMTP server. Once installed on a SwiftMQ router in a network, it enables every JMS client to send eMails via JMS.

Futher Extension Swiftlets are scheduled.

 
 
     
 

[Overview]     [Persistence Mechanism]     [Federated Router Network]     [Security]     [Administration & Monitoring]     [Software Architecture]    
[Document Index]

 
 

Online Documentation    Introduction to SwiftMQ

 
 

 Copyright © 2000, IIT GmbH, Bremen/Germany. All rights reserved.
SwiftMQ and Swiftlet are registered trademarks of IIT GmbH.
All other product names mentioned herein are trademarks of their respective owners.