Before You Begin
It is strongly recommend that you read the preceding solutions before beginning this solution:
This architecture diagram shows the completed RESTful Java microservices application. Each microservice consists of the application running in multiple Docker containers in a Kubernetes cluster. A load balancer selects which instance is used to process a request. The number of application instances is controlled by the Kubernetes cluster and can be scaled up or down automatically. Use this architecture for deploying similar microservices applications.
Figure - Completed Microservices Application Architecture
Description of "Figure - Completed Microservices Application Architecture"
- The client connects to the application through a network. This could be a local network on a machine or the Internet.
- The back end application is a set of Docker containers running Helidon servers in a Kubernetes cluster. Typically more than one copy of the application is deployed and a load balancer is used to select which instance the client communicates with. The containers are managed by the Kubernetes cluster which automatically scales the number of instances.
- The application uses an Oracle database for persistence. Any stored data is pushed to the database. No state is saved in the Kubernetes cluster.
About the Application
The application used in this solution is a simple Employee Directory application. What follows is an overview of how the application works and how the application was built.
The application is composed of two main parts.
- A microservice back end (written in Java)
The two parts demonstrate how a front end interacts with a microservices back end.
About the Microservices-Based Back End
The back end of the application is a microservice that's coded in Java and uses libraries from the Helidon project (https://helidon.io).
The core of the application is the
Main class and the
EmployeeService class. The
Main class loads the
microservice and starts a Netty web server. The
defines the end points for the application and handles requests and responses. The
application has only one microservice. But, a typical production server is likely to
contain more services.
Note that the application is designed to be stateless. All data should be pushed to the database for persistence. This approach allows you to easily scale the application.
You can download the application from the Download Code section.
The application implements the data access object (DAO) pattern and it contains two implementations to store the data.
EmployeeRepositoryImpl class uses a mock database
written with an in-memory
ArrayList classes so that you can test the
application locally or in a Kubernetes cluster without a database connection. The
initial testing with the application is done with this version.
If more than one instance of the application is present in an application cluster, then new data is not replicated across nodes. Keep this in mind when testing.
EmployeeRepositoryImplDB class connects to an Oracle
Database for a back end. Use this version after you have setup your database and are
ready to connect the application to the database.
About the Client
The application is written using a combination of BootStrap and Angular.js
frameworks. The application client is included with the source of the Java backend. When
the application is built, the application directory is copied to the
/public directory and is available to load from your browser at
By default, the client looks for the microservice on the current host on port 8080.
About Required Services and Roles
This solution requires the following services:
- Oracle Cloud Infrastructure Database
- Oracle Cloud Infrastructure Container Engine for Kubernetes
- Oracle Cloud Infrastructure Registry
Define policies that, at a minimum, permit your user's group to manage the
database-family resource-types in your compartment. In addition, grant access to the
repos resource-type in the tenancy.
See Learn how to get Oracle Cloud services for Oracle Solutions to get the cloud services you need.