Microservice

There are two types of microservices: servlet and native. Servlet microservice is nothing more than an application running in servlet container. That means that full support for http requests is provided through it and all tools and libraries which are relying on servlet container (like JSP, Spring REST, etc.) are supported by this type of microservice. On the other hand native application is best described as a "remote spring container". You put simple Java clases inside and use it.

servlet microservice

Servlet microservice is generated as a directory with two folders inside: additional-files and implementation.

Figure 1. Servlet microservice.

Directory "additional-files" is designed for files which should be visible on microservice class path but are not desired to live inside jar archive. A good example for such a file is a logging system configuration file. Administrators should have possiblity to change path for logs. But for security reasons they shouldn't change content of jar file - thay can by accident remove some class or any other important file. Once jar is created and tested it shouldn't be changed. Such a log configuration file can be put inside additional-files directory and will be included into deployable zip where it will be seperated from Java code.

Module named "implementation" includes microservice Java sources. Default structure and configuration files are generated to reduce time required to create running code.

native microservice

Native microservice is generated as a directory with three folders inside: additional-files, interfaces and implementation.

Figure 2. Native microservice.

Directory "additional-files" is designed for files which should be visible on microservice class path but are not desired to live inside jar archive. A good example for such a file is a logging system configuration file. Administrators should have possiblity to change path for logs. But for security reasons they shouldn't change content of jar file - thay can by accident remove some class or any other important file. Once jar is created and tested it shouldn't be changed. Such a log configuration file can be put inside additional-files directory and will be included into deployable zip where it will be seperated from Java code.

Module named "interfaces" includes all interfaces and objects required for remote binary communication with exposed service. Remote clients (like other microservices running on JLupin Next Server or any other application from outside the platform) will use jar created from this code to create proper proxy objects and serialize input.

Module named "implementation" includes microservice Java sources. Default structure and configuration files are generated to reduce time required to create running code.