Java, one of the most popular programming languages, is suited for nearly any application providing that architects...
select the proper versions and tools. Java is also flexible and extensible regarding those tools, which sometimes creates issues for planners and developers who don't know what choices to make. This problem is compounded by the explosion of interest in distributed multi-component architectures. Most tutorials describe these applications as "message-based," posing the question of what that means and whether there's an optimal implementation path.
A distributed application has to communicate among its elements, and techniques to support this can be classified as tightly coupled or loosely coupled. In tightly coupled systems, the application components have direct communications paths with each other -- often things like TCP sockets, but also various remote procedure call implementations. Connecting all the pieces of such an application is an integration task, and organizing applications across different platforms or making them work reliably can be difficult.
Loosely coupled systems, referred to as message-oriented systems, provide a real or virtual message bus or server that serves as a connector between message sources and components that process messages. The basic idea of Java messaging is that a component that wants something done by another sends that other component a "message" and then goes on with its work. The response to the request is another message, sent when the processing component is done.
Because components using Java messaging don't wait for a response, they don't have to remember that one is expected. That independence of processing phases associated with a transaction is called stateless behavior. HTML servers are stateless, and that's why Java messaging is used so often in Web applications. You can quickly replace or replicate stateless components as needed because they don't store information, and that's what makes message-based systems more reliable and cloud ready. Message systems also map well to transaction processing, and they are usually an element in linking Web front ends to existing applications.
All Java messaging systems support either point-to-point conventions to link two components, or they are a publish-and-subscribe model where message sources publish their information and process points subscribe as needed. From there, classifying implementations gets complicated; the choices include application-architecture divisions and application-performance divisions, and there are differences in the APIs and protocols used.
Most native Java messaging is based either on the Java Message Service (JMS) APIs and protocols or on the Advanced Message Queuing Protocol (AMQP). In addition to the standard point-to-point and publish-and-subscribe models, AMQP supports other, more complex component relationships. Although not as ubiquitous as JMS, AMQP implementations are available from a dozen different sources. AMQP is far more platform independent than basic JMS, so most users prefer it for applications that involve other programming languages. AMQP also was designed to be optimized for transactions that require very fast execution. The financial industry was the first major user of the standard.
JMS is a message-broker or server-based approach that requires a separate component to receive, store and forward messages. Some implementations of AMQP require a central broker (e.g., RabbitMQ and one of the deployment options of ActiveMQ); some work in a loose, distributed way with no central broker (e.g., the other ActiveMQ model and ZeroMQ). Brokerless approaches don't have the performance bottleneck and central point of failure of broker systems, but they do have more complicated architectures because each component has to be able to find the others instead of all finding a central broker.
Other component messaging options
It's fair to say that AMQP is displacing basic JMS as the message system of choice for Java, because developers can use brokerless (also called peer-to-peer or P2P) architectures for better performance and because it has wider platform choices. However, it's also true that major vendors such as Microsoft, IBM and Oracle have their own component messaging options, and Java supports all of these with the proper libraries. Some of these options provide support for AMQP-compatible publishers and clients. Users who have developed applications using these vendors' tools may find it easier to integrate Java components with these applications using a vendor's own middleware tools and APIs.
Those unfamiliar with Java messaging might be tempted to start with JMS, but that may not be the best approach. We're moving into an age of increased application componentization and distribution of components -- including in the cloud. That makes it critical to accommodate all possible programming languages and application platforms, which is harder to do with JMS. Developers should look beyond JMS for Java messaging unless their applications are very simple.
Users of Java messaging generally agree on only three statements. First, it's smart for developers to think about moving away from JMS to an AMQP approach if they're a Java shop and to look at how they can use AMQP to integrate Java with manufacturing operation management from vendors like IBM, Oracle and Microsoft. Second, if developers aren't sure whether they can use a brokerless approach, select a Java messaging product that supports both broker and brokerless operation (e.g., ActiveMQ). The other option would be to create a hybrid of two message systems, which might be too difficult for most early message service users. Third, brokerless/P2P architectures are harder to deploy and sustain without access to skilled software developers and network specialists. Don't go there unless absolutely necessary.
Messaging is important to Java developers, but "messaging" is increasingly separating from Java to become a general application development tool. Treat it that way now, and developers are less likely to hit a roadblock later on.