Introduction

The explosion of the Internet and the rapid proliferation of computer networks have created the need for a comprehensive software platform that specifically addresses the requirements of event-based network-centric applications. FioranoMQ is a software platform, developed to meet these requirements.

Today’s enterprise networks typically deploy hundreds of applications from different vendors. There is little standardization of communication protocols between individual distributed systems and exchanging information between applications from different vendors is surprisingly difficult. The lack of a standard platform for network-centric computing increases the cost and complexity of developing and deploying distributed systems. FioranoMQ was designed to alleviate these and other problems.

FioranoMQ has been designed over JMS (Java Message Service) standard. JMS provides a common technique for Java programs to create, send, receive and read messages in an enterprise messaging system.

Enterprise messaging products (sometimes called, Message Oriented Middleware products) are becoming an essential component for integrating intracompany operations. They allow separate business components to be combined into a reliable, yet flexible system. In addition to the traditional Message Oriented Middleware (MOM) vendors, enterprise messaging products are provided by several database vendors and a number of Internet related companies. Java language clients and Java language middle tier services must be capable of using these messaging systems. JMS provides a common technique for Java language programs to access these systems.

JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product. A JMS provider is an entity that implements the JMS specifications and the APIs for providing an enterprise messaging solution. FioranoMQ is such a JMS provider that has support for all the JMS specifications. In addition, it provides numerous proprietary features such as scalable connection management, file based data store and load balancing that make it one of the fastest, most scalable JMS servers currently available.

The JMS messaging model consists of two basic domains PTP (point-to-point) and Pubsub (publish/subscribe).

Point-to-point (PTP) products are built around the concept of message queues. Each message is addressed to a specific queue; clients extract messages from the queue(s) established to hold their messages. Publish and subscribe (Pub/Sub) clients address messages to some node in a content hierarchy. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from the multiple publishers of a node to its multiple subscribers.

FioranoMQ implements both the messaging domains and also the unified domain concept that has been introduced in JMS 1.1.

JMS Communication Models

Traditional communication models involve demand driven request/reply “polling” to access information, which is then transferred over a point-to-point topology. This section discusses how JMS combines the benefits provided by traditional models with event-based publish/subscribe “push” technology, offering real time transmission of business events.

Publish/Subscribe Interactions

Publish/Subscribe interactions, illustrated in Figure 1, are event driven rather than demand driven. In this paradigm, producers (also called publishers) send data to one or more consumers (also called subscribers) over the network. Publish/subscribe interactions are driven by events (usually the creation or arrival of data) in a producer. When an event occurs, messages containing event data are published to Topics. Consumers place a standing request for the data by subscribing to Topics and installing message listeners (callback functions), which allow them to filter the exact set of data to be delivered to the application. Through this process, producers are completely decoupled from consumers and they do not coordinate data transmission with each other.

Example applications that use publish/subscribe interactions include:

Benefits of Publish/Subscribe

Distributed systems based on the publish/subscribe paradigm are very easy to change and modify because event dependencies are resolved through runtime event names, rather than by compilers, linkers or operating systems. Publishers and subscribers of JMS messages operate independently of and asynchronously from each other; and may change without recompilation. All communication between applications occur through messages that are routed through the FioranoMQ server, which implements the JMS API. This allows new JMS applications to be added to the distributed system later without recompiling, relinking or even stopping and restarting any existing applications.

Publish/Subscribe greatly reduces complexity in distributed system design and implementation. Events are published to channels as they happen; business processes that depend on these events automatically receive them as they occur. Key advantages of publish/subscribe include:

Publish/Subscribe Implementation in FioranoMQ

FioranoMQ coordinates all communication between publishing and subscribing applications by using a set of shared Topics as keys to distributing messages. Client applications, both publishers and subscribers, connect to the server to send and receive messages. For each topic, the client may act as a publisher, subscriber, or both.

The process of publishing involves sending messages to the JMS server. Whenever a JMS client wants to send a message to other clients, it simply publishes the information as a message to the server. There may be many publishers on a given Topic.

The process of subscription involves notifying the JMS server of a client application’s interest in one or more Topics. The subscription must occur before a message on that topic gets published, in order for the client to receive that message. A subscriber can subscribe to one or more topics; a topic may have many subscribers. A subscribing client executes callback functions (called MessageListeners in JMS) to filter messages and process the ones of interest.

Advantages of Topic based Addressing

Topic-based addressing eases the development and deployment of distributed systems. Any application can send messages to any other application over the network in a location independent manner. Senders and receivers can be anywhere on the network. Application components can be moved from one machine to another without causing any disruption in functionality. Server applications can migrate or replicate (to share heavy loads, for example) without disrupting the existing clients. Topic-based addressing allows you to build distributed systems that adapt easily to change and growth.

Request/ Reply Interactions

Traditional client/server applications fall under this category. A request/reply interaction consists of two point-to-point messages: a request and a reply. For example, a client requests data from a given server, which generates or computes an individual response and sends it back to the client. Communication is bidirectional. Examples of request/reply interactions include:

In a request/reply interaction, producers and consumers of data interact closely, as shown in Figure 2. A client sends a request to a server; the server receives the request, processes it, and sends back a reply only to the client that made the request. The requesting client waits until it receives a reply, and then continues processing. Requesting clients can listen in either blocking or non blocking mode.

Request/ Reply Implementation in FioranoMQ

In traditional implementations, request/reply is based on polling, which requires an application or process to request event information at regular intervals. A poll requests information from a database, which either returns the requested information or a message indicating that the information is unavailable. As long as the application runs, it will continuously issue demands for information.

In FioranoMQ, request/reply is based on the publish/subscribe engine. When a client application publishes a request message on a subject, multiple subscribers registered to that subject may reply. This is unlike a poll based request, which typically specifies a single information source. Most messages in the FioranoMQ system use a Topic for routing, but reply messages do not have a topic. The server routes these directly to the requestor. The publishing client application accepts the first reply to the request; all other responses are ignored.

Key Features of FioranoMQ

FioranoMQ offers a unique set of advantages to the developers. Besides reducing the development time for applications, FioranoMQ imparts significant network functionality to applications, ultimately benefiting the end users. The following section describes the key features of FioranoMQ:

Internet Ready

FioranoMQ software is implemented in 100% pure Java, both on the server and client (i.e. runtime library) sides. Leveraging Java on the server side offers cross platform application support, and, in the case of downloaded applets, removes the need to preprovision client nodes with the application code. This greatly reduces client administration and overhead, while increasing application accessibility across enterprise Intranets and the Internet.

In addition to the 100% pure Java implementation of the default connection manager, FioranoMQ software incorporates a special Scalable Connection Management (SCM) module. This allows a single FioranoMQ server to support several thousand concurrent client connections on a variety of operating platforms (including Windows NT, Solaris and other Unix platforms). FioranoMQ allows the user to choose between the default Java connection management and Scalable Connection Management, as described in detail below.

event-based Communication System

To more closely model how business systems function, the JMS API incorporates complete support for the Publish/Subscribe communications model. The Publish/Subscribe communications model supports event-based computing. event-based computing using publish/subscribe, more closely mirrors how business events flow in the real world. Events are disseminated automatically to relevant subscribers as the event happens, without requiring each subscriber to continuously poll a centralized repository of information.

FioranoMQ’s implementation of JMS is based on highly efficient “true push” technology, which does not waste any network bandwidth or computational cycles. As such, it is ideal for the deployment of Internet based applications.

Location Transparency

FioranoMQ applications communicate with each other over Destinations (Topics or Queues). Sending applications publish data to Destinations rather than to a fixed physical location or network address; receiving applications subscribe to Destinations of interest to receive data on those Destinations. The FioranoMQ Server then dynamically routes data from the sender to the receiver, eliminating the need for applications to locate clients or determine network addresses. Because FioranoMQ applications are location independent, they can be easily ported between machines and across different platforms. For example, one can move a server application from one machine to another without disrupting the existing clients. Clients can be added to (or removed from) the FioranoMQ network dynamically, without interrupting other clients or servers.

Ease of Change and Application Modification

Distributed systems (such as FioranoMQ) based on the publish/subscribe paradigm are very easy to change and modify. This is because event dependencies are resolved through runtime event names, rather than by compilers, linkers or operating systems. Publishers and subscribers of FioranoMQ messages operate independently of and asynchronously from each other, and may change without recompilation. All communication between applications is through messages that are routed through the FioranoMQ daemon on each machine. This allows new FioranoMQ applications to be added to the distributed system later, without recompiling, relinking or even stopping and restarting any current applications.

Reduced Complexity

Publish/Subscribe and message queuing greatly reduce complexity in distributed system design and implementation. Events are published to Topics (or Queues) as they happen. Business processes that depend on these events, automatically receive them as they occur. By allowing change notifications to be easily propagated through an enterprise, FioranoMQ software reduces the complexity in distributed system implementation.

Scalability, Extensibility and Performance

The FioranoMQ platform combines all the benefits of standards based JMS APIs with high performance and massive scalability. The FioranoMQ server architecture is highly scalable and extensible by design.

FioranoMQ includes a special native Scalable Connection Management (SCM) module that allows thousands of concurrent clients to connect to a single FioranoMQ server, on Windows NT as well as on Solaris and other Unix platforms. FioranoMQ gives users the choice of using the default serverside connection management, or the native SCM module, which allows an unlimited number of concurrent clients to connect to the server (while keeping server resources constant). The default serverside connection management involves a new thread on the server for each additional client connecting to the server, a model used by default on all Java server implementations.

In addition to the scalability enhancements on a single server, multiple FioranoMQ servers can be connected together to support large numbers of concurrent client connections. In addition, the FioranoMQ environment includes message repeaters to efficiently route data between multiple FioranoMQ servers, with facilities to filter the data using message selectors. These servers could be placed locally or across geographically distributed locations on a WAN.

Robust Features for Distributed Application Development

The use of publish/subscribe and queuing techniques allow FioranoMQ distributed application systems to scale smoothly as you add new component processes. FioranoMQ based distributed Java systems are easier to maintain and have longer useful lifetimes than traditional networked application systems.

Standards based Pub/ Sub and PTP (Queuing) Communication APIs

FioranoMQ software supports both the Publish/Subscribe and PTP communication models, as required by the JMS specification.These communications can operate with either synchronous or asynchronous timing. This depends on whether the developer wants a thread to block while waiting for information or set a listener, which invokes a callback whenever any information is available.

Reliable and Guaranteed Message Delivery

FioranoMQ supports both reliable and guaranteed delivery of messages, as required by the JMS API. Guaranteed delivery is specified using the Durable Subscription API, as specified by JMS. FioranoMQ software ensures that all the persistent messages are delivered once and only once to all the subscribers marked durable, even in the presence of intermittent or long term network failures. Once and only once message delivery is also guaranteed across multiple FioranoMQ servers over a WAN, allowing the deployment of reliable distributed systems across geographically dispersed locations. FioranoMQ supports both guaranteed as well as reliable delivery.

With reliable (at most once) delivery semantics, FioranoMQ delivers messages to all the connected clients, assuming there are no network or application failures. Messages sent with reliable delivery are not logged to persistent storage and so may be lost on occasion. For several applications, reliable delivery offers the most appropriate quality of service. For example, if an application drops a single message in a web based chat application, users might not worry, since another message will arrive in a few seconds.

Transactions

Several applications often require grouping several individual tasks into a single logical unit of work, called a Transaction. FioranoMQ supports basic transactions (with commit/rollback of messages) as specified in the JMS API, but does not support distributed transactions (specified by the XA classes in the JMS specification).

Language Interoperability

FioranoMQ messaging services can be accessed by an available C++ runtime library to support access to the legacy systems. The C++ runtime library is a thin wrapper, which uses JNI to call the corresponding Java APIs. This allows Java and C++ programs to exchange and share data seamlessly.

Open Architecture

FioranoMQ software is designed to support Integration with existing directory servers (based on JNDI and LDAP) and with Java application servers. Several application server vendors have already integrated messaging services (based on FioranoMQ) with their core platforms.

Comprehensive Security Features

FioranoMQ software incorporates a comprehensive security system that allows organizations to easily implement their security policies with respect to identification and authentication, authorization and access control, and privacy/integrity protection using encryption.

The secure version of FioranoMQ Server includes 40bit (export version) and 128bit (U.S. version) encryption, using SSL sockets. Authentication is implemented through client and serverside digital certificates. Client digital certificates may be passed to a customized callback function on the server, allowing developers to implement a layer of access control, based on digital certificates. FioranoMQ also implements the normal Username/Password authentication API, as specified by JMS.

FioranoMQ implements access control based Java 2 Security APIs. For instance, in an FioranoMQ network it is possible to do the following:

Remote Management

FioranoMQ includes a comprehensive administration API and external tools for creating and configuring ConnectionFactories, Topics, Queues, Users, ACLs(Access Control Lists) and user permissions. The administration API together with available external tools allow to monitor the server at any time from any location on the web.

True Push Technology

Traditional applications search for information by polling, which overloads server machines and wastes machine cycles in general. FioranoMQ implements standards based JMS APIs through truepush technology. This allows applications to wait efficiently for events to occur and take actions on those events (through installed callback functions referred to as listeners).

The push technology was created to alleviate problems like information overload and low bandwidth that are associated with the usual pull technology. The push technology is a data distribution technology, in which selected data is automatically delivered to the user's computer at prescribed intervals or based on some event that occurs. The push technology can be used to make information more accessible for the user. By applying the push technology, FioranoMQ designs and implements user friendly and effective information delivery systems.

FioranoMQ System Architecture

Hub and Spoke Topology

FioranoMQ’s design departs from the traditional point-to-point communications architecture to follow a “hub-and-spoke” design. The FioranoMQ Server acts as the hub and JMS enabled applications as the spokes.

The hub-and-spoke topology has several benefits:

In Figure 1, with six applications communicating, the system requires 15 connections with the traditional point-to-point design and only six connections with the hub-and-spoke topology. The point-to-point model requires each application to include the code to interface with the five other applications; furthermore, each application requires modification if another application joins the network. In the hub-and-spoke model, each model only needs to include a single set of code for communicating with the FioranoMQ Server at the hub. The hub decouples applications, thereby reducing system complexity and increasing system flexibility and adaptability.

FioranoMQ Internal Architecture Details

The FioranoMQ messaging server implements both the publish/subscribe (Pub/Sub) as well as the point-to-point (PTP) subsets of the JMS API. Both of these subsets of the JMS API require some form of offline database to store persistent messages, which have been received but not yet delivered to all the client applications. The system architecture of the FioranoMQ server is illustrated in Figure 2.

The offline database storage subsystem ensures that all the persistent messages are delivered to all registered durable subscribers, with guaranteed onetime delivery. In case a provider failure occurs during message delivery or if the client application crashes, a persistent message is always redelivered. The redelivered message is marked, as required by JMS semantics.

Note that JMS allows non persistent messages to be lost in case some subscribers are not connected to the system. Therefore, if you are developing a distributed system and want to ensure that none of your messages are ever lost, it is best for you to:

Thread Management in FioranoMQ

In addition to the 100% pure Java implementation of the default connection manager, FioranoMQ software incorporates a special Scalable Connection Management (SCM) module. This allows a single FioranoMQ server to support several thousand concurrent clients connections on a variety of operating platforms, such as Windows NT, Solaris and other Unix platforms. FioranoMQ allows the user to choose between the default Java connection management and Scalable Connection Management.

Using the default Java Connection Manager, each server instance runs in its own JVM. Clients communicate with the server through sockets, with each client connection using two threads.

A single FioranoMQ server can handle as many concurrent connections as are supported by the JVM, under which the server runs. It is the responsibility of the administrator or the application designer to ensure that the clients connect to servers in the cluster in such a manner that the client load is automatically distributed between the servers.

As more clients connect to the server, the number of threads used on the server goes up linearly. This is because client connections are persistent and are not aborted/removed even if the client is not sending or receiving any messages. In case the server JVM runs out of threads, an error is reported and the FioranoMQ server refuses the requested client connection. This condition implies that the thread limit for the JVM on the server machine has been reached. This number depends on the JVM being used, and varies depending on the target platform. On Solaris, our tests (April 2000) show that over 3500 concurrent connections can be supported using JDK 1.2, while Windows NT environments are a little less scalable. As JVM technology improves, the total number of concurrent connections that can be supported on a single server will continue to rise. The FioranoMQ server is only limited by the JVM that it runs under, and not by any internal server limits. If your application needs more concurrent client connections than are supported by a single server, you should use the Scalable Connection Manager and/or cluster multiple FioranoMQ servers connected together.

The thread limit is typically very dynamic and depends critically on the load on the server machine. By aborting compute and thread intensive applications, one can increase the number of threads available to the JVM, running the FioranoMQ server. Thus, concurrent client connections to a single FioranoMQ Server are limited in number. The exact limit critically depends on the hardware configuration and the system software (for example, the JVM) running on the FioranoMQ Server machine.

Memory Management and Publisher Throttling in the FioranoMQ Server

Each client connection to the FioranoMQ Server uses up some amount of available memory. The FioranoMQ Server implements internal memory management algorithms in order to keep track of the approximate amount of memory being consumed by the system. When the memory limit of the JVM is reached, the FioranoMQ Server automatically starts throttling the publisher application(s) connected to the server and, where allowed by JMS semantics, overflowing the internal buffers. The publisher throttling algorithms automatically governs the speed of running applications, ensuring that the server never gets flooded at any point and that total server throughput remains constant. Publisher throttling ensures that the server scales well as more clients are added to the server.

Typical FioranoMQ Server Setup

In a typical case, the FioranoMQ Server is used in standalone mode. During the setup process, the system administrator uses external tools and special administrative APIs to create a set of destinations on a FioranoMQ server. As defined by JMS, a Destination is either a Topic for Publish/Subscribe interactions or a Queue for point-to-point interactions. Each standalone FioranoMQ server owns a set of available destinations and clients connect directly to the server, as illustrated in Figure 3.

Figure 3 Typical setup of a FioranoMQ Server

In the typical setup illustrated in Figure 3 , all the clients connect to a single server. This setup, while adequate for a large number of applications, suffers from the inherent problem that multiple concurrent client connections can overload the server, resulting in a general slowdown in response time for all applications. To solve this problem, multiple FioranoMQ servers can be connected together, allowing clients connected to one server to exchange information with clients connected to another server.