REDA's BLOG

Optimized docker images for Spring Boot applications with layering feature

Reda Messoudi — Mon, 16 Nov 2020 18:59:23 GMT

Since Spring Boot 2.3, support for building jar files with contents separated into layers has been added to the Maven and Gradle plugins.

The question is : How this layering can help us to improve our docker images ?

Let's see how Spring Boot defines layering :

The layering separates the jar’s contents based on how frequently they will change.

Spring Boot uses fat Jar as default packaging format. If we inspect our application by checking this fat Jar, we can observe that our business code (application) forms a small part of this big jar file. The rest of parts forms the framework, external dependencies and some internal dependencies as we'll see with multi-module projects.

Code example

This post has a working code example available here.

How to read

During this post, I'll go progressively through the optimization of our docker image based on a sample of Spring Boot application.

Our goal through this post is to reach the following result:

Optimization to reach

Base code

Let's create a basic Spring Boot application with a simple /hello endpoint to use as sample for the following. You can get it under branch '/nodocker'.

Basic dockerization of Spring Boot application

Code

The code of this section is available under branch '/initdockerization'.

Details

As a first step, we'll dockerize our sample application by a simple Dockerfile which looks like:

FROM adoptopenjdk/openjdk11:alpine-jre
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
EXPOSE 8081
ENTRYPOINT ["java","-jar","/application.jar"]

Dockerfile for a basic dockerization

Now we can :

pack our application to a fat Jar with Maven

mvn clean package

and build the docker image

docker build -t optimized_dockerimage_springboot:0.0.1 .

By checking our image size, it's around 167 MB and by using Dive we can see that the application layer is 16 MB which is a significant part of the image size.

dive optimized_dockerimage_springboot:0.0.1

Dive into basic docker image

If you don't have Dive or you want to continue without it, you can get similar result using:

docker history --format "{{.ID}} {{.CreatedBy}} {{.Size}}" optimized_dockerimage_springboot:0.0.1

You would say 16 MB isn't such big size but here our sample application contains only one class with some lines, but consider the sizes of real production-ready applications (fat Jars), it can more larger as the complexity and dependencies growth.

What's the problem with large size application ?

The aim of docker images is to be lightweight and reusable as much as possible so our deployment and release processes can be faster.

With large docker images and frequent release cycle we can end by a lot of gigabytes of storage space and increase the network traffic which can be a very bad design specially in cloud environment and when you pay for the traffic usage and storage.

Another problematic thing with unoptimized docker images is performance during Scheduling process.

What's Scheduling ?

In a nutshell, scheduling is how containers are placed and run on your instance.
Take one container with 1GB, managing it couldn't be tricky but what if you have multiple containers with 1GB ?

Every time, pulling this 1GB from your registry causes a long scheduling process and long build times in CI pipelines.

Think about scalability, think about time needed by your orchestration system to place this containers on your instance(s) and think about problems that you can face every time you deploy your 1GB containers.

Add new feature to our application

Now we want to add a new endpoint to our controller which means new feature and new release of our application.

Once the new feature is implemented and our new application version is released we can use the same basic dockerization and build our new docker image version right ?

But the problem here is that our basic dockerization can't see the small size and difference added by our new feature. This new docker image will be built with all our Spring framework dependencies, internal and external dependencies instead of considering the thin change on our business code.

Can we optimize ?

Of course we can.

As explained in the intro, Spring Boot 2.3 made it possible to extract content of our fat Jar without any additional plugins.

This possibility allows us to easily include additional separation between our project dependencies.

Optimized docker image

Code

The code of this section is available under branch '/optimized_dockerimage'

Layering

Spring Boot splits the content of *fat Jar* to 4 layers but by default this layering feature is disabled and needs to be explicitly enabled with the Spring Boot Maven plugin:


    
        
        org.springframework.boot
        spring-boot-maven-plugin
        
            
                true

Enable layering feature in Spring Boot 2.3 project

The 4 layers by default are like following :

dependencies : Contains dependency without SNAPSHOT version
spring-boot-loader : Includes JAR loader classes
snapshot-dependencies : Contains any dependency with SNAPSHOT version
application : Includes application classes and resources

And this application layer will be our main changing layer while our development progress.

To obtain this layering information, we do:

java -Djarmode=layertools -jar target/*.jar list

Until now we just got what compound the layers of our fat Jar.

Next step is to extract those layers to create an optimized docker image. Hopefully, the -Djarmode=layertools system property exists with extract command in aim to extract layers from the jar file and unpack it into seperate directories.

Take-away

If you want to extract in a specific folder/destination, just add --destination argument like:

java -Djarmode=layertools -jar target/*.jar extract --destination target/extracted

Build docker image

A Docker image is composed of a stack of layers each representing an instruction in our Dockerfile, so we can use those extracted layers from fat Jar to construct Docker layers that change the least.

Let's build our docker image while taking benefit of layering feature and multi-stage build.

FROM adoptopenjdk/openjdk11:alpine-jre as builder
# First stage : Extract the layers
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

FROM adoptopenjdk/openjdk11:alpine-jre as runtime
# Second stage : Copy the extracted layers
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
CMD ["java", "org.springframework.boot.loader.JarLauncher"]

Dockerfile for the optimized dockerization

You may notice that no application JAR to run with java -jar. Instead we use the org.springframework.boot.loader.Launcher class which is a special bootstrap class that is used as an executable jar’s main entry point. It's the actual Main-Class in the jar file, and it is used to setup an appropriate URLClassLoader and call the main() method.

Now we can :

pack our application to a layered fat Jar with Maven:

mvn clean package

and build the docker image:

docker build -t optimized_dockerimage_springboot:0.0.2 .

By verifying our optimized docker image size, it's around 167 MB (same size) but by using Dive we can see that the application code is only 5.7 kB which is a very lightweight part of the image size.

Dive into optimized docker image

Now every time we build our docker image, existing layers that have not changed can be reused and only this layer of 5.7 kB will change/growth while delivering new releases (new features, bug fixing, ...).

Optimized docker image with multi-module project

What we did until now was good for most applications but it's possible that in some projects we need to go differently than the out-of-the-box provided by Spring Boot.

For example, we might have some company dependencies that change less frequently than our application or we can have a multi-module project with internal dependencies with different change cadence. We'll cover all that in this section.

Code

The code of this section is available under branch '/multimodule_optimized_dockerimage'.

Multi-module project

First let's change our sample application to a multi-module maven project.

Our project will look like:

domain : Contains our module of domain classes (models, ...)
application : Contains our controllers, ...
and you can also add if you want other modules like persistence, security, ...

Structure of multimodule project with maven

We need to adjust our different pom.xml files, you can take a look on the dedicated branch of this section.

Custom layers configuration

Let's tune how layers are created and add new ones. This can be done using a separate layers.xml file that should be :

registred (application/pom.xml):

    
        
            
                org.springframework.boot
                spring-boot-maven-plugin
                
                    
                        repackage
                        
                            repackage
                        
                    
                
                
                    
                        true
                        true
                        ${project.basedir}/src/layers.xml

Indicate the path to layers.xml file

configured (application/src/layers.xml):


  
    
      org/springframework/boot/loader/**
    
    
  
  
    
      *:*:*SNAPSHOT
    
    
      com.redamessoudi.optimizeddockerimage:*:*
    
    
      com.redamessoudi*:*:*
    
    
  
  
    dependencies
    spring-boot-loader
    organization-dependencies
    modules-dependencies
    snapshot-dependencies
    application

Define the content of layers.xml

The configuration file above describes how the jar can be separated into layers, and the order of those layers.

The layers XML format is defined in three sections:

application : defines how the application classes and resources should be layered.
dependencies : defines how dependencies should be layered.
layerOrder : defines the order that the layers should be written.

More information about different blocks of this file can be found under official documentation.

Keep in mind that include schema is group:artifact[:version] and allows to use Ant matcher patterns.

As we want to add a :

layer containing all modules dependencies (com.redamessoudi.optimizeddockerimage:*:*).
layer containing all organization/company dependencies (com.redamessoudi*:*:*)

regardless of their version, so we used wildcard to match every artifactId and version with the specified groupId.

Docker layers optimization

Let's adjust our Dockerfile to support the 2 new layers (modules-dependencies and organization-dependencies).

Our new Dockerfile will look like:

FROM adoptopenjdk/openjdk11:alpine-jre as builder
# First stage : Extract the layers
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

FROM adoptopenjdk/openjdk11:alpine-jre as runtime
# Second stage : Copy the extracted layers
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader ./
COPY --from=builder application/organization-dependencies ./
COPY --from=builder application/modules-dependencies ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
CMD ["java", "org.springframework.boot.loader.JarLauncher"]

Dockerfile for the optimized dockerization of multi-module project

Now if we build a new version of our docker image, you can see that we take the benefit of Docker cache.

Below I added small change in one of the modules and I rebuilt the docker image thus we can see all previous layers (Step 1 to 18/22) didn't change and took the advantage of Docker cache (--> using cache).

Docker cache with multi-stage and multi-module project

And tadaaaa 👏, we reached our goal defined in the beginning of this post which is to optimize our docker images of Spring Boot based applications with layering feature 💪

Before closing this topic, I'll add below some best practices that every docker user should think about while building image specially with Spring Boot.

Best practices

Now we have optimized our Spring Boot and docker layers, we can see some best practices to have a secure, fast startup and readable docker image.

Non root user

Just as in classic VM-deployments, processes should not be run with root permissions. Your application should have privileges which are essential to perform its intended function.

In other words, the docker image should contain a non-root user that runs the application.

In a Dockerfile, this can be achieved by adding another layer that adds a (system) user and group, then set it as the current user (instead of root):

ARG USER=myuser
ARG HOME=/home/$USER
RUN addgroup --gid 1000 "$USER" \
  && adduser -u 1000 -G "$USER" -h "$HOME" "$USER" --disabled-password

In our multi-stage build, we can add it to our second layer which is runtime. Complete example can be found in Dockerfile in code section of optimized multi-module project.

Labels

Labels are very helpful metadata to organize images, record licensing information, annotate relationships between containers, volumes, and networks, or in any way that makes sense for your business or application.

In a nutshell, docker images with metadata are more readable and easy/quick understandable by others.

Specifying label for docker Image is simple. we just need to specify it as another Dockerfile instruction.

LABEL maintainer="contact@yourcompany.com"
LABEL com.yourcompany.application.name = "optimizedSBDimage"
LABEL com.yourcompany.application.version = "0.0.3"

You can also manage the version value from your Maven version field in pom.xml while building/publishing your docker image to your repo.

You can check the added information under layers section with:

docker image inspect optimized_dockerimage_springboot:0.0.3

Base image

Consider your FROM with using small base image. There is different images whose can be used and maybe smaller than one we used in this post, but you need to know what you want in your base image and select one fills your needs.

We used *-jre base image which means that doesn't include JDK, is smaller than *-jdk but not all apps work with a JRE (as opposed to a JDK), but most do, and indeed some organizations enforce a rule that every app has to because of the risk of misuse of some of the JDK features (like compilation).

Fast startup

If you want to start your app (inside a container) as quickly as possible here is some tweaks you might consider:

Use Spring Boot >= 2.3 and Spring >= 5.1
Avoid actuators if you can
Switch off JMX with spring.jmx.enabled=false
and more

Resources

Source code: https://github.com/redamessoudi/optimized-docker-image-for-springboot

Spring articles :

Polymorphic deserialization with Jackson and no annotations

Reda Messoudi — Sun, 11 Oct 2020 21:24:04 GMT

Suppose I asked you to take a cup from the multiple choices in the header photo, certainly you'll ask which one to choose as there is many cups and you need something precise and maybe unique by cup to decide.

All the choices are cups, they share some common points (color, weight, ...) but maybe each one has something that the other cups don't have. This is polymorphism.

Code example

This post has a working code example available here.

What's polymorphism ?

Polymorphism is the ability to have different implementations represented by a single interface or abstract class.

This post is about how to deserialize objects by their abstract. Same idea presented below can be used to serialize objects.

Let's consider the following abstraction :

Player abstraction

Suppose you have an POST endpoint which supports creation of multiple objects by abstraction. Something like : you POST /players when PLAYER can be FootballPlayer, TennisPlayer or BasketPlayer.

@PostMapping(value = "/players", consumes = MediaType.APPLICATION_JSON_VALUE)
  ResponseEntity createPlayer(@RequestBody Player player);

POST /players endpoint

Problem

If we go directly invoking the /players endpoint, we'll face the InvalidDefinitionException as Jackson can't define to which class instance the PLAYER request body should be deserialized.

What's Jackson ?

As claimed by it's creators :

Jackson has been known as "the Java JSON library" or "the best JSON parser for Java". Or simply as "JSON for Java".

Simply, Jackson is a Java library to serialize and deserialize objects to/from JSON.

I'll use Spring Boot in this post but if you want to go without it, just grab the latest dependency of Jackson Databind on Maven Central.


  com.fasterxml.jackson.core
  jackson-core
  VERSION_HERE

pom.xml

Deserialization

The deserialization part will have to determine which concrete class the JSON represents, and instantiate an instance of it.

Deserialization using annotation

Using annotation is probably the most used technique because of it's simplicity and time-saving, but sometimes it's impossible to go with it.

Some resources describe how it can be done, you can check here or here if you are curious.

Deserialization with no annotation

Not every project gives the possibility to add annotations on your domain classes.

Sometimes, your domain classes (Player, FootballPlayer, ...) are hidden behind an imported jar dependency and you can't access them for annotating

you are using DDD and hexagonal architecture where purists say :

No framework or libraries inside the domain

simply because of some technical constraints in your company/project.

First thing to do is to create a custom Jackson deserializer and implement the logic of deserialization.

To implement a custom deserializer, we need to create an implementation of StdDeserializer which is an abstract type and the base class for common Jackson deserializers.

public class PlayerDeserializer extends StdDeserializer {

  public PlayerDeserializer() {
    this(null);
  }

  public PlayerDeserializer(final Class vc) {
    super(vc);
  }

  @Override
  public Player deserialize(JsonParser jsonParser, DeserializationContext deserializationContext)
      throws IOException {
    // TODO - implement deserialization logic here
    return null;
  }

First draft of custom Jackson deserializer

Few lines above, we exposed our abstraction of Player. Let's create an enum to distinguish the different Player instances.

public enum SportType {

  FOOTBALL("FOOTBALL"),
  TENNIS("TENNIS"),
  BASKET("BASKET");

  private final String value;

  SportType(String value) {
    this.value = value;
  }

  @Override
  public String toString() {
    return String.valueOf(value);
  }

  public static SportType fromValue(String text) {
    for (SportType sportType : SportType.values()) {
      if (String.valueOf(sportType.value).equals(text)) {
        return sportType;
      }
    }
    return null;
  }

SportType enum

As now we defined our SportType enum, based on that we can implement in details our deserialize method. Here we can take the benefit of this sportType field inside our abstract class PLAYER.

@Override
  public Player deserialize(JsonParser jsonParser, DeserializationContext deserializationContext)
      throws IOException {

    final ObjectMapper mapper = (ObjectMapper) jsonParser.getCodec();
    final JsonNode playerNode = mapper.readTree(jsonParser);

    final SportType sportType = SportType.fromValue(playerNode.get("sportType").asText());
    switch (sportType) {
      case FOOTBALL:
        return mapper.treeToValue(playerNode, FootballPlayer.class);
      case TENNIS:
        return mapper.treeToValue(playerNode, TennisPlayer.class);
      default:
        log.warn("Unexpected Player type : {}", sportType.toString());
        throw new IllegalStateException("Unexpected Player type : " + sportType.toString());
    }
  }

Deserialization logic based on submitted type of the abstract class Player

The last step to do before going ready for deserialization is to indicate that our PlayerDeserializer is a part of Jackson serializers/deserializers. Two possibilities available here :

As we use Spring Boot, we can use the @JsonComponent which do the same behavior but with less lines of code.

Maybe you're asking why we have this annotation as the title indicates "FREE ANNOTATIONS"? .

@JsonComponent is a Spring Boot annotation and not a part of Jackson and it lives in our newly created deserializer.

Another question can be :

What if we don't have this kind of "type" in our abstract class (e.g sportType) ?

In this case, we can change a little bit our deserialize method to inspect fields of each PLAYER instance (looking for something unique by each instance).

  @Override
  public Player deserialize(JsonParser jsonParser, DeserializationContext deserializationContext)
      throws IOException {

    final ObjectMapper mapper = (ObjectMapper) jsonParser.getCodec();
    final JsonNode playerNode = mapper.readTree(jsonParser);

    final SportType sportType = SportType.fromValue(playerNode.get("sportType").asText());

    if (playerNode.has("position")) {
      return mapper.treeToValue(playerNode, FootballPlayer.class);
    }
    if (playerNode.has("atpPoints")) {
      return mapper.treeToValue(playerNode, TennisPlayer.class);
    }
    log.warn("Unexpected Player type : {}", sportType.toString());
    throw new IllegalStateException("Unexpected Player type : " + sportType.toString());
  }

Deserialization logic based on fields of the Player abstract instances

Conclusion

In this post, we learned how to handle, in the same endpoint, variable requests (polymorphism) in Jackson by using custom deserializer and without polluting our domain classes with annotations and external libraries.

Resources

Source code : https://github.com/redamessoudi/polymorphic-deserialization

Header photo by Eric Prouzet on Unsplash

Receive emails with SubEtha SMTP and Spring Boot

Reda Messoudi — Sat, 04 Jul 2020 14:15:42 GMT

Some years ago I needed to write a Java application that receives emails and process some business stuff on those. It wasn't an easy task as I didn't find a lot of information. Because of that I decided, one day, I'll write about it and maybe that could helps 🙂.

Code example

This post has a working code example available here.

Context

Why ?

You would ask why do you need that ? I would say :

Business requirements can surprise you every day

Below a small list of some use cases when this incoming emails processing can be helpful.

Testing : Can be good option for integration testing the email capabilities of your services/applications (The old FakeSMTP is a good GUI example)
Analyse received emails and extract some specific information
...

What ?

SubEtha SMTP is low-level API for writing almost any kind of SMTP mail-receiving application.

To avoid you a long history presentation, the most updated version of SubEtha SMTP is a fork by David Moten (many thanks to him for his excellent work and keeping this library updated). We'll use this fork in this post.

I think no need to describe what's Spring Boot in nowadays.

Let's code

Before starting the code, I suggest to see how we can send an email via terminal. We'll need that to send an email to our future emails receiver application.

Send email with cURL

Below an example of sending email to specific mail server with parameters like from, recipient, auth and the content of the email.

curl --url 'smtp://localhost:25000' \                                     
  --mail-from 'customer-address@mail.com' \
  --mail-rcpt 'info@marketing.company.com' \
  --user 'superus3r:passw0rd' \
  -T <(echo -e 'From: customer-address@mail.com\nTo: info@marketing.company.com\nSubject: cURL Test\n\nHello, this is the content')

Send email with cURL

SubEtha dependency

Here we add the maven dependency of SubEtha SMTP.


    com.github.davidmoten
    subethasmtp
    5.2.4

SubEtha SMTP maven dependency

Start the embedded SMTP server

It's very easy to start a simple SMTP server with the library. Just create/build an instance of SMTPServer with the right parameters like port and start this instance.

// Build the embedded SMTP server
SMTPServer smtpServer = SMTPServer.port(25000).build();
// Start server asynchronously 
smtpServer.start();

Build and start SMTP server

Now our SMTP server is started but not fully ready to receive emails. We need to implement a MessageListener to extract important data like from and recipient addresses but also the subject and the body of the received email.

For that we can implement the SimpleMessageListener interface :

public class MarketingMailListener implements SimpleMessageListener {

    private static final String MARKETING_DOMAIN = "@marketing.company.com";

    /**
     * Do some business logic here
     */
    @Override
    public boolean accept(String from, String recipient) {
        return recipient != null && recipient.endsWith(MARKETING_DOMAIN);
    }

    @Override
    public void deliver(String from, String recipient, InputStream data) 
    throws TooMuchDataException, IOException {
        System.out.println("deliver message of MARKETING department");
        System.out.println("From : "+from);
        System.out.println("Recipient : "+recipient);
    }

Implement SimpleMessageListener interface

As you can see here, I added a simple business rule inside accept method to handle only emails sent to marketing department.

The accept method is responsible for defining if the received message will be proceeded by this listener or not.

The deliver method is responsible for extracting :

From : The sender address
Recipient : The receiver address
Data : It's an InputStream type from which we can extract content and relevant information related to the received email like : subject, body, CC, attachments and else.

Let's see how we can extract the content of the email :

Convert to MimeMessage

We can retrieve content from multipart content-typed message using MimeMessage instance.

public MimeMessage convertToMimeMessage(InputStream data) 
throws MessagingException {
        Session session = Session.getDefaultInstance(new Properties());
        try {
            return new MimeMessage(session, data);
        }catch (MessagingException e){
            throw new MessagingException();
        }
    }

Convert InputStream to MimeMessage

Extract email content

To extract the email content, we'll create an ReceivedEmail model to facilitate the processing.

public class ReceivedEmail {

    private String subject;
    private String senderAddress;
    private String senderName;
    private String recipientAddress;
    private String recipientName;
    private String cc;
    private String bcc;
    private String contentType;
    private List attachments = new ArrayList();

    // Getters and setters
    // ...
}

ReceivedEmail model

For the sake of simplicity I used String for recipientAddress, CC and BCC but it's can be a list of addresses (example in the code).

We create dedicated service for email content extraction and the extract method could looks like :

public ReceivedEmail extractReceivedEmail(InputStream data) throws Exception {
        ReceivedEmail receivedEmail = new ReceivedEmail();
        MimeMessage message;
        try {
            message = this.convertToMimeMessage(data);
            receivedEmail.setSubject(message.getSubject());
            receivedEmail.setSenderAddress(InternetAddress.toString(message.getFrom()));
            InternetAddress[] recipientAddresses = InternetAddress.parse(InternetAddress.toString(message.getAllRecipients()));
            receivedEmail.setRecipientAddress(InternetAddress.toString(recipientAddresses));
            receivedEmail.setRecipientName(recipientAddresses[0].getPersonal());
            receivedEmail.setContentType(message.getContentType());
            // Use here Apache library for parsing
            MimeMessageParser messageParser = new MimeMessageParser(message);
            messageParser.parse(); // very important to parse before getting data
            receivedEmail.setCc(messageParser.getCc().toString());
            receivedEmail.setBcc(messageParser.getBcc().toString());
            receivedEmail.setAttachments(messageParser.getAttachmentList());
            System.out.println(receivedEmail);
            return receivedEmail;
        } catch (Exception e) {
            throw new Exception();
        }
    }

Extract content of the received email

Now we have a full complete email receiver with minimal lines of code.

Secure SMTP Server

Let's go further step to see how we can secure our mail server.

First thing to do is to indicate that the authentication is required and implement basic auth with username and password.

this.smtpServer = SMTPServer
                .port(25000)
                .simpleMessageListener(marketingMsgListener)
                .requireAuth(true) // auth required
                .authenticationHandlerFactory(easyAuth) // implement type of auth
                .build();

Add authentication to the mail receiver server

Different implementations of authenticationHandlerFactory can be done, I chose here, again for the sake of simplicity, the EasyAuthenticationHandlerFactory class which needs implementation of the UsernamePasswordValidator interface.

@Configuration
public class SimpleAuthValidatorImpl implements UsernamePasswordValidator {

    private final String CREDENTIALS_LOGIN = "superus3r";
    private final String CREDENTIALS_PASSWORD = "passw0rd";

    @Override
    public void login(String username, String password, MessageContext context) throws LoginFailedException {
        if(CREDENTIALS_LOGIN.equals(username) && CREDENTIALS_PASSWORD.equals(password)){
            System.out.println("Authenticated successfully");
        }else{
            System.err.println("Invalid authentication !");
            throw new LoginFailedException();
        }
    }
}

Add authentication to the mail receiver server

And this how our SMTPServerConfig looks like :

@Configuration
public class SMTPServerConfig {

    private final SMTPServer smtpServer;
    private final SimpleMessageListener marketingMsgListener;
    private final UsernamePasswordValidator authValidator;
    private final EasyAuthenticationHandlerFactory easyAuth;

    public SMTPServerConfig(SimpleMessageListener marketingMsgListener) {
        authValidator = new SimpleAuthValidatorImpl();
        easyAuth = new EasyAuthenticationHandlerFactory(authValidator);
        this.marketingMsgListener = marketingMsgListener;

        this.smtpServer = SMTPServer
                .port(25000)
                .simpleMessageListener(this.marketingMsgListener)
                .requireAuth(true)
                .authenticationHandlerFactory(easyAuth)
                .build();

        this.smtpServer.start();
    }
}

Custom configuration of SMTP server

Go deeper

More parameters can be customised to fit your needs and improve your SubEtha server, I list those below and you can try to explore them to improve your mail receiver implementation :

Max connections and connection timeout
TLS support
Messages size
Shutdown of the SMTP server
Testing

Conclusion

I presented how we can, with small lines of code, write an application that can receive emails, handle those and apply some magic to them with SubEtha SMTP and Spring Boot.

If you have any questions or suggestions, please, leave your comments down below.

Thanks for reading and happy coding.

Resources

Source code : https://github.com/redamessoudi/subethasmtp-springboot.

Header photo by Liam Truong on Unsplash

Choreography vs. Orchestration for football fans

Reda Messoudi — Fri, 19 Jun 2020 12:03:23 GMT

Recently, I worked on a micro-services project which is cool thing but also challenging. Micro-services can solve many problems but also brings a panel of challenges.

Today we'll focus on micro-services communication challenge and for that we'll need a little bit knowledge of football and Ultras world specially.

Spoiler : I'm a fan of Wydad Athletic Club, a Moroccan sports club.

µServices communication challenge

If we build a micro-services architecture, in general we have at some point a communication between different/all services.

Those needs to communicate come with difficulties while the number of (business) services increase. We can imagine a simple business use case today can be chaotic in the future as business needs grows and changes.

In micro-services world and specifically communicating between different services, 2 main ways comes to mind : Choreography & Orchestration.

On Internet, you can find most of the articles explaining this topic with the comparison between Dancers (Choreography) and Orchestra (Orchestration) which is good explanation, but let's try a different way.

CHOREOGRAPHY :

Is Tifo sounds familiar to you ?

Tifo by ultra Winners 2005 from Morocco

If not and in nutshell way, Tifo is a visual choreography performed by ultra using different materials. This performance needs a lot of preparation by many persons but also a lot of collaboration and communication.

In a Tifo choreography, supporters are synchronized, move and accomplish their missions with no central task decider. Everything is prepared and repeated previously (days, months ago) .

Similar in µService world, perform a business process needs the involve of different services to be completed. The code is written, services deployed and ready to execute.

With choreography, every service is talking to another service with no mediator in the middle. Each service knows about the other. The business logic is distributed.

The workflow initiator service triggers the (business) flow by informing each service participant which will performs its tasks and informs other services.

Pros :

Distributed business logic with no centralized point
Decision logic managed by the service (= team)
Works well with agile delivery approach

Cons :

Peer to peer event chains (excellent description here by Bernd Rücker)
One service needs to subscribe to many events (is it healthy in a large scale architecture ? )
Complexity to change the flow of business processes (e.g It'll be complex to change the shopping flow : Delivery before payment)
Error handling can be a nightmare as each service (team) have the responsibility to understand how other services work and prevent cascading failure.

ORCHESTRATION :

Ultra Winners 2005

Did you see this man in the middle surrounded by a lot of supporters ? This is the Capo in football and ultras jargon.

Capo means "head" in Italian. He is the representative leader of a group of ultras supporters. As you can see in the image, his back to the game and his face to supporters to lead them in terms of chants and movements (Headphones and low volume highly recommended).

Capo is the guarantor of the show

Yes, you're right if you guessed that Capo is Orchestrator in Orchestrated µService architecture.

Orchestration is driven by a central system (the Orchestrator in general) which is the responsible to determine what to do, when and by who in order to guide and control a business workflow/process, which is very similar to the Capo who controls the movements and chants of supporters.

Supporters = Workers in orchestrated architecture and workers are – generally– your business services (e.g shipment, delivery, payment).

Each worker performs its tasks and informs the Orchestrator by returning the result. The Orchestrator takes decisions for the next steps.

Pros :

Flexibility : Easy to change and evolve the business workflows and processes
DRY : The workflow logic is on the same place
Clear monitoring of your processes progress

Cons :

The workflow engine becomes a central piece of the architecture and could be SPoF
As its very important component, the orchestrator could become more proprietary than the business itself in terms of operations specially with a decentralized approach.

Conclusion

Both of architectures are valid but the choice depends on the complexity of your µService world.

For a small/medium systems with moderated complexity, I would say go for Choreography but if the number of events is large or can increase in the near future, it'll become more and more complex to handle the code and logic in individual services. Whereas Orchestration can be more elegant in handling multiple events with less confusion.

For sure you can mix the both architectures – as Ultras do to support their clubs while spending a lot of time, effort and engagement to have such impressive results – but don't push your luck.

Resources

Header photo by sergio souza on Unsplash