In the previous article I described how the creators of standards are coping with the industry interest in the REST (Representational State Transfer) style of Web services. I found both new approaches and adaptation of existing standards to include REST.
I find the same thing happening with developers of software toolkits widely used in distributed systems. That is to say, existing projects are adding REST interfaces in order to keep up with developer interest, and there are a few totally new tools. I was rather surprised to find that the latest version of a well known open-source Java Message Service (JMS) has added some REST related functionality.
Java Message Service
JMS is an example of message-oriented middleware" (MOM), one of the simplest ways to implement data exchange between loosely coupled distributed systems. The JMS API has changed little since the first release in 2001 because the basic ideas are so simple. A JMS server manages messages sent by "producers" and stored for subsequent asynchronous reading by "consumers." The server can provide for persistence so there is no requirement for producer and consumer to be connected to the network at the same time.
Each message is self-contained and consists of routing information plus a message body. The JMS server only pays attention to the routing information and ignores the message body, in contrast with the Javaspaces pattern of distributed systems where the content controls the fate of messages.
There are two basic messaging patterns, publish-subscribe and point-to-point message queue. Published messages can be read by all subscribers to a particular named topic. An example might be a price list copied by multiple clients in an organization. Subscribers do not have to be connected at the time a message is published if they have registered a durable connection to the topic.
Messages sent to a point-to-point message queue are consumed when read. There may be multiple consumers connected to a queue but only one will get each message so a queue is ideal for distributing work in a computation grid. Since both message queues and published topics are addressed by name, the REST style of addressing resources fits easily into the JMS addressing scheme.
The Apache ActiveMQ JMS Server
I installed the free download of the latest ActiveMQ build. The download is a very complete package. In order to experiment with the provided examples you only need a 1.5 or later Java SDK and the Ant build toolkit. The Jetty servlet container is included in the download so you don't need to install any HTTP server.
ActiveMQ has grown to be a powerful toolkit with many more capabilities than simple JMS support. For example, there is support for specialized serving of JavaScript scripts and handling Ajax requests.
Of greatest interest here are the examples of REST style web services. The demos include:
- Reading data from a publish-subscribe stock price topic to create a stock portfolio display.
- Sending a message with POST to a publish-subscribe topic or a point-to-point queue.
- Reading from a queue with GET.
The way ActiveMQ has handled reading from a queue with GET illustrates an interesting problem. In strict REST style, a GET should not alter the resource, but JMS requires that reading a point-to-point queue removes the message. I suspect that retrofitting REST to other frameworks may encounter similar conflicts. Here is what the developers have to say about it:
Note that strict REST requires that GET be a read-only operation. So, strictly speaking, we should not use GET to allow folks to consume messages. Though we allow this as it simplifies HTTP/DHTML/Ajax integration somewhat.
As is typical of open source projects, the documentation provided with the download is relatively thin. However, the source, with typical Javadocs comments, can be downloaded and the project Web site has plenty of resources.
Restlet - a aew approach
As an example of a clean slate approach to RESTful Web services, we find the Restlet project. Restlet is a trademark of Noelios Consulting, the originators of the API. This open-source project is licensed under the Open Source Initiative Common Development and Distribution License. The first public release was in November 2005 and is currently at version 1.0.7, with a major revision to 1.1 in the works.
The Restlet developers feel that only a complete replacement of the servlet API can fully exploit REST concepts. For example, the servlet API assumption of one thread per request prevents use of Java's "NIO" non-blocking I/O classes and limits scalability. Use of the NIO classes permits more flexible connectors between computing components.
The Restlet examples are going to look very odd at first glance to developers used to the servlet API. For example, there is nothing comparable to the servlet Session. Fortunately, the recent book, "RESTful Web Services" by Leonard Richardson and Sam Ruby, contains examples of use of the Restlet framework to implement a service.
The downloadable Restlet distribution includes Java classes implementing the Restlet API and a reference implementation, called the Noelios Restlet Engine. This creates a complete Web server including efficient serving of basic static files. However, if you are already committed to an existing servlet engine such as Tomcat, an adapter to run Restlet applications is provided. Adapters are also provided to connect to an Apache Web server or Microsoft IIS.
What Next?
I will be looking around for other examples of both old frameworks with new REST features and completely new approaches. Perhaps I will find enough to make a part 3 article.
Resources
Discussion of the implementation of REST style in ActiveMQ.
The Java Community Process specification for JMS (JSR 914).
JMS with a SOAP Web Service
Open Source Initiative license conditions.
