This article is excerpted from the forthcoming book ActiveMQ In Action (http://bit.ly/2je6cQ) by Bruce Snyder, Rob Davies and Dejan Bosanac (Manning Publications, ISBN: 1933988940)
At one time or another, every software developer has the need to communicate between applications or transfer data from one system to another. Not only are there many solutions to this sort of problem, but depending on your constraints and requirements, deciding how to go about such a task can be a big decision. Business requirements oftentimes place restrictions on items that directly impact such a decision including performance, scalability, reliability and more. There are many applications that we use every day that impose just such requirements including ATMs, airline reservation systems, credit card systems, point-of-sale systems and telecommunications just to name a few. Where would we be without most of these applications in our daily lives today?
When it comes to developing and deploying Java applications, it is extremely common to use Tomcat as a runtime container. As you expand your Java applications, new business needs arise including the ability to communicate with other applications, the need to scale an application architecture and quite possibly the need to decrease application coupling just to name a few. These requirements and many more can be addressed through the use of ActiveMQ with Tomcat.
In a series of articles, you will learn about the integration of ActiveMQ and Tomcat. In the first article, you will learn a bit about Java Servlet technology, Tomcat and you will be introduced to Apache ActiveMQ. Future articles will continue to dive deeper into the topic of integrating ActiveMQ with Tomcat.
Apache Tomcat is arguably the most widely used Java web container available today. Tomcat is used for both development and production throughout the world because it is extremely robust, highly configurable and commercially supported by a number of companies. Tomcat also provides facilities for integrating third party resources such as JDBC data sources, JMS connection factories, etc. and making them JNDI accessible. This is how ActiveMQ will be integrated with Tomcat. Before proceeding, you need to download Apache Tomcat 6.0.26 (http://tomcat.apache.org/download-60.cgi) and expand it on your computer.
Prior to the invention of Java Servlets, developing web applications meant doing CGI (Common Gateway Interface) programming. Although CGI is a powerful tool, it also comes with some drawbacks. Although some technologies came about to address some of the issues, Java Servlets turned out to be a much more powerful alternative. Servlets provide better performance, portability, standardized exception handling, the ability to manage sessions, a standardized security model and much more. Servlets abstract away low-level functions such as protocols, sockets, threading, etc. allowing you to focus on application development. In addition to these myriad benefits, servlets also provide standardization in both the API and the packaging. Because of this, as long as a given servlet abides by the specification, it should run just fine in any servlet container.
Tomcat offers a great deal of functionality in a very small package. Not only is Tomcat a highly capability and very lightweight runtime container for Java Servlet based application, but it is also quite easy to bootstrap a so-called headless application in Tomcat (a Java application without a GUI). Tomcat provides the ability to scale the container independent of the deployed applications and Tomcat is fully instrumented via JMX for management and monitoring capabilities. With all of these incredible features, it's not surprising to learn how truly widespread Tomcat really is in the business world. It is used in development and production by many Fortune 500 businesses as well as by a great of small and medium sized businesses.
Clearly Tomcat is an incredibly capable and a highly popular application server. So how does ActiveMQ fit into this picture?
Apache ActiveMQ is arguably the most popular open source message-oriented middleware in existence today. ActiveMQ was intended to be used as the JMS spec intended, for remote communications between distributed applications. To better understand what this means, the best thing to do is take a look at a few of the ideas behind distributed application design, specifically, communications.
ActiveMQ provides the benefits of loose coupling for application architecture. Loose coupling is commonly introduced into an architecture to mitigate the classic tight coupling of Remote Procedure Calls (RPC). Such a loosely coupled design is considered to be asynchronous where the calls from either application have no bearing on one another; there is no interdependence or timing requirements. The applications can rely upon ActiveMQ's ability to guarantee message delivery. Because of this, it is often said that applications sending messages just fire-and-forget. That is, they send the message to ActiveMQ and are not concerned with how or when the message is delivered. Furthermore, the consuming applications have no concerns with where the messages originated or how they were sent to ActiveMQ. This is an especially powerful benefit in heterogeneous environments allowing clients to be written using different languages and even possibly different wire protocols. ActiveMQ acts as the middleman allowing heterogeneous integration and interaction in an asynchronous manner.
When considering distributed application design, application coupling is important. Coupling refers to the interdependence of two or more applications or systems. An easy way to think about coupling is to consider the affect of changes to any application in the system; the implications across the other applications in the architecture as features are added. Do changes to one application force changes to other applications involved? If the answer is yes, then those applications are tightly coupled. However, if one application can be changed without affecting other applications, then those applications are more loosely coupled. The overall lesson here is that tightly coupled applications are more difficult to maintain compared to loosely coupled applications. Said another way, loosely coupled applications can more easily deal with unforeseen changes.
Technologies such as COM, CORBA, DCE and EJB that make use of RPC techniques are said to be tightly coupled. Using RPC, when one application calls another application, the caller is blocked until the callee returns control to the caller. The diagram in Figure 1 below depicts this concept.
Figure 1. Two tightly-coupled applications using remote procedure calls to communicate
The caller (application one) in Figure 1 is blocked until the callee (application two) returns control. Many system architectures use RPC and are very successful. However, there are many disadvantages to such a tightly coupled design, most notable is the higher amount of maintenance that is required since even small changes ripple throughout the system architecture. Also, correct timing is a necessity between the two applications that are tightly coupled. Both applications must be available at the same time for the request from application one to reach application two (label #1), and for the response to travel from application two to application one (label #2). Such timing requirements can be very cumbersome. Compare such a tightly coupled design with a design where two applications are completely unaware of one another such as that depicted in Figure 2.
Figure 2. Two loosely-coupled applications using JMS messaging to communicate
Application one in Figure 2 sends a message to the MOM in a one-way fashion. Then, possibly sometime later, application two receives a message from the MOM, in a one-way fashion. Neither application has any knowledge that the other even exists and there is no timing interdependence between the two applications. This one-way style of interaction results in much lower maintenance because changes in one application have little to no effect on the other application. For these reasons, loosely coupled applications offer big advantages over tightly coupled architectures when considering distributed application design. This is where ActiveMQ enters the picture.
Think about the changes necessary when an application must move to a new location. This can happen when new hardware is necessary or the application needs to be moved. With a tightly coupled system design, such movement is difficult because all segments of the application must experience an outage. With an application designed using loose coupling, different segments of the system can be moved independent of one another. Consider a scenario where there are multiple instances of application one and multiple instances of application two, where each instance resides on different machines. ActiveMQ is installed on still another machine independent of either application one or application two. In this scenario, any one of the application one or application two instances can be moved around without affecting one another. In fact, multiple instances of ActiveMQ can be used in what's known as a network of brokers configuration which would allow the ActiveMQ instances to be moved around without affecting either application one or application two. This means that any segment of this architecture can be taken down for maintenance at any time without taking down the entire system.
So ActiveMQ provides an incredible amount of flexibility in application architecture and for the concepts surrounding loose coupling to become a reality. But when should ActiveMQ be used to introduce these benefits?
There are many occasions where ActiveMQ and asynchronous messaging can have a meaningful impact on a system architecture. Here are just a few example scenarios:
Heterogeneous application integration - The ActiveMQ broker is written in Java so naturally a Java client API is provided. But ActiveMQ also provides clients for C/C++, .NET, Perl, PHP, Python, Ruby and a few other languages. This is a huge advantage when considering how you might integrate applications written in different languages on different platforms. In cases such as this, the various client APIs make it possible to send and receive messages via ActiveMQ no matter what language is used. In addition to the cross-language capabilities provided by ActiveMQ, the ability to integrate such applications without the use of remote procedure calls (RPC) is definitely a big benefit because messaging truly helps to decouple the applications.
As a replacement for RPC - Applications using RPC style synchronous calls are very widespread. Consider that the vast majority of client-server applications use RPC including ATMs, most web applications, credit card systems, point-of-sale systems and many, many more. Even though many of these systems are very successful, conversion to the use of asynchronous messaging can bring about many benefits without giving up the guarantee of a response. Systems that rely upon synchronous requests typically have a limited ability to scale because eventually requests will begin to back up, thereby slowing the whole system. Instead of experiencing this type of a slow down, using asynchronous messaging, additional message receivers can be easily added so that messages are consumed concurrently and therefore handled faster. This, of course, assumes that your applications can be decoupled.
To loosen the coupling between applications - As already discussed, tightly coupled architectures can be problematic for many reasons, especially if they are distributed. Loosely coupled architectures, on the other hand, exhibit fewer dependencies making them better at handling unforeseen changes. Not only will a change to one component in the system not ripple across the entire system, but component interaction is also dramatically simplified. Instead of using a synchronous scheme for component interaction (where one method calls another and the caller waits for a response from the callee), components utilize asynchronous communications (where they simply send a message without waiting for a response - also known as fire-and-forget). Such loose coupling throughout a system can lead to what is known as an event-driven architecture (EDA).
As the backbone of an event-driven architecture - The decoupled, asynchronous style of architecture described in the previous point allows the software itself to scale much further (known as horizontal scalability) instead of only relying upon the ability of the hardware to scale (known as vertical scalability). Consider an incredibly high-traffic, e-commerce site such as Amazon. When a user makes a purchase on Amazon there are many separate stages through which that order must travel including order placement, invoice creation, payment processing, order fulfillment, shipping and more. However, when a user actually places an order, the user is immediately taken to a page stating, 'Thanks for your order'. Not only that but, without delay, the user also receives an email stating that the order was received. The order placement process that is employed by Amazon is a good example of the first stage in a much larger set of asynchronous processes. Each stage of the order is handled discretely by a separate service. When the user places the order there is a synchronous call to submit the order, but the entire order process does not take place behind a synchronous call via the web browser. Instead, the order is accepted and acknowledged immediately. The rest of the steps in the process are handled asynchronously. If a problem occurs that prevents the process from proceeding, the user is notified via email. Such asynchronous processes are what afford massive scalability and high availability.
To improve application scalability - Many applications utilize an event-driven architecture in order to provide massive scalability including such domains as e-commerce, government, manufacturing and online gaming just to name a few. By separating an application along lines in the business domain using asynchronous messaging, many other possibilities begin to emerge. Consider the ability to design an application using a service for a specific task. This is the backbone of service-oriented architecture (SOA). Each service fulfills a discrete function and only that function. Then applications are built through the composition of these services and the communication among services is achieved using asynchronous messaging and eventual consistency. This style of application design makes it possible to introduce such concepts as complex event processing (CEP). Using CEP, the interactions among the components in a system are tracked for further analysis. Such possibilities are truly endless when you consider that asynchronous messaging is simply adding a level of indirection between components in a system.
Tomcat is extremely popular and so is ActiveMQ. Given Tomcat's runtime capabilities and the wide variety of uses for ActiveMQ, it only makes sense to explore the integration of these two technologies. In this article, you learned a bit about how Java Servlets came about and about how ActiveMQ can help to use loose coupling in your applications. You were also introduced to some use cases for ActiveMQ. Hopefully this background on ActiveMQ is enough to whet your appetite and encourage you to learn more about ActiveMQ.
In the next two articles, you will learn about the two styles of integration that are available in Tomcat and how ActiveMQ can utilize both styles for different benefits.