Java Magazine, Jan/Feb 2016
KumuluzEE Building Microservices with Java EE Develop self contained microservices with standard Java EE APIs using the open source KumuluzEE framework ORACLE COM JAVAMAGAZINE JANUARY FEBRUARY 2016 80 microservices In this article we explore how to develop microservices with standard Java EE APIs Microservices have become an important architectural style for developing complex applications composed of small independent services deployed as individual processes These services communicate through well defined APIs Each microservice is self contained is responsible for a single task is accessible through a lightweight API such as REST and has its own lifecycle Microservices result in a highly decoupled modular and reusable architecture for composite applications Developing microservices in Java means that not only is the application designed around REST services but also that each service the front end and other components are deployed separately and independently In other words instead of packing all the services business logic front end and other modules into a single EAR file and deploying it as a monolith microservices use individual archives such as JAR files for each component The KumuluzEE framework as well see shortly automates the tasks related to the configuration and deployment of microservices specifically on Java EE Note KumuluzEE won the Dukes Choice Award at the 2015 JavaOne conference Ed Microservices with Java EE Suppose we want to create an online train reservation service people can use to plan their route and buy their tickets For brevity we are going to look at a simplified version of this example it will allow only viewing routes and booking a route via a simple user interface Using the traditional approach we would create a monolithic EAR package that would include our business logic services and one or more WAR packages containing the front end We would deploy the EAR file to an application server such as Oracle WebLogic Server or GlassFish In contrast using the microservice architecture we start by separating the responsibilities Routes the booking service reservations and the UI become three separately developed configured and deployed microservices They are stateless and communicate through REST interfaces although we could also use SOAP or remote method invocation RMI In this way we create microservices that are domain defined and follow the single responsibility principle with regard to explicit interfaces We have created a highly modular decoupled architecture where each service is responsible for a single dedicated piece of functionality Also each microservice has its own lifecycle The proposed architecture using microservices is shown in Figure 1 In the remainder of this article we use this simplified example But keep in mind that microservices are best suited for complex applications and systems TILEN FAGANEL AND MATJAZ B JURIC
You must have JavaScript enabled to view digital editions.
