Copyright © 2019 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Commissioning Editor: Aaron Lazar
Acquisition Editor: Denim Pinto
Content Development Editor: Zeeyan Pinheiro
Technical Editor: Romy Dias
Copy Editor: Safis Editing
Project Coordinator: Vaidehi Sawant
Proofreader: Safis Editing
Indexer: Mariammal Chettiyar
Graphics: Alishon Mendonsa
Production Coordinator: Deepika Naik

First published: June 2016
Second edition: December 2017
Third edition: February 2019

Production reference: 1220219

Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.

ISBN 978-1-78953-072-8

www.packtpub.com

Â

Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.

• Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals

• Improve your learning with Skill Plans built especially for you

• Get a free eBook or video every month

• Mapt is fully searchable

• Copy and paste, print, and bookmark content

Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.packt.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at customercare@packtpub.com for more details.

At www.packt.com , you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.

Sourabh Sharma has over 16 years of experience in product/application development. His expertise lies in designing, developing, deploying, and testing N-tier web applications and leading teams. He loves to troubleshoot complex problems and develop innovative ways to solve problems. Sourabh believes in continuous learning and sharing your knowledge.

Aristides Villarreal Bravo is a Java developer, member of the NetBeans Dream Team and the Java User Groups community, and a developer of the jmoordb framework. He is currently residing in Panama. He has organized and participated in various conferences and seminars related to Java, Java EE, NetBeans, the NetBeans Platform, open source software, and mobile devices, both nationally and internationally. He is a writer of tutorials and blogs for web developers about Java and NetBeans. He has participated in several interviews on sites including NetBeans, NetBeans Dzone, and JavaHispano. He is a developer of plugins for NetBeans.

If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.

Presently, microservices are the de-facto way to design scalable, easy-to-maintain applications. Microservice-based systems not only make application development easier, but also offer great flexibility in utilizing various resources optimally. If you want to build an enterprise-ready implementation of a microservice architecture, then this is the book for you!

Starting off by understanding the core concepts and framework, you will then focus on the high-level design of large software projects. You will gradually move on to setting up the development environment and configuring it, before implementing continuous integration to deploy your microservice architecture. Using Spring Security, you will secure microservices and integrate sample online table reservation system ( OTRS ) services with an Angular-based UI app. We'll show you the best patterns, practices, and common principles of microservice design, and you'll learn to troubleshoot and debug the issues faced during development. We'll show you how to design and implement event-based and gRPC microservices. You will learn various ways to handle distributed transactions and explore choreography and orchestration of business flows. Finally, we'll show you how to migrate a monolithic application to a microservice-based application.

By the end of the book, you will know how to build smaller, lighter, and faster services that can be implemented easily in a production environment.

This book is designed for Java developers who are familiar with microservice architecture and now want to effectively implement microservices at an enterprise level. A basic knowledge of Java and Spring Framework is necessary.

Chapter 1 , A Solution Approach , starts with basic questions about the existence of microservices and how they evolve. It highlights the problems that large-scale on-premises and cloud-based products face, and how microservices deal with them. It also explains the common problems encountered during the development of enterprise or large-scale applications, and the solutions to these problems. Many of you might have experienced the pain of rolling out the whole release due to failure of one feature.

Microservices give the flexibility to roll back only those features that have failed. This is a very flexible and productive approach. For example, let's assume you are the member of an online shopping portal development team and want to develop an application based on microservices. You can divide your application based on different domains such as products, payments, cart, and so on, and package all these components as a separate package. Once you deploy all these packages separately, these would act as a single component that can be developed, tested, and deployed independently—these are called microservices.

Now let's see how this helps you. Let's say that after the release of new features, enhancements, and bug fixes, you find flaws in the payment service that need an immediate fix. Since the architecture is based on microservices, you can roll back just the payment service, instead of rolling back the whole release. You could also apply the fixes to the payment microservice without affecting the other services. This not only allows you to handles failure properly, but helps to deliver features/fixes swiftly to the customer.

Chapter 2 , Environment Setup , teaches you how to set up the development environment from an integrated development environment ( IDE ), and looks at other development tools from different libraries. This chapter covers everything from creating a basic project, to setting up Spring Boot configuration, to building and developing our first microservice. Here, we'll use Java 11 as our language and Jetty as our web server.

Chapter 3 , Domain-Driven Design , sets the tone for rest of the chapters by referring to one sample project designed using domain-driven design. This sample project is used to explain different microservice concepts from this chapter onward. This chapter uses this sample project to drive through different functional and domain-based combinations of services or apps to explain domain-driven design.

Chapter 4 , Implementing a Microservice , takes you from the design to the implementation of a sample project. Here, the design of our sample project explained in the last chapter is used to build the microservices. This chapter not only covers the coding, but also other different aspects of the microservices—build, unit testing, and packaging. At the end of this chapter, the sample microservice project will be ready for deployment and consumption.

Chapter 5 , Microservice Pattern – Part 1 , elaborates upon the different design patterns and why these are required. You'll learn about service discovery, registration, configuration, how these services can be implemented, and why these services are the backbone of microservice architecture. During the course of microservice implementation, you'll also explore Netflix OSS components, which have been used for reference implementation.

Chapter 6 , Microservice Pattern – Part 2 , continues from the first chapter on microservice patterns. You'll learn about the API Gateway pattern and its implementation. Failures are bound to happen, and a successful system design prevents the failure of the entire system due to one component failure. We'll learn about the circuit breaker, its implementation, and how it acts as a safeguard against service failure.

Chapter 7 , Securing Microservices , explains how to secure microservices with respect to authentication and authorization. Authentication is explained using basic authentication and authentication tokens. Similarly, authorization is examined using Spring Security 5.0. This chapter also explains common security problems and their solutions.

Chapter 8 , Consuming Microservices Using the Angular App , explains how to develop a web application using AngularJS to build the prototype of a web application that will consume microservices to show the data and flow of a sample project – a small utility project.

Chapter 9 , Inter-Process Communication Using REST , explains how REST can be used for inter-process communication. The use of RestTemplate and the Feign client for implementing inter-process communication is also considered. Lastly, it examines the use of load balanced calls to services where more than one instance of a service is deployed in the environment.

Chapter 10 , Inter-Process Communication Using gRPC , explains how to implement gRPC services and how these can be used for inter-process communication.

Chapter 11 , Inter-Process Communication Using Events , discusses reactive microservices and their fundamentals. It outlines the difference between plain microservices and reactive microservices. At the end, you'll learn how to design and implement a reactive microservice.

Chapter 12 , Transaction Management , teaches you about the problem of transaction management when a transaction involves multiple microservices, and a call when routed through various services. We’ll discuss the two-phase commit and distributed saga patterns, and resolve the transaction management problem with a distributed saga implementation.

Chapter 13 , Service Orchestration , introduces you to different designs for establishing inter-process communication among services for specific flows or processes. You’ll learn about choreography and orchestration. You will also learn about using Netflix Conductor to implement the orchestration.

Chapter 14 , Troubleshooting Guide , talks about scenarios when you may encounter issues and get stuck. This chapter explains the most common problems encountered during the development of microservices, along with their solutions. This will help you to follow the book smoothly and will make learning swift.

Chapter 15 , Best Practices and Common Principles , teaches the best practices and common principles of microservice design. It provides details about microservices development using industry practices and examples. This chapter also contains a few examples where microservice implementation can go wrong, and how you can avoid such problems.

Chapter 16 , Converting a Monolithic App to a Microservices-Based App , shows you how to migrate a monolithic application to a microservice-based application.

You need to have a basic knowledge of Java and Spring Framework. You can explore the reference links given at the end of each chapter to get the more out of this book.

For this book, you can use any operating system (out of Linux, Windows, or macOS) with a minimum of 4 GB RAM. You will also require NetBeans with Java, Maven, Spring Boot, Spring Cloud, Eureka Server, Docker, and a continuous integration/continuous deployment application. For Docker containers, you may need a separate virtual machine or cloud host, preferably with 16 GB or more of RAM.

You can download the example code files for this book from your account at www.packt.com . If you purchased this book elsewhere, you can visit www.packt.com/support and register to have the files emailed directly to you.

You can download the code files by following these steps:

1. Log in or register at www.packt.com .
2. Select the SUPPORT tab.
3. Click on Code Downloads & Errata .
4. Enter the name of the book in the Search box and follow the onscreen instructions.

Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:

• WinRAR/7-Zip for Windows
• Zipeg/iZip/UnRarX for Mac
• 7-Zip/PeaZip for Linux

The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Mastering-Microservices-with-Java-Third-Edition . In case there's an update to the code, it will be updated on the existing GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/ . Check them out!

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://www.packtpub.com/sites/default/files/downloads/9781789530728_ColorImages.pdf .

There are a number of text conventions used throughout this book.

CodeInText : Indicates c ode words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: " First, we'll add Spring Cloud dependencies, as shown in pom.xml . "

A block of code is set as follows:

logging:
    level:
      ROOT: INFO
      org.springframework.web: INFO

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

endpoints:
    restart:
        enabled: true
    shutdown:
        enabled: true

Any command-line input or output is written as follows:

Chapter6> mvn clean package

Bold : Indicates a new term, an important word, or w ords that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "After the values are updated, click on the Save and Test button. "

Feedback from our readers is always welcome.

General feedback : If you have questions about any aspect of this book, mention the book title in the subject of your message and  email us at customercare@packtpub.com .

Errata : Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packt.com/submit-errata , selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy : If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at copyright@packt.com with a link to the material.

If you are interested in becoming an author : If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com .

Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!

For more information about Packt, please visit packt.com .

The following part of this book will teach you about the fundamentals of microservices and the basics that you need in order to implement microservice-based systems.

In this section, we will cover the following chapters:

• Chapter 1 , A Solution Approach
• Chapter 2 , Environment Setup
• Chapter 3 , Domain-Driven Design
• Chapter 4 , Implementing a Microservice

As a prerequisite for proceeding with this book, you should have a basic understanding of microservices and different software architecture styles. Having a basic understanding of these will help you understand what we discuss in this book.

After reading this book, you will be able to implement microservices for on-premises or cloud production deployments and you will understand the complete life cycle, from design and development to testing and deployment, of continuous integration and deployment. This book is specifically written for practical use and to stimulate your mind as a solution architect. Your learning will help you to develop and ship products in any situation, including Software-as-a-Service ( SaaS ) and Platform-as-a-Service ( PaaS ) environments. We'll primarily use Java and Java-based framework tools, such as Spring Boot and Jetty, and we will use Docker for containerization.

In this chapter, you will learn about microservices and how they have evolved. This chapter highlights the problems that on-premises and cloud-based products face and how microservices architectures deal with them. It also explains the common problems encountered during the development of SaaS, enterprise, or large applications and their solutions.

In this chapter, we will explore the following topics:

• Services and service-oriented architecture ( SOA )
• Microservices, nanoservices, teraservices, and serverless
• Deployment and maintenance

Martin Fowler explains the following:

Let's get some background on the way microservices have evolved over the years. Enterprise architecture evolved from historic mainframe computing, through client-server architecture (two-tier to n -tier), to SOA.

The transformation from SOA to microservices is not a standard defined by an industry organization, but a practical approach practiced by many organizations. SOA eventually evolved to become microservices .

Adrian Cockcroft, a former Netflix architect, describes a microservice-based architecture as follows:

Similarly, the following quote from Mike Gancarz, a member who designed the X Windows system, which defines one of the paramount precepts of Unix philosophy, describes the microservice paradigm as well:

Microservice architectures share many common characteristics with SOAs, such as the focus on services and how one service decouples from another. SOA evolved around monolithic application integration by exposing APIs that were mostly Simple Object Access Protocol ( SOAP )-based. Therefore, having middleware such as an enterprise service bus ( ESB ) is very important for SOA. M icroservices are less complex than SOAs, and, even though they may use a message bus, it is only used for message transport and it does not contain any logic. It is simply based on smart endpoints.

Tony Pujals defined m icroservices beautifully:

Though Tony only talks about HTTP, event-driven microservices may use a different protocol for communication. You can make use of Kafka to implement event-driven microservices. Kafka uses the wire protocol, a binary protocol over TCP.

Microservices are not new—they have been around for many years. For example, Stubby, a general purpose infrastructure based on Remote Procedure Call ( RPC ), was used in Google data centers in the early 2000s to connect a number of services with and across data centers. Its recent rise is due to its popularity and visibility. Before microservices became popular, monolithic architectures were mainly being used for developing on-premises and cloud-based applications.

A monolithic architecture allows the development of different components such as presentation, application logic, business logic, and Data Access Objects ( DAOs ), and then you either bundle them together in an Enterprise Archive ( EAR ) or a Web Archive ( WAR ), or store them in a single directory hierarchy (such as Rails or Node.js).

Many famous applications, such as Netflix, have been developed using a microservices architecture. Moreover, eBay, Amazon, and Groupon have evolved from monolithic architectures to microservices architectures.

Now that you have had an insight into the background and history of microservices , let's discuss the limitations of a traditional approach—namely, monolithic application development—and see how microservices would address them.

As we know, change is eternal. Humans always look for better solutions. This is how microservices became what it is today and it will evolve further in the future. Today, organizations are using agile methodologies to develop applications—it is a fast-paced development environment that has grown to a much larger scale after the invention of the cloud and distributed technologies. Many argue that monolithic architectures could also serve a similar purpose and be aligned with agile methodologies, but microservices still provide a better solution to many aspects of production-ready applications.

To understand the design differences between monolithic and microservices architectures, let's take an example of a restaurant table-booking application. This application may have many services to do with customers, bookings, analytics, and so on, as well as regular components, such as presentation and databases.

We'll explore three different designs here: the traditional monolithic design, the monolithic design with services, and the microservices design.

The following diagram explains the traditional monolithic application design. This design was widely used before SOA became popular:

In a traditional monolithic design, everything is bundled in the same archive (all the presentation code is bundled in with the Presentation archive, the application logic goes into the Application Logic archive, and so on), regardless of how it all interacts with the database files or other sources.

After SOA, applications started being developed based on services, where each component provides services to other components or external entities. The following diagram depicts a monolithic application with different services; here, services are being used with a Presentation component. All services, the Presentation component, or any other components are bundled together:

The following diagram depicts the microservices design . Here each component is autonomous. Each component could be developed, built, tested, and deployed independently. Here, even the application User Interface ( UI ) component could also be a client and consume the microservices . For the purpose of our example, the layer designed is used within the µService.

The API Gateway provides an interface where different clients can access the individual services and solve various problems, such as what to do when you want to send different responses to different clients for the same service. For example, a booking service could send different responses to a mobile client (minimal information) and a desktop client (detailed information), providing different details to each, before providing something different again to a third-party client.

A response may require the fetching of information from two or more services:

After observing all the sample design diagrams we've just gone through, which are very high-level designs, you might find that in a monolithic design, the components are bundled together and tightly coupled. All the services are part of the same bundle. Similarly, in the second design diagram, you can see a variant of the first diagram where all services could have their own layers and form different APIs, but, as shown in the diagram, these are also all bundled together.

Conversely, in the microservices design , the design components are not bundled together and have loose couplings. Each service has its own layers and database, and is bundled in a separate archive to all others. All these deployed services provide their specific APIs, such as Customers or Bookings. These APIs are ready to consume. Even the UI is also deployed separately and designed using µServices. For this reason, the microservices provides various advantages over its monolithic counterpart. I would, nevertheless, remind you that there are some exceptional cases where monolithic application development is highly successful, such as Etsy, and peer-to-peer e-commerce web applications.

Now let us discuss the limitations you'd face while working with Monolithic applications.

Monolithic applications that are large when scaled, scale everything, as all the components are bundled together. For example, in the case of a restaurant table reservation application, even if you would like to scale only the table-booking service, you would scale the whole application; you cannot scale the table-booking service separately. This design does not utilize resources optimally.

In addition, this scaling is one-dimensional. Running more copies of the application provides the scale with increasing transaction volume. An operation team could adjust the number of application copies that were using a load balancer based on the load in a server farm or a cloud. Each of these copies would access the same data source, therefore increasing the memory consumption, and the resulting I/O operations make caching less effective.

Microservices architectures give the flexibility to scale only those services where scale is required and allow optimal utilization of resources. As mentioned previously, when needed, you can scale just the table-booking service without affecting any of the other components. It also allows two-dimensional scaling; here we can not only increase the transaction volume, but also the data volume using caching (platform scale). A development team can then focus on the delivery and shipping of new features, instead of worrying about the scaling issues (product scale).

Microservices could help you scale platforms, people, and product dimensions, as we have seen previously. People scaling here refers to an increase or decrease in team size depending on the microservices ' specific development needs.

Microservice development using RESTful web service development provides scalability in the sense that the server-end of REST is stateless; this means that there is not much communication between servers, which makes the design horizontally scalable.

Since monolithic applications are either bundled in the same archive or contained in a single directory, they prevent the deployment of code modularity. For example, many of you may have experienced the pain of delaying rolling out the whole release due to the failure of one feature.

To resolve these situations, microservices give us the flexibility to roll back only those features that have failed. It's a very flexible and productive approach. For example, let's assume you are the member of an online shopping portal development team and want to develop an application based on microservices . You can divide your application based on different domains such as products, payments, cart, and so on, and package all these components as separate packages. Once you have deployed all these packages separately, these would act as single components that can be developed, tested, and deployed independently, and called µService .

Now, let's see how that helps you. Let's say that after a production release launching new features, enhancements, and bug fixes, you find flaws in the payment service that need an immediate fix. Since the architecture you have used is based on microservices , you can roll back the payment service instead of rolling back the whole release, if your application architecture allows, or apply the fixes to the microservices payment service without affecting the other services. This not only allows you to handle failure properly, but it also helps to deliver the features/fixes swiftly to a customer.

Monolithic applications are mostly developed and enhanced based on the technologies primarily used during the initial development of a project or a product. This makes it very difficult to introduce new technology at a later stage of development or once the product is in a mature state (for example, after a few years). In addition, different modules in the same project that depend on different versions of the same library make this more challenging.

Technology is improving year on year. For example, your system might be designed in Java and then, a few years later, you may want to develop a new service in Ruby on Rails or Node.js because of a business need or to utilize the advantages of new technologies. It would be very difficult to utilize the new technology in an existing monolithic application.

It is not just about code-level integration, but also about testing and deployment. It is possible to adopt a new technology by rewriting the entire application, but it is a time-consuming and risky thing to do.

On the other hand, because of its component-based development and design, microservices architectures give us the flexibility to use any technology, new or old, for development. They do not restrict you to using specific technologies, and give you a new paradigm for your development and engineering activities. You can use Ruby on Rails, Node.js, or any other technology at any time.

So, how is this achieved? Well, it's very simple. M icroservices -based application code does not bundle into a single archive and is not stored in a single directory. Each µService has its own archive and is deployed separately. A new service could be developed in an isolated environment and could be tested and deployed without any technical issues. As you know, microservices also own their own separate processes, serving their purpose without any conflicts to do with things such as shared resources with tight coupling, and processes remain independent.

Monolithic systems does not provide flexibility to introduce new technology. However, introduction of new technology comes as low risk features in microservices based system because by default these small and self contained components.

You can also make your microservice available as open source software so it can be used by others, and, if required, it may interoperate with a closed source, a proprietary one, which is not possible with monolithic applications.

There is no question that monolithic applications can be developed using agile practices, and these are being developed all the time. Continuous integration (CI) and continuous deployment (CD) could be used, but the question is—do they use agile practices effectively? Let's examine the following points:

• When there is a high probability of having stories dependent on each other, and there could be various scenarios, a story would not be taken up until the dependent story is complete.
• The build takes more time as the code size increases.
• The frequent deployment of a large monolithic application is a difficult task to achieve.
• You would have to redeploy the whole application even if you updated a single component.
• Redeployment may cause problems to already running components; for example, a job scheduler may change whether components impact it or not.
• The risk of redeployment may increase if a single changed component does not work properly or if it needs more fixes.
• UI developers always need more redeployment, which is quite risky and time-consuming for large monolithic applications.

The preceding issues can be tackled very easily by microservices . For example, UI developers may have their own UI component that can be developed, built, tested, and deployed separately. Similarly, other microservices might also be deployable independently and, because of their autonomous characteristics, the risk of system failure is reduced. Another advantage for development purposes is that UI developers can make use of JSON objects and mock Ajax calls to develop the UI, which can be taken up in an isolated manner. After development is finished, developers can consume the actual APIs and test the functionality. To summarize, you could say that microservices development is swift and it aligns well with the incremental needs of businesses.

Generally, large monolithic application code is the toughest to understand for developers, and it takes time before a new developer can become productive. Even loading the large monolithic application into an integrated development environment ( IDE ) is troublesome, as it makes the IDE slower and the developer less productive.

A change in a large monolithic application is difficult to implement and takes more time due to the large code base, and there can also be a high risk of bugs if impact analysis is not done properly and thoroughly. Therefore, it becomes a prerequisite for developers to do a thorough impact analysis before implementing any changes.

In monolithic applications, dependencies build up over time as all components are bundled together. Therefore, the risk associated with code changes rises exponentially as the amount of modified lines of code grows.

When a code base is huge and more than 100 developers are working on it, it becomes very difficult to build products and implement new features because of the previously mentioned reason. You need to make sure that everything is in place, and that everything is coordinated. A well-designed and documented API helps a lot in such cases.

Netflix, the on-demand internet streaming provider, had problems getting their application developed, with around 100 people working on it. Then, they used a cloud service and broke up the application into separate pieces. These ended up being microservices. Microservices grew from the desire for speed and agility and to deploy teams independently.

Microcomponents are made loosely coupled thanks to their exposed APIs, which can be continuously integration tested. With microservices ' continuous release cycle, changes are small and developers can rapidly exploit them with a regression test, then go over them and fix the defects found, reducing the risk of a flawed deployment. This results in higher velocity with a lower associated risk.

Owing to the separation of functionality and the single responsibility principle, microservices make teams very productive. You can find a number of examples online where large projects have been developed with very low team sizes, such as 8 to 10 developers.

Developers can have better focus with smaller code bases and better feature implementation, leading to a higher empathetic relationship with the users of the product. This conduces better motivation and clarity in feature implementation. An empathetic relationship with users allows for a shorter feedback loop and better and speedier prioritization of the feature pipeline. A shorter feedback loop also makes defect detection faster.

Each microservices team works independently and new features or ideas can be implemented without being coordinated with larger audiences. The implementation of endpoint failure handling is also easily achieved in the microservices design.

At a recent conference, a team demonstrated how they had developed a microservices -based transport-tracking application for iOS and Android, within 10 weeks, with Uber-type tracking features. A big consulting firm gave a seven-month estimation for this application to its client. This shows how the microservices design is aligned with agile methodologies and CI/CD.

So far, we have discussed only the microservices design—there are also nanoservices, teraservices, and serverless designs to explore.

Microservices that are especially small or fine-grained are called nanoservices. A nanoservices pattern is really an  anti-pattern .

In the case of nanoservices, overheads such as communication and maintenance activities outweigh its utility. Nanoservices should be avoided. An example of a nanoservices (anti-) pattern would be creating a separate service for each database table and exposing its CRUD operation using events or a REST API.

Teraservices are the opposite of microservices. The teraservices design entails a sort of a monolithic service. Teraservices require two terabytes of memory, or more. These services could be used when services are required only to be in memory and have high usage.

These services are quite costly in cloud environments due to the memory needed, but the extra cost can be offset by changing from quad-core servers to dual-core servers.

Such a design is not popular.

Serverless is another popular cloud architecture offered by cloud platforms such as AWS. There are servers, but they are managed and controlled by cloud platforms.

This architecture enables developers to simply focus on code and implementing functionality. Developers need not worry about scale or resources (for instance, OS distributions as with Linux, or message brokers such as RabbitMQ ) as they would with coded services.

A serverless architecture offers development teams the following features: zero administration, auto-scaling, pay-per-use schemes, and increased velocity. Because of these features, development teams just need to care about implementing functionality rather than the server and infrastructure.

CI and CD are important parts of today's development process. Therefore, having a proper pipeline for building, and for containerized delivery, is discussed in the following sub-sections.

Microservices can be built and tested using popular CI/CD tools, such as Jenkins and TeamCity. This is done very similarly to how a build is done in a monolithic application. In a microservices architecture, each microservice is treated like a small application.

For example, once you commit the code in the repository (SCM), CI/CD tools trigger the build process:

1. Cleaning code
2. Code compilation
3. Unit test execution
4. Contract/acceptance test execution
5. Building the application archives/container images
6. Publishing the archives/container images to repository management
7. Deployment on various delivery environments such as development, quality assurance, and staging environments
8. Integration and functional test execution
9. Any other steps

Then, release-build triggers, which change the SNAPSHOT or RELEASE version in pom.xml (in the case of Maven), build the artifacts as described in the normal build trigger, publish the artifacts to the artifacts repository, and tag the version in the repository. If you use the container image, then build the container image as a part of the build.

Because of the design of microservices , you need to have an environment that provides flexibility, agility, and smoothness for CI and CD as well as for shipment. M icroservice deployments need speed, isolation management, and an agile life cycle.

Products and software can also be shipped using an intermodal-container model. An intermodal container is a large standardized container, designed for intermodal freight transport. It allows cargo to use different modes of transport—truck, rail, or ship—without unloading and reloading. This is an efficient and secure way of storing and transporting goods. It resolves the problem of shipping, which previously had been a time-consuming, labor-intensive process, and repeated handling often broke fragile goods.

Shipping containers encapsulate their content. Similarly, software containers are starting to be used to encapsulate their content (such as products, applications, and dependencies).

Previously, Virtual Machines ( VMs ) were used to create software images that could be deployed where needed. Later, containerization engines such as Docker became more popular as they were compatible with both traditional virtual stations systems and cloud environments. For example, it is not practical to deploy more than a couple of VMs on a developer's laptop. Building and booting a VM is usually I/O intensive and consequently slow.

A container provides a lightweight runtime environment consisting of the core features of VMs and the isolated services of OSes. This makes the packaging and execution of microservices easy and smooth.

As the following diagram shows, a container runs as an application (microservice) within the OS. The OS sits on top of the hardware and each OS could have multiple containers, with one container running the application.

A container makes use of an OS' kernel interfaces, such as cnames and namespaces , which allow multiple containers to share the same kernel while running in complete isolation of one another. This gives the advantage of not having to complete an OS installation for each usage; the result is that the overhead is removed. This also makes optimal use of the hardware:

Container technology is one of the fastest growing technologies today, and Docker is leading it. Docker is an open source project and it was launched in 2013. 10,000 developers tried it after its interactive tutorial launched in August 2013. It was downloaded 2.75 million times by the time of the launch of its 1.0 release in June 2013. Many large companies have signed a partnership agreement with Docker, such as Microsoft, Red Hat, HP, OpenStack, and service providers such as AWS, IBM, and Google.

As we mentioned earlier, Docker also makes use of Linux kernel features, such as cgroups and namespaces, to ensure resource isolation and the packaging of the application with its dependencies. This packaging of dependencies enables an application to run as expected across different Linux OSes/distributions, supporting a level of portability. Furthermore, this portability allows developers to develop an application in any language and then easily deploy it from a laptop to a test or production server.

Containers are comprised of just the application and its dependencies, including the basic OS. This makes the application lightweight and efficient in terms of resource utilization. Developers and system administrators are interested in a container's portability and efficient resource utilization.

Everything in a Docker container executes natively on the host and uses the host kernel directly. Each container has its own user namespace.

As specified on the Docker documentation, Docker architecture uses a client-server architecture. The Docker client is basically a user interface that is used by an end user; clients communicate back and forth with a Docker daemon. The Docker daemon does the heavy lifting of the building, running, and distributing of your Docker containers. The Docker client and the daemon can run on the same system or on different machines.

The Docker client and daemon communicate via sockets or through a RESTful API. Docker registers are public or private Docker image repositories from which you upload or download images; for example, Docker Hub ( hub.docker.com ) is a public Docker registry.

The primary components of Docker are the following:

• Docker image : A Docker image is a read-only template. For example, an image could contain an Ubuntu OS with an Apache web server and your web application installed. Docker images are build components of Docker, and images are used to create Docker containers. Docker provides a simple way to build new images or update existing images. You can also use images created by others and/or extend them.
• Docker container : A Docker container is created from a Docker image. Docker works so that the container can only see its own processes, and have its own filesystem layered onto a host filesystem and a networking stack, which pipes to the host-networking stack. Docker containers can be run, started, stopped, moved, or deleted.

For more information, you can take a look at the overview of Docker that is provided by Docker ( https://docs.docker.com/engine/docker-overview/ ).

Microservices deployment with Docker involves three things:

• Application packaging, for example, JAR.
• Building a Docker image with a JAR and dependencies using a Docker instruction file, a Dockerfile , and the docker build command. This allows you to repeatedly create images.
• Docker container execution from this newly built image using docker run .

The preceding information will help you to understand the basics of Docker. You will learn more about Docker and its practical usage in Chapter 4 , Implementing a Microservice . For more information, refer to https://docs.docker.com .

In this chapter, you have learned about or recapped the high-level design of large software projects, from traditional monolithic applications to microservices-based applications. You were also introduced to a brief history of microservices , the limitations of monolithic applications, and the benefits and flexibility that microservices offer. I hope this chapter helped you to understand the common problems faced in a production environment by monolithic applications and how microservices can resolve such problems. You were also introduced to lightweight and efficient Docker containers and saw how containerization is an excellent way to simplify microservices deployment.

In the next chapter, you will learn about setting up a development environment, looking at everything from your IDE and other development tools, to different libraries. We will deal with creating basic projects and setting up a Spring Boot configuration to build and develop our first microservice. We will be using Java 11 as the language and Spring Boot for our project.

This chapter focuses on the development environment setup and configurations. If you are familiar with the tools and libraries, you could skip this chapter and continue with Chapter 3 , Domain-Driven Design , where you can explore domain-driven design ( DDD ).

This chapter will cover the following topics:

• Spring Boot
• REST
• An embedded web server
• Testing using Postman
• Maven

This book will use only the open source tools and frameworks for examples and code. This book will also use Java 11 as its programming language, while the application framework will be based on the Spring Framework. It will also make use of Spring Boot for developing microservices.

Eclipse, IntelliJ IDEA, and NetBeans' Integrated Development Environment ( IDE ) provide state-of-the-art support for both Java and JavaScript, and is sufficient for our needs. These have evolved a lot over the years and have built-in support for most of the technologies used by this book, including Maven, and Spring Boot. Therefore, I would recommend using any of these IDEs. You are, however, better off using IDEs that support Java 11.

We will use Spring Boot to develop the REST services and microservices. Opting for the most popular offering of Spring Framework, Spring Boot, or its subset, Spring Cloud, in this book was a conscious decision. Because of this, we don't need to write applications from scratch and it provides the default configuration for most of the technologies used in cloud applications. A Spring Boot overview is provided in Spring Boot's configuration section. If you are new to Spring Boot, this would definitely help you.

We will use Maven as our build tool. As with the IDE, you can use whichever build tool you want; for example, Gradle, or Ant with Ivy. We will use an embedded Jetty server as our web server, but another alternative is to use an embedded Tomcat web server. We will also use the Postman extension of Chrome for testing our REST services.

We will start with Spring Boot configurations. You can either create fresh new projects or import the project (Maven) using source code hosted on GitHub.

Spring Boot is an obvious choice for developing state-of-the-art, production-ready applications specific to Spring. Its website ( https://projects.spring.io/spring-boot/ ) also states its real advantages

Spring Boot is an amazing Spring tool created by Pivotal that was released in April 2014 (GA). It was developed based on the request of SPR-9888 ( https://jira.spring.io/browse/SPR-9888 ) with the title, Improved support for 'containerless' web application architectures .

You must be wondering: Why containerless? Because, today's cloud environment, or PaaS, provides most of the features offered by container-based web architectures, such as reliability, management, or scaling. Therefore, Spring Boot focuses on making itself an ultralight container.

Spring Boot is preconfigured to make production-ready web applications very easily. Spring Initializr ( http://start.spring.io ) is a page where you can select build tools, such as Maven or Gradle, along with project metadata, such as group, artifact, and dependencies. Once you feed the required fields, you can just click on the Generate Project button, which will give you the Spring Boot project that you can use for your production application.

On this page, the default Packaging option is Jar . We'll also use JAR packaging for our microservices development. The reason is very simple: it makes microservices development easier. Just think how difficult it would be to manage and create an infrastructure where each microservice runs on its own server instance.

Josh Long shared the following in his talk on one of the Spring IOs:

Later, we will use Spring Cloud, which is a wrapper on top of Spring Boot.

We will develop a sample REST application that will use the Java 9 module feature. We will create two modules— lib and rest . The lib module will provide the models or any supported classes to the rest module. The rest module will include all the classes that are required to develop the REST application and it will also consume the model classes defined in the lib module.

Both the lib and rest modules are maven modules, and their parent module is our main project, 6392_chapter2 .

The module-info.java file is an important class that governs the access of its classes. We'll make use of requires , opens , and exports to use the spring modules and establish the provider-consumer relationship between the lib and rest modules of our REST application.

We will use Java 11 to develop microservices. Therefore, we'll use the latest Spring Framework and Spring Boot project. At the time of writing, Spring Boot 2.1.0 M2 release version is available.

You can use the latest released version. Spring Boot 2.1.0 M2 snapshot uses Spring 5 (5.1.0 M2 release).

Now, let's take a look at the following steps and learn about adding Spring Boot to our main project:

1. Open the pom.xml file (available under Chapter2 | Project Files ) to add Spring Boot to your sample project:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0   
   http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>

   <groupId>com.packtpub.mmj</groupId>
   <artifactId>11537_chapter2</artifactId>
   <version>1.0-SNAPSHOT</version>
   <packaging>pom</packaging>

   <modules>
      <module>lib</module>
      <module>rest</module>
   </modules>

   <properties>
      <project.build.sourceEncoding>UTF-8
         </project.build.sourceEncoding>
      <maven.compiler.source>11</maven.compiler.source>
      <maven.compiler.target>11</maven.compiler.target>
      <start-class>com.packtpub.mmj.rest.RestSampleApp
      </start-class>
   </properties>
   <parent>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-parent</artifactId>
      <version>2.1.0.M2</version>
   </parent>
   <dependencyManagement>
      <dependencies>
         <dependency>
            <groupId>com.packtpub.mmj</groupId>
            <artifactId>rest</artifactId>
            <version>${project.version}</version>
         </dependency>
         <dependency>
            <groupId>com.packtpub.mmj</groupId>
            <artifactId>lib</artifactId>
            <version>${project.version}</version>
         </dependency>
      </dependencies>
   </dependencyManagement>

   <build>
      <plugins>
         <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <executions>
               <execution>
                  <goals>
                     <goal>repackage</goal>
                  </goals>
                  <configuration>
                     <classifier>exec</classifier>
                     <mainClass>${start-class}</mainClass>
                  </configuration>
               </execution>
            </executions>
         </plugin>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
               <release>11</release>
               <source>1.11</source>
               <target>1.11</target>
               <executable>${JAVA_1_11_HOME}/bin/javac</executable>
               <showDeprecation>true</showDeprecation>
               <showWarnings>true</showWarnings>
            </configuration>
            <dependencies>
               <dependency>
                  <groupId>org.ow2.asm</groupId>
                  <artifactId>asm</artifactId>
                  <version>6.2</version> 
                  <!-- Use newer version of ASM -->
               </dependency>
            </dependencies>
         </plugin>
      </plugins>
   </build>
   <repositories>
      <repository>
         <id>spring-snapshots</id>
         <name>Spring Snapshots</name>
         <url>https://repo.spring.io/snapshot</url>
         <snapshots>
            <enabled>true</enabled>
         </snapshots>
      </repository>
      <repository>
         <id>spring-milestones</id>
         <name>Spring Milestones</name>
         <url>https://repo.spring.io/milestone</url>
         <snapshots>
            <enabled>false</enabled>
         </snapshots>
      </repository>
   </repositories>

   <pluginRepositories>
      <pluginRepository>
         <id>spring-snapshots</id>
         <name>Spring Snapshots</name>
         <url>https://repo.spring.io/snapshot</url>
         <snapshots>
            <enabled>true</enabled>
         </snapshots>
      </pluginRepository>
      <pluginRepository>
         <id>spring-milestones</id>
         <name>Spring Milestones</name>
         <url>https://repo.spring.io/milestone</url>
         <snapshots>
            <enabled>false</enabled>
         </snapshots>
      </pluginRepository>
   </pluginRepositories>
</project>

You can observe that we have defined our two modules, lib and rest , in the pom.xml parent project.

2. If you are adding these dependencies for the first time, project build would download these dependencies.
3. Similarly, to resolve the project problems, right-click on the NetBeans project, 6392_chapter2 , and opt for the Resolve Project Problems... . It will open the dialog shown as follows. Click on the Resolve... button to resolve the issues.
4. If you are using Maven behind the proxy, then update the proxies in settings.xml in the Maven home directory. If you are using the Maven bundled with NetBeans, then use <NetBeans Installation Directory>\java\maven\conf\settings.xml . You may need to restart the NetBeans IDE.

The preceding steps will download all the required dependencies from a remote Maven repository if the declared dependencies and transitive dependencies are not available in a local Maven repository. If you are downloading the dependencies for the first time, then it may take a bit of time, depending on your internet speed.

Spring Boot adopts the simplest approach to building a standalone application that runs on an embedded web server. It creates an executable archive (JAR) file that contains everything, including an entry point defined by a class that contains the main() method. For making it an executable JAR file, you use Spring's support for embedding the Jetty servlet container as the HTTP runtime, instead of deploying it to an external instance for execution.

Therefore, we would create the executable JAR file in place of the WAR that needs to be deployed on external web servers, which is a part of the rest module. We'll define the domain models in the lib module and API related classes in the rest module.

We need to create separate pom.xml files for the lib and rest modules, respectively.

The pom.xml file of the lib module is as follows:

<?xml version="1.0" encoding="UTF-8"?> 
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> 
    <modelVersion>4.0.0</modelVersion> 
    <parent> 
        <groupId>com.packtpub.mmj</groupId> 
        <artifactId>11537_chapter2</artifactId> 
        <version>1.0-SNAPSHOT</version> 
    </parent> 
    <artifactId>lib</artifactId> 
</project> 

The pom.xml file of the rest module is as follows:

    <modelVersion>4.0.0</modelVersion> 
    <parent> 
        <groupId>com.packtpub.mmj</groupId> 
        <artifactId>11537_chapter2</artifactId> 
        <version>1.0-SNAPSHOT</version> 
    </parent> 
    <artifactId>rest</artifactId> 
  <dependencies> 
        <dependency> 
            <groupId>com.packtpub.mmj</groupId> 
            <artifactId>lib</artifactId> 
        </dependency> 
        <dependency> 
            <groupId>org.springframework.boot</groupId> 
            <artifactId>spring-boot-starter-web</artifactId> 
    ... 
    ...  

Here, the spring-boot-starter-web dependency is used for developing the standalone executable REST service.

Now, we need to define modules using the module-info.java class in the lib and rest modules in their default package, respectively.

The module-info.java file in the lib module is as follows:

module com.packtpub.mmj.lib { 
    exports com.packtpub.mmj.lib.model to com.packtpub.mmj.rest; 
    opens com.packtpub.mmj.lib.model; 
} 

Here, we are exporting the com.packtpub.mmj.lib.model package to com.packtpub.mmj.rest , which allows access on the part of the lib model classes to the rest module classes.

The module-info.java file in the lib module is as follows :

module com.packtpub.mmj.rest { 
 
    requires spring.core; 
    requires spring.beans; 
    requires spring.context; 
    requires spring.aop; 
    requires spring.web; 
    requires spring.expression; 
 
    requires spring.boot; 
    requires spring.boot.autoconfigure; 
 
    requires com.packtpub.mmj.lib; 
 
    exports com.packtpub.mmj.rest; 
    exports com.packtpub.mmj.rest.resources; 
 
    opens com.packtpub.mmj.rest; 
    opens com.packtpub.mmj.rest.resources; 
} 

Here, module definition contains all the requisite spring  modules and our own created com.packtpub.mmj.lib packages by using the requires statement. This allows rest module classes to use classes defined in the spring modules and the newly created lib module. Also, we're exporting and opening the com.packt.mmj.rest and com.packt.mmj.rest.resources packages.

Now, as you are ready regarding which module to utilize, you can create a sample web service. You will create a math API that performs simple calculations and generates the response in JSON format.

Let's discuss how we can call and get responses from REST services.

The service will handle the GET requests for /calculation/sqrt or /calculation/power , and so on. The GET request should return a 200 OK response with JSON in the body that represents the square root of a given number. It should look something like this:

{ 
  "function": "sqrt", 
  "input": [ 
    "144" 
  ], 
  "output": [ 
    "12.0" 
  ] 
} 

The input field is the input parameter for the square root function, and the content is the textual representation of the result.

You could create a resource representation class to model the representation by using Plain Old Java Object ( POJO ) with fields, constructors, setters, and getters for the input, output, and function data. Since it is a model, we'll create it in the lib module:

package com.packtpub.mmj.lib.model; 
 
import java.util.List; 
 
public class Calculation { 
 
    String function; 
    private List<String> input; 
    private List<String> output; 
 
    public Calculation(List<String> input, 
    List<String> output, String function) { 
        this.function = function; 
        this.input = input; 
        this.output = output; 
    }  
    public List<String> getInput() { 
        return input; 
    }  
    public void setInput(List<String> input) { 
        this.input = input; 
    }  
    public List<String> getOutput() { 
        return output; 
    } 
 
    public void setOutput(List<String> output) { 
        this.output = output; 
    }  
    public String getFunction() { 
        return function; 
    }  
    public void setFunction(String function) { 
        this.function = function; 
    }  
} 

You could say that Roy Fielding is the father of Representational State Transfer ( REST ), given that he had defined this term in his doctoral dissertation. REST is a style of software architecture that amazingly utilizes the existing HTTP/S protocols. RESTful systems comply with REST architecture properties, principles, and constraints.

Now, you'll create a REST controller to handle the Calculation resource. The REST controller class handles the HTTP requests in the Spring RESTful web service implementation.

@RestController is a class-level annotation used for the resource class introduced in Spring 4. It is a combination of @Controller and @ResponseBody , and because of it, a class returns a domain object instead of a view.

In the following code, you can see that the CalculationController class handles GET requests for /calculation by returning a new instance of the calculation class.

We will implement two URIs for a Calculation resource—the square root (the Math.sqrt() function) as the /calculations/sqrt URI, and power (the Math.pow() function) as the /calculation/power URI.

The @RequestMapping annotation is used at class level to map the /calculation URI to the CalculationController class; that is, it ensures that the HTTP request to /calculation is mapped to the CalculationController class. Based on the path defined using the @RequestMapping annotation of the URI (postfix of /calculation , for example, /calculation/sqrt/144 ), it would be mapped to the respective methods. Here, the request mapping, /calculation/sqrt , is mapped to the sqrt() method, and /calculation/power is mapped to the pow() method.

You might have also observed that we have not defined what request method ( GET / POST / PUT , and so on) these methods would use. The @RequestMapping annotation maps all the HTTP request methods by default. You could use specific methods by using the method property of RequestMapping . For example, you could write a @RequestMethod annotation in the following way to use the POST method:

@RequestMapping(value = "/power", method = POST) 

For passing the parameters along the way, the sample demonstrates both request parameters and path parameters using the @RequestParam and @PathVariable annotations, respectively.

@RequestParam is responsible for binding the query parameter to the parameter of the controller's method. For example, the QueryParam base and exponent are bound to parameters b and e of the pow() method of CalculationController , respectively. Both of the query parameters of the pow() method are required, since we are not using any default value for them. Default values for query parameters could be set using the defaultValue property of @RequestParam , for example, @RequestParam(value="base", defaultValue="2") . Here, if the user does not pass the query parameter base, then the default value 2 would be used for the base.

If no defaultValue is defined, and the user doesn't provide the request parameter, then RestController returns the HTTP status code 400 with the message Required String parameter 'base' is not present . It always uses the reference of the first parameter required if more than one of the request parameters is missing:

{ 
  "timestamp": 1464678493402, 
  "status": 400, 
  "error": "Bad Request", 
  "exception": "org.springframework.web.bind.MissingServletRequestParameterException", 
  "message": "Required String parameter 'base' is not present", 
  "path": "/calculation/power/" 
} 

@PathVariable helps you to create the dynamic URIs. The @PathVariable annotation allows you to map Java parameters to a path parameter. It works with @RequestMapping , where the placeholder is created in a URI, and then the same placeholder name is used either as a PathVariable or a method parameter, as you can see in the CalculationController class method sqrt() . Here, the value placeholder is created inside the @RequestMapping annotation and the same value is assigned to the value of the @PathVariable .

The sqrt() m ethod takes the parameter in the URI in place of the request parameter, for example, http://localhost:8080/calculation/sqrt/144 . Here, the 144 value is passed as the path parameter and this URL should return the square root of 144 , which is 12 .

To use the basic check in place, we use the regular expression, "^-?+\\d+\\.?+\\d*$" , to allow only valid numbers in parameters.

If non-numeric values are passed, the respective method adds an error message to the output key of the JSON:

The following is the code of the CalculationController resource, where we have implemented two REST endpoints:

package com.packtpub.mmj.rest.resources; 
 
import com.packtpub.mmj.lib.model.Calculation; 
import java.util.ArrayList; 
import java.util.List; 
import org.springframework.web.bind.annotation.PathVariable; 
import org.springframework.web.bind.annotation.RequestMapping; 
import static org.springframework.web.bind.annotation.RequestMethod.GET; 
import org.springframework.web.bind.annotation.RequestParam; 
import org.springframework.web.bind.annotation.RestController; 
 
/** 
 * 
 * @author sousharm 
 */ 
@RestController 
@RequestMapping("calculation") 
public class CalculationController { 
 
    private static final String PATTERN = "^-?+\\d+\\.?+\\d*$"; 
 
    /** 
     * 
     * @param b 
     * @param e 
     * @return 
     */ 
    @RequestMapping("/power") 
    public Calculation pow(@RequestParam(value = "base") String b, @RequestParam(value = "exponent") String e) { 
        List<String> input = new ArrayList(); 
        input.add(b); 
        input.add(e); 
        List<String> output = new ArrayList(); 
        String powValue; 
        if (b != null && e != null && b.matches(PATTERN) && e.matches(PATTERN)) { 
            powValue = String.valueOf(Math.pow(Double.valueOf(b), Double.valueOf(e))); 
        } else { 
            powValue = "Base or/and Exponent is/are not set to numeric value."; 
        } 
        output.add(powValue); 
        return new Calculation(input, output, "power"); 
    } 
 
    /** 
     * 
     * @param aValue 
     * @return 
     */ 
    @RequestMapping(value = "/sqrt/{value:.+}", method = GET) 
    public Calculation sqrt(@PathVariable(value = "value") String aValue) { 
        List<String> input = new ArrayList<>(); 
        input.add(aValue); 
        List<String> output = new ArrayList<>(); 
        String sqrtValue; 
        if (aValue != null && aValue.matches(PATTERN)) { 
            sqrtValue = String.valueOf(Math.sqrt(Double.valueOf(aValue))); 
        } else { 
            sqrtValue = "Input value is not set to numeric value."; 
        } 
        output.add(sqrtValue); 
        return new Calculation(input, output, "sqrt"); 
    } 
} 

Here, we are exposing only the power and sqrt functions for the Calculation resource using the /calculation/power and /calculation/sqrt URIs.

One interesting thing here is that due to Spring's HTTP message converter support, the Calculation object gets converted to JSON automatically. You don't need to do this conversion manually. If Jackson 2 is on the classpath, Spring's MappingJackson2HttpMessageConverter converts the Calculation object to JSON.

Create a RestSampleApp class using the SpringBootApplication annotation. The main() method uses Spring Boot's SpringApplication.run() method to launch an application.

We will annotate the RestSampleApp class with the @SpringBootApplication annotation that adds all of the following tags implicitly:

• The @Configuration annotation tags the class as a source of bean definitions for the application context.
• The @EnableAutoConfiguration annotation indicates that Spring Boot is to start adding beans based on classpath settings, other beans, and various property settings.
• The @EnableWebMvc annotation is added if Spring Boot finds spring-webmvc on the classpath. It treats the application as a web application and activates key behaviors, such as setting up DispatcherServlet .
• The @ComponentScan annotation tells Spring to look for other components, configurations, and services in the given package:

package com.packtpub.mmj.rest; 
 
import org.springframework.boot.SpringApplication; 
import org.springframework.boot.autoconfigure.SpringBootApplication; 
 
@SpringBootApplication 
public class RestSampleApp { 
 
    public static void main(String[] args) { 
        SpringApplication.run(RestSampleApp.class, args); 
    } 
}

This web application is 100 percent pure Java and you don't have to deal with configuring any plumbing or infrastructure using XML; instead, it uses the Java annotation that is made even simpler by Spring Boot. Therefore, there wasn't a single line of XML, except pom.xml for Maven; there wasn't even a web.xml file.

Spring Boot, by default, provides Apache Tomcat as an embedded application container. This book will use the Jetty-embedded application container in place of Apache Tomcat. Therefore, we need to add a Jetty application container dependency to support the Jetty web server.

Jetty also allows you to read keys or trust stores using classpaths; that is, you don't need to keep these stores outside the JAR files. If you use Tomcat with SSL, then you will need to access the key store or trust store directly from the filesystem, but you can't do that using the classpath. The result is that you can't read a key store or a trust store within a JAR file because Tomcat requires that the key store (and trust store if you're using one) is directly accessible on the filesystem. This situation may change after this book has been written.

This limitation doesn't apply to Jetty, which allows the reading of keys or trust stores within a JAR file. A relative section on the pom.xml file of the rest module is as follows:

<dependencies> 
  <dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-web</artifactId> 
    <exclusions> 
      <exclusion> 
        <groupId>org.springframework.boot</groupId> 
        <artifactId>spring-boot-starter-tomcat</artifactId> 
      </exclusion> 
    </exclusions> 
  </dependency> 
  <dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-jetty</artifactId> 
  </dependency> 
</dependencies>

Maven's pom.xml build file contains the description that would allow the REST sample service code to compile, build, and execute. It packages the executable code inside a JAR file. We can choose one of the following options to execute the packaged executable JAR file:

• Running the Maven tool
• Executing with the Java command

The following sections will cover them in detail.

All popular IDEs, such as Eclipse, Netbeans, and IntelliJ IDEA, support Java 11 and Spring. You can use any of the preferred IDEs having Java 11 support.

Here, we use the Maven executable to package the generated JAR file. The steps for this are as follows:

1. Right-click on the pom.xml file for Eclipse/NetBeans IDE. For IntelliJ, use the Run menu.
2. For NetBeans, select Run Maven | Goals... from the pop-up menu. It will open the dialog. Type spring-boot:run in the Goals field. We have used the released version of Spring Boot in the code. However, if you are using the snapshot release, you can check the Update Snapshots checkbox. To use it in the future, type spring-boot-run in the Remember as field. For Eclipse/IntelliJ IDEA, use the respective fields.

Â

3. Next time, you could directly click Run | Maven | Goals | spring-boot-run to execute the project or on the basis of a similar option in the respective IDE:

4. Click OK to execute the project.

Please make sure that Java and JAVA_HOME is set to Java 11 before executing the following commands.

Observe the following steps:

1. To build the JAR file, perform the mvn clean package command from the Command Prompt from the parent project root directory ( Chapter2 ). Here, clean and package are Maven goals:

mvn clean package

2. This creates the JAR files in a respective target directory. We will now execute the JAR files generated in the Chapter2\rest\target directory. A JAR file can be executed using the following command:

java -jar rest\target\rest-1.0-SNAPSHOT-exec.jar

This book uses the Postman tool for REST service testing. I have used the 6.2.5 version of Postman.

Let's test our first REST resource once you have the Postman—REST client installed. We start the Postman—REST client from either the Start menu or from a shortcut.

By default, the embedded web server starts on port 8080 . Therefore, we need to use the http://localhost:8080/<resource> URL for accessing the sample REST application, for example, http://localhost:8080/calculation/sqrt/144 .

Once it's started, you can type the Calculation REST URL for sqrt and the value 144 as the path parameter. You can see it in the following screenshot. This URL is entered in the URL (enter request URL here) input field of the Postman extension. By default, the request method is GET . We use the default value for the request method, as we have also written our RESTful service to serve the request GET method.

Once you are ready with your input data as mentioned earlier, you can submit the request by clicking the Send button. You can see in the following screenshot that the response code 200 is returned by your sample REST service. You can find the Status label in the following screenshot to view the 200 OK code. A successful request also returns the JSON data of the Calculation resource, shown in the Pretty tab in the screenshot.

The returned JSON shows the sqrt method value of the function key. It also displays 144 and 12.0 as the input and output lists, respectively:

Similarly, we also test our sample REST service for calculating the power function. We input the following data in the Postman extension:

• URL : http://localhost:8080/calculation/power?base=2&exponent=4
• Request method : GET

Here, we are passing the request parameters, base and exponent , with values of 2 and 4 , respectively. This returns the following JSON:

{ 
    "function": "power", 
    "input": [ 
        "2", 
        "4" 
    ], 
    "output": [ 
        "16.0" 
    ] 
}

This returns the preceding JSON with a response status of 200 OK, as shown in the following screenshot:

In the following table, all the URLs start with http://localhost:8080 :

{   
    "function":   "sqrt",   
    "input":   [   
        "12344.234"   
    ],   
    "output":   [   
        "111.1046083652699"   
    ]   
}   

{   
    "function":   "sqrt",   
    "input":   [   
        "-9344.34"   
    ],   
    "output":   [   
        "NaN"   
    ]   
}   

{   
    "function":   "power",   
    "input":   [   
        "2.09",   
        "4.5"   
    ],   
    "output":   [   
        "27.58406626826615"   
    ]   
}   

{   
    "function":   "power",   
    "input":   [   
        "-92.9",   
        "-4"   
    ],   
    "output":   [   
        "1.3425706351762353E-8"   
    ]   
}   

Similarly, you could also perform some negative scenarios, as shown in the following table. In this table, all the URLs start with http://localhost:8080 :

{   
    "function":   "power",   
    "input":   [   
        "2a",   
        "4"   
    ],   
    "output":   [   
        "Base   or/and Exponent is/are not set to numeric value."   
    ]   
}   

{   
    "function":   "power",   
    "input":   [   
        "2",   
        "4b"   
    ],   
    "output":   [   
        "Base   or/and Exponent is/are not set to numeric value."   
    ]   
}   

{   
    "function":   "power",   
    "input":   [   
        "2.0a",   
        "a4"   
    ],   
    "output":   [   
        "Base   or/and Exponent is/are not set to numeric value."   
    ]   
}   

{   
    "function":   "sqrt",   
    "input":   [   
        "144a"   
    ],   
    "output":   [   
        "Input   value is not set to numeric value."   
    ]   
}   

{   
    "function":   "sqrt",   
    "input":   [   
        "144.33$"   
    ],   
    "output":   [   
        "Input   value is not set to numeric value."   
    ]   
}   

In this chapter, you have explored various aspects of setting up a development environment, Maven configurations, Spring Boot configurations, and so on.

You have also learned how to make use of Spring Boot to develop a sample REST service application. We learned how powerful Spring Boot is—it eases development so much that you only have to worry about the actual code, and not about the boilerplate code or configurations that you write. We have also packaged our code into a JAR file with an embedded application container Jetty. This allows it to run and access the web application without worrying about the deployment.

In the next chapter, you will learn about domain-driven design ( DDD ) using a sample project that can be used across the remainder of the chapters. We'll use the online table reservation system ( OTRS ) sample project to go through various phases of microservices development and understand the DDD. After completing Chapter 3 , Domain-Driven Design, you will learn the fundamentals of DDD.

You will understand how to use the DDD by design sample services in practical terms. You will also learn to design the domain models and REST services on top of it.

The following are a few links that you can take a look at in order to learn more about the tools we used here:

• Spring Boot : http://projects.spring.io/spring-boot/
• Download NetBeans : https://netbeans.org/downloads
• Representational State Transfer ( REST ): Chapter 5 ( https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm ) of Roy Thomas Fielding's PhD dissertation entitled Architectural Styles and the Design of Network-based Software Architectures
• REST : https://en.wikipedia.org/wiki/Representational_state_transfer
• Maven : https://maven.apache.org/
• Gradle : http://gradle.org/

This chapter sets the tone for the rest of the chapters by referring to one sample project. The sample project will be used to explain different microservice concepts from here onward. This chapter uses this sample project to drive through different combinations of functional and domain services or applications to explain domain-driven design ( DDD ). It will help you to learn the fundamentals of DDD and its practical usage. You will also learn about concepts related to the design of domain models using REST services.

This chapter covers the following topics:

• The fundamentals of DDD
• How to design an application using DDD
• Domain models
• A sample domain model design based on DDD

Good software design is as much the key to the success of a product or service as the functionalities offered by it, adding equal weight to the success of the product; for example, Amazon provides a shopping platform, but its architecture design makes it different from other similar sites and contributes to its success. This shows how important a software or architecture design is to the success of a product/service. DDD is a software design practice, and we'll explore it with various theories and practical examples.

DDD is a key design practice that can be used to design the microservices of the product that you are developing. Therefore, we'll first explore DDD, before jumping into the development of microservices. After studying this chapter, you will understand the importance of DDD for microservices development.

An enterprise, or cloud application, solves business problems and other real-world problems. These problems cannot be resolved without knowledge of the particular domain. For example, you cannot provide a software solution for a financial system such as online stock trading if you don't understand stock exchanges and how they function. Therefore, having domain knowledge is a must for solving problems. Now, if you want to offer a solution such as software or an application, you need to have some domain knowledge to design it. Combining the domain and software design is a software design methodology known as DDD.

When we develop software to implement real-world scenarios offering the functionalities needed for a domain, we create a model of that domain. A model is an abstraction, or a blueprint, of the domain.

Designing this model is not rocket science, but it does take a lot of effort, refinement, and input from domain experts. This is the collective job of software designers, domain experts, and developers. They organize information, divide it into smaller parts, group them logically, and create modules. Each module can be taken up individually, and can be divided using a similar approach. This process can be followed until we reach the unit level, or until we cannot divide it any further. A complex project may have more such iterations; similarly, a simple project could have just a single iteration.

Once a model has been defined and well-documented, it can move onto the next stage—code design. So, here, we have a software design —a domain model and code design, and code implementation of the domain model. The domain model provides a high-level view of the architecture of a solution (software/application), and the code implementation gives the domain model a life, as a working model.

DDD makes design and development work together. It provides the ability to develop software continuously, while keeping the design up to date based on feedback received on the development. It solves one of the limitations of the agile and waterfall methodologies, making software maintainable, including its design and code, as well as keeping application minimum viable ( minimum viable product — MVP ).

Design-driven development involves a developer right from the initial stage, and software designers discuss the domain with domain experts at all meetings during the modeling process . This gives developers the right platform to understand the domain, and provides the opportunity to share early feedback on the domain model implementation. It removes the bottleneck that appears in later stages when stockholders wait for deliverables.

The fundamentals of DDD can broadly be categorized into two parts—building blocks, and strategic design and principles. These can be further categorized into different parts, shown as follows:

• Building blocks:
  • Ubiquitous language and Unified Model Language ( UML )
  • Multilayered architecture
  • Artifacts (components)
• Strategic design and principles:
  • Bounded context
  • Continuous integration
  • Context map

The following subsections explain the usage and importance of the building blocks of DDD.

Ubiquitous language is a common language to communicate with within a project. As we have seen, designing a model is the collective effort of software designers, domain experts, and developers; therefore, a common language is required to communicate with. DDD makes it necessary to use ubiquitous language. Domain models use ubiquitous language in their diagrams, descriptions, presentations, speeches, and meetings. It removes misunderstanding, misinterpretation, and communication gaps between them. Therefore, it must be included in all diagrams, descriptions, presentations, meetings, and so on—in short, in everything.

UML is widely used and is very popular when creating models. It also has a few limitations; for example, when you have thousands of classes drawn from a paper, it's difficult to represent class relationships and simultaneously understand their abstraction while taking meaning from it. Also, UML diagrams do not represent the concepts of a model and what objects are supposed to do. Therefore, UML should always be used with other documents, code, or any other reference material for effective communication.

Other ways to communicate a domain model include the use of documents, code, and so on.

Multilayered architecture is a common solution for DDD. It contains four layers:

1. A presentation layer or user interface ( UI ).
2. An application layer.
3. A domain layer.
4. An infrastructure layerÂ

The multilayered architecture can be seen in the following diagram as follows:

You can see in the preceding diagram that only the Domain layer is responsible for the domain model, and the other layers relate to other components, such as UI, application logic, and so on. This layered architecture is very important. It keeps domain-related code separate from other layers.

In multilayered architecture, each layer contains its respective code. This helps to achieve loose coupling and avoids mixing code from different layers. It also helps a product/service's long-term maintainability and contributes to easy enhancements, as a change to one-layer code does not impact on other components if the change is intended for the respective layer only. Each layer can be switched with another implementation easily with multitier architecture.

This layer represents the UI, and provides the user interface for interaction and the display of information. This layer could be a web application, mobile application, or a third-party application consuming your services.

This layer is responsible for application logic. It maintains and coordinates the overall flow of the product/service. It does not contain business logic or a UI. It may hold the state of application objects, such as tasks in progress. For example, your product's REST services would be part of this application layer.

The domain layer is a very important layer, as it contains domain information and business logic. It holds the state of the business object. It persists the state of business objects and communicates these persisted states to the infrastructure layer.

The infrastructure layer provides support to all the other layers and is responsible for communication between the other layers, for example, interaction with databases, message brokers, file systems, and so on. It contains the supporting libraries that are used by the other layers. It also implements the persistence of business objects.

To understand the interaction of the different layers, let's use an example of booking a table at a restaurant. The end user places a request for a table booking using the UI. The UI passes the request to the application layer. The application layer fetches domain objects, such as the restaurant, the table, a date, and so on, from the domain layer. The domain layer fetches these existing persisted objects from the infrastructure and invokes relevant methods to make the booking and persist them back to the infrastructure layer. Once domain objects are persisted, the application layer shows the booking confirmation to the end user.

There are seven different artifacts used in DDD to express, create, and retrieve domain models:

• Entities
• Value objects
• Services
• Aggregates
• A repository
• A factory
• A module

Entities are certain types of objects that are identifiable and remain the same throughout the different states of products/services. These objects are not identified by their attributes, but by their identity and thread of continuity. These types of objects are known as entities .

This sounds pretty simple, but it carries complexity. You need to understand how we can define entities. Let's take an example of a table-booking system, where we have a restaurant class with attributes such as restaurant name, address, phone number, establishment data, and so on. We can take two instances of the restaurant class that are not identifiable using the restaurant name, as there could be other restaurants with the same name. Similarly, if we go by any other single attribute, we will not find any attributes that can singularly identify a unique restaurant. If two restaurants have all the same attribute values, they are therefore the same and are interchangeable with each other. Still, they are not the same entities, as both have different references (memory addresses).

Conversely, let's take a class of US citizens. Each citizen has his or her own social security number. This number is not only unique, but remains unchanged throughout the life of the citizen and assures continuity. This citizen object would exist in the memory, would be serialized, and would be removed from the memory and stored in the database. It would even exist after the person is deceased. It would be kept in the system for as long as the system exists. A citizen's social security number remains the same irrespective of its representation.

Therefore, creating entities in a product means creating an identity . So, give an identity to any restaurant in the previous example, then either use a combination of attributes, such as restaurant name, establishment date, and street, or add an identifier such as restaurant_id to identify it. The basic rule is that two identifiers cannot be the same. Therefore, when we introduce an identifier for an entity, we need to be sure of it.

There are different ways to create a unique identity for objects, described as follows:

• Using the primary key in a table.
• Using an automated generated ID (generated by a domain module). A domain program generates the identifier and assigns it to objects that are being persisted between different layers.
• A few real-life objects carry user-defined identifiers themselves. For example, each country has its own country code for dialing ISD calls.
• Using a composite key. This is a combination of attributes that can also be used to create an identifier, as explained for the preceding restaurant object.

When an object can be identified by its identifier and not by its attributes, a class representing these objects should have a simple definition, and care should be taken with the life cycle continuity and identity. It's imperative to identify objects in this class that have the same attribute values. A defined system should return a unique result for each object if queried. Designers should ensure that the model defines what it means to be the same thing.

Value objects (VOs) simplify a design. Entities have traits such as an identity, a thread of continuity, and attributes that do not define their identity. In contrast to entities, value objects have only attributes and no conceptual identity . Best practice is to keep value objects as immutable objects. If possible, you should even keep entity objects immutable too.

Entity concepts may bias you toward keeping all objects as entities, as a uniquely identifiable object in the memory or database with life cycle continuity, but there has to be one instance for each object. Now, let's say you are creating customers as entity objects. Each customer object would represent the restaurant guest, and this cannot be used for booking orders for other guests.

This may create millions of customer entity objects in the memory if millions of customers are using the system. Not only are there millions of uniquely identifiable objects that exist in the system, but each object is being tracked. Tracking as well as creating an identity is complex. A highly credible system is required to create and track these objects, which is not only very complex, but also resource-heavy. It may result in system performance degradation. Therefore, it is important to use value objects instead of using entities. The reasons for this are explained in the next few paragraphs.

Applications don't always need to be traceable and have an identifiable customer object; there are cases when you just need to have some or all attributes of the domain element. These are the cases when value objects can be used by the application. This makes things simple and improves performance.

Value objects can easily be created and destroyed, owing to the absence of identity. This simplifies the design—it makes value objects available for garbage collection if no other object has referenced them.

Let's discuss the immutability of value objects. Value objects should be designed and coded as immutable. Once they have been created, they should never be modified during their life cycle. If you need a different value for the VO, or any of its objects, then simply create a new value object, but don't modify the original value object. Here, immutability carries all the significance from object-oriented programming ( OOP ). A value object can be shared and used without impacting on its integrity if, and only if, it is immutable.

FAQs

The following are the most commonly asked questions:

• Can a value object contain another value object?
  Yes, it can.
• Can a value object refer to another value object or entity?
  Yes, it can.
• Can I create a value object using the attributes of different value objects or entities?
  Yes, you can.

While creating the domain model, you may encounter various situations where behavior may not be related to any object specifically. These behaviors can be accommodated in service objects .

Service objects are a part of the domain layer that does not have any internal state. The sole purpose of service objects is to provide behavior to the domain that does not belong to a single entity or value object.

Ubiquitous language helps you to identify different objects, identities, or value objects with different attributes and behaviors during the process of domain modeling. During the course of creating the domain model, you may find different behaviors or methods that do not belong to any specific object. Such behaviors are important, and so cannot be neglected. Neither can you add them to entities or value objects. It would spoil the object to add behavior that does not belong to it. Keep in mind that behavior may impact on various objects. The use of object-oriented programming makes it possible to attach to some objects; these are known as services .

Services are common in technical frameworks. These are also used in domain layers in DDD. A service object does not have any internal state; the only purpose of it is to provide a behavior to the domain. Service objects provide behaviors that cannot be related to specific entities or value objects. Service objects may provide one or more related behaviors to one or more entities or value objects. It is best practice to define the services explicitly in the domain model.

When creating services, you need to check all of the following points:

• Service objects' behavior performs on entities and value objects, but it does not belong to entities or value objects
• Service objects' behavior state is not maintained, and hence, they are stateless
• Services are part of the domain model

Services may also exist in other layers. It is very important to keep domain-layer services isolated. This removes the complexities and keeps the design decoupled.

Let's take an example where a restaurant owner wants to see the report of his monthly table bookings. In this case, he will log in as an admin and click the Display Report button after providing the required input fields, such as duration.

Application layers pass the request to the domain layer that owns the report and templates objects, with some parameters such as report ID, and so on. Reports get created using the template, and data is fetched from either the database or other sources. Then the application layer passes through all the parameters, including the report ID to the business layer. Here, a template needs to be fetched from the database or another source to generate the report based on the ID. This operation does not belong to either the report object or the template object. Therefore, a service object is used that performs this operation to retrieve the required template from the database.

The aggregate domain pattern is related to the object's life cycle, and defines ownership and boundaries.

When you reserve a table at your favorite restaurant online using an application, you don't need to worry about the internal system and process that takes place to book your reservation, including searching for available restaurants, then for available tables on the given date, time, and so on and so forth. Therefore, you can say that a reservation application is an aggregate of several other objects, and works as a root for all the other objects for a table reservation system.

This root should be an entity that binds collections of objects together. It is also called the aggregate root . This root object does not pass any reference to inside objects to external worlds, and protects the changes performed within internal objects.

We need to understand why aggregates are required. A domain model can contain large numbers of domain objects. The bigger the application functionalities and size and the more complex its design, the greater number of objects present. A relationship exists between these objects. Some may have a many-to-many relationship, a few may have a one-to-many relationship, and others may have a one-to-one relationship. These relationships are enforced by the model implementation in the code, or in the database that ensures that these relationships between the objects are kept intact. Relationships are not just unidirectional; they can also be bidirectional. They can also increase in complexity.

The designer's job is to simplify these relationships in the model. Some relationships may exist in a real domain, but may not be required in the domain model. Designers need to ensure that such relationships do not exist in the domain model. Similarly, multiplicity can be reduced by these constraints. One constraint may do the job where many objects satisfy the relationship. It is also possible that a bidirectional relationship could be converted into a unidirectional relationship.

No matter how much simplification you input, you may still end up with relationships in the model. These relationships need to be maintained in the code. When one object is removed, the code should remove all the references to this object from other places. For example, a record removal from one table needs to be addressed wherever it has references in the form of foreign keys and such, to keep the data consistent and maintain its integrity. Also, invariant (rules) need to be forced and maintained whenever data changes.

Relationships, constraints, and invariant bring a complexity that requires efficient handling in code. We find the solution by using the aggregate represented by the single entity known as the root , which is associated with the group of objects that maintains consistency with regards to data changes.

This root is the only object that is accessible from outside, so this root element works as a boundary gate that separates the internal objects from the external world. Roots can refer to one or more inside objects, and these inside objects can have references to other inside objects that may or may not have relationships with the root. However, outside objects can also refer to the root, and not to any inside objects.

An aggregate ensures data integrity and enforces the invariant. Outside objects cannot make any changes to inside objects; they can only change the root. However, they can use the root to make a change inside the object by calling exposed operations. The root should pass the value of inside objects to outside objects if required.

If an aggregate object is stored in the database, then the query should only return the aggregate object. Traversal associations should be used to return the object when it is internally linked to the aggregate root. These internal objects may also have references to other aggregates.

An aggregate root entity holds its global identity, and holds local identities inside their entity.

A simple example of an aggregate in the table-booking system is the customer. Customers can be exposed to external objects, and their root object contains their internal object address and contact information.

When requested, the value object of internal objects, such as address, can be passed to external objects:

In a domain model, at a given point in time, many domain objects may exist. Each object may have its own life cycle, from the creation of objects to their removal or persistence. Whenever any domain operation needs a domain object, it should retrieve the reference of the requested object efficiently. It would be very difficult if you didn't maintain all of the available domain objects in a central object. A central object carries the references of all the objects, and is responsible for returning the requested object reference. This central object is known as the repository .

The repository is a point that interacts with infrastructures such as the database or filesystem. A repository object is the part of the domain model that interacts with storage such as the database, external sources, and so on, to retrieve persisted objects. When a request is received by the repository for an object's reference, it returns the existing object's reference. If the requested object does not exist in the repository, then it retrieves the object from storage. For example, if you need a customer, you would query the repository object to provide the customer with ID 31 . The repository would provide the requested customer object if it was already available in the repository, and if not, it would query the persisted stores, such as the database, fetch it, and provide its reference.

The main advantage of using the repository is having a consistent way to retrieve objects where the requester does not need to interact directly with storage such as the database.

A repository may query objects from various storage types, such as one or more databases, filesystems, or factory repositories, and so on. In such cases, a repository may have strategies that also point to different sources for different object types or categories:

As shown in the repository object flow diagram, the repository interacts with the i nfrastructure layer, and this interface is part of the domain layer . The requester may belong to a domain layer, or an application layer. The repository helps the system to manage the life cycle of domain objects.

A factory is required when a simple constructor is not enough to create the object. It helps to create complex objects, or an aggregate that involves the creation of other related objects.

A factory is also a part of the life cycle of domain objects, as it is responsible for creating them. Factories and repositories are in some way related to each other, as both refer to domain objects. The factory refers to newly created objects, whereas the repository returns the pre-existing objects either from the memory, or from external storage.

Let's see how control flows, by using a user creation process application. Let's say that a user signs up with a username, user1 . This user creation first interacts with the factory, which creates the name user1 and then caches it in the domain using the repository, which also stores it in the storage for persistence.

When the same user logs in again, the call moves to the repository for a reference. This uses the storage to load the reference and pass it to the requester.

The requester may then use this user1 object to book the table in a specified restaurant, and at a specified time. These values are passed as parameters, and a table booking record is created in storage using the repository:

The factory may use one of the object-oriented programming patterns, such as the factory or abstract factory pattern, for object creation.

Modules are the best way to separate related business objects. These are best suited to large projects where the size of domain objects is bigger. For the end user, it makes sense to divide the domain model into modules and set the relationship between those modules. Once you understand the modules and their relationship, you start to see the bigger picture of the domain model, thus it's easier to drill down further and understand the model.

Modules also help with code that is highly cohesive, or that maintains low coupling. Ubiquitous language can be used to name these modules. For the table-booking system, we could have different modules, such as user-management, restaurants and tables, analytics and reports, reviews, and so on.

An enterprise model is usually very large and complex. It may be distributed between different departments in an organization. Each department may have a separate leadership team, so working and designing together can create difficulty and coordination issues. In such scenarios, maintaining the integrity of the domain model is not an easy task.

In such cases, working on a unified model is not the solution, and large enterprise models need to be divided into different sub-models. These sub-models contain the predefined accurate relationship and contract in minute detail. Each sub-model has to maintain the defined contracts without any exception.

There are various principles that can be followed to maintain the integrity of a domain model, and these are listed as follows:

• Bounded context
• Continuous integration
• Context map:
  • Shared kernel
  • Customer-supplier
  • Conformist
  • Anti-corruption layer
  • Separate ways
  • Open Host Service
  • Distillation

When you have different sub-models, it is difficult to maintain the code when all sub-models are combined. You need to have a small model that can be assigned to a single team. You might need to collect the related elements and group them. Context keeps and maintains the meaning of the domain term defined for its respective sub-model by applying this set of conditions. Domain models are divided into sub-models, and bounded context distinguishes the context of one sub-domain from the context of another sub-domain.

These domain terms define the scope of the model that creates the boundaries of the context.

Bounded context seems very similar to the module that you learned about in the previous section. In fact, the module is part of the bounded context that defines the logical frame where a sub-model takes place and is developed, whereas the module organizes the elements of the domain model, and is visible in the design document and the code. This also helps to isolate the models and the language from one model to another to avoid ambiguity.

Now, as a designer, you need to keep each sub-model well-defined and consistent. In this way, you can refactor each model independently without affecting the other sub-models. This gives the software designer the flexibility to refine and improve it at any point in time.

Now, let's examine the table reservation example we've been using. When you started designing the system, you would have seen that the guest would visit the application, and would request a table reservation at a selected restaurant, date, and time. Then, there is the backend system that informs the restaurant about the booking information, and similarly, the restaurant would keep their system updated with regard to table bookings, given that tables can also be booked by the restaurant themselves. So, when you look at the system's finer points, you can see two domain models:

• The online table-reservation system
• The offline restaurant-management system

Both have their own bounded context and you need to make sure that the interface between them works okay.

When you are developing, the code is scattered between many teams and various technologies. This code may be organized into different modules and may have applicable bounded contexts for respective sub-models.

This sort of development may bring with it a certain level of complexity with regard to duplicate code, a code break, or maybe broken-bounded context. This happens not only because of the large size of the code and the domain model, but also because of other factors, such as changes in team members, new members, or not having a well-documented model, to name just a few.

When systems are designed and developed using DDD and agile methodologies, domain models are not designed fully before coding starts, and the domain model and its elements evolve over a period of time with continuous improvements and refinement happening gradually.

Therefore, integration continues, and this is one of the key reasons for development today, so it plays a very important role. In continuous integration , code is merged frequently to avoid any breaks and issues with the domain model. Merged code not only gets deployed, but it is also tested on a regular basis. There are various continuous integration tools available on the market that merge, build, and deploy the code at scheduled times. These days, organizations put more emphasis on the automation of continuous integration. Hudson, TeamCity, and Jenkins CI are a few of the popular tools available today for continuous integration. Hudson and Jenkins CI are open source tools, and TeamCity is a proprietary tool.

Having a test suite attached to each build confirms the consistency and integrity of the model. A test suite defines the model from a physical point of view, whereas UML does it logically. It informs you of any error or unexpected outcome that requires a code change. It also helps to identify errors and anomalies in a domain model early on.

The context map helps you to understand the overall picture of a large enterprise application. It shows how many bounded contexts are present in the enterprise model, and how they are interrelated. Therefore, we can say that any diagram or document that explains the bounded contexts and relationship between them is called a context map .

Context maps help all team members, whether they are on the same team or in a different team, to understand the high-level enterprise model in the form of various parts (bounded context or sub-models) and relationships.

This gives individuals a clearer picture about the tasks one performs, and may allow them to raise any concerns/questions about the model's integrity:

The context map example diagram is a sample of a context map. Here, Table1 and Table2 both appear in the Table Reservation Context and also in the Restaurant Ledger Context . The interesting thing is that Table1 and Table2 have their own respective concept in each bounded context. Here, ubiquitous language is used to name the bounded context table reservation and restaurant ledger .

In the following section, we will explore a few patterns that can be used to define the communication between different contexts in the context map.

As the name suggests, one part of the bounded context is shared with the other's bounded context. As you can see in the following diagram, the Restaurant entity will be shared between the Table Reservation Context and the Restaurant Ledger Context:

The customer-supplier pattern represents the relationship between two bounded contexts, when the output of one bounded context is required for the other bounded context. That is, one supplies the information to the other (known as the customer), who consumes the information. The supplier provides the output; the customer consumes the output.

In a real-world example, a car dealer cannot sell cars until the car manufacturer delivers them. Hence, in this domain model, the car manufacturer is the supplier and the dealer is the customer. This relationship establishes a customer-supplier relationship, because the output (car) of one bounded context (car-manufacturer) is required by the other bounded context (dealer).

Here, both customer and supplier teams should meet regularly to establish a contract and form the right protocol to communicate with each other.

This pattern is a form of customer-supplier context map, where one needs to provide the contract and information while the other needs to use it. Here, instead of bounded context, actual teams are involved in having an upstream/downstream relationship.

Moreover, upstream teams do not provide for the needs of the downstream team, because of their lack of motivation. Therefore, it is possible that the downstream team may need to plan and work on items that will never be available. To resolve such cases, the customer team could develop their own models if the supplier provides information that is not sufficient. If the supplier provided information that is really of worth or of partial worth, then the customer could use the interface or translators that can be used to consume the supplier-provided information with the customer's own models.

The anti-corruption layer remains part of a domain that interacts with external systems, or their own legacy systems. Here, anti-corruption is the layer that consumes data from external systems and uses external system data in the domain model without affecting the integrity and originality of the domain model.

For the most part, a service can be used as an anti-corruption layer that may use a facade pattern with an adapter and translator to consume external domain data within the internal model. Therefore, your system would always use the service to retrieve the data. The service layer can be designed using the facade pattern. This would make sure that it would work with the domain model to provide the required data in a given format. The service could then also use the adapter and translator patterns that would make sure that, whatever format and hierarchy the data is sent in by external sources, the service would be provided in the desired format and the hierarchy would use adapters and translators.

When you have a large enterprise application and a domain where different domains have no common elements, and it's made of large sub-models that can work independently, this still works as a single application for an end user. Therefore, the separate ways pattern is the most challenging and complex.

In such cases, a designer could create separate models that have no relationship and develop a small application on top of them. These small applications become a single application when merged together and sit on top of all sub-models.

An employer's intranet application that offers various small applications, such as those that are HR-related, issue trackers, transport, or intra-company social networks, is one such application where a designer could use the separate ways pattern.

It would be very challenging and complex to integrate applications that were developed using separate models. Therefore, you should take care before implementing this pattern.

A translation layer is used when two sub-models interact with each other. This translation layer is used when you integrate models with an external system. This works fine when you have one sub-model that uses this external system. The Open Host Service is required when more than one sub-model interacts with external systems. Then, the Open Host Service removes any extra or duplicated code, because then you need to write a translation layer for each sub-model's external system.

An Open Host Service provides the services of an external system using a wrapper for all sub-models.

As you know, distillation is the process of purifying liquid. Similarly, in DDD, distillation is a process that filters out information that is not required, and keeps only meaningful information. It helps you to identify the core domain and the essential concepts for your business domain. It also helps you to filter out generic concepts until you get the core domain concept.

The core domain should be designed, developed, and implemented with the highest attention to detail, using developers and designers, as it is crucial to the success of the whole system.

In our table-reservation system example, which is not a large or complex domain application, it is not difficult to identify the core domain. The core domain here exists to share real-time, accurate information regarding vacant tables in restaurants, and allows the user to reserve them in a hassle-free process.

Let's create a sample domain service based on our table-reservation system. As discussed in this chapter, the importance of an efficient domain layer is the key to successful products or services. Projects developed based on the domain layer are more maintainable, highly cohesive, and decoupled. They provide high scalability in terms of business requirement changes, and have a low impact on the design of other layers.

Domain-driven development is based on the relevant domain, hence it is not recommended that you use a top-down approach where the UI would be developed first, followed by the rest of the layers, and finally the persistence layer. Nor should you use a bottom-up approach, where the persistence layer, such as the DB, is designed first, followed by the rest of the layers, with the UI last.

Having a domain model developed first, using the patterns described in this book, gives clarity to all team members functionality-wise, and an advantage to the software designer to build a flexible, maintainable, and consistent system that helps the organization to launch a world-class product with fewer maintenance costs.

Here, you will create a restaurant service that provides a feature to add and retrieve restaurants. Based on your implementation, you can add other functionalities, such as finding restaurants based on cuisine or ratings.

Start with the entity. Here, the restaurant is our entity, as each restaurant is unique and has an identifier. You can use an interface, or set of interfaces, to implement the entity in our table-reservation system. Ideally, if you follow the interface segregation principle, you will use a set of interfaces rather than a single interface.

For the first interface, you could have an abstract class or interface that is required by all the entities. For example, if we consider ID and name, attributes would be common for all entities.

Therefore, you could use the abstract Entity  class as an abstraction of the entity in your domain layer:

public abstract class Entity<T> {  
    T id; 
    String name; 
    ... (getter/setter and other relevant code)
} 

The following diagram contains the OTRS domain entities and their relationships:

Based on that, you can also have another abstract class that inherits Entity , an abstract class:

public abstract class BaseEntity<T> extends Entity<T> { 
 
    private final boolean isModified;

    public BaseEntity(T id, String name) { 
        super.id = id; 
        super.name = name; 
        isModified = false; 
    } 
    ... (getter/setter and other relevant code) 
}

Based on the preceding abstractions, we could create the Restaurant entity for restaurant management.

Now, since we are developing a table-reservation system, Table is another important entity in terms of the domain model. So, if we follow the aggregate pattern, Restaurant would work as a root, and the Table entity would be internal to the Restaurant entity. Therefore, the Table entity would always be accessible using the Restaurant entity.

You can create the Table entity using the following implementation, and you can add attributes as you wish. For demonstration purposes only, basic attributes are used:

public class Table extends BaseEntity<BigInteger> { 
 
    private int capacity; 
 
    public Table(String name, BigInteger id, int capacity) { 
        super(id, name); 
        this.capacity = capacity; 
    } 
 
    public void setCapacity(int capacity) { 
        this.capacity = capacity; 
    } 
 
    public int getCapacity() { 
        return capacity; 
    } 
} 

Now, we can implement the aggregator Restaurant class, shown as follows. Here, only basic attributes are used. You could add as many as you want, and you may also add other features:

public class Restaurant extends BaseEntity<String> { 
 
    private List<Table> tables = new ArrayList<>();
    public Restaurant(String name, String id, List<Table> tables) { 
        super(id, name); 
        this.tables = tables; 
    } 
 
    public void setTables(List<Table> tables) { 
        this.tables = tables; 
    } 
 
    public List<Table> getTables() { 
        return tables; 
    } 
 
    @Override 
    public String toString() { 
        return new StringBuilder("{id: ").append(id).append(", name: ") 
                .append(name).append(", tables: ").append(tables).append("}").toString(); 
    } 
} 

Now we can implement the repository pattern, as learned about in this chapter. To start with, you will first create the two interfaces, Repository and ReadOnlyRepository . The ReadOnlyRepository interface will be used to provide an abstraction for read-only operations, whereas the Repository abstraction will be used to perform all types of operations:

public interface ReadOnlyRepository<TE, T> { 
 
    boolean contains(T id); 
 
    TE get(T id); 
 
    Collection<TE> getAll(); 
}

The following diagram contains the OTRS domain repositories:

Based on the defined interface, we could create the abstraction of the Repository , which would execute additional operations such as adding, removing, and updating:

public interface Repository<TE, T> extends ReadOnlyRepository<TE, T> {  
    void add(TE entity);  
    void remove(T id);  
    void update(TE entity); 
} 

The Repository abstraction, as defined previously, could be implemented, in a way that suits you, to persist your objects. The change in persistence code, which is a part of the infrastructure layer, won't impact on your domain layer code, as the contract and abstraction are defined by the domain layer. The domain layer uses abstraction classes and interfaces that remove the use of the direct concrete class, and provides loose coupling. For demonstration purposes, we could simply use the map that remains in the memory to persist the objects:

public interface RestaurantRepository<Restaurant, String> extends Repository<Restaurant, String> { 
 
    boolean containsName(String name); 
} 
 
public class InMemRestaurantRepository implements RestaurantRepository<Restaurant, String> { 
 
    private Map<String, Restaurant> entities; 
 
    public InMemRestaurantRepository() { 
        entities = new HashMap(); 
    } 
 
    @Override 
    public boolean containsName(String name) { 
        return entities.containsKey(name); 
    } 
 
    @Override 
    public void add(Restaurant entity) { 
        entities.put(entity.getName(), entity); 
    } 
 
    @Override 
    public void remove(String id) { 
        if (entities.containsKey(id)) { 
            entities.remove(id); 
        } 
    } 
 
    @Override 
    public void update(Restaurant entity) { 
        if (entities.containsKey(entity.getName())) { 
            entities.put(entity.getName(), entity); 
        } 
    } 
 
    @Override 
    public boolean contains(String id) { 
        throw new UnsupportedOperationException("Not supported yet."); 
     //To change body of generated methods, choose Tools | Templates. 
    } 
 
    @Override 
    public Entity get(String id) { 
        throw new UnsupportedOperationException("Not supported yet."); 
     //To change body of generated methods, choose Tools | Templates. 
    } 
 
    @Override 
    public Collection<Restaurant> getAll() { 
        return entities.values(); 
    } 
 
} 

Using the preceding approach, you could divide the abstraction of the domain service into two parts—the main service abstraction and a read-only service abstraction:

public abstract class ReadOnlyBaseService<TE, T> { 
 
    private final Repository<TE, T> repository; 
 
    ReadOnlyBaseService(ReadOnlyRepository<TE, T> repository) { 
        this.repository = repository; 
    } 
    ... 
}

The following diagram contains the OTRS services and their relationships:

Now, we could use this ReadOnlyBaseService to create BaseService . Here, we are using the dependency injection pattern via a constructor to map concrete objects with abstraction:

public abstract class BaseService<TE, T> extends ReadOnlyBaseService<TE, T> { 
    private final Repository<TE, T> _repository;
 
    BaseService(Repository<TE, T> repository) { 
        super(repository); 
        _repository = repository; 
    } 
 
    public void add(TE entity) throws Exception { 
        _repository.add(entity); 
    } 
 
    public Collection<TE> getAll() { 
        return _repository.getAll(); 
    } 
}

Now, after defining the service abstraction services, we could implement the RestaurantService in the following way:

public class RestaurantService extends BaseService<Restaurant, BigInteger> { 
 
    private final RestaurantRepository<
         Restaurant, String> restaurantRepository; 
 
    public RestaurantService(RestaurantRepository repository) { 
        super(repository); 
        restaurantRepository = repository; 
    } 
 
    public void add(Restaurant restaurant) throws Exception { 
        if (restaurantRepository.ContainsName(restaurant.getName())) { 
            throw new Exception(String.format("There is already a 
                  product with the name - %s", restaurant.getName())); 
        } 
 
        if (restaurant.getName() == null || 
                                   "".equals(restaurant.getName())) { 
            throw new Exception("Restaurant name cannot be null or 
                                empty string."); 
        } 
        super.add(restaurant); 
    } 
    @Override 
    public Collection<Restaurant> getAll() { 
        return super.getAll(); 
    } 
} 

Similarly, you could write the implementation for other entities. This code is a basic implementation, and you might add various implementations and behaviors to the production code.

We can write an application class that would execute and test the sample domain model code that we have just written.

The RestaurantApp.java file will look something like this:

public class RestaurantApp {
  public static void main(String[] args) {
    try {
      // Initialize the RestaurantService
      RestaurantService restaurantService = new RestaurantService(new InMemRestaurantRepository());

      // Data Creation for Restaurants
      List<Table> tableList = Arrays.asList(
          new Table("Table 1", BigInteger.ONE, 6),
          new Table("Table 2", BigInteger.valueOf(2), 4),
          new Table("Table 3", BigInteger.valueOf(3), 2)
      );

      // Add few restaurants using Service
      // Note: To raise an exception give same restaurant name to one of the below restaurant
      restaurantService
          .add(new Restaurant("Big-O Restaurant", "1", Optional.ofNullable(tableList)));
      restaurantService.add(new Restaurant("Pizza Shops", "2", Optional.empty()));
      restaurantService.add(new Restaurant("La Pasta", "3", Optional.empty()));

      // Retrieving all restaurants using Service
      Collection<Restaurant> restaurants = restaurantService.getAll();

      // Print the retrieved restaurants on console
      System.out.println("Restaurants List:");
      restaurants.stream()
          .map(r -> String.format("Restaurant: %s", r))
          .forEach(System.out::println);
    } catch (Exception ex) {
      System.out.println(String.format("Exception: %s", ex.getMessage()));
      // Exception Handling Code
    }
  }
}

To execute this program, either execute it directly from the IDE, or run it using Maven. It prints the following output:

Scanning for projects... 
                                                                         
------------------------------------------------------------------------ 
Building 11537_chapter3 1.0-SNAPSHOT 
------------------------------------------------------------------------ 
 
Restaurants List: 
Restaurant: {id: 3, name: La Pasta, tables: null} 
Restaurant: {id: 2, name: Pizza Shops, tables: null} 
Restaurant: {id: 1, name: Big-O Restaurant, tables: [{id: 1, name: Table 1, capacity: 6}, {id: 2, name: Table 2, capacity: 4}, {id: 3, name: Table 3, capacity: 2}]} 
------------------------------------------------------------------------ 
BUILD SUCCESS 
------------------------------------------------------------------------ 

In this chapter, you have learned the fundamentals of DDD. You have also explored multilayered architecture and different patterns that can be used to develop software using DDD. By now, you should be aware that domain model design is very important for the success of software. To conclude, we demonstrated a domain service implementation using the restaurant table-reservation system.

In the next chapter, you will learn how to use the design to implement the sample project. The explanation of the design of this sample project is derived from the last chapter, and the DDD will be used to build microservices. This chapter not only covers coding, but also the different aspects of microservices, such as building, unit testing, and packaging. By the end of the next chapter, the sample microservice project will be ready for deployment and consumption.

This chapter takes you from the design stage to the implementation of our sample project—an online table reservation system ( OTRS ). Here, you will use the same design we explained in the last chapter and enhance it to build microservices. By the end of this chapter, you will have not only learned how to implement the design, but also the different aspects of microservices—building, testing, packaging, and containerization. Although the focus is on building and implementing the restaurant microservices, you can use the same approach to build and implement other microservices that are used in the OTRS. Sample code available on GitHub provides all three services in this chapter—the restaurant service, the booking service, and the user service.

In this chapter, we will cover the following topics:

• OTRS overview
• Developing and implementing the microservices
• Testing
• Containerization of microservices using Docker

We will use the concepts of domain-driven design that were demonstrated in the last chapter. In the last chapter, you saw how domain-driven design is used to develop the domain model using core Java. Now, we will move from a sample domain implementation to a Spring Framework-driven implementation. You'll make use of Spring Boot to implement the domain-driven design concepts and transform them from core Java to a Spring Framework-based model.

In addition, we'll also use Spring Cloud, which provides a cloud-ready solution that is available through Spring Boot. Spring Boot will allow you to use an embedded application container relying on Tomcat or Jetty inside your service, which is packaged as a JAR or as a WAR. This JAR is executed as a separate process, a microservice that will serve and provide the responses to all requests and point to endpoints that are defined in the service.

Spring Cloud can also be integrated easily with Netflix Eureka, a service registry and discovery component. The OTRS will use it for the registration and the discovery of microservices.

Based on microservice principles, we need to have separate microservices for each functionality. After looking at OTRS, we can easily divide it into three main microservices—the restaurant service, the booking service, and the user service. There are other microservices that can be defined in the OTRS, but our focus is on these three microservices. The idea is to make them independent, including having their own separate databases.

We can summarize the functionalities of these services as follows:

• Restaurant service : This service provides the functionality for the restaurant resource— create , read , update , delete ( CRUD ) operations and searching. It provides the association between restaurants and tables. This service also provides access to the Table entity.
• User service : This service, as the name suggests, allows the end user to perform CRUD operations on user entities.
• Booking service : This makes use of the restaurant service and the user service to perform CRUD operations on bookings. It will use restaurant searching and its associated table lookup and allocation based on table availability for a specified time period. It creates a relationship between the restaurant/table and the user:

The preceding diagram shows how each microservice works independently. This is the reason why microservices can be developed, enhanced, and maintained separately, without affecting others. These services can each have their own layered architecture and database. There is no restriction to use the same technologies, frameworks, and languages to develop these services. At any given point in time, you can also introduce new microservices. For example, for accounting purposes, we can introduce an accounting service that can be exposed to restaurants for bookkeeping. Similarly, analytics and reporting are other services that can be integrated and exposed.

For demonstration purposes, we will only implement the three services that are shown in the preceding diagram.

We will use the domain-driven implementation and approach we described in the last chapter to implement the microservices using Spring Cloud. Let's revisit the key artifacts:

• Entities : These are categories of objects that are identifiable and remain the same throughout the states of the product/services. These objects are not defined by their attributes, but by their identities and threads of continuity. Entities have traits such as identity, a thread of continuity, and attributes that do not define their identity.
• Value objects ( VOs ): These just have the attributes and no conceptual identity. A best practice is to keep VOs as immutable objects. In the Spring Framework, entities are pure POJOs; therefore, we'll also use them as VOs.
• Service objects : These are common in technical frameworks. These are also used in the domain layer in DDD. A service object does not have an internal state; the only purpose of it is to provide the behavior to the domain. Service objects provide behaviors that cannot be related with specific entities or VOs. Service objects may provide one or more related behaviors to one or more entities or VOs. It is a best practice to define the services explicitly in the domain model.
• Repository objects : A repository object is a part of the domain model that interacts with storage, such as databases, external sources, and so on, to retrieve the persisted objects. When a request is received by the repository for an object reference, it returns the existing object reference. If the requested object does not exist in the repository, then it retrieves the object from storage.

Each OTRS microservice API represents a RESTful web service. The OTRS API uses HTTP verbs such as GET , POST , and so on, and a RESTful endpoint structure. Request and response payloads are formatted as JSON. If required, XML can also be used.

The restaurant microservice will be exposed to the external world using REST endpoints for consumption. We'll find the following endpoints in the restaurant microservice example. You can add as many endpoints as you need:

1. This is the endpoint for retrieving restaurants by ID:

2. This is the endpoint for retrieving all the restaurants that match the value of the query parameter Name :

3. This is the endpoint for creating a new restaurant:

Similarly, we can add various endpoints and their implementations. For demonstration purposes, we'll implement the preceding endpoints using Spring Cloud.

We'll create the multi-module Maven project for implementing OTRS. The following stack would be used to develop the OTRS application. Please note that at the time of writing this book, only the snapshot build of Spring Boot and Cloud was available. Therefore, in the final release, one or two things may change:

• Java version 1.11
• Spring Boot 2.1.0.M4
• Spring Cloud Finchley.SR1
• Maven version 3.3.9
• Maven Compiler Plugin (for Java 11) with 6.2 version of org.ow2.asm

All the preceding points are mentioned in the root pom.xml file, along with the following OTRS modules:

• restaurant-service
• user-service
• booking-service

The root pom.xml file will look something like this:

...

  <groupId>com.packtpub.mmj</groupId>
  <artifactId>11537_chapter4</artifactId>
  <version>PACKT-SNAPSHOT</version>
  <name>Chapter4</name>
  <description>Master Microservices with Java 11, Chapter 4</description>
  <packaging>pom</packaging>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <java.version>1.11</java.version>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
  </properties>

  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.1.0.M4</version>
  </parent>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>Finchley.SR1</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <modules>
    <module>restaurant-service</module>
    <module>user-service</module>
    <module>booking-service</module>
  </modules>

  <!-- Build step is required to include the spring boot artifacts in generated jars -->
  <build>
    <finalName>${project.artifactId}</finalName>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <release>11</release>
          <source>1.11</source>
          <target>1.11</target>
          <executable>${JAVA_1_11_HOME}/bin/javac</executable>
          <showDeprecation>true</showDeprecation>
          <showWarnings>true</showWarnings>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.ow2.asm</groupId>
            <artifactId>asm</artifactId>
            <version>6.2</version> <!-- Use newer version of ASM -->
          </dependency>
        </dependencies>
      </plugin>
    </plugins>
  </build>
...
...
</project>

We are developing REST-based microservices. We'll implement the restaurant module. The booking and user modules are developed on similar lines.

Here, the restaurant service implementation is explained. You can take the same approach to develop other services.

We'll start the restaurant-service module ( mvn ) by creating the restaurant-service POM inside the restaurant-service directory. We have added docker-maven-plugin to build the Docker image of the executable service that we'll discuss later in this chapter.

After this, we can add Java classes and other files. First, we'll add pom.xml :

...
  <parent>
    <groupId>com.packtpub.mmj</groupId>
    <artifactId>11537_chapter4</artifactId>
    <version>PACKT-SNAPSHOT</version>
  </parent>

  <name>online-table-reservation:restaurant-service</name>
  <artifactId>restaurant-service</artifactId>
  <packaging>jar</packaging>
  <properties>
    <start-class>com.packtpub.mmj.restaurant.RestaurantApp</start-class>
    <docker.registry.name>localhost:5000/</docker.registry.name>
    <docker.repository.name>${docker.registry.name}sourabhh/
    ${project.artifactId}</docker.repository.name>
    <docker.host.address>192.168.43.194</docker.host.address>
    <docker.port>8080</docker.port>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <!-- Testing starter -->
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-test</artifactId>
    </dependency>
  </dependencies>

  <build>
...
        <groupId>org.jolokia</groupId>
        <artifactId>docker-maven-plugin</artifactId>
        <version>0.13.9</version>
        <configuration>
...
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-failsafe-plugin</artifactId>
...
...
   </build>
</project>

The RestaurantController class uses the @RestController annotation to build the restaurant service endpoints. We went through the details of @RestController in Chapter 2 , Environment Setup . @RestController is a class-level annotation that is used for resource classes. It is a combination of the @Controller and @ResponseBody annotations. It returns the domain object.

As we move forward, I would like to share with you that we are using the v1 prefix on our REST endpoint. That represents the version of the API. I would also like to explain the importance of API versioning. Versioning APIs is important because APIs change over time. Your knowledge and experience improves with time, which leads to changes to your API. A change of API may break existing client integrations.

Therefore, there are various ways of managing API versions. One of these is using the version in the path; some people use the HTTP header. The HTTP header can be a custom request header or an accept header to represent the calling API version:

@RestController
@RequestMapping("/v1/restaurants")
public class RestaurantController {

   // code omitted

  /**
   * Fetch restaurants with the specified name. A partial case-insensitive match is supported. So
   */
  @RequestMapping(method = RequestMethod.GET)
  public ResponseEntity<Collection<Restaurant>> findByName(@RequestParam("name") String name)
      throws Exception {
    logger.info(String.format("restaurant-service findByName() 
        invoked:{} for {} ",
        restaurantService.getClass().getName(), name));
    name = name.trim().toLowerCase();
    Collection<Restaurant> restaurants;
    try {
      restaurants = restaurantService.findByName(name);
    } catch (RestaurantNotFoundException ex) {
      // Exception handling code
    }
    return restaurants.size() > 0 ? new ResponseEntity<>(restaurants, 
        HttpStatus.OK)
        : new ResponseEntity<>(HttpStatus.NO_CONTENT);
  }

  /**
   * Fetch restaurants with the given id.
   */
  @RequestMapping(value = "/{restaurant_id}", method = RequestMethod.GET)
  public ResponseEntity<Entity> findById(@PathVariable("restaurant_id") 
  String id) throws Exception {
    logger.info(String.format("restaurant-service findById() 
        invoked:{} for {} ",
        restaurantService.getClass().getName(), id));
    id = id.trim();
    Entity restaurant;
    try {
      restaurant = restaurantService.findById(id);
    } catch (Exception ex) {
        // Exception Handling code
    }
    return restaurant != null ? new ResponseEntity<>(
        restaurant, HttpStatus.OK)
        : new ResponseEntity<>(HttpStatus.NO_CONTENT);
  }

  /**
   * Add restaurant with the specified information.
   */
  @RequestMapping(method = RequestMethod.POST)
  public ResponseEntity<Restaurant> add(@RequestBody RestaurantVO restaurantVO) throws Exception {
    logger.info(String.format("restaurant-service add()
    invoked: %s for %s",
        restaurantService.getClass().getName(), restaurantVO.getName()));
    System.out.println(restaurantVO);
    Restaurant restaurant = Restaurant.getDummyRestaurant();
    BeanUtils.copyProperties(restaurantVO, restaurant);
    try {
      restaurantService.add(restaurant);
    } catch (DuplicateRestaurantException | InvalidRestaurantException ex) {
        // Exception handling code
    }
    return new ResponseEntity<>(HttpStatus.CREATED);
  }
}

Please refer to RESTful Java Patterns and Best Practices by Bhakti Mehta, Packt Publishing, https://www.packtpub.com/application-development/restful-java-patterns-and-best-practices , for more information.

The RestaurantController class uses the RestaurantService interface. RestaurantService is an interface that defines CRUD and some search operations, and is defined as follows:

public interface RestaurantService { 
 
    public void add(Restaurant restaurant) throws Exception; 
 
    public void update(Restaurant restaurant) throws Exception; 
 
    public void delete(String id) throws Exception; 
 
    public Entity findById(String restaurantId) throws Exception; 
 
    public Collection<Restaurant> findByName(String name) throws Exception; 
 
    public Collection<Restaurant> findByCriteria(Map<String, ArrayList<String>> name) throws Exception; 
}

Now, we can implement the RestaurantService we have just defined. It also extends the BaseService class you created in the last chapter. We use the @Service Spring annotation to define it as a service:

@Service("restaurantService")
public class RestaurantServiceImpl extends BaseService<Restaurant, String>
    implements RestaurantService {

  private RestaurantRepository<Restaurant, String> restaurantRepository;

  @Autowired
  public RestaurantServiceImpl(RestaurantRepository<Restaurant, String> 
    restaurantRepository) {
    super(restaurantRepository);
    this.restaurantRepository = restaurantRepository;
  }

  @Override
  public void add(Restaurant restaurant) throws Exception {
    if (restaurantRepository.containsName(restaurant.getName())) {
      Object[] args = {restaurant.getName()};
      throw new DuplicateRestaurantException("duplicateRestaurant", args);
    }

    if (restaurant.getName() == null || "".equals(restaurant.getName())) {
      Object[] args = {"Restaurant with null or empty name"};
      throw new InvalidRestaurantException("invalidRestaurant", args);
    }
    super.add(restaurant);
  }

  @Override
  public Collection<Restaurant> findByName(String name) throws Exception {
    return restaurantRepository.findByName(name);
  }

  @Override
  public void update(Restaurant restaurant) throws Exception {
    restaurantRepository.update(restaurant);
  }

  @Override
  public void delete(String id) throws Exception {
    restaurantRepository.remove(id);
  }

  @Override
  public Entity findById(String restaurantId) throws Exception {
    return restaurantRepository.get(restaurantId);
  }

  @Override
  public Collection<Restaurant> findByCriteria(Map<String, 
  ArrayList<String>> name)
      throws Exception {
    throw new UnsupportedOperationException(
        "Not supported yet."); 
  //To change body of generated methods, choose Tools | Templates.
  }
} 

The RestaurantRepository interface defines two new methods: the containsName and findByName methods. It also extends the Repository interface:

public interface RestaurantRepository<Restaurant, String> extends Repository<Restaurant, String> { 
 
    boolean containsName(String name) throws Exception; 
 
    public Collection<Restaurant> findByName(String name) throws Exception; 
} 

The Repository interface defines three methods: add , remove , and update . It also extends the ReadOnlyRepository interface:

public interface Repository<TE, T> extends ReadOnlyRepository<TE, T> { 
 
    void add(TE entity); 
 
    void remove(T id); 
 
    void update(TE entity); 
} 

The ReadOnlyRepository interface definition contains the get and getAll methods, which return Boolean values, entity , and a collection of entity , respectively. It is useful if you only want to expose a read-only abstraction of the repository:

public interface ReadOnlyRepository<TE, T> { 
 
    boolean contains(T id); 
 
    TE get(T id); 
 
    Collection<TE> getAll(); 
} 

The Spring Framework makes use of the @Repository annotation to define the repository bean that implements the repository. In the case of RestaurantRepository , you can see that ConcurrentMap is used in place of the actual database implementation. This keeps all entities saved in memory only. Therefore, when we start the service, we find only initialized restaurants in memory.

We can use JPA for database persistence, which is the general practice for production-ready implementations, along with a database:

@Repository("restaurantRepository")
public class InMemRestaurantRepository implements RestaurantRepository<Restaurant, String> {

  private static final Map<String, Restaurant> entities;

  /* Initialize the in-memory Restaurant map  */
  static {
    entities = new ConcurrentHashMap<>(Map.ofEntries(
        new SimpleEntry<>("1",
            new Restaurant("Le Meurice", "1", "228 rue de Rivoli, 
                           75001, Paris", Optional.empty())),
        ...
        ...
        new SimpleEntry<>("10", new Restaurant("Le Bristol", "10",
            "112, rue du Faubourg St Honoré, 8th arrondissement, 
            Paris", Optional.empty()))));
  }

  /**
   * Check if given restaurant name already exist.
   */
  @Override
  public boolean containsName(String name) {
    try {
      return !this.findByName(name).isEmpty();
    } catch (RestaurantNotFoundException ex) {
      return false;
    }
    return false;
  }

  @Override
  public void add(Restaurant entity) {
    entities.put(entity.getId(), entity);
  }

  @Override
  public void remove(String id) {
    if (entities.containsKey(id)) {
      entities.remove(id);
    }
  }

  @Override
  public void update(Restaurant entity) {
    if (entities.containsKey(entity.getId())) {
      entities.put(entity.getId(), entity);
    }
  }

  @Override
  public boolean contains(String id) {
    throw new UnsupportedOperationException("Not supported yet.");
  }

  @Override
  public Restaurant get(String id) {
    return entities.get(id);
  }

  @Override
  public Collection<Restaurant> getAll() {
    return entities.values();
  }

  @Override
  public Collection<Restaurant> findByName(String name) throws RestaurantNotFoundException {
    int noOfChars = name.length();
    Collection<Restaurant> restaurants = entities.entrySet().stream()
        .filter(e -> e.getValue().getName().toLowerCase()
                .contains(name.subSequence(0, noOfChars)))
        .collect(Collectors.toList())
        .stream()
        .map(k -> k.getValue())
        .collect(Collectors.toList());
    if (restaurants != null && restaurants.isEmpty()) {
      Object[] args = {name};
      throw new RestaurantNotFoundException("restaurantNotFound", args);
    }
    return restaurants;
  }
}

The Restaurant entity, which extends BaseEntity , is defined as follows:

public class Restaurant extends BaseEntity<String> {

  private Optional<List<Table>> tables;
  private String address;

  public String getAddress() {
    return address;
  }

  public void setAddress(String address) {
    this.address = address;
  }

  public Restaurant(String name, String id, String address, Optional<List<Table>> tables) {
    super(id, name);
    this.address = address;
    this.tables = tables;
  }

  private Restaurant(String name, String id) {
    super(id, name);
    this.tables = Optional.empty();
  }

  public static Restaurant getDummyRestaurant() {
    return new Restaurant(null, null);
  }

  public void setTables(Optional<List<Table>> tables) {
    this.tables = tables;
  }

  public Optional<List<Table>> getTables() {
    return tables;
  }

  @Override
  public String toString() {
    return String.format("{id: %s, name: %s, address: %s, tables: %s}", this.getId(),
        this.getName(), this.getAddress(), this.getTables());
  }
}

The Table entity, which extends BaseEntity , is defined as follows:

public class Table extends BaseEntity<BigInteger> {

  private int capacity;

  public Table(@JsonProperty("name") String name, @JsonProperty("id") 
  BigInteger id, @JsonProperty("capacity") int capacity) {
    super(id, name);
    this.capacity = capacity;
  }

  public int getCapacity() {
    return capacity;
  }

  public void setCapacity(int capacity) {
    this.capacity = capacity;
  }

  @Override
  public String toString() {
    return String.format("{id: %s, name: %s, capacity: %s}",
        this.getId(), this.getName(), this.getCapacity());
  }

}

The Entity abstract class is defined as follows:

public abstract class Entity<T> { 
 
    T id; 
    String name; 
 
    public T getId() { 
        return id; 
    } 
 
    public void setId(T id) { 
        this.id = id; 
    } 
 
    public String getName() { 
        return name; 
    } 
 
    public void setName(String name) { 
        this.name = name; 
    } 
 
} 

The BaseEntity abstract class is defined as follows. It extends the Entity
abstract class:

public abstract class BaseEntity<T> extends Entity<T> { 
 
    private boolean isModified; 
 
    public BaseEntity(T id, String name) { 
        super.id = id;
        super.name = name;
        isModified = false;
    }
 
    public boolean isIsModified() { 
        return isModified; 
    } 
} 

You might have seen that we are throwing a few user-defined exceptions. We have added a few exception handling classes that can throw localized messages (English, French, and German).

We have made use of @ControllerAdvice in the EndpointErrorHandler class to handle exceptions while serving the REST calls:

@ControllerAdvice
public class EndpointErrorHandler {

  private static final String UNEXPECTED_ERROR = "Exception.unexpected";
  private final MessageSource messageSource;

  @Autowired
  public EndpointErrorHandler(MessageSource messageSource) {
    this.messageSource = messageSource;
  }

  @ExceptionHandler(RestaurantNotFoundException.class)
  public ResponseEntity<ErrorInfo> handleRestaurantNotFoundException(HttpServletRequest request,
      RestaurantNotFoundException ex, Locale locale) {
    ErrorInfo response = new ErrorInfo();
    response.setUrl(request.getRequestURL().toString());
    response.setMessage(messageSource.getMessage(ex.getMessage(), 
                        ex.getArgs(), locale));
    return new ResponseEntity<>(response, HttpStatus.NOT_FOUND);
  }

  @ExceptionHandler(DuplicateRestaurantException.class)
  public ResponseEntity<ErrorInfo> handleDuplicateRestaurantException(HttpServletRequest request,
      DuplicateRestaurantException ex, Locale locale) {
    ErrorInfo response = new ErrorInfo();
    response.setUrl(request.getRequestURL().toString());
    response.setMessage(messageSource.getMessage(ex.getMessage(), 
                        ex.getArgs(), locale));
    return new ResponseEntity<>(response, HttpStatus.IM_USED);
  }

  @ExceptionHandler(InvalidRestaurantException.class)
  public ResponseEntity<ErrorInfo> handleInvalidRestaurantException(HttpServletRequest request,
      InvalidRestaurantException ex, Locale locale) {
    ErrorInfo response = new ErrorInfo();
    response.setUrl(request.getRequestURL().toString());
    response.setMessage(messageSource.getMessage(ex.getMessage(), 
                        ex.getArgs(), locale));
    return new ResponseEntity<>(response, HttpStatus.NOT_ACCEPTABLE);
  }

  @ExceptionHandler(Exception.class)
  public ResponseEntity<ErrorInfo> handleException(Exception ex, 
  Locale locale) {
    String errorMessage = messageSource.getMessage(UNEXPECTED_ERROR, 
                          null, locale);
    return new ResponseEntity<>(new ErrorInfo(errorMessage), 
    HttpStatus.INTERNAL_SERVER_ERROR);
  }
}

EndpointErrorHandler uses the ErrorInfo class to wrap the error details:

public class ErrorInfo {
  private String url;
  private String message;

  public ErrorInfo() {
    
  }
  
  public ErrorInfo(String message) {
    this.message = message;
  }
  
  public ErrorInfo(String url, String message) {
    this.url = url;
    this.message = message;
  } 
  
    public String getUrl() {
    return url;
  }

  public void setUrl(String url) {
    this.url = url;
  }

  public String getMessage() {
    return message;
  }

  public void setMessage(String message) {
    this.message = message;
  }
}

Please refer to the DuplicateRestaurantException code to create the other custom exception classes:

public class DuplicateRestaurantException extends Exception {

  private static final long serialVersionUID = -8890080495441147845L;

  private String message;
  private Object[] args;

  public DuplicateRestaurantException(String name) {
    this.message = String.format("There is already a restaurant 
                   with the name - %s", name);
  }

  public DuplicateRestaurantException(Object[] args) {
    this.args = args;
  }

  public DuplicateRestaurantException(String message, Object[] args) {
    this.message = message;
    this.args = args;
  }

  public String getMessage() {
    return message;
  }

  public void setMessage(String message) {
    this.message = message;
  }

  public Object[] getArgs() {
    return args;
  }

  public void setArgs(Object[] args) {
    this.args = args;
  }
}

Also, to provide error messages in different languages, the following configuration class is used:

@Configuration
public class AppConfig implements WebMvcConfigurer {
 
   @Bean
   public LocaleResolver localeResolver() {
     AcceptHeaderLocaleResolver localeResolver = 
           new AcceptHeaderLocaleResolver();
       localeResolver.setDefaultLocale(Locale.US);
       return localeResolver;
   }
 
   @Bean
   public LocaleChangeInterceptor localeChangeInterceptor() {
       LocaleChangeInterceptor localeChangeInterceptor = 
           new LocaleChangeInterceptor();
       localeChangeInterceptor.setParamName("lang");
       return localeChangeInterceptor;
   }
 
   @Override
   public void addInterceptors(InterceptorRegistry registry) {
       registry.addInterceptor(localeChangeInterceptor());
   }
}

We have also added the following property in application.yml to localize messages:

spring.messages.fallback-to-system-locale = false

We are done with the restaurant service implementation.

We can refer to the RestaurantService implementation to develop the booking and user services. The user service can offer the endpoint related to the user resource with respect to CRUD operations. The booking service offers endpoints related to the booking resource with respect to CRUD operations and the availability of table slots. You can find the sample code of these services on the Packt website or GitHub repository.

To see how our code works, first we need to build it and then execute it. We'll use the maven clean package command to build the service JARs.

Now, to execute these service JARs, simply execute the following command from the project's home directory:

java -jar <service>/target/<service_jar_file> 

Here are some examples:

java -jar restaurant-service/target/restaurant-service.jar 
java -jar user-service/target/user-service.jar
java -jar booking-service/target/booking-service.jar

So far, we have created the microservices that run independently and have no dependencies on each other. Later in this book in Chapter 9 , Inter-Process Communication Using REST , we'll see how these microservices communicate with each other.

To enable testing, the following dependency in the pom.xml file is used:

<dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-test</artifactId> 
</dependency> 

To test the RestaurantController , the following files have been added:

• The RestaurantControllerIntegrationTests class uses the
  @SpringBootTest annotation to pick the same configuration that Spring Boot uses. Also, we use the SpringRunner class to run our integration tests. Please find the restaurant API integration test code:

@RunWith(SpringRunner.class)
@SpringBootTest(classes = RestaurantApp.class, webEnvironment = WebEnvironment.RANDOM_PORT, properties = {
    "management.server.port=0", "management.context-path=/admin"})
public class RestaurantControllerIntegrationTests extends
    AbstractRestaurantControllerTests {

  // code omitted
  /* Test the GET /v1/restaurants/{id} API */
  @Test
  public void testGetById() {
    //API call
    Map<String, Object> response
        = restTemplate.getForObject("http://localhost:" + port + 
          "/v1/restaurants/1", Map.class);
    assertNotNull(response);
    //Asserting API Response
    String id = response.get("id").toString();
    assertNotNull(id);
    assertEquals("1", id);
    String name = response.get("name").toString();
    assertNotNull(name);
    assertEquals("Le Meurice", name);
    boolean isModified = (boolean) response.get("isModified");
    assertEquals(false, isModified);
    List<Table> tableList = (List<Table>) response.get("tables");
    assertNull(tableList);
  }

  /* Test the GET /v1/restaurants/{id} API for no content */
  @Test
  public void testGetById_NoContent() {
    HttpHeaders headers = new HttpHeaders();
    HttpEntity<Object> entity = new HttpEntity<>(headers);
    ResponseEntity<Map> responseE = restTemplate
        .exchange("http://localhost:" + port + "/v1/restaurants/99", 
            HttpMethod.GET, entity,
            Map.class);
    assertNotNull(responseE);
    // Should return no content as there 
    // is no restaurant with id 99
    assertEquals(HttpStatus.NO_CONTENT, responseE.getStatusCode());
  }

  /**
   * Test the GET /v1/restaurants API
   */
  @Test
  public void testGetByName() {

    HttpHeaders headers = new HttpHeaders();
    HttpEntity<Object> entity = new HttpEntity<>(headers);
    Map<String, Object> uriVariables = new HashMap<>();
    uriVariables.put("name", "Meurice");
    ResponseEntity<Map[]> responseE = restTemplate
        .exchange("http://localhost:" + port + "/v1/restaurants?
            name={name}", HttpMethod.GET,
            entity, Map[].class, uriVariables);

    assertNotNull(responseE);

    // Should return no content as there 
    // is no restaurant with id 99
    assertEquals(HttpStatus.OK, responseE.getStatusCode());
    Map<String, Object>[] responses = responseE.getBody();
    assertNotNull(responses);

    // Assumed only single instance exist for restaurant name 
    // contains word "Meurice"
    assertTrue(responses.length == 1);

    Map<String, Object> response = responses[0];
    String id = response.get("id").toString();
    assertNotNull(id);
    assertEquals("1", id);
    String name = response.get("name").toString();
    assertNotNull(name);
    assertEquals("Le Meurice", name);
    boolean isModified = (boolean) response.get("isModified");
    assertEquals(false, isModified);
    List<Table> tableList = (List<Table>) response.get("tables");
    assertNull(tableList);
  }

 // few tests omitted here

}

• An abstract class to write our tests:

public abstract class AbstractRestaurantControllerTests {

  /**
   * RESTAURANT ID constant having value 1
   */
  protected static final String RESTAURANT = "1";

  /**
   * RESTAURANT name constant having value Big-O Restaurant
   */
  protected static final String RESTAURANT_NAME = "Le Meurice";

  /**
   * RESTAURANT address constant
   */
  protected static final String RESTAURANT_ADDRESS = "228 rue de 
                                         Rivoli, 75001, Paris";

  @Autowired
  RestaurantController restaurantController;

  /**
   * Test method for findById method
   */
  @Test
  public void validResturantById() throws Exception {
    Logger.getGlobal().info("Start validResturantById test");
    ResponseEntity<Entity> restaurant = 
         restaurantController.findById(RESTAURANT);

    Assert.assertEquals(HttpStatus.OK, restaurant.getStatusCode());
    Assert.assertTrue(restaurant.hasBody());
    Assert.assertNotNull(restaurant.getBody());
    Assert.assertEquals(RESTAURANT, restaurant.getBody().getId());
    Assert.assertEquals(RESTAURANT_NAME, 
                        restaurant.getBody().getName());
    Logger.getGlobal().info("End validResturantById test");
  }

  /**
   * Test method for findByName method
   */
  @Test
  public void validResturantByName() throws Exception {
    Logger.getGlobal().info("Start validResturantByName test");
    ResponseEntity<Collection<Restaurant>> restaurants = 
                                       restaurantController
        .findByName(RESTAURANT_NAME);
    Logger.getGlobal().info("In validAccount test");

    Assert.assertEquals(HttpStatus.OK, restaurants.getStatusCode());
    Assert.assertTrue(restaurants.hasBody());
    Assert.assertNotNull(restaurants.getBody());
    Assert.assertFalse(restaurants.getBody().isEmpty());
    Restaurant restaurant = 
         (Restaurant) restaurants.getBody().toArray()[0];
    Assert.assertEquals(RESTAURANT, restaurant.getId());
    Assert.assertEquals(RESTAURANT_NAME, restaurant.getName());
    Logger.getGlobal().info("End validResturantByName test");
  }

  /**
   * Test method for add method
   */
  @Test
  public void validAdd() throws Exception {
    Logger.getGlobal().info("Start validAdd test");
    RestaurantVO restaurant = new RestaurantVO();
    restaurant.setId("999");
    restaurant.setName("Test Restaurant");

    ResponseEntity<Restaurant> restaurants = 
        restaurantController.add(restaurant);
    Assert.assertEquals(HttpStatus.CREATED, 
        restaurants.getStatusCode());
    Logger.getGlobal().info("End validAdd test");
  }
}

• Finally, the RestaurantControllerTests class, which extends the previously created abstract class and also creates the RestaurantService and RestaurantRepository implementations:

public class RestaurantControllerTests extends AbstractRestaurantControllerTests {

  protected static final Restaurant restaurantStaticInstance = new Restaurant(RESTAURANT,
      RESTAURANT_NAME, RESTAURANT_ADDRESS, null);
  /**
   * Initialized Restaurant Repository
   */
  protected TestRestaurantRepository testRestaurantRepository = new TestRestaurantRepository();
  protected RestaurantService restaurantService = new RestaurantServiceImpl(
      testRestaurantRepository);

  /**
   * Setup method
   */
  @Before
  public void setup() {
    restaurantController = 
        new RestaurantController(restaurantService);
  }

  protected static class TestRestaurantRepository implements
      RestaurantRepository<Restaurant, String> {

    private Map<String, Restaurant> entities;

    public TestRestaurantRepository() {
      entities = new HashMap();
      Restaurant restaurant = new Restaurant(RESTAURANT_NAME, 
                        RESTAURANT, RESTAURANT_ADDRESS, null);
      entities.put("1", restaurant);
      restaurant = new Restaurant("O Restaurant", "2", 
                    "Address of O Restaurant", null);
      entities.put("2", restaurant);
    }

    @Override
    public boolean containsName(String name) {
      try {
        return this.findByName(name).size() > 0;
      } catch (Exception ex) {
        //Exception Handler
      }
      return false;
    }

    @Override
    public void add(Restaurant entity) {
      entities.put(entity.getId(), entity);
    }

    @Override
    public void remove(String id) {
      if (entities.containsKey(id)) {
        entities.remove(id);
      }
    }

    @Override
    public void update(Restaurant entity) {
      if (entities.containsKey(entity.getId())) {
        entities.put(entity.getId(), entity);
      }
    }

    @Override
    public Collection<Restaurant> findByName(String name) 
    throws Exception {
      Collection<Restaurant> restaurants = new ArrayList();
      int noOfChars = name.length();
      entities.forEach((k, v) -> {
        if (v.getName().toLowerCase().contains(name.subSequence(
        0, noOfChars))) {
          restaurants.add(v);
        }
      });
      return restaurants;
    }

    @Override
    public boolean contains(String id) {
      throw new UnsupportedOperationException(
          "Not supported yet."); //To change body of generated methods, choose Tools | Templates.
    }

    @Override
    public Restaurant get(String id) {
      return entities.get(id);
    }

 
    @Override
    public Collection<Restaurant> getAll() {
      return entities.values();
    }
  }
}

If you are using a few Spring Cloud dependencies that you don't want to use during testing the integration test, then you can disable specific Spring Cloud features, such as spring.cloud.discovery , using the configuration in test/resources/application.yml , as shown in the following snippet. Here, we have disabled service discovery. You'll learn about service discovery in the next chapter:

# Spring properties
spring:
  cloud:
    discovery:
      enabled: false
  aop:
    auto: false

Docker is a very popular containerization product. You might have an idea about it, or you can refer to Chapter 1 , A Solution Approach , for an overview.

A Docker container provides a lightweight runtime environment that consists of the core features of a virtual machine and the isolated services of operating systems, known as a Docker image. Docker makes the packaging and execution of microservices easier and smoother. Each operating system can have multiple Docker instances, and each Docker instance can run multiple applications.

Docker needs a virtualized server if you are not using a Linux OS. Windows 10 provides Hyper-V. You can install VirtualBox or similar tools such as Docker Toolbox to make it work for you prior to Windows 10. The Docker installation page gives more details about it and explains how to do it. So, take a look at the Docker installation guide that's available on Docker's website for more information.

You can install Docker by following the instructions given at https://docs.docker.com/engine/installation/ .

For Windows, default machines are created with 2 GB of memory. We'll recreate a Docker Machine with 4 GB of memory:

docker-machine rm default

# Windows 10 (Hyper V)
docker-machine create --driver hyperv --hyperv-virtual-switch <switch name configured in Hyper V e.g. DockerNAT> --hyperv-memory 4096 default

# prior to Windows 10 (Docker Toolbox)
docker-machine create -d virtualbox --virtualbox-memory 4096 default

There are various Docker Maven plugins that can be used:

• https://github.com/rhuss/docker-maven-plugin
• https://github.com/alexec/docker-maven-plugin
• https://github.com/spotify/docker-maven-plugin

You can use any of these. I found the Docker Maven plugin by @rhuss to be best suited for us. It has not been updated for a while, but it works perfectly.

We need to introduce the Docker Spring profile in application.yml before we start discussing the configuration of docker-maven-plugin . It will make our job easier when building services for various platforms.

Configuring the Spring profile for Docker:

1. We'll use the Spring profile identified as Docker.
2. There won't be any conflict of ports among embedded Tomcat, since services will be executed in their own respective containers. We can now use port 8080 .
3. We will prefer using an IP address to register our services in Eureka. Therefore, the Eureka instance property preferIpAddress will be set to true .
4. Finally, we'll use the Eureka server hostname in serviceUrl:defaultZone .

To add a Spring profile in your project, add the following lines in application.yml after the existing content:

---
# For deployment in Docker containers
spring:
  profiles: docker
  aop:
    auto: false

server:
  port: 8080

The mvn clean package command will generate the service JAR, and you can use the -Dspring.profiles.active flag to activate a specific profile, for example, Docker, while executing this JAR. We'll use this flag while configuring the Docker file.

Now, let's configure docker-maven-plugin to build the image with our restaurant microservice. This plugin has to create a Dockerfile first. The Dockerfile is configured in two places—in pom.xml and docker-assembly.xml . We'll use the following plugin configuration in pom.xml :

...
 
<properties>
    <start-class>com.packtpub.mmj.restaurant.RestaurantApp
    </start-class>
    <docker.registry.name>localhost:5000/</docker.registry.name>
    <docker.repository.name>${docker.registry.name}sourabhh/${project.artifactId}</docker.repository.name>
    <docker.host.address>192.168.43.194</docker.host.address>
    <docker.port>8080</docker.port>
  </properties>
...

<build>
    <plugins>
      <plugin>
        <groupId>org.jolokia</groupId>
        <artifactId>docker-maven-plugin</artifactId>
        <version>0.13.9</version>
        <configuration>
          <images>
            <image>
              <name>${docker.repository.name}:${project.version}</name>
              <alias>${project.artifactId}</alias>

              <build>
                <from>openjdk:11-jre</from>
                <maintainer>sourabhh</maintainer>
                <assembly>
                  <descriptor>docker-assembly.xml</descriptor>
                </assembly>
                <ports>
                  <port>${docker.port}</port>
                </ports>
                <cmd>
                  <shell>java -Dspring.profiles.active="docker" -jar \
                    /maven/${project.build.finalName}.jar server \
                    /maven/docker-config.yml</shell>
                </cmd>
              </build>
              <run>
                <namingStrategy>alias</namingStrategy>
                <ports>
                  <port>${docker.port}:8080</port>
                </ports>
                <!-- <volumes>
                    <bind>
                        <volume>${user.home}/logs:/logs</volume>
                    </bind>
                </volumes> -->
                <wait>
                  <http><url>http://${docker.host.address}:${docker.port}/v1/restaurants/1</url></http>
                  <time>500000</time>
                </wait>
                <log>
                  <prefix>${project.artifactId}</prefix>
                  <color>cyan</color>
                </log>
              </run>
            </image>
          </images>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-failsafe-plugin</artifactId>
        <configuration>
          <phase>integration-test</phase>
          <groups>com.packtpub.mmj.restaurant.resources.docker.DockerIT</groups>
          <systemPropertyVariables>
            <service.url>http://${docker.host.address}:${docker.port}/</service.url>
          </systemPropertyVariables>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>integration-test</goal>
              <goal>verify</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>          <excludedGroups>com.packtpub.mmj.restaurant.resources.docker.DockerIT
</excludedGroups>
        </configuration>
      </plugin>
    </plugins>
  </build>

You can update the properties as per your system, including the Docker hostname and port. The Docker Maven plugin is used to create a Dockerfile that creates the JRE 11 ( openjdk:11-jre )-based image. This exposes ports 8080 and 8081 .

Next, we'll configure docker-assembly.xml , which tells the plugin which files should be put into the container. It will be placed in the src/main/docker directory:

<assembly xmlns="http://maven.apache.org/plugins/maven-assemblyplugin/
assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
          xsi:schemaLocation="http://maven.apache.org/plugins/maven-assemblyplugin/
assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
    <id>${project.artifactId}</id>
    <files>
        <file>
            <source>target/${project.build.finalName}.jar</source>
            <outputDirectory>/</outputDirectory>
        </file>
        <file>
            <source>src/main/resources/docker-config.yml</source>
            <outputDirectory>/</outputDirectory>
        </file>
    </files>
</assembly>

In the preceding assembly, add the service JAR and docker-config.yml in the generated Dockerfile . This file is located in src/main/resources . On opening this file, you will find the following contents:

FROM openjdk:11-jre
MAINTAINER sourabhh
EXPOSE 8080
COPY maven /maven/
CMD java -Dspring.profiles.active="docker" -jar \
/maven/restaurant-service.jar server \
/maven/docker-config.yml

We are using openjdk:11-jre as a base image.

The preceding file can be found at restaurant-service\target\docker\localhost\5000\<username>\restaurant-service\PACKT-SNAPSHOT\build . The build directory also contains the maven directory, which contains everything mentioned in docker-assembly.xml .

Let's build the Docker image (please make sure docker and docker-machine are running):

mvn docker:build

Once this command completes, we can validate the image in the local repository using Docker images, or by running the following command:

docker run -d -p 8080:8080 <username>/restaurant-service:PACKT-SNAPSHOT

Use -it to execute this command in the foreground, in place of –d .

To execute a Docker image with Maven, we need to add the configuration in the pom.xml file under the <run> block of docker-maven-plugin . Please refer to the <run> section under the docker-maven-plugin block in pom.xml .

We have defined the parameters for running our restaurant-service container. We have mapped Docker container ports 8080 and 8081 to the host system's ports, which allows us to access the service. Similarly, we have also bound the containers' logs directory to the host systems' <home>/logs directory.

The Docker Maven plugin can detect whether the container has finished starting up by polling the ping URL of the admin backend until it receives an answer.

Please note that a Docker host is not a localhost if you are using Docker Toolbox or Hyper-V on Windows or macOS X. You can check the Docker machine's IP by executing docker-machine ip <machine-name/default> . It is also shown while starting up.

The Docker container is ready to start. Use the following command to start it using Maven:

mvn docker:start

Starting and stopping a Docker container can be done by adding the <execution> block in the docker-maven-plugin life cycle phase to the pom.xml file.

Next, the failsafe plugin can be configured to perform integration testing with Docker. This allows us to execute the integration tests. We are passing the service URL in the service.url tag so that our integration test can use it to perform integration testing.

We'll use the DockerIntegrationTest marker to mark our Docker integration tests. It is defined as follows:

package com.packtpub.mmj.restaurant.resources.docker;

public interface DockerIT {
    // Marker for Docker integration Tests
}

Please refer the <configuration> <phase> section inside the maven-failsafe-plugin plugin section of pom.xml . You can see that DockerIT is configured for the inclusion of integration tests (the failsafe plugin). However, it is excluded in unit tests (the surefire plugin).

A simple integration test looks like this:

@Category(DockerIT.class)
public class RestaurantAppDockerIT {

    @Test
    public void testConnection() throws IOException {
        String baseUrl = System.getProperty("service.url");
        URL serviceUrl = new URL(baseUrl + "v1/restaurants/1");
        HttpURLConnection connection = (HttpURLConnection) serviceUrl.openConnection();
        int responseCode = connection.getResponseCode();
        assertEquals(200, responseCode);
    }
}

You can use the following command to perform integration testing using Maven (please make sure to run mvn clean install from the root of the project directory before running the integration test):

mvn integration-test

Each microservice will have its own Docker container. Therefore, we'll use the docker-compose Docker container manager to manage our containers. You can also use Docker Swarm or Kubernetes, which are more popular and used at production environments.

Docker Compose will help us specify the number of containers and how these will be executed. We can specify the Docker image, ports, and each container's links to other Docker containers.

We'll create a file called docker-compose.yml in our root project directory and add all the microservice containers to it:

version: '3'
services:
  restaurant-service:
    image: localhost:5000/sourabhh/restaurant-service:PACKT-SNAPSHOT
    ports:
      - "8080:8080"

  booking-service:
    image: localhost:5000/sourabhh/booking-service:PACKT-SNAPSHOT
    ports:
      - "8081:8080"

  user-service:
    image: localhost:5000/sourabhh/user-service:PACKT-SNAPSHOT
    ports:
      - "8082:8080"

The preceding code is explained as follows:

• version depends on your Docker installation. You can refer to the Docker documentation to find out which version is compatible with the respective Docker environment.
• image represents the published Docker image for each service.
• ports represents the mapping between the host being used for executing the Docker image and the Docker host. The first one represents the external port that can be used to access the service.

Before executing Docker Compose, you need to build the JAR of all services. You can execute mvn clean package from the code's home directory ( home/Chapter5 ) to do so. Then, you need to build the Docker images using the mvn docker:build command. You need to go to the service's home directory ( home/Chapter5/restaurant-service ) and then execute it.

You can validate all generated images using the following command if you're pushing to a local Docker repository. Otherwise, this command will display the images once docker-compose is up and running:

docker image ls -a

Use the following command to execute the service containers. You need to run it from the same directory in which the docker-compose file is stored:

$ docker-compose up –d
Creating network "chapter4_default" with the default driver
Creating chapter4_restaurant-service_1 ... done
Creating chapter4_booking-service_1 ... done
Creating chapter4_user-service_1 ... done

This will start up all Docker containers that are configured in the docker-composer file. Here, -d (detached mode) runs containers in the background.

To view the status and details of all executed containers, use the following command:

$ docker-compose ps
 Name                         Command                     State     Ports
---------------------------------------------------------------------------------
chapter4_booking-service_1 /bin/sh -c java -Dspring.p ... Up 0.0.0.0:8081->8080/tcp
chapter4_restaurant-service_1 /bin/sh -c java -Dspring.p ... Up 0.0.0.0:8080->8080/tcp
chapter4_user-service_1 /bin/sh -c java -Dspring.p ... Up 0.0.0.0:8080->8080/tcp

You can also check Docker image logs using the following command:

$ docker-compose logs
// Or if you want to access specific service logs
$ docker-compose logs restaurant-service

Once the containers are started successfully using the docker-compose up command, we can test the REST services. For an example, let's take a negative case and see if we can get the restaurant not found error message in French. We'll use the Docker host IP to make the call, along with the exposed port that's mentioned in the docker-compose file:

$ curl -X GET \
> 'http://192.168.8.101:8080/v1/restaurants?name=o1' \
> -H 'Accept-Language: de'
 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
100 98 0 98 0 0 98000 0 --:--:-- --:--:-- --:--:-- 98000{"url":"http://192.168.8.101:8080/v1/restaurants","message":"Restaurant o1 wurde nicht gefunden."}

Similarly, you can test other endpoints.

Finally, you can use the docker-compose down command to stop and remove the containers.

In this chapter, we have learned how the domain-driven design model can be used in a microservice. After running the demo application, we can see how each microservice can be developed, deployed, and tested independently, or bundled and executed together using Docker. You can create microservices using Spring Boot and Spring Cloud very easily.

In the next chapter, we will see how to use these microservice effectively by using service patterns such as service discovery and registration, as well as other tools.

In this part of the book, you will learn about different microservice patterns and their implementations. Patterns are the required components of successful microservice implementation.

In this section, we will cover the following chapters:

• Chapter 5 , Microservice Patterns – Part 1
• Chapter 6 , Microservice Patterns – Part 2
• Chapter 7 , Securing Microservices
• Chapter 8 , Consuming Services Using the Angular App

This chapter takes you from the implementation of our sample project—an online table reservation system ( OTRS )—to the next stage. In this chapter, we'll implement two important patterns that constitute the backbone of microservice-based systems—service discovery and registration, and a centralized configuration server . We'll learn more about the other important service patterns in the next chapter.

In this chapter, we will cover the following topics:

• Service discovery and registration
• Centralized configuration
• The execution and testing of our containerized OTRS application

We'll continue adding to the code from our previous chapters. You can copy the last chapter's code and start following this chapter, or alternatively refer to the code that's available on GitHub or Packt's website.

First, we'll add two more modules in pom.xml — eureka-server and config-server (highlighted in the following code snippet). Then, we'll add the same code structure that is available in other services to create those modules in the config-server and eureka-server directories under the project home:

...
...
<modules>
  <module>restaurant-service</module>
  <module>user-service</module>
  <module>booking-service</module>
  <module>eureka-server</module>
  <module>config-server</module>
</modules>
...
...

Service discovery and registration is one of the most popular service patterns. It is used extensively in SOAP-based web services. Put simply, you need a place where all microservices, also known as services, get registered and can be referenced. In this way, you can refer, monitor, and check the availability of service instances at a single place.

Everything is dynamic today. Services may change IP or port frequently, which is quite common in cloud platforms. Therefore, you can't use hardcoded values for the host IP, name, port, and so on.

Service discovery and registration entails the use of a database where service instance details are kept, including their locations. On top of that, there is also a health check API, which provides prudent ways to identify dead instances.

The main features of service registration and discovery are as follows:

• Registration : There are two ways a service can be registered with a service discovery and registration service— self-registration or by using third-party applications such as AWS auto-scaling groups or Netflix Prana . While booting up s ervices calls the service discovery and registration service .
• Un-registration : Services are unregistered while shutting down, or service discovery and registration makes use of the health check API to mark down or un-register the service .
• Discovery : A client of any service simply calls the service discovery and registration service using the service identifier, and gets the instance reference.

The following are some examples of service discovery and registration services:

• Netflix Eureka
• Apache Zookeeper
• Consul

Here, we'll make use of Netflix Eureka using Spring Cloud for our sample OTRS project . Spring Cloud provides a state-of-the-art service registry and discovery application, which is Netflix's Eureka library.

Once you have configured the Eureka service as described in this section, it will be available for all incoming requests so that they're listed there. The Eureka service registers/lists all microservices that have been configured by the Eureka client. Once you start your service, it pings the Eureka service configured in your application.yml file , and once a connection is established, the Eureka service registers the service.

Eureka service also enables the discovery of microservices through a uniform way to connect to other microservices. You don't need an IP, hostname, or port to find the service; you just need to provide the service ID to it. Service IDs are configured in the application.yml file of the respective microservices.

Netflix Eureka Server stores all information in memory. In fact, Eureka Server is also a Eureka client, which is required to ping peer Eureka Servers that are defined using the service URI. Peer Eureka Servers are required in high-availability zones and regions. However, if you don't have a peer Eureka Server, you can simply run it using standalone mode by changing its configuration. We'll cover this in the third step of the Implementation section.

We'll modify the service code structure of the eureka-server directory. We'll do so by following three steps:

1. Maven dependency : First, we'll add a Spring Cloud dependency, as shown here, and a startup class with the @EnableEurekaServer annotation in pom.xml :

<dependency> 
   <groupId>org.springframework.cloud</groupId> 
   <artifactId>spring-cloud-netflix-eureka-server</artifactId> 
</dependency>

2. Startup class : Next, the startup class, App , will run the Eureka service seamlessly by just using the @EnableEurekaServer class annotation. This annotation does all the work for us. It adds /eureka endpoints, which provide the Eureka HTTP API. It also adds a Eureka UI, which displays the service instance tables with some other details:

package com.packtpub.mmj.eureka.service; 
 
import org.springframework.boot.SpringApplication; 
import org.springframework.boot.autoconfigure.SpringBootApplication; 
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer; 
 
@SpringBootApplication 
@EnableEurekaServer
public class App { 
    public static void main(String[] args) { 
        SpringApplication.run(App.class, args); 
    } 
} 

3. Spring configuration : Eureka Server also needs the following Spring configuration for the Eureka Server configuration ( src/main/resources/application.yml ):

# Spring properties
spring:
  application:
    name: eureka-server

server:
  port: ${vcap.application.port:8761} # HTTP port

info:
  component: Discovery Server

eureka:
    instance:
          hostname: localhost
    client:
        registerWithEureka: false
        fetchRegistry: false
        serviceUrl:
          defaultZone: ${vcap.services.${PREFIX:}eureka.credentials.uri:http://user:password@localhost:8761}/eureka/
    server:
        waitTimeInMsWhenSyncEmpty: 0
        enableSelfPreservation: false

---
# For deployment in Docker containers
spring:
  profiles: docker

server:
    port: ${vcap.application.port:8761}

eureka:
    instance:
          hostname: eureka
    client:
        registerWithEureka: false
        fetchRegistry: false
        serviceUrl:
          defaultZone: http://eureka:8761/eureka/
    server:
        waitTimeInMsWhenSyncEmpty: 0
        enableSelfPreservation: false 

The preceding code snippet is explained here:

• • eureka.instance.hostname : Name of the host where the Eureka instance is running. Required only if the machine does not know its own hostname. Either the IP or the hostname is used for registration. Set eureka.instance.preferIpAddress to true if you want to use the IP.
  • eureka.client.registerWithEureka : Takes a Boolean value. This determines whether you want to register with Eureka Server or not. We have set it to false since we want to run it in standalone mode.
  • eureka.client.fetchRegistry : Takes a Boolean value. This determines whether you want to fetch the Eureka registry or not. We have set it to false since we want to run it in standalone mode.
  • eureka.client.serviceUrl.defaultZone : Accepts the URL of Eureka Server. We have set it to the same host as the local instance (standalone mode).
  • eureka.server.waitTimeInMsWhenSyncEmpty : Accepts a time in milliseconds. This could refer to the warm-up time when Eureka Server is started with an empty registry, for example. During a specified time, Eureka Server does not respond to client queries, but accepts registration and renewals. The default time is 5 minutes.
  • eureka.server.enableSelfPreservation : Eureka uses self-preservation mode when it detects many clients are disconnected in an ungraceful manner. Self preservation protects Eureka registry data from catastrophic network events. If you don't want self preservation, you can set this to false.

Similar to Eureka S erver, each OTRS service should also be the Eureka client that enables the services to be registered on Eureka Server and should be able to consume other services using the discovery service provided by Eureka Server. Eureka clients are equally important for implementing the service discovery and registration pattern.

Eureka clients provide metadata such as hostname/IP, port, and the health check API. On successful registration call, Eureka Server stores service instances and their details in a Eureka registry. Eureka clients send heartbeats (API calls) to Eureka Server regularly. Eureka Server removes any instance from the registry if no heartbeats are received during the specified time.

Eureka clients can be implemented using the following three steps. Here, an implementation is written for our restaurant service. The same approach could be used for making other service Eureka clients. Please refer to the code for this chapter if you face any issues.

Let's add a Eureka client with the following steps:

1. Maven dependency : First, we'll add a Spring Cloud dependency :

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-netflix-eureka-client
   </artifactId>
</dependency>

2. Startup class : Next, the startup class, RestaurantApp , will run the Eureka client seamlessly by just using the @EnableEurekaClient class annotation. This annotation does all the work for us. It adds /eureka endpoints, which provide the Eureka HTTP API. It also adds the Eureka UI, which displays the service instance tables with some other details:

package com.packtpub.mmj.restaurant;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;

SpringBootApplication
@EnableEurekaClient
public class RestaurantApp {
  public static void main(String[] args) {
    SpringApplication.run(RestaurantApp.class, args);
  }
}

3. Spring configuration : Eureka Server also needs the following Spring configuration for Eureka Server configuration ( src/main/resources/application.yml ):

...
...
# Discovery Server Access
eureka:
  instance:
    leaseRenewalIntervalInSeconds: 10
    leaseExpirationDurationInSeconds: 20
    metadataMap:
      instanceId: ${vcap.application.instance_id:${spring.application.name}:${spring.application.instance_id:${random.value}}}

  client:
    registryFetchIntervalSeconds: 5
    instanceInfoReplicationIntervalSeconds: 5
    initialInstanceInfoReplicationIntervalSeconds: 5
    serviceUrl:
      defaultZone: ${vcap.services.${PREFIX:}eureka.credentials.uri:http://user:password@localhost:8761}/eureka/
    fetchRegistry: true

...
...

---
# For deployment in Docker containers
...
...

eureka:
  instance:
    preferIpAddress: true
    leaseRenewalIntervalInSeconds: 10
    leaseExpirationDurationInSeconds: 20
  client:
    registryFetchIntervalSeconds: 5
    instanceInfoReplicationIntervalSeconds: 5
    initialInstanceInfoReplicationIntervalSeconds: 5
    serviceUrl:
      defaultZone: http://eureka:8761/eureka/
      fetchRegistry: true
      healthcheck:
        enabled: true

The preceding code is explained here:

• • eureka.instance.leaseRenewalIntervalInSeconds : The i nstance sends periodic heartbeats to Eureka Server to let it know that it is still alive. The default value of this property is 30 seconds. You can change this interval using this property. It is recommend to use the default value in production. Ideally, a service instance is not discoverable until the service instance, Eureka Server, and all other Eureka clients have the same metadata in the local cache. If Eureka Server does not receive heartbeats as per the time value defined for leaseExpirationDurationInSeconds (the next property) , Eureka Server removes the client instance from the registry view and does not allow any traffic to this instance.
  • eureka.instance.leaseExpirationDurationInSeconds : The default value for this is 90 seconds. Eureka Server waits for the time defined using this property after no heartbeats are received from the client instance. Once the waiting period is over, Eureka Server removes the client instance from the registry view and does not allow any traffic to the removed client instance. Please make sure to keep this value higher than the value of leaseRenewalIntervalInSeconds , so that a temporary network glitch won't unnecessarily remove the client instance.
  • eurkea.instance.metadataMap.instanceId : This is the client instance ID that is used to register on the Eureka Server registry.
  • eurkea.instance.preferIpAddress : This Boolean flag determines whether the IP address should be used or not, while updating the client instance details in the Eureka registry. If it is set to false, then the hostname is used.
  • eureka.client.registryFetchIntervalSeconds : This property value (in seconds) determines the periodic interval when the Eureka client fetches the registry information from Eureka Server. The default value is 30 seconds.
  • eureka.client.instanceInfoReplicationIntervalSeconds : This interval property determines when to replicate the instance changes to Eureka Server. The default value is 30 seconds.
  • eureka.client.initialInstanceInfoReplicationIntervalSeconds : This reflects the initial period of the instanceInfoReplicationIntervalSeconds property. The default value is 40 seconds.
  • eureka.client.serviceUrl.defaultZone : This is a fallback value of the service URL when the client does not provide any preferences. The instance sends heartbeats using the service URL to the Eureka Server registry.
  • eureka.client.serviceUrl.fetchRegistry : This is a Boolean flag that determines whether the client should fetch registry information from Eureka Server or not.
  • eureka.client.serviceUrl.healthcheck.enabled : This is a Boolean flag that determines whether the health check API should be used or not.

The Eureka Server and Eureka client implementation for our restaurant service is now complete. The restaurant service should be referred to in order to implement the Eureka client in booking, user, and other services if you have added any.

We'll see the execution and output of Eureka Server and the Eureka clients at the end of this chapter, after we've implemented the centralized configuration.

You might have faced configuration problems while writing monolithic applications. On top of that, sometimes, any changes in property depending on the way configuration is implemented requires a restart of application servers such as WebLogic/JBoss and/or web servers such as Tomcat. Configuration management is especially challenging in microservice-based systems when the number of microservices is huge.

Another problem is how to execute microservice-based systems in different environments without making any changes in the code. You may have different database connections, third-party application configurations, or different properties for different environments (development, QA, production, and so on). In such cases, configuration should not be hardcoded; instead, it should dynamically change based on the active environment. Configuration of microservices is a cross-cutting concern and can be resolved using externalized and centralized configuration.

Spring Boot provides externalized configuration so that you can use the same code in different environments (for example, the local environment and the Docker environment). We are using YAML files for configuration, which is preferred over using the properties file. Then, you can make use of the @Value annotation to read properties in your code with the POST /actuator /refresh call, or use the object of the class that's annotated with @ConfigurationProperties . Spring Boot's externalized configuration resolves one problem of having different properties for different environments and allows us to use different environments without making any changes.

The next problem is how to make a change in a property on the fly while keeping all the configuration for different environments in a single place. To achieve more control over configuration management—as in what to keep, what to remove, and what to change—centralized configuration tools could be helpful. There are many tools available, such as Spring Cloud Config, Zookeeper, and Consul. We'll implement centralized configuration using Spring Cloud Config.

Spring Cloud Config Server is a centralized configuration server that you can run independently as a microservice using an embedded web server. Moreover, you can also club it with other services if you want. However, this is not recommended since we want to implement a pure microservice.

This works well with different backends, such as version control systems, Vault, JDBCs, and filesystems. It works quite well if you want to have security, encryption/decryption, and more.

Spring Cloud Config Server provides an HTTP resource-based API for external configuration (name-value pairs or equivalent YAML content).

We'll implement the JDBC version of the backend for our OTRS Config Server, and use H2 as the database. First, we'll implement Spring Cloud Config Server. Follow the steps given here to implement the Config Server:

1. Maven dependency : First, we'll add the Spring Cloud Config Server dependency, Spring JDBC, and the H2 dependency in Config Server's pom.xml file, as follows:

...
...
<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-jdbc</artifactId>
</dependency>
<dependency>
   <groupId>com.h2database</groupId>
   <artifactId>h2</artifactId>
</dependency>
...
...

2. Startup class : Next, the startup class, App , will run the Config Server seamlessly by just using the @EnableConfigServer class annotation. This annotation does all the work for us.

Also, we want to insert a few property records in the config database after Config Server startup. You could just add data.sql , which would run automatically. However, the data.sql script was being executed twice, therefore we added this code block to avoid multiple executions.

We are going to use the in-memory database. You can change the data insertion approach if you want to use a permanent database. In that case, you want to insert the seed data records only once:

@SpringBootApplication
@EnableConfigServer
public class App {

  @Autowired
  JdbcTemplate jdbcTemplate;

  /**
   * @param args
   */
  public static void main(String[] args) {
    SpringApplication.run(App.class, args);}

  @EventListener(ApplicationReadyEvent.class)
  public void insertDataAfterStartup() {
    Resource resource = new ClassPathResource("data-config.sql");
    ResourceDatabasePopulator databasePopulator = new 
        ResourceDatabasePopulator(resource);
    databasePopulator.execute(jdbcTemplate.getDataSource());
  }
}

3. Spring configuration : Eureka Server also needs the following Spring configuration for the Eureka Server configuration ( src/main/resources/bootstrap.yml and src/main/resources/application.yml ):

# bootstrap.yml

server:
  port: 8888

spring:
  application:
    name: config-server
  cloud:
    config:
      label: master
      server:
        bootstrap: true
  datasource:
    continue-on-error: true
    initialize-mode: never
  h2:
    console:
      enabled: true
      settings:
        web-allow-others: true

---
spring:
  profiles:
    active: jdbc, docker

application.yml will be added with the following configuration:

# application.yml

info:
  component: Config Server

logging:
  level:
    ROOT: INFO
    org.springframework.jdbc: DEBUG

---

Here, you could see that we have enabled the h2 console and can access it using http://<hostname>:8888/h2-console , and we have allowed web-allow-others so that we can access the h2 console in Docker:

• • spring.cloud.config.label : This label is attached to the versioned set of configuration files. It is an optional property and the default is master only. It is meaningful in version control backends such as Git, where you can use a label that could be specific to a Git tag, branch, or commit ID.
  • spring.cloud.config.server.bootstrap : This accepts a Boolean flag. By default, the flag is marked as false. Once it is set to true, Config Server gets initialized from its own repository during startup.

4. SQL Scripts : The database should have a property table to make the JDBC work as a backend. Also, for our testing purposes, we'll add a few records of user-service configuration. Similarly, you can add configuration for other services as well:

-- schema.sql
CREATE TABLE IF NOT EXISTS properties (
    id IDENTITY PRIMARY KEY,
    application VARCHAR(128),
    profile VARCHAR(128),
    label VARCHAR(128),
    key VARCHAR(512),
    value VARCHAR(512)
);

Here, application , profile , and label are required columns that are used by the configuration server while serving config requests. The application column represents spring.application.name ; for example, user-service . The profile column represents the Spring profile and label , which we is already discussed in step 3. Also, we need to provide the key property and its value. You can refer to the following data-config.sql script for sample records. Config HTTP service has resources in the following form: /{application}/{profile}[/{label}] :

-- data-config.sql
INSERT INTO properties (id, application, profile, label, key, value)
VALUES (1, 'user-service', 'jdbc', 'master', 'app.greet.msg', 'JDBC: Warm welcome from user microservice!');
INSERT INTO properties (id, application, profile, label, key, value)
VALUES (2, 'user-service', 'docker', 'master', 'app.greet.msg', 'Docker: Warm welcome from user microservice!');

We have a centralized configuration server already and now we can make use of it to configure our services. So, basically, whatever key-value pairs the application uses in the application.yml file or coded in Java can be linked and centralized to a configuration server. A change in a property in the Config Server backend can be reflected on the fly in the Config Server client service (for instance, a client service might use a @ConfigurationProperties annotated structured object, or use the @Value variable with a POST /actuator/refresh call). We will make use of @Value in the sample code with a POST /actuator/refresh call to show the on-the-fly change.

When the Config client application starts, it connects to Config Server and retrieves and sets the properties that have been fetched from Config Server. Properties bound with @ConfigurationProperties get changed on the fly if there is a change in Config Server. Properties bound with @RefreshScope get changed on the fly only if the POST /actuator/refresh endpoint is fired on the client after a property update in Config Server. At startup time, if the client cannot connect to Config Server, it uses the default values from the client, but only if spring.cloud.config.fail-fast is set to false (the default value). When spring.cloud.config.fail-fast is set to true, a connection error to Config Server may fail the application startup.

We'll use user-service to make it into a config client by using the following steps:

1. Maven dependency : First, we'll add the Spring Cloud Starter Config dependency, Spring, and Spring Boot Starter Actuator (which is required for the health check API and refresh calls) in the user service's pom.xml as follows:

<dependency>
   <groupId>org.springframework.cloud</groupId>
   <artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

2. Sample REST Endpoint : Next, we use the existing UserApp class to add a REST controller and endpoint. In an ideal scenario, you would create a separate class or use an existing resource class. You can see that we have added @RefreshScope to the UserApp class and have read the app.greet.msg property using the @Value annotation. If Config Server is not available and the spring.cloud.config.fail-fast property is set to false, it loads the default value ( Hello Microservice! ) that's defined in the user service. If the user service connects to Config Server, app.greet.msg would be loaded from Config Server; whether the value is Docker/JDBC: Warm welcome from user microservice! depends on which Spring profile is used. Later, you can change the value in the Config Server backend and then hit the POST /refresh endpoint on the user service to reflect the change:

@SpringBootApplication
@EnableEurekaClient
@RefreshScope
@RestController
public class UsersApp {

  @Value("${app.greet.msg}")
  String message;

  @RequestMapping("/")
  public String greet() {
    return message;
  }
  /**
   * @param args
   */
  public static void main(String[] args) {
    SpringApplication.run(UsersApp.class, args);
  }

}

3. Spring configuration : Eureka Server also needs the following Spring configuration for the Eureka Server configuration ( src/main/resources/bootstrap.yml and src/main/resources/application.yml ):

# bootstrap.yml
management:
  security:
    enabled: false

---
# Spring properties
spring:
  profiles: jdbc
  cloud:
    config:
      uri: http://localhost:8888
      fail-fast: false
      label: master

---
# For deployment in Docker containers
spring:
  profiles: docker
  aop:
    auto: false
  cloud:
    config:
      uri: http://config:8888
      fail-fast: true

application.yml will be updated with the following configuration:

# application.yml

# Spring properties
spring:
  application:
    name: user-service # Service registers under this name
  messages:
    fallback-to-system-locale: false
  cloud:
    config:
      uri: http://localhost:8888
      fail-fast: false
      label: master

app:
  greet:
    msg: Hello Microservice!

management:
  endpoints:
    web:
      exposure:
        include: refresh

# Discovery Server Access
eureka:
  instance:
    leaseRenewalIntervalInSeconds: 3
    leaseExpirationDurationInSeconds: 2
    metadataMap:
      instanceId: ${vcap.application.instance_id:${spring.application.name}:${spring.application.instance_id:${random.value}}}

  client:
    registryFetchIntervalSeconds: 5
    instanceInfoReplicationIntervalSeconds: 5
    initialInstanceInfoReplicationIntervalSeconds: 5
    serviceUrl:
      defaultZone: ${vcap.services.${PREFIX:}eureka.credentials.uri:http://user:password@localhost:8761}/eureka/
    fetchRegistry: true

# HTTP Server
server:
  port: 2224 # HTTP (Tomcat) port


---

server:
  port: 8080

eureka:
  instance:
    preferIpAddress: true
    leaseRenewalIntervalInSeconds: 1
    leaseExpirationDurationInSeconds: 2
  client:
    registryFetchIntervalSeconds: 5
    instanceInfoReplicationIntervalSeconds: 5
    initialInstanceInfoReplicationIntervalSeconds: 5
    serviceUrl:
      defaultZone: http://eureka:8761/eureka/
      fetchRegistry: true
      healthcheck:
        enabled: true

The preceding code is explained here:

• • spring.cloud.config.uri : This is the URI of Config Server.
  • spring.cloud.config.fail-fast : This is a Boolean flag that determines whether the application startup failed if the client does not connect to Config Server. The default value of this property is false.
  • spring.cloud.config.label : This represents the label of the versioned configuration sets.
  • management.endpoints.web.exposure : This represents the endpoints that you want to expose.

Now, we are ready execute our code. Let's update the docker-compose configuration as follows. We'll add two new services—Eureka Server and Config Server:

version: '3'
services:
  eureka:
    image: localhost:5000/sourabhh/eureka-server:PACKT-SNAPSHOT
    ports:
      - "8761:8761"

  config:
    image: localhost:5000/sourabhh/config-server:PACKT-SNAPSHOT
    ports:
      - "8888:8888"

  restaurant-service:
    image: localhost:5000/sourabhh/restaurant-service:PACKT-SNAPSHOT
    ports:
      - "8080:8080"
    links:
      - eureka
      - config

  booking-service:
    image: localhost:5000/sourabhh/booking-service:PACKT-SNAPSHOT
    ports:
      - "8081:8080"
    links:
      - eureka
      - config

  user-service:
    image: localhost:5000/sourabhh/user-service:PACKT-SNAPSHOT
    restart: on-failure
    ports:
      - "8082:8080"
    depends_on:
      - eureka
      - config

You can configure the version of the docker-compose file as per your Docker version. As you can see, we have modified the user service block as well identify when a specific service is up. We want to make sure that the user service boots up with the configuration that was loaded from Config Server. Therefore, it is important that the user service should be started once Config Server is up.

We have marked spring.cloud.config.fail-fast flag as true in the Docker profile. Therefore, the user service fails if it cannot find Config Server up. restart: on-failure makes sure that the user service restarts until it finds Config Server up.

Now, let's see the output of the Eureka Server UI and user service API for checking the property value by using the following steps:

1. Execute docker-compose up -d from your command prompt to make a containerized environment available:

Creating network "chapter5_default" with the default driver
Creating chapter5_config_1 ... done
Creating chapter5_eureka_1 ... done
Creating chapter5_restaurant-service_1 ... done
Creating chapter5_booking-service_1 ... done
Creating chapter5_user-service_1 ... done

2. Once the containerized environment is up, hit GET http://<docker-host-ip>:8761 t o access the Eureka Server instance . This will display all the instances (in the Application column) of Eureka clients:

3. Hit the GET http://<docker-host-ip>:8082 user service endpoint, which displays the following text:

"Docker: Warm welcome from user microservice!

4. Access http://<docker-host-ip>:8888/h2-console . Make sure to use jdbc:h2:mem:testdb as the JDBC URL.
5. Modify the value of the app.greet.msg key for the Docker profile in the properties table with "Config Magic: Warm welcome from user microservice!" .
6. Again, hit the GET http://<docker-host-ip>:8082/ user service endpoint. You will see that the response has not changed:

"Docker: Warm welcome from user microservice!

7. Use the following command. Use the Docker host IP of your environment:

$ curl -X POST \
 http://192.168.8.101:8082/actuator/refresh \
 -H 'Content-Type: application/json'

   % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
100 2 0 2 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0 ["app.greet.msg"]

8. A gain, hit GET http://<docker-host-ip>:8082/ . You will see that the response reflects that the value has changed in the Config Server backend:

Config Magic: Warm welcome from user microservice!

This is Spring Cloud Config Server magic. If you don't want to use the refresh way of changing the property value, then you can use the configuration structure bound to the @ConfigurationProperties class object; it does so without using the refresh call.

In this chapter, we have explored the importance of service discovery and registration, as well as centralized configuration patterns. We have implemented them using the Spring Cloud Netflix Eureka and Spring Cloud Config libraries. The Eureka UI shows all the registered service instances that are available for discovery and can be consumed by other services.

In the next chapter, w e'll see how we can consume the service instances that are available on the Eureka Server registry. We will also explore a few more patterns that are important for the effective implementation of microservices-based systems.

• Netflix Eureka: https://github.com/netflix/eureka
• Spring Cloud Eureka Server: https://cloud.spring.io/spring-cloud-netflix/multi/multi_spring-cloud-eureka-server.html
• Spring Cloud Eureka Client: https://cloud.spring.io/spring-cloud-netflix/multi/multi__service_discovery_eureka_clients.html
• Spring Cloud Config: https://github.com/spring-cloud/spring-cloud-config
• Spring Cloud Config Server documentation: https://cloud.spring.io/spring-cloud-config/multi/multi__spring_cloud_config_server.html

Patterns make development easier and code more maintainable. Therefore, we'll learn about a few more patterns and continue our development where we left off in Chapter 5 , Microservice Patterns – Part 1 , by implementing a few more microservice patterns. We'll add a few more patterns that are required to implement a successful microservice-based system. In this chapter, we'll learn about the API gateway pattern, circuit breakers, and centralized monitoring and their implementation using Spring Cloud.

In this chapter, we will cover the following topics:

• The overall architecture
• Edge servers and the API gateway
• Circuit breakers
• Centralized monitoring

We'll continue adding code from the previous chapter. You can copy the code from that chapter and start following this chapter, or, alternatively, refer to the code available on GitHub or the Packt website.

First, we'll add two more modules in pom.xml — zuul-server and api-service (highlighted in the following code snippet). Then, we'll use the same code structure that is available in other services to create those modules in, by creating respective directories under project home:

...
...
<modules>
  <module>restaurant-service</module>
  <module>user-service</module>
  <module>booking-service</module>
  <module>eureka-server</module>
  <module>config-server</module>
  <module>zuul-server</module>
  <module>api-service</module>
</modules>
...
...

From this chapter onward, we'll use the Spring Cloud Greenwich.M3 milestone release with Spring Boot GA release 2.1.0. You should expect minor changes before the GA release of Greenwich. Spring Cloud has started supporting Java 11 from Greenwich code line.

Netflix was one of the early adopters of microservice-based systems. They were the first to successfully implement microservice architecture on a large scale and make it popular. They also helped increase its popularity and contributed immensely to microservices by open sourcing most of their microservice tools with the Netflix Open Source Software ( OSS ) center.

According to the Netflix blog, when Netflix was developing their platform, they used Apache Cassandra for data storage, which is an open source tool from Apache. They started contributing to Cassandra with fixes and optimization extensions. This led to Netflix seeing the benefits of releasing Netflix projects with the name OSS Center.

Spring took the opportunity to integrate many Netflix OSS projects, such as Zuul, Ribbon, Hystrix, Eureka Server, and Turbine, into Spring Cloud Netflix. This is one of the reasons Spring Cloud provides a ready-made platform for developing production-ready microservices. Now, let's take a look at a few important Netflix tools and how they fit into microservice architecture:

As you can see in the preceding diagram, for each of the microservice practices, we have a Netflix tool associated with it. We can go through the following mapping to understand the diagram. Detailed information is covered in the respective sections of this chapter except for the Eureka and Config server, which are elaborated on in the previous chapter. Also, there are a few that will be explained in the forthcoming chapter:

• Edge server : We use Netflix Zuul server as an Edge server, most commonly known as the API gateway. An Edge server provides a single point to allow the external world to interact with your system. All of your APIs' frontends would only be accessible using this server. Therefore, these are also referred to as gateway or proxy servers. These are configured to route requests to different microservices or frontend applications.
• Load balancing : Netflix Ribbon is used for load balancing. It is integrated with the Zuul and Eureka services to provide load balancing for both internal and external calls.
• Circuit breaker : Netflix Hystrix is used as a circuit breaker and helps to keep the system up and running and avoids the cascading of repeated failures. A fault or break should not cause your whole system not to work. Also, the repeated failure of a service or an API should be handled properly. A circuit breaker provides these features. Netflix Hystrix is used as a circuit breaker and helps to keep a system running.
• Service discovery and registration : The Netflix Eureka server is used for service discovery and registration. We learned and implemented it in Chapter 5 , Microservice Patterns – Part 1 (in the Service discovery and registration section). It not only allows you to register and discover services, but also provides load balancing using Ribbon.
• Monitoring dashboard : Grafana is used with Prometheus for microservice monitoring. It provides a dashboard to check the health of running microservices.
• Config server : A centralized configuration server to store and manage the configuration of different microservices. We discussed and implemented it in chapter 5 , Microservice Patterns – Part 1 (in the Configuration service section).
• ELK Stack : The ELK Stack provides us with log monitoring and visualizing functionality. It can also be clubbed with Zipkin for issue analysis. We'll learn more about it in Chapter 14 , Troubleshooting Guide (in the Logging and the ELK Stack section).
• Zipkin server: This is used for tracing service requests that lie across multiple services. It attaches the trace ID and the span ID to each request to trace in multiple services. We'll learn more about it in Chapter 14 , Troubleshooting Guide (in the Use of correlation ID for service calls section, using Zipkin and Sleuth).

This is not new: the API gateway has been used for a long time. A proxy server is one of the most important components of internet applications, routing different requests based on the URI or header information. An example is the Oracle proxy server.

Microservices expose endpoints to communicate and serve requests. Imagine that you have multiple microservies, perhaps 10/100 or more. It would be a clutter of requests across microservices and clients (web, desktop or mobile app and so on). It would be a nightmare to manage with complex and fragile requests (see the following figure for only three clients and three services):

As soon as we introduce the Edge server, things looks better, less fragile, resilient, and easy to manage:

The introduction of the Edge server allows your system to scale and makes it easier to manage and implement cross-cutting concerns such as security. Primarily, it provides the following features:

• Routing and canarying : This is the main feature. It provides request routing that identifies the pattern and, based on the predicate, routes the request to the respective server. For example, calls having /api/v1/restaurant in the path would be served by restaurant-service and /api/v1/booking would be served by booking-service . Canarying allows you to implement the strategy of routing requests to different instances of the same application based on header information, users' credentials, the time of the request and so on. Canarying can be configured easily on an Edge server. If your app is in a transition mode towards microservices, you could use monolithic strangling to route a few requests to your monolithic application until you migrate to microservices.
• Handling of cross-cutting concerns:
  • Security : Since an Edge server provides you with a single entry point to access all resources, you can easily handle security here. We'll do that in the next chapter.
  • Monitoring: You can monitor all incoming requests easily and add analytics to identify different patterns, and also use analytics data to fine-tune and improve your system. You can also add rate monitoring to limit the calls based on APIs.
  • Many other issues, such as logging and so on. You will wish to have traceable logs for each business call, such as booking a table, spread across multiple services— booking-service , billing-service , payment-service , security-service , and so on.
• Resiliency: Failures are bound to happen. An Edge server can insulate users from seeing any problem that may occur with any downstream services.

We are going to use Spring Cloud Netflix Zuul. However, you are free to modify the code to use Netflix Zuul 2 or the Spring Cloud Gateway, which are new and reactive, and hence serve requests in a non-blocking way.

We'll modify the service code structure of the zuul-server directory. We'll do this in the following three steps:

1. Maven dependency : First, we'll add Spring Cloud dependencies in the pom.xml file. spring-cloud-starter-netflix-zuul is a Zuul dependency that provides all the classes and autoconfiguration for the gateway. We are also making it a Eureka client so that it communicates with the Eureka server. We'll configure the routes based on the instance information available on Eureka; therefore, you need Eureka client information. If you don't want to configure routes based on service instance IDs, then there's no need to add it. In that case, you can use direct URI paths to configure routing:

<!-- Metrics and Discovery client Dependencies -->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-eureka-
       client</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
    </dependency>
<!-- JAXB and Java 11: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-with-Java-9-and-above -->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <groupId>org.glassfish.jaxb</groupId>
      <artifactId>jaxb-runtime</artifactId>
    </dependency>

2. Startup class : Next, the EdgeApp startup class will run the Zuul server seamlessly by just using the @EnableZuulProxy class annotation. This annotation does all the work for us. We'll also add the @EnableDiscoveryClient annotation to make it a Eureka client:

@SpringBootApplication
@EnableZuulProxy
@EnableDiscoveryClient
public class EdgeApp {

  public static void main(String[] args) {
    SpringApplication.run(EdgeApp.class, args);
  }
}

3. Spring configuration : Now, we'll configure the route information in application.yml . The Zuul Edge server also needs Eureka configuration if you want to use service IDs to configure routes. Here, we are just adding restaurant-service . You can similarly configure other services. This file is located at src/main/resources/application.yml :

spring:
  application:
     name: zuul-server

endpoints:
    restart:
        enabled: true
    shutdown:
        enabled: true
    health:
        sensitive: false

zuul:
    ignoredServices: "*"
    routes:
        restaurantapi:
            path: /restaurantapi/**
            serviceId: restaurant-service
            stripPrefix: true

server:
    port: 8765
    compression:
        enabled: true

# Discovery Server Access
eureka:
    instance:
        leaseRenewalIntervalInSeconds: 5
        leaseExpirationDurationInSeconds: 5
        metadataMap:
            instanceId: ${vcap.application.instance_id:${spring.application.name}:${
         spring.application.instance_id:${random.value}}}

    client:
        registryFetchIntervalSeconds: 5
        instanceInfoReplicationIntervalSeconds: 5
        initialInstanceInfoReplicationIntervalSeconds: 5
        serviceUrl:
            defaultZone: ${vcap.services.${PREFIX:}eureka.credentials.uri:http://user:password@localhost:8761}/eureka/
        fetchRegistry: true

logging:
    level:
      ROOT: INFO
      org.springframework.web: INFO

app:
  ConnectTimeout: 100
  ReadTimeout: 3000

Here, we'll only discuss Zuul configuration:

• • zuul.ignoredServices : This is required to ignore the automatic addition of service routes. The "*" value makes sure that only routes configured in the configuration file or the config server are only allowed based on the predicate. Other requests would simply be ignored. Therefore, as per this configuration, only calls to /restaurantapi get forwarded to restaurant-service .
  • zuul.routes : This is used for configuring routes.
  • zuul.routes.restaurantapi : restaurantapi is the ID of the configured route for restaurant-service .
  • zuul.routes.<ID>.path : Here, URI paths are defined. /restaurantapi/** denotes that all requests that call to /restaurantapi will be served by the Edge server and forwarded based on the configuration.
  • zuul.routes.<ID>.serviceId : This represents the service ID registered on the Eureka server. The restaurant-service ID is configured to forward requests to restaurant-service . If you don't use Eureka, you could use the zuul.routes.<ID>.url property to define the URL of the service instead of the service ID, for example, http://hostname:port/v1/restaurant .
  • zuul.routes.<ID>.stripPrefix : You can mark the prefix, for example, /api , to all mappings using the zuul.prefix property. This prefix is stripped before the request is forwarded to a service. It can be marked false to switch off this behavior using zuul.stripPrefix , which is applicable to all mapping. Similarly, this behavior can be controlled specifically for each service using zuul.routes.<ID>.stripPrefix .

Also, Zuul uses the Apache HTTP client by default. If you want to use the Ribbon-based RestClient or OkHttpClient , you can set ribbon.restclient.enabled or ribbon.okclient.enabled to true respectively.

You can play with the other configurations given in the reference section of this chapter to learn more about it. An E dge server is demonstrated at the end of the chapter.

First, build the code from the root directory of Chapter06 using the following command:

Chapter06> mvn clean package

Once the build is successful, run the following commands:

java -jar eureka-server/target/eureka-server.jar
java -jar restaurant-service/target/restaurant-service.jar
java -jar user-service/target/user-service.jar
java -jar booking-service/target/booking-service.jar

Once zuul-server is up, check the Eureka dashboard again to make sure all services are up and running. Now, we can perform testing. Execute the following command:

curl -X GET 'http://localhost:8765/restaurantapi/v1/restaurants?name=o'

This should print the following response. Calls go to the API gateway, which finds the matching route service ( restaurant-service ). It forwards the request as /v1/restaurants?name=0 to restaurant-service and strips the restaurantapi prefix. It forwards the response received from the service to the caller:

[
    {
        "id": "2",
        "name": "L'Ambroisie",
        "isModified": false,
        "tables": null,
        "address": "9 place des Vosges, 75004, Paris"
    },
    {
        "id": "5",
        "name": "Pavillon LeDoyen",
        "isModified": false,
        "tables": null,
        "address": "1, avenue Dutuit, 75008, Paris"
    },
    {
        "id": "9",
        "name": "Guy Savoy",
        "isModified": false,
        "tables": null,
        "address": "18 rue Troyon, 75017, Paris"
    },
    {
        "id": "10",
        "name": "Le Bristol",
        "isModified": false,
        "tables": null,
        "address": "112, rue du Faubourg St Honoré, 8th arrondissement, 
                    Paris"
    }
]

If you fire the zuul-server URL without the restaurantapi prefix, or routes not configured in zuul-server , it will return a 404 error.

You can add more configuration and play with it.

In general terms, a circuit breaker is:

The same concept is used for microservice development, known as the circuit breaker design pattern. It tracks the availability of external services such as Eureka Server, API services such as restaurant-service , and so on, and prevents service consumers from performing any action on any service that is not available.

It is another important aspect of microservice architecture, a safety measure (a failsafe mechanism) for when the service does not respond to a call made by the service consumer—a circuit breaker.

We'll use Netflix Hystrix as a circuit breaker. It calls the internal fallback method in the service consumer when failures occur (for example, due to a communication error or timeout). Hystrix code gets executed embedded within its consumer of service for example, booking-service (consumer of user-service or restaurant-service ). In the next section, you will find the code that implements this feature:

Hystrix opens the circuit and fail-fast (fails immediate when any error occurs) when the service fails to respond repeatedly, until the service is available again. When the number of failed calls to a particular service reaches a certain threshold (the default threshold is 20 failures in 5 seconds), the circuit opens and the call is not made. You must be wondering, if Hystrix opens the circuit, then how does it know that the service is available? It exceptionally allows some requests to call the service.

For more information about how Hystrix works, please refer to https://github.com/Netflix/Hystrix/wiki/How-it-Works .

There are five steps to implement fallback methods. For this purpose, we'll create another service, api-service , the way we have created other services. api-service would consume the other services, such as restaurant-service and so on, and would be configured in the Edge server to expose OTRS APIs for external use.

Eureka clients can be implemented using the following three steps. Here, the implementation is written for a restaurant service. The same approach could be used to make another service a Eureka client. Please refer to the download code if you face any issues:

1. Maven dependency : First, we need to add the following dependency in pom.xml , along with other dependencies for the API service or in other projects where you want to failsafe API calls:

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

2. Startup class : Next, t he ApiApp startup class (consumes other services) will enable the circuit breaker using the @EnableCircuitBreaker class annotation. This annotation does all the work for us. This class is located at src\main\java\com\packtpub\mmj\api\service\ApiApp.java :

@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
public class ApiApp {

    private static final Logger LOG = LoggerFactory.getLogger(ApiApp.class);

    @Value("${app.rabbitmq.host:localhost}")
    String rabbitMqHost;

    @Bean
    public ConnectionFactory connectionFactory() {
        LOG.info("Create RabbitMqCF for host: {}", rabbitMqHost);
        CachingConnectionFactory connectionFactory = 
                  new CachingConnectionFactory(rabbitMqHost);
        return connectionFactory.getRabbitConnectionFactory();
    }

    @LoadBalanced
    @Bean
    RestTemplate restTemplate() {
        return new RestTemplate();
    }

    public static void main(String[] args) {
        LOG.info("Register MDCHystrixConcurrencyStrategy");
        SpringApplication.run(ApiApp.class, args);
    }
}

3. Define the fallback method: The fallback method handles failures and performs safety steps or the steps for cascading the failure. Here, we have just added a sample. This can be modified based on the way we want to handle the failure. In this example, we are going to consume the restaurant service APIs. Therefore, a RestaurantServiceAPI class is added to consume its services. The path to the file is src\main\java\com\packtpub\mmj\api\service\restaurant\RestaurantServiceAPI.java :

/**
* Fallback method for getRestaurant()
*
* @param restaurantId
*/
  public ResponseEntity<Restaurant> defaultRestaurant(
      @PathVariable int restaurantId) {
    return new ResponseEntity<>(HttpStatus.BAD_GATEWAY);
  }

  /**
   * Fallback method for findByName()
   *
   * @param input
   */
  public ResponseEntity<Collection<Restaurant>>   
  defaultRestaurants(String input) {
    LOG.warn("Fallback method for user-service is being used.");
    return new ResponseEntity<>(HttpStatus.NO_CONTENT);
  }

4. Configure the fallback method : The @HystrixCommand annotation is used to configure fallbackMethod . We'll annotate controller RestaurantServiceAPI.java methods to configure the fallback methods. Whenever repeated failures are identified in restaurat-api calls written in this controller class, the respective fallback method would be called and would stop unwanted or cascading failures. Obviously, you need to write the proper handling of failures:

@RequestMapping("/restaurants/{restaurant-id}")
@HystrixCommand(fallbackMethod = "defaultRestaurant")
public ResponseEntity<Restaurant> getRestaurant(
  @PathVariable("restaurant-id") int restaurantId) {
  String url = "http://restaurant-service/v1/restaurants/" + 
                restaurantId;
  LOG.debug("GetRestaurant from URL: {}", url);

  ResponseEntity<Restaurant> result = restTemplate.getForEntity(
                                      url, Restaurant.class);
  LOG.info("GetRestaurant http-status: {}", result.getStatusCode());
  LOG.debug("GetRestaurant body: {}", result.getBody());

  return new ResponseEntity<>(result.getBody(), HttpStatus.OK);
}

@HystrixCommand(fallbackMethod = "defaultRestaurants")
@RequestMapping(method = RequestMethod.GET)
public ResponseEntity<Collection<Restaurant>> findByName(@RequestParam("name") String name) {
  LOG.info(
        String.format("api-service findByName() 
        invoked:{} for {} ", "v1/restaurants?name=", name));
  String url = "http://restaurant-service/v1/restaurants?
                name=".concat(name);
  LOG.debug("GetRestaurant from URL: {}", url);
  Collection<Restaurant> restaurants;
  ResponseEntity<Collection> result = restTemplate.getForEntity(
                                      url, Collection.class);
  LOG.info("GetRestaurant http-status: {}", result.getStatusCode());
  LOG.debug("GetRestaurant body: {}", result.getBody());

  return new ResponseEntity<>(result.getBody(), HttpStatus.OK);
}

5. Spring configuration : We will add the following Hystrix configurations in the application configuration file src/main/resources/application.yml :

...
...
hystrix:
  threadpool:
    default:
      # Maximum number of concurrent requests when using thread 
      # (Default: 10) pools 
      coreSize: 100
      # Maximum LinkedBlockingQueue size - -1 for using 
      # SynchronousQueue (Default: -1)
      # maxQueueSize: -1 Queue size rejection threshold (Default: 5)
      queueSizeRejectionThreshold: 5
  command:
    default:
      circuitBreaker:
        sleepWindowInMilliseconds: 30000
 requestVolumeThreshold: 2
 execution:
 isolation:
 # strategy: SEMAPHORE, no thread pool but 
 # timeout handling stops to work
 strategy: THREAD
 thread:
 timeoutInMilliseconds: 6000

The preceding code is explained as follows:

• • hystrix.threadpool.default.coreSize : Hystrix uses threadpool for circuit breaker implementation. You can change the default coreSize of threadpool using this property. The default value for the thread pool core size is 10 .
  • hystrix.threadpool.default. maxQueueSize : Hystrix uses BlockingQueue . This property determines which implementation of BlockingQueue should be used. The default value is -1 . -1 represents SyncronousQueue of the BlockingQueue implementation. A positive value represents LinkedBlockingQueue of the BlockingQueue implementation . This property could be assigned during initialization. Any change after initialization requires a restart.
  • hystrix.threadpool.default.queueSizeRejectionThreshold : This is used when HystrixCommand queues a thread for execution. The default value of this property is 5 , which determines the queue size rejection threshold. This works only when maxQueueSize is not -1 .
  • command.default.circuitBreaker.sleepWindowInMilliseconds : By default, CircuitBreaker is enabled. You can disable it by setting false to command.default.circuitBreaker.enabled . The default value of this property is 5000 . This represents the amount of time the circuit breaker should wait before determining whether the circuit should be closed again.
  • command.default.circuitBreaker.requestVolumeThreshold : This represents the minimum number of requests that would trip the circuit. The default value is 20 . This means that, in a rolling window, a minimum of 20 requests should be received and failed; then the circuit would only trip open if the default value is used.
  • command.default.execution.isolation.strategy : This property determines which isolation strategy should be used by HystrixCommand.run() . Possible values are THREAD and SEMAPHORE . THREAD is a default value:
    • THREAD : A separate thread is used for its execution. The number of allowed concurrent requests are determined by the current thread pool size.
    • SEMAPHORE : The calling thread is used for its execution. The number of allowed concurrent requests are determined by the semaphore count.
  • command.default.execution.isolation.thread.timeoutInMilliseconds : The time unit in milliseconds, as defined in the property name too. The default value is 1000 milliseconds. Hystrix marks TIMEOUT if the caller request is not served during this time period and performs fallback.

First, build the code from the root directory of Chapter06 using the following command:

Chapter06> mvn clean package

Once the build is successful, then run the following commands to execute the services developed in Chapter 5 , Microservice Patterns - Part 1 :

java -jar eureka-server/target/eureka-server.jar
java -jar restaurant-service/target/restaurant-service.jar
java -jar user-service/target/user-service.jar
java -jar booking-service/target/booking-service.jar
java -jar api-service/target/api-service.jar

Once all the services are up and running, we can perform testing. You can fire any of the URLs of api-service . You will receive successful responses. The circuit breaker is closed:

Either
    http://localhost:7771/restaurants?name=a
or
    http://localhost:7771/restaurants/1

Now, you can stop the restaurant-service and hit the api-service endpoints again. After hitting the URLs a few times, you should see the circuit breaker is open and the fallback methods are called. Until the circuit breaker is open, you will receive the response sent back by the fallback methods.

Now, again, you can start restaurant-service . You should see that, once restaurant-service is up, you again get responses from restaurant-service instead of from the fallback methods of api-service .

Monitoring is key when microservice-based systems are deployed on a production environment. You need a monitoring system in place that captures different metrics such as health services, request and response monitoring, circuit breakers, CPU/RAM/storage, hardware monitoring, security, and all different metrics.

We need a system that consistently sends all information, a collector that collects this information and makes it available for consumption, and a visualization tool that shows collected information in a meaningful way. You can also add a notification tool that generates alerts.

Spring Boot provides health data and other metrics using Spring Boot Actuator. Moreover, a micrometer is also included in Spring Boot 2's Actuator and is also back ported to older Spring Boot versions with the addition of dependencies. Micrometer is SLF4J of metrics, a dimensional-first metrics collection facade. As per the Spring documentation, the autoconfigured Spring Boot 2 application provides:

• Memory and CPU metrics:
  • Processing statistics—threads, classes—loaded or unloaded
  • Memory statistics—cache, buffer pools and so on
  • Garbage Collection Statistics
• Web Server Usages—Jetty, Tomcat and so on
• Connection Pool, Data Source statistics or message broker connection statistics
• Request latencies
• Logging and other monitoring information like up time and so on

You can add/remove metrics by changing configuration. Hystrix streams would also add the request/response and circuit breaker metrics. As an exercise, you may wish to add DB and other stuff to metrics once done with the current implementation at the end of this chapter.

Now, we can discuss the metrics collector and the UI dashboard. We used Netflix Turbine and Hystrix Dashboard for the Hystrix stream combiner/collection and the UI dashboard respectively i n previous editions of this book . Hystrix Dashboard was deprecated in 2018. We'll use new tools, Prometheus and Grafana, in this edition as the collector and monitoring dashboard for both health/system metrics and Hystrix.

Spring Boot provides state-of-the-art support for generating various metrics using actuator and micrometer. We already added Hystrix in api-service , created in the last section. We'll continue updating the api-service code that generates the various metrics required for monitoring.

Spring Boot makes developers' work easy and provides all of the libraries and configuration to support various metrics. We can make the following changes to the api-service , which would enable and generate various metrics.

Update the API service using the following steps:

1. Maven dependency : We must include the spring-boot-starter-actuator dependency, shown as follows, to generate different metrics (this automatically includes micrometer dependencies, as explained earlier) in chapter06/api-service/pom.xml :

...
...
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
...
...

2. Spring configuration : Eureka S erver also needs the following Spring configuration for the Eureka server configuration ( src/main/resources/application.yml ):

# application.yml
...
...
endpoints:
  health:
    sensitive: false

management:
  security:
    enabled: false
  metrics:
    distribution:
      percentiles:
        hystrix: 0.90, 0.99
      percentiles-histogram:
        hystrix: true
  endpoints:
    metrics:
      enabled: true
    web:
      exposure:
        include: '*'
...
...

Here, we have added configuration to generate all the metrics, including ones that may contain sensitive data:

• • endpoints.health.sensitive : Information shared by the health indicator may contain sensitive information, for example, database server information that we don't want to expose to the public. The default value of this property is true . We have set it to false because we want to publish complete health information. Please use this value wisely and have security in place if you publish sensitive information.
  • management.security.enabled : Management endpoints could be exposed on a different port using the management.port property in production environments . The management port should be disabled for public use by the firewall or other means to prevent public access. This property is required to disable the security on management endpoints if security libraries are in the application classpath. You can simply ignore this property because security libraries have not yet been added in api-service . This property is required in the next chapter, which is related to security. Since it is more related to metrics' endpoints, it's been added here.
  • management.metrics.distribution.percentile.hystrix : This property allows the micrometer to generate the Hystrix latency data based on given percentiles.
  • management.metrics.distribution.percentile-histrogram.hystrix : This property a ccepts a Boolean value. It will generate the Hystrix latency histrogram data if marked with a true value.
  • management.endpoints.metrics.enabled : Metrics web endpoints are disabled by default. By setting this property to true, we'll make it accessible.
  • management.endpoints.web.exposure.include : This property helps us to define the endpoints that we want to expose. We can expose all endpoints by setting this property to * .

After making the preceding changes, once you hit the http://<host>:<port>/actuator endpoint, you will receive a JSON object as a response, which contains all of the exposed endpoints, like the following:

{
  "_links": {
    "self": {
      "href": "http://localhost:7771/actuator",
      "templated": false
    },
    "archaius": {
      "href": "http://localhost:7771/actuator/archaius",
      "templated": false
    },
    "auditevents": {
      "href": "http://localhost:7771/actuator/auditevents",
      "templated": false
    },
    "beans": {
      "href": "http://localhost:7771/actuator/beans",
      "templated": false
    },
    "caches-cache": {
      "href": "http://localhost:7771/actuator/caches/{cache}",
      "templated": true
    },
    "caches": {
      "href": "http://localhost:7771/actuator/caches",
      "templated": false
    },
    "health-component": {
      "href": "http://localhost:7771/actuator/health/{component}",
      "templated": true
    },
    "health": {
      "href": "http://localhost:7771/actuator/health",
      "templated": false
    },
    "health-component-instance": {
      "href": "http://localhost:7771/actuator/health/{component}/{instance}",
      "templated": true
    },
    "conditions": {
      "href": "http://localhost:7771/actuator/conditions",
      "templated": false
    },
    "configprops": {
      "href": "http://localhost:7771/actuator/configprops",
      "templated": false
    },
    "env": {
      "href": "http://localhost:7771/actuator/env",
      "templated": false
    },
    "env-toMatch": {
      "href": "http://localhost:7771/actuator/env/{toMatch}",
      "templated": true
    },
    "info": {
      "href": "http://localhost:7771/actuator/info",
      "templated": false
    },
    "integrationgraph": {
      "href": "http://localhost:7771/actuator/integrationgraph",
      "templated": false
    },
    "loggers": {
      "href": "http://localhost:7771/actuator/loggers",
      "templated": false
    },
    "loggers-name": {
      "href": "http://localhost:7771/actuator/loggers/{name}",
      "templated": true
    },
    "heapdump": {
      "href": "http://localhost:7771/actuator/heapdump",
      "templated": false
    },
    "threaddump": {
      "href": "http://localhost:7771/actuator/threaddump",
      "templated": false
    },
    "metrics-requiredMetricName": {
      "href": 
      "http://localhost:7771/actuator/metrics/{requiredMetricName}",
      "templated": true
    },
    "metrics": {
      "href": "http://localhost:7771/actuator/metrics",
      "templated": false
    },
    "scheduledtasks": {
      "href": "http://localhost:7771/actuator/scheduledtasks",
      "templated": false
    },
    "httptrace": {
      "href": "http://localhost:7771/actuator/httptrace",
      "templated": false
    },
    "mappings": {
      "href": "http://localhost:7771/actuator/mappings",
      "templated": false
    },
    "refresh": {
      "href": "http://localhost:7771/actuator/refresh",
      "templated": false
    },
    "features": {
      "href": "http://localhost:7771/actuator/features",
      "templated": false
    },
    "service-registry": {
      "href": "http://localhost:7771/actuator/service-registry",
      "templated": false
    },
    "bindings": {
      "href": "http://localhost:7771/actuator/bindings",
      "templated": false
    },
    "bindings-name": {
      "href": "http://localhost:7771/actuator/bindings/{name}",
      "templated": true
    },
    "channels": {
      "href": "http://localhost:7771/actuator/channels",
      "templated": false
    },
    "hystrix.stream": {
      "href": "http://localhost:7771/actuator/hystrix.stream",
      "templated": false
    }
  }
}

We are done with the initial configuration required for exposing the various endpoints required for monitoring, such as metrics, health, Hystrix stream and so on.

Next, we'll set up Prometheus to aggregate the various information retrieved from the exposed endpoints.

Prometheus is a leading open source tool for monitoring and alerting. Originally, it was developed at SoundCloud and was later open sourced. It is also part of Cloud Native Computing Foundation ( CNCF ), like Kubernetes.

You can aggregate data received from various sources, such as Spring Boot metrics, hystrix.stream , and so on, in time-series fashion, which is identifiable by the metric names and key-value pairs. We'll discuss its internal workings in brief. You can explore its documentation for detailed information.

We will explain the Prometheus architecture by discussing its key components:

• Prometheus server : This is the heart of Prometheus and does the main job of scraping and storing time series data. pull-metrics pulls the time series data from jobs or exporters using HTTP endpoints. For example, Prometheus would pull the different metrics and other data from api-service based on the configuration done on Prometheus ( .yml file). Once metrics are scraped, they are stored locally. Then, Prometheus server runs rules on the stored data to generate time series data or raise alerts.
• Pushgateway: This is used for fetching data from short-lived jobs. Short-lived jobs push metrics before exiting to Pushgateway. Prometheus server pulls metrics data from Pushgateway for scraping.
• Alertmanager: This component is responsible for alerting. Prometheus server pushes raised alerts to Alertmanager, which sends them to different clients, such as email and so on.
• PromQL: PromQL is a functional expression language or a query language.  It allows you to select and aggregate data in real time. You can then consume this data to create meaningful information such as charts, tables, and so on, for example, on Prometheus Web UI. We'll consume PromQL in another UI tool, Grafana.

api-service already exposes all metrics except Prometheus. Now we need to add a micrometer library and change api-service to expose a separate Prometheus endpoint to export the metrics in a format accepted by Prometheus.

Once Prometheus endpoints start producing metrics data, we can configure Prometheus server to pull metrics data from the API service's /actuator/prometheus endpoint.

We'll take the following steps to integrate api-service with Prometheus. We'll start by making a few modifications in api-service :

1. Maven dependency : First, we'll add the micrometer-registry-prometheus dependency in the API service's pom.xml , shown as follows. This provides the data metrics to Prometheus using the /actuator/prometheus endpoint:

<dependency>
   <groupId>io.micrometer</groupId>
   <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

2. Spring configuration : Next, we'll add the following configuration on the existing src/main/resources/application.yml file:

# application.yml
...
...
management:
  metrics:
    export:
      prometheus:
        enabled: true
  endpoints:
    prometheus:
      enabled: true
...
...

The preceding code is explained as follows:

• • management.metrics.export.prometheus.enabled : This property accepts a Boolean value. Micrometer generates the metrics data for Prometheus if set it to true.
  • management.endpoints.prometheus.enabled : This property a ccepts a Boolean value. Once set to true, it exposes the /actuator/prometheus endpoint.

3. Now, restart api-service to confirm that the /actuator/prometheus endpoint is available af ter making the preceding changes. Hit the http://<host>:<port>/actuator endpoint u sing curl or in the browser and you will receive a Prometheus endpoint exposed along with others in the JSON response object, shown as follows:

    ...
    ...
    "prometheus": {
      "href": "http://localhost:7771/actuator/prometheus",
      "templated": false
    },
    ...
    ...

4. Now, we can hit the http://localhost:7771/actuator/prometheus endpoint. It should publish all the metrics data, including Hystrix metrics. Take a look at the sample data that follows:

...
...
# HELP jvm_gc_memory_promoted_bytes_total Count of positive increases in the size of the old generation memory pool before GC to after GC
# TYPE jvm_gc_memory_promoted_bytes_total counter
jvm_gc_memory_promoted_bytes_total 1.15169824E8
# HELP process_cpu_usage The "recent cpu usage" for the Java Virtual Machine process
# TYPE process_cpu_usage gauge
process_cpu_usage 0.06525843863755007
# HELP hystrix_latency_execution_seconds_max 
# TYPE hystrix_latency_execution_seconds_max gauge
hystrix_latency_execution_seconds_max{group="RestaurantServiceAPI",key="getRestaurant",} 0.0
hystrix_latency_execution_seconds_max{group="RestaurantServiceAPI",key="findByName",} 0.0
# HELP hystrix_latency_execution_seconds 
# TYPE hystrix_latency_execution_seconds histogram
hystrix_latency_execution_seconds{group="RestaurantServiceAPI",key="getRestaurant",quantile="0.9",} 0.0
hystrix_latency_execution_seconds{group="RestaurantServiceAPI",key="getRestaurant",quantile="0.99",} 0.0
hystrix_latency_execution_seconds{group="RestaurantServiceAPI",key="getRestaurant",quantile="0.995",} 0.0
hystrix_latency_execution_seconds_bucket{group="RestaurantServiceAPI",key="getRestaurant",le="0.001",} 0.0
...
...

Now, the api-service is up and ready to integrate with Prometheus server.

5. In this step, we'll start the Prometheus server, which will pull the data from the exposed API service's /actuator/prometheus endpoint. We'll create a new Prometheus configuration file for OTRS, api-service , otrs-api.yml (you can find this file at the root of the Chapter06 code directory). Its contents are as follows:

# OTRS api-service config

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

scrape_configs:
  - job_name: 'otrs-api'
    metrics_path: '/actuator/prometheus'
    static_configs:
    - targets: ['localhost:7771']

The preceding code is explained as follows:

• • global.scrape_interval : The Prometheus server scrapes the metrics data based on the given interval. The default interval for scraping is a minute.
  • global.evaluation_interval : This property defines the interval duration of the rules evaluation done by the Prometheus server. The default interval for rule evaluation is a minute.
  • rule_files : Using this property, you can define rules files. We have not defined any rules files.
  • scrape_configs.job_name : scrape_configs accepts an array of job configurations. Each job configuration executes a separate job to scrape data. We have defined only a single job. This property a ccepts a string value that denotes the job name. otrs_api would be the job name that executes the scraping of the api-service data.
  • scrape_configs.metrics_path : This would set the /actuator/prometheus endpoint to request and pull the information for metrics scraping.
  • scrape_configs.static_configs.targets : This property a ccepts an array of values. The address ( ['localhost:7001'] ) defined will be targeted by the Prometheus server to pull metrics data.

Prometheus would scrape the api-service metrics data hosted on localhost:7001 by calling the http://localhost:7001/actuator/prometheus endpoint every 15 seconds , and the scheduled job would be identified as otrs-api , based on the configuration defined in otrs-api.yml . Rules would be evaluated every 15 seconds too. Now, we are good to start the Prometheus server.

6. Start the Prometheus server by executing the following command from Command Prompt. Change the values as per your environment:

<Prometheus home directory>/<prometheus executable> --config.file=<path to otrs-api.yml>

for example, on Windows:
c:\prometheus> prometheus.exe --config.file=otrs-api.yml

7. Once the Prometheus server is up and running, hit the http://<hostname/IP>:<port> URL. By default, the Prometheus Server starts on port 9090 . So, on your local environment, you can simply hit http://localhost:9090 . You may see the Prometheus default UI, as follows:

8. Now, you can click on the - insert metric at cursor - dropdown, and you should see similar Hystrix and other api-service metrics shown in response to http://localhost:7771/actuator/prometheus to confirm the expected integration.

At this point, we can integrate Prometheus with Grafana. The good thing is, we don't need to change the api-service code at all. Let's set up Grafana and integrate it with Prometheus.

We can use Prometheus for visualization, which is quite dull and not as powerful as Grafana. Grafana has the edge over other visualizing tools when we talk about the dashboard, due to its amazing visualizing features. Therefore, we are going to use Grafana to monitor the dashboard.

Grafana is a popular open source visualizing tool. It also provides alerts and query features. If you would like to explore its documentation, you can do so at http://docs.grafana.org/ , because we want to limit its scope for integration and creating monitoring dashboard.

1. First, we'll start Grafana using the following command. It will start Grafana with the default configurations:

<Grafana Home>\bin\<grafana-server executable>

For example, on Windows:
C:\grafana\bin> grafana-server.exe

2. Once Grafana has started successfully, hit http://localhost:3000 . 3000 is a default port for Grafana. You can change the Grafana configuration by modifying the configuration files available at <Grafana Home>/conf/ . This will show the login page:

3. Log in with the default username and password ( admin / admin ). Once you have logged in successfully, it will ask you to change the password. Once the password gets reset, you will see the home page, as follows:

4. Click on the A dd data source link shown on the home page, with the green background. It will open the blank Data sources page. We will add the Prometheus data source that is pointing to http://localhost:9090 . Update the input fields as shown in the following screenshot. After the values have been updated, click on Save & Test . If Grafana makes a successful connection to the Prometheus server , it will show Data source is working , as shown in the following screenshot:

5. Once you're back on the Home screen, you should see that the New dashboard link is now highlighted, as shown in the following screenshot:

6. After clicking on the New dashboard link, the following screen will appear. You can then choose any panel from the various panel options. We'll add the Graph panel; click on it:

7. Now, click on the Edit menu option after opening the pop-up menu, as shown in the following screenshot:

8. Give the panel a proper title and description and choose other options if required. We'll create a panel that will show the total successful requests and the total error requests. We can add All Calls OTRS API as Title :

9. Then, click on the Metrics tab. This is an important step. We define the query that will fetch the data from the given data source. You can select the data source ( prometheus-otrs-api ) we created in the previous step . You can choose the query either from the Prometheus UI or from the API service's /actuator/prometheus endpoint. We have added the following query:

A:
http_server_requests_seconds_count{job=~"$service",outcome="SERVER_ERROR",status=~"502|500|400|401|403"}

B:
sum(http_server_requests_seconds_count{exception="None",job=~"$service", status=~"200|201|204", uri!="/actuator/prometheus", uri!="/**/favicon.ico", key=~"$function|"}) by (outcome)

Query A will select all the failed requests and query B will select all the successful calls of api-service except calls made to the /actuator/prometheus endpoint and the /**/favicon.ico URI. Then, the sum function will add all calls and show the total successful calls are grouped by outcome.

The Grafana edit panel will look like the following screenshot:

10. Similarly, you can edit other tabs — Axes , Legend , Display and so on.
11. Now, click on the Sav e button (in the top-right corner) or click on Ctrl + S :

12. We have added one more panel ( SingleStat ) similar to Graph , and we use the following query:

sum(http_server_requests_seconds_count{exception="None",job=~"$service",outcome="SUCCESS", uri!="/actuator/prometheus", uri!="/**/favicon.ico"}) by (outcome)

13. Once you open the newly created dashboard, it will look like the following screenshot. You should see that it shows successful calls and errors:

14. There is also one more complex dashboard (Hystrix Dashboard) that's created using Hystrix metrics. It is available in the code repository of the Chapter06 root directory. It is inspired by the SoundCloud sample dashboard: https://grafana.com/dashboards/2113 :

You have learned how we can enable monitoring, use aggregates, create time-series data and create nice monitoring dashboards. These dashboards provide live feeds. You can also add alerts in Prometheus and Grafana to fully utilize the live monitoring of microservices.

In this chapter, we have learned about a few more microservice patterns: the API gateway or Edge server, circuit breakers, and the centralized monitoring of microservices. You should now know how to implement and configure, how to implement the API gateway, how to add fallback methods for the circuit breaker pattern, and how to generate and consume different metrics' time-series data.

In the next chapter, we will learn how to secure the microervices with respect to authentication and authorization. We will also explore other aspects of microservice securities.

You can refer to the following links for more information:

• Netflix Zuul: https://github.com/netflix/zuul
• Spring Cloud Netflix Zuul routing and filtering: https://cloud.spring.io/spring-cloud-netflix/multi/multi__router_and_filter_zuul.html
• Netflix Hystrix: https://github.com/Netflix/Hystrix
• Netflix Hystrix configuration: https://github.com/Netflix/Hystrix/wiki/Configuration
• Prometheus: https://prometheus.io
• Grafana: https://grafana.com/grafana

Microservices are the components that are deployed either on-premises or in cloud environments. Microservices can offer external APIs or web APIs for UI apps. Our sample application, OTRS, offers APIs. This chapter will focus on how to secure these APIs using Spring Security and Spring OAuth2. We'll also focus on OAuth 2.0 fundamentals, using OAuth 2.0 to secure the OTRS APIs. For more information on securing REST APIs, you can refer to RESTful Java Web Services Security , Packt Publishing. You can also refer to the Spring Security , Packt Publishing video for more information on Spring Security. We'll also learn about cross-origin request site filters and cross-site scripting blockers.

Covering security in a single chapter is a Herculean task. Therefore, we will only cover the following topics:

• Secure Socket Layer
• Securing microservices by adding authentication and authorization
• OAuth 2.0

So far, we have used Hyper Text Transfer Protocol ( HTTP ). HTTP transfers data in plain text, but data being transferred over the internet in plain text is not a good idea at all; it makes hacker's jobs easy and allows them to get your private information, such as your user ID, passwords, and credit card details using a packet sniffer.

We definitely don't want to compromise user data, so we will provide the most secure way to access our web application. Therefore, we need to encrypt the information that is exchanged between the end user and our application. We'll use Secure Socket Layer ( SSL ) or Transport Security Layer ( TSL ) to encrypt data.

SSL is a protocol designed to provide security (encryption) for network communications. HTTP associates with SSL to provide a secure implementation of HTTP, known as Hyper Text Transfer Protocol Secure , or Hyper Text Transfer Protocol over SSL ( HTTPS ). HTTPS makes sure that the privacy and integrity of the data exchanged is protected. It also ensures the authenticity of websites visited. This security centers around the distribution of signed digital certificates between the server hosting the application, the end user's machine, and a trusted third-party storage server. Let's see how this process takes place:

1. The end user sends the request to the web application, for example, http://twitter.com , using a web browser.
2. On receiving the request, the server redirects the browser to https://twitter.com using the HTTP code 302.
3. The end user's browser connects to https://twitter.com and, in response, the server provides the certificate containing the digital signature to the end user's browser.
4. The end user's browser receives this certificate and checks it against a list of trusted certificate authorities ( CAs ) for verification.
5. Once the certificate gets verified all the way to the root CA, an encrypted communication is established between the end user's browser and the application's hosting server:

We can implement SSL for our sample OTRS project. We don't need to implement SSL for all microservices. All microservices will be accessed using our proxy or Edge server by the external environment, except our new microservice— security-service , which we will introduce in this chapter for authentication and authorization.

You can set up SSL in an Edge server. We need to have the keystore that is required for enabling SSL in an embedded web server. For self-learning, you could use the self-signed certificate. However, it is not supposed to be used in a production environment. In a production environment, you could use the SSL certificates taken from professional providers or use the free certificate from https://letsencrypt.org/

Providing authentication and authorization is necessary for web applications. We'll discuss authentication and authorization in this section. The new paradigm that has evolved over the past few years is OAuth. We'll learn about and use OAuth 2.0 for implementation. OAuth is an open authorization mechanism, implemented in every major web application. Web applications can access each other's data by implementing the OAuth standard. It has become the most popular way to authenticate oneself for various web applications.

For example, on https://www.quora.com/ , you can register and log in using your Google, Twitter, or Facebook login IDs. It is also more user-friendly, as client applications (for example, https://www.quora.com/ ) don't need to store the user's passwords. The end user does not need to remember any more user IDs and passwords:

The Internet Engineering Task Force ( IETF ) governs the standards and specifications of OAuth. OAuth 1.0a was the most recent version before OAuth 2.0, which had a fix for the session-fixation security flaw in OAuth 1.0. OAuth 1.0 and 1.0a are very different from OAuth 2.0. OAuth 1.0 relies on security certificates and channel binding, whereas OAuth 2.0 does not support security certification and channel binding. It works completely on Transport Layer Security ( TLS ). Therefore, OAuth 2.0 does not provide backward compatibility.

The various uses of OAuth are as follows:

• As discussed, it can be used for authentication. You might have seen it in various applications, displaying messages such as sign in using Facebook or sign in using Twitter.
• Applications can use it to read data from other applications, such as by integrating a Facebook widget into the application, or having a Twitter feed on your blog.
• Or, the opposite of the previous point can be true: you enable other applications to access the end user's data.

We'll try to discuss and understand the OAuth 2.0 specifications in a concise manner. Let's first see how signing in using Twitter works.

Please note that the process mentioned here was used at the time of writing, and may change in the future. However, this process describes one of the OAuth 2.0 processes properly:

1. The user visits the Quora home page, which shows various login options. We'll explore the process of the Continue with Twitter link.
2. When the user clicks on the Continue with Twitter link, Quora opens a new window (in Chrome) that redirects the user to the www.twitter.com application. During this process, few web applications redirect the user to the same opened tab/window.
3. In this new window/tab, the user signs in to www.twitter.com with their credentials.
4. If the user has not already authorized the Quora application to use their data, Twitter asks for the user's permission to authorize Quora to access their information. If the user has already authorized Quora, then this step is skipped.
5. After proper authentication, Twitter redirects the user to Quora's redirect URI with an authentication code.
6. Quora sends the client ID, client secret token, and authentication code (sent by Twitter in step five) to Twitter when the Quora redirect URI is entered in the browser.
7. After validating these parameters, Twitter sends the access token to Quora.
8. The user is logged in to Quora on successful retrieval of the access token.
9. Quora may use this access token to retrieve user information from Twitter.

You must be wondering how Twitter got Quora's redirect URI, client ID, and secret token. Quora works as a client application and Twitter as an authorization server. Quora, as a client, is registered on Twitter by using Twitter's OAuth implementation to use resource owner (end user) information. Quora provides a redirect URI at the time of registration. Twitter provides the client ID and secret token to Quora. In OAuth 2.0, user information is known as user resources. Twitter provides a resource server and an authorization server. We'll discuss more of these OAuth terms in the following sections. The following diagram shows the workflow:

There are four roles defined in the OAuth 2.0 specifications:

• Resource owner
• Resource server
• Client
• Authorization server

The following diagram represents the different roles and how the interact with each other:

For the example of a Quora sign-in using Twitter, the Twitter user was the resource owner. The resource owner is an entity that owns the protected resources (for example, user handle, tweets, and so on) that are to be shared. This entity can be an application or a person. We call this entity the resource owner because it can only grant access to its resources. The specifications also define that when the resource owner is a person, they are referred to as an end user.