Monolithic to Microservices Refactoring for Java EE Applications

have you ever wondered what does it take to refactor an existing java ee monolithic application to a microservices-based one?

this blog explains how a trivial shopping cart example was converted to microservices-based application, and what are some of the concerns around it. the complete code base for monolithic and microservices-based application is at: github.com/arun-gupta/microservices .

read on for full glory!

java ee monolith

a java ee monolithic application is typically defined as a war or an ear archive. the entire functionality for the application is packaged in a single unit. for example, an online shopping cart may consist of user, catalog, and order functionalities. all web pages are in root of the application, all corresponding java classes are in the web-inf/classes directory, resources in web-inf/classes/meta-inf directory.

lets assume that your monolith is not designed as a distributed big ball of mud and the application is built following good software architecture. some of the common rules are:

• separation of concerns, possibly using model-view-controller
• high cohesion and low coupling using well-defined apis
• don’t repeat yourself (dry)
• interfaces/apis and implementations are separate, and following law of demeter . classes don’t call other classes directly because they happen to be in the same archive
• using domain driven design to keep objects related to a domain/component together
• yagni or you aren’t going to need it: don’t build something that you don’t need now

here is how a trivial shopping cart monolithic war archive might look like:

this monolithic application has:

• web pages, such as .xhtml files, for user, catalog, and order component, packaged in the root of the archive. any css and javascript resources that are shared across different webpages are also packaged with these pages.
• classes for the three components are in separate packages in web-inf/classes directory. any utility/common classes used by multiple classes are packed here as well.
• configuration files for each component are packaged in web-inf/classes/meta-inf directory. any config files for the application, such as persistence.xml and load.sql to connect and populate the data store respectively, are also packaged here.

it has the usual advantages of well-known architecture, ide-friendly, easy sharing, simplified testing, easy deployment, and others. but also comes with disadvantages such as limited agility, obstacle for continuous delivery, “stuck” with a technology stack, growing technical debt, and others.

even though microservices are all the raze these days, but monoliths are not bad. even those that are not working for you may not benefit much, or immediately, from moving to microservices. other approaches, such as just better software engineering and architecture, may help. microservices is neither a free lunch or a silver bullet and requires significant investment to be successful such as service discovery, service replication, service monitoring, containers, paas, resiliency, and a lot more.

don’t even consider microservices unless you have a system that’s too complex to manage as a monolith.

microservice premium

microservice architecture for java ee

alright, i’ve heard about all of that but would like to see a before/after, i.e. how a monolith code base and how a refactored microservice codebase looks like.

first, lets look at the overall architecture:

the key pieces in this architecture are:

• application should be functionally decomposed where user, order, and catalog components are packaged as separate war files. each war file should have the relevant web pages ( #15 ), classes, and configuration files required for that component.
  • java ee is used to implement each component but there is no long term commitment to the stack as different components talk to each other using a well-defined api ( #14 ).
  • different classes in this component belong to the same domain and so the code is easier to write and maintain. the underlying stack can also change, possibly keeping technical debt to a minimum.
• each archive has its own database, i.e. no sharing of data stores. this allows each microservice to evolve and choose whatever type of datastore – relational, nosql, flat file, in-memory or some thing else – is most appropriate.
• each component will register with a service registry. this is required because multiple stateless instances of each service might be running at a given time and their exact endpoint location will be known only at the runtime ( #17 ). netflix eureka , etcd , zookeeper are some options in this space ( more details ).
• if components need to talk to each other, which is quite common, then they would do so using a pre-defined api. rest for synchronous or pub/sub for asynchronous communication are the common means to achieve this.in our case, order component discovers user and catalog service and talks to them using rest api.
• client interaction for the application is defined in another application, shopping cart ui in our case. this application mostly discover the services from service registry and compose them together. it should mostly be a dumb proxy where the ui pages of different components are invoked to show the interface ( #18 ).a common look-and-feel can be achieved by providing a standard css/javascript resources.

this application is fairly trivial but at least highlights some basic architectural differences.

monolith vs microservice

some of the statistics for the monolith and microservices-based applications are compared below:

code base for the monolithic application is at: github.com/arun-gupta/microservices/tree/master/monolith/everest

code base for the microservices-enabled application is at: github.com/arun-gupta/microservices/tree/master/microservice

issues and todos

here are the issues encountered, and todos, during refactoring of the monolith to a microservices-based application:

• java ee already enables functional decomposition of an application using ear packaging. each component of an application can be packaged as a war file and be bundled within an ear file. they can even share resources that way. now that is not a true microservices way, but this could be an interim step to get you started. however, be aware that @flowscoped bean is not activated in an ear correctly ( wfly-4565 ).
• extract all template files using jsf resource library templates.
  • all web pages are currently in everest module but they should live in each component instead ( #15 ).
  • resource library template should be deployed at a central location as opposed to packaged with each war file ( #16 ).
• breakup monolithic database into multiple databases require separate persistence.xml and ddl/dml scripts for each application. similarly, migration scripts, such as using flyway, would need to be created accordingly.
• a rest interface for all components, that need to be accessed by another one, had to be created.
• ui is still in a single web application. this should instead be included in the decomposed war ( #15 ) and then composed again in the dumb proxy. does that smell like portlets?
• deploy the multiple war files in a paas ( #12 )
• each microservice should be easily deployable in a container ( #6 )

here is the complete list of classes for the monolithic application:

./target/classes/org/javaee7/wildfly/samples/everest/cart/cart.class
./target/classes/org/javaee7/wildfly/samples/everest/cart/cartitem.class
./target/classes/org/javaee7/wildfly/samples/everest/catalog/catalogitem.class
./target/classes/org/javaee7/wildfly/samples/everest/catalog/catalogitembean.class
./target/classes/org/javaee7/wildfly/samples/everest/catalog/catalogitemtype.class
./target/classes/org/javaee7/wildfly/samples/everest/checkout/order.class
./target/classes/org/javaee7/wildfly/samples/everest/checkout/orderbean.class
./target/classes/org/javaee7/wildfly/samples/everest/checkout/orderitem.class
./target/classes/org/javaee7/wildfly/samples/everest/checkout/shipping.class
./target/classes/org/javaee7/wildfly/samples/everest/uzer/uzer.class
./target/classes/org/javaee7/wildfly/samples/everest/uzer/uzerbean.class
./target/classes/org/javaee7/wildfly/samples/everest/uzer/uzeritem.class

here is the complete list of classes for the microservices-based application:

./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/applicationconfig.class
./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/catalogitem.class
./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/catalogitemrest.class
./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/catalogitemtype.class
./catalog/target/classes/org/javaee7/wildfly/samples/everest/catalog/serviceregistration.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/cart/cart.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/cart/cartitem.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/catalog/catalogbean.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/catalog/catalogitem.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/checkout/order.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/checkout/orderbean.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/checkout/orderitem.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/checkout/shipping.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/servicediscovery.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/servicediscoverystatic.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/servicediscoveryuri.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/servicediscoveryzookeeper.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/uzer/uzerbean.class
./everest/target/classes/org/javaee7/wildfly/samples/everest/uzer/uzeritem.class
./order/target/classes/org/javaee7/wildfly/samples/everest/order/applicationconfig.class
./order/target/classes/org/javaee7/wildfly/samples/everest/order/order.class
./order/target/classes/org/javaee7/wildfly/samples/everest/order/orderitem.class
./order/target/classes/org/javaee7/wildfly/samples/everest/order/orderrest.class
./user/target/classes/org/javaee7/wildfly/samples/everest/uzer/applicationconfig.class
./user/target/classes/org/javaee7/wildfly/samples/everest/uzer/userrest.class
./user/target/classes/org/javaee7/wildfly/samples/everest/uzer/uzer.class

once again, the complete code base is at github.com/arun-gupta/microservices .

future topics

some of the future topics in this series would be:

• are containers required for microservices?
• how do i deploy multiple microservices using containers?
• how can all these services be easily monitored?
• a/b testing
• continuous deployment using microservices and containers

what else would you like to see?