The first in a series of articles to examine what it means for a Java EE developer to evolve a monolithic application into a microservices architecture. The existing Plants By WebSphere sample is used as a representative monolithic application.

Evolving an existing monolithic Java EE application into microservices is something that is being actively investigated by a growing number of organisations. The end goal may simply be to learn more about microservices, split out existing functionality, or to create brand new services.

In this series of articles, I will be looking at the things that WebSphere Liberty and Java EE 7 can do to help you evolve a monolithic application into a microservices architecture as easily as possible. To the extent that, unless you want to produce services in another runtime or language, everything that you need to do can be done simply and easily with your existing environment and tools.

Find the code for the Plants By WebSphere sample application on GitHub.

Microservices are not free

Before looking at how we evolve an application it is worth stating that microservices are not free (which is possibly contrary to what you might currently believe). If you are able to manage your current application then there is a strong argument for not changing anything and benefiting from the simplified deployment, management, and operation model that a monolith provides.

If, however, your application is becoming too complex, or perhaps there is a business opportunity in exposing some internal APIs, then microservices become a more attractive option. If you want read a more in-depth discussion on the benefits (such as easier, more agile deployment) compared to the costs involved in managing multiple microservices, then have a look at this Martin Fowler article about the trade-offs. You will still have to deal with issues such as the eventual consistency of your data, but you will benefit from more rapid deployment and the option to embrace updated technologies.

Monolithic decomposition

Microservices typically evolve from a monolithic application by functional decomposition; a new service is composed of a number of existing and related functions. There are a number of ways in which this can be achieved, one of which is by looking at the high-level capabilities exposed to the end-user.

Taking the Plants By WebSphere homepage as an example, you can see that there is a shopping cart, so this might naturally be considered a candidate service. However, this relies on the underlying implementation having been properly componentised with clearly defined boundaries so that it fits neatly into a service. While this type of observational decomposition is a good, general-purpose methodology, we are looking specifically at Java EE applications so we can use technological decomposition to help identify our services.

There are, of course, a large number of technologies in use for any given application but only a subset of these are externally facing. It is these that can be used to provide an initial set of services. The diagram below shows how for the Plants application you can start at the JSF layer. By following the interactions between various technologies you can carve out a microservice, all the way down to data in the database being accessed using JPA.


PbWMonolithToMS-Identify

Java EE technological decomposition

The WebSphere Application Server Migration Toolkit is normally used to scan your application for migration issues, but it has the ability to tell you what technologies your application is using. Below is the result of running this tool against the Plants By WebSphere application, the left-hand column shows what technologies were discovered. The image has been trimmed to focus on the technologies, when you run the tool there are more columns, headers etc.


JEETechLandscape

The migration tool can also produce some helpful diagrams as part of its architectural discovery report showing how classes relate to each other. This is useful when deciding which classes might make up your new services. Below is an example for the AdminServlet. See WebSphere Application Server Migration Toolkit for more detailed instructions on how to generate this architectural report.


ComponentInteraction

The table below examines the results of running the migration tool against the Plants By WebSphere application and generating the reports mentioned above. It highlights those technologies that are good starting points for defining microservices.

Technology Points of interest Plants By WebSphere examples
Java Servlet,
JavaServer Faces (JSF),
JavaServer Pages (JSP)
Servlets and JSFs provide an obvious starting point for identifying the kind of related functionality that can be extracted into its own service. ImageServlet
AdminServlet
AccountServlet
cart.jsf/cart.xhtml
supplierconfig.jsp
JavaServer Pages/Expression Language (JSP/EL),
Contexts and Dependency Injection for Java (CDI),
Dependency Injection for Java,
Bean Validation
Beans can also be a good indicator of potential services. Their interactions and use of other beans show how potential services may need to communicate between each other. For example, the presence of a CDI bean may indicate a future inter-service call. ProductBean
HelpBean
Enterprise JavaBeans (EJB) Lite subset EJBs commonly represent a compositional boundary and are typically invoked by another entity, be it synchronously or asynchronously. Synchronously-invoked EJBs are potentially collapsed into the same service as their invoker. Asynchronously-invoked EJSs are candidates for their own service. ShoppingCartBean
CustomerMgr

Initial service breakdown

Taking all of the existing information from the migration tool, and by examining the code, you will arrive at a candidate list of microservices with a good idea of where the functionality for that service is going to come from. Below is an example table showing one potential mapping of services to classes. Note that it only deals with the major classes because there are too many for one table. It is also illustrative of the fact that where a class appears in more than one location, then it highlights the requirement to either separate the concerns involved or potential future inter-service calls.

Service Servlet JSF Beans EJB JPA
ImageService ImageServlet Inventory
CartService cart.xhtml
shopping.xhtml
ShoppingBean
AccountBean
ShoppingItem
ShoppingCartBean Inventory
OrderItem
Order
BackOrder
ProductService product.xhtml
shopping.xhtml
ProductBean Inventory
MailService EMailMessage MailerBean
HelpService ResetDBBean
SuppliersBean
BackOrderMgr
ShoppingCartBean
CatalogMgr
CustomerMgr
BackOrder
Customer
Supplier
OrderItem
Order
PromotionService promo.xhtml CustomerMgr Customer
CustomerService AccountServlet account.xhtml AccountBean CustomerMgr Customer

In this article we have examined various methods that can be applied to a monolithic Java EE application evolve it into an application based on a microservices architecture. Using the Plants By WebSphere sample as an representative application, the WebSphere Application Server Migration Toolkit was used to analyse the structure and composition of the Java code. This analysis, combined with inspection of the source, was then used to create an initial set of candidate services. Furthermore we were able to start to identify potential issues and future inter-service calls.

The next article in this series will start to evolve an image microservice from the existing monolith. It will look at the possible stages of evolution that the service can go through, and how the monolith will also need to evolve in parallel to use the new service.

1 comment on"Starting the evolution to microservices (using the Plants By WebSphere sample)"

  1. Looking forward to this. Thanks.

Join The Discussion

Your email address will not be published. Required fields are marked *