FioranoMQ provides the following features to solve the above problems:
Automatic Failover Protection
Failure of a component should not cause failure of the whole system. The backup of important components is required to provide high availability. There should be no single point of failure. FioranoMQ's runtime invocation ensures that clients connected to a server are automatically 'failed over' to the back-up server. When an application wants to connect to a particular server, N attempts are made to connect to that server. If a connection still fails, the runtime library tries the URL of backup servers specified in the connection factory used to open the connection. Since this operation is performed automatically by Fiorano's runtime library, the application does not fetch the list of backup URLs. This avoids any vendor lock-in as the application code is based on pure JMS.
Transparency and Code Portability
The automatic failover protection mechanism should be completely transparent to the client. FioranoMQ provides this transparency by making the reconnection mechanism invisible to the client. The reconnection is done automatically by the runtime library. This is achieved via server configuration and does not require the use of any proprietary APIs making the client code completely portable across JMS server implementations.
Configurability
FioranoMQ achieves a high degree of configurability through its modular design. Interfaces for a number of modules are available to the public, which allow a developer to implement their own version of the module and plug it in. For example, a developer is free to write a Log Module that displays information in a Java Frame instead of the java console and plug it in. Besides these modules, a number of configurable flags are provided to the developer through the server's config file, which allows a developer to tweak various parameters of the server. For example, FioranoMQ provides a configurable option for the maximum number of clients waiting to connect to the server. The default number is 500. This figure can be increased or decreased through the server's configuration file. Note that the numbers specified represents the length of the queue of pending sockets and has no relationship with the maximum number of simultaneous clients that FioranoMQ can support.
Admin System
Availability of the system holding the administered objects (admin system) must be provided in the first place. The admin system should be different from the client systems and it should be backed up by a secondary source. Client access to primary or backup admin system should be transparent. FioranoMQ allows the administrator to configure the admin system storage as and when required.
The administrator can choose the storage media of administered objects from the following options:
- JNDI compliant Directory Server
- RDBMS Server
- XML File
- Fiorano's proprietary file format (that also uses JNDI)
Despite these options, a developer is free to write his/her own customized version of admin system. Storing the admin objects in a central Directory Server allows a client to directly lookup these objects through JNDI. The client need not go through the FioranoMQ server (though it is possible to do so). This makes the admin system independent of the server.
Connection if the Server is lost
FioranoMQ provides a client with the ability to automatically connect to a failover or backup FioranoMQ server. This mechanism works if the client's existing connection is broken or if the client's primary server is unavailable at the time of creating a connection.
This mechanism is transparent to the client application. In case an existing connection breaks and there is no backup URL specified, the client application can continue its routine operations of pushing more messages. These messages are stored in a local repository on the client machine. Meanwhile, the runtime library automatically tries to re-connect back to the server in the background, periodically. Once the connection has been established, the runtime system automatically transfers all the messages stored in the local repository to the server. This provides the client application with the 'store and forward' facility for a publisher in those situations when the connection to the server is temporarily broken. More importantly, this does not require the use of any proprietary APIs and hence avoids vendor lock-in of any kind.
Server Runs Out of Resources
FioranoMQ's dispatcher is the load-balancing component within the Fiorano Server. The dispatcher can be enabled or disabled easily through the server's configuration file. If enabled, the server distributes incoming connections to members of its clusters. Again, this does not require special APIs for the client application. The application only sees the dispatcher-enabled server. The dispatcher administrator is free to add/remove members in the dispatcher cluster any time. If a member server in the cluster goes down for to any reason, all the applications connected to this server shift to one of the other members in the cluster. FioranoMQ also provides fail-over for the dispatcher server, which means that users can setup a secondary dispatcher that is used in cases where the dispatcher server goes down. The client system can have the URL of the secondary dispatcher as its backup URL. When the primary dispatcher goes down the client system gets automatically load-balanced by the secondary dispatcher.
An important requirement for running FioranoMQ Servers in a cluster is that TopicConnectionFactories (TCF), Topics, QueueConnectionFactories (QCF), Queues and UnifiedConnectionFactories (CF) should exist on all servers running in the clustered environment and on the server acting as a dispatcher. These components are used by the clients to make connections to the least loaded FioranoMQ server through the dispatcher. The TCFs, QCFs and CFs replication amongst servers is required to make the new connections to the server. The Topic and Queue replication is required for automatic failover support for clients. If the client connection to any of the servers in the cluster goes down, the client gets connected to another server running on the cluster.
Server's Connection if a Client is Lost
If a connection with a consumer gets broken and if the consumer is durable, the server continues to store messages for the consumer published by the producer. These messages are made available to the consumer next time it logs into the system. Fiorano's runtime library also pings the connections to the server periodically (with a configurable time difference between two pings), which allows the server to detect dead sockets and clean them up. This becomes a lifesaver in case of network failure, which is not detected by the JVM unless a write operation is performed on it, which is usually not the case.
Server-to-Server Communication
It is a common requirement of real world applications to allow clients to exchange information seamlessly across servers. The Repeater and Bridge components of FioranoMQ are used for server-to-server communication over topics and queues respectively. Apart from FioranoMQ to FioranoMQ server communication, bridges are available for other messaging servers including IBM WebsphereMQ, MSMQ, and Tibco Rendezvous.
Scalability
The load balancing and failover protection architecture of FioranoMQ Server allow unlimited scalability in terms of the number of client applications that can concurrently access JMS services. Thousands of concurrent client connections can be supported by a single cluster of servers. Combined with server-to-server communication, the Fiorano clustering architecture provides a very robust solution for a vast set of customer problems. For handling thousands of concurrent client connections, FioranoMQ also provides scalable connection management.