FIGURE 15-2: Publish/subscribe implementation
Java EE provides a convenient application programming interface (API) that deals with these
implementations and is called the Java Message Service (JMS). It is a set of interfaces that describe
the creation of messages, providers, and consumers. When implemented in an EJB container,
message‐driven beans (MDBs) act as listeners for JMS messages being invoked asynchronously.
WHAT IS THE MICROSERVICE ARCHITECTURE?
Over the past few years, the microservice architecture pattern has become a hotly discussed and
popular pattern. The idea behind it is to design a large distributed scalable application that consists
of small cohesive services that are able to evolve or even be completely rewritten over the life of the
This is not a new idea, and it is similar to the Service Orientated Architecture (SOA) pattern that has
been in use for a long time. The essence of the microservice is the idea that each service should be
small—perhaps as small as only a few hundred lines of code. The objective is to decompose a large,
monolithic application into much smaller applications to solve development and evolutionary problems.
This chapter discusses the reasons for following the microservice path, its disadvantages and
benei ts, and how it compares to the more established and familiar monolithic architecture.
The most common way to develop and package a web application has always been to collect all the
resources, components, and class i les into a single Web application ARchive (WAR) or Enterprise
ARchive (EAR) i le and deploy it to a web server. A typical application for a bookstore might
include components that manage the user's accounts, process payment, control stock, administer
customer services, and generate front‐end views. All this is developed in one monolithic application
and then packaged and deployed to a web server. Figure 15-3 shows a simplii ed representation of a