Creating Java-Based Microservices for Abixen Platform: Part 1
Separated microservices are simpler than adding features to a monolith. Learn to create an app with a functional Java-based microservice on the Abixen Platform.
Join the DZone community and get the full member experience.
Join For FreeIn my previous article, I depicted a microservices-based architecture of Abixen Platform. If you are still not familiar with it, you can do a quick catch up reading the article.
Since Abixen Platform (available on GitHub) allows you to create a functional microservices and deploy them on the platform, I decided to write a series of articles showing and explaining step by step how to develop a custom functional microservice. There are many advantages doing a separated functional microservice instead of adding new features to one big monolith; it’s easier to develop where there are many developers in the same project, easier to maintain. The application with deployed functional microservices can look like this:
Or with a Web Content module and an article:
Within this series, I’m going to show what Java developers need to start a development, how to configure a microservice project, what is required to be setup and how to start a coding both a backend and a frontend, as well as how to deploy on the platform and what is desirable to configure.
First of all, the developer has to setup a development environment. There is a good tutorial how to do it here. The recommended IDE is IntelliJ IDEA, but there are no contraindications to use one like Eclipse or Netbeans.
Generally, developers have an opportunity to create microservices for Abixen Platform using different technologies, not only Java. They can do it in .Net, PHP, Python, RoR, or other web technologies. Interfaces of communication processes with the platform are important. However, in the current version of Abixen Platform, the easier way is to use Java (the whole platform has been written in Java). The reason is because Abixen Platform provides an abixen-platform-common project containing useful utilities classes, interfaces which the developer just has to implement in his own microservice, or some abstracts which have to be extended. There are also some Spring components helping in the communication process between functional microservices and the core microservice.
This series of tutorials will be based on an existing microservice delivered by Abixen Platform called Web Content Service. The service is located in abixen-platform-web-content-service as a Maven module. Let's start!
Setup a Backend Structure for the Project
Starting a new Java-based microservice within Abixen Platform, we have to create a new Maven module. In our example, it will be abixen-platform-web-content-service. To stick to a naming convention, it would be good to have both an “abixen-platform” prefix and a “service” suffix.
Now let’s fill out the pom.xml file. In the project repository, we can find a whole listing, so I will not place it here. However, I will focus on a few important parts of the file.
Since Abixen Platform is based on Spring Boot, I recommend to use it also in our own microservices. That is why in the parent section we have to indicate on Spring Boot:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.4.1.RELEASE</version>
</parent>
Also in the dependency management section, we have to indicate to Spring Cloud dependencies because we will be using these features as well:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Camden.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
In the dependencies section, there is a place where we can include all libraries we are going to use in our project:
<dependencies>
<!-- Here your dependencies -->
</dependencies>
For a regular Java-based microservice which has to meet with all supported features by Abixen Platform, it is required to add the following dependencies:
abixen-platform-common: contains all interfaces, abstracts, utilities and beans the developer can use in his own microservice. By using of these elements there is an easy way to integrate with the platform features.
spring-cloud-starter-security: allows use of a security layer supported by Abixen Platform. The developer can protect his own microservice using functionalities served by the platform.
spring-cloud-starter-feign: enables an easy connection between a created microservice and others.
spring-cloud-starter-hystrix: enables monitoring features for the created microservice.
spring-cloud-starter-eureka: since Abixen Platform uses Eureka as a registry service, connecting to Eureka allows to make the created microservice visible in a whole microservices cluster.
spring-cloud-sleuth-zipkin: enables additional monitoring features for the created microservice.
spring-cloud-config-client: Abixen Platform keeps all configuration in one place. This is a configuration microservice which can serve configurations for other ones. The client is required to connect to the configuration microservice.
spring-boot-starter-web: we are going to create a web application, that's why we need web features.
spring-boot-starter-redis: things like user sessions are stored in Redis. Because we would like to get information about the user (i.e. to check some securities), we have to connect to the Redis database.
spring-boot-starter-data-jpa: a convenient way to connect to a main database of the created microservice. Abixen Platform Common delivers some abstracts help to use Spring Data JPA in a custom microservice.
spring-boot-starter-test: helps in testing.
spring-retry: allows retrying a connection to the configuration microservice. Very useful when all microservices are starting and the configuration is not available yet.
Not all the dependencies have been described above. For more, I strongly encourage to check the pom.xml file of the Web Content Service.
Because we are going to create the microservice with a web layer, it would be desirable to include a plugin to process static resources. Abixen Platform uses Maven Frontend Plugin:
<plugin>
<groupId>com.github.eirslett</groupId>
<artifactId>frontend-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<phase>process-resources</phase>
<id>install node and npm</id>
<goals>
<goal>install-node-and-npm</goal>
</goals>
<configuration>
<nodeVersion>v6.7.0</nodeVersion>
<npmVersion>3.10.9</npmVersion>
</configuration>
</execution>
<execution>
<phase>prepare-package</phase>
<id>npm install</id>
<goals>
<goal>npm</goal>
</goals>
<configuration>
<arguments>install</arguments>
</configuration>
</execution>
<execution>
<phase>prepare-package</phase>
<id>gulp build</id>
<goals>
<goal>gulp</goal>
</goals>
<configuration>
<arguments>--no-color</arguments>
</configuration>
</execution>
</executions>
</plugin>
Thanks to this plugin, we can build a whole application (both a backend and a frontend) by execution of one command: mvn install
. Maven will install Node and NPM. Then having NPM, developers can use Bower Components for static dependencies.
The next important plugin we have to add is Spotify's Docker Maven Plugin. Because the whole platform is Dockerized, our microservice should be as well:
<plugin>
<groupId>com.spotify</groupId>
<artifactId>docker-maven-plugin</artifactId>
<version>${docker.plugin.version}</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>build</goal>
</goals>
</execution>
</executions>
<configuration>
<imageName>${docker.image.prefix}/${project.artifactId}</imageName>
<dockerDirectory>${project.basedir}/src/main/docker</dockerDirectory>
<imageTags>
<imageTag>${project.version}</imageTag>
<imageTag>latest</imageTag>
</imageTags>
<useConfigFile>false</useConfigFile>
<resources>
<resource>
<targetPath>/</targetPath>
<directory>${project.build.directory}</directory>
<include>${project.build.finalName}.jar</include>
</resource>
</resources>
</configuration>
</plugin>
I recommend using Liquibase in your microservice. It helps in a database schema versioning. Then we must add Liquibase Maven Plugin:
<plugin>
<groupId>org.liquibase</groupId>
<artifactId>liquibase-maven-plugin</artifactId>
<version>3.5.3</version>
<configuration>
<propertyFile>src/main/resources/liquibase.properties</propertyFile>
</configuration>
</plugin>
At the end, it would be good to take care for good quality of the source code. Maven Checkstyle Plugin will help. Abixen Platform has configured rules and all we have to do is add the plugin to the POM file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.17</version>
<executions>
<execution>
<id>validate</id>
<phase>validate</phase>
<configuration>
<configLocation>../checkstyle.xml</configLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<failsOnError>true</failsOnError>
</configuration>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
What Next?
This tutorial showed what to look for when setting up a backend layer of microservice we would like to deploy on Abixen Platform. In the next parts of the series, I'm going to explain how to configure a frontend layer of the microservice and how to start development.
Opinions expressed by DZone contributors are their own.
Comments