LAMP and the Spread Toolkit

Strip away the veritable verbosity of voluminous framework verbiage (I've wanted to get that out of my system since watching V for Vendetta) from your average application server, and the remaining skeleton will be suspiciously similar to a standard Linux distribution running Apache and a few default programming languages. Look through the features you get for free with an app server, and you'll realize you get most of them for free with Linux/Apache as well--or at least a close approximation. Of course, you're reading ONLamp, so you already know this.

There is, however, one glaring omission. A feature of the app server stack doesn't seem to come by default in your average, open source LAMP bundle, and it's particularly important in many enterprise environments: messaging. To be more precise, it's the concept of enterprise messaging--the efficient and reliable routing of business-critical data from one server to another. Corporate environments might use messaging for multiple reasons: delivering data to multiple departments for processing, offloading CPU-intensive processing tasks to distributed servers, the modularization of enterprise components, etc. The words "robustness," "reliability," "scalability," and "flexibility" invariably come up when anyone is talking about messaging in the enterprise.

While enterprise messaging might not come by default, it is relatively easy to add this to a LAMP stack. One of the technologies to accomplish the task is the Spread toolkit.

Spread is an open source toolkit that satisfies the goals most people have in mind when they think about this kind of messaging. From the Spread home page:

Spread is an open source toolkit that provides a high performance messaging service that is resilient to faults across local and wide area networks. Spread functions as a unified message bus for distributed applications, and provides highly tuned application-level multicast, group communication, and point-to-point support. Spread services range from reliable messaging to fully ordered messages with delivery guarantees.

Spread has language bindings for Python, PHP, and Perl (not to mention C/C++, Java, Ruby, Squeak, Lua, Tcl, and others), and is available for a variety of platforms. It admirably fits most flexibility requirements. Spread can reliably deliver and order messages, allowing you to tailor Spread applications to meet the reliability and robustness needs of many corporate environments.

In a LAMP environment, you might want to use messaging to split your application load, without affecting the performance of specific components. For example, generating complex reports (perhaps using XSLT to transform XML to PDF, for example) may reduce your web server or database performance, so you might want to shift this processing onto a different server. You could connect those machines in a number of different ways: write data into a database and use a regular cron job to process them, call web services, or even make a direct socket connection between the two. Spread provides another alternative--a truly asynchronous request, potentially also allowing you to add more servers for scaling the load, without requiring complicated changes at the client (web server) end of the connection.

In addition, companies such as Zope Corporation use the Spread toolkit for its Zope Replication Services, for high availability. Indeed, while researching this article, one of the more common ideas I came across for the use of Spread was database replication. Early versions of replication for the Postgres database (the pgreplication project), for example, used Spread.

Installing Spread

The latest version of Spread, at time of writing, is Version 4, release candidate 2. As you might expect, third-party library support isn't quite so up to date. The stable release is Spread version 3.17.3. To install, extract the contents of the distribution, change into the directory created (spread-src-3.17.3), and then run the commands:

./configure
make
sudo su (or just su to root)
make install

Among the apps installed as part of this process are:

spread, the spread daemon

spmonitor, a monitoring and administration client

spuser, a client program for sending and receiving messages, joining groups, and so on

spflooder, another client program for flooding messages and measurement

Running with Daemons

To start up the Spread daemon, you need a configuration file. There's an example in /usr/local/etc/spread.conf. Basic spread configuration is straightforward, specifying a multicast address for a subnet and associated port, followed by a list of names and IP addresses:

This example uses the broadcast address for my local network, runs on port 4804, and specifies two machines (machine1, machine2) along with their IP addresses to run in this segment. Once you've changed the configuration file to reflect your own environment (a single machine will work fine), set up a runtime directory and user/group for the daemon:

There are a range of other configuration options for operating the Spread daemon (see the example in /usr/local/etc for more detail), including controlling the level of logging, but for the moment this simple configuration will work.