WildFly Swarm is a "Just Enough" Application Server. If you don't need EJB, don't bundle it. Likewise for JPA, JAX-RS, or whatever subsystem. Bringing only the portions of an App Server that you need is the strategy that makes Java EE and the JVM a real contender in the microservices space. Ken Finnigan, Co Founder/Lead of WildFly Swarm, walked us through how easy it is to move a monolith deployment to a WildFly Swarm Microservice.
Getting Started
Getting started is as simple as adding the wildfly-swarm-plugin to your project's pom.xml file. This plugin will automatically scan your application classes for dependencies on Java EE subsystems and build an uber jar including only the subsystems you need, how neat! After adding the plugin try mvn clean package to create an uber jar.
The plugin goes beyond that and also provides an option to build the microservice and run it directly with mvn wildfly-swarm:run . This will build the uber jar and run it directly from maven.
Debugging in your IDE is possible by debugging the Main class org.wildfly.swarm.Swarm. Take note: you will not get classpath resolution of your Java EE dependencies in this case. So, you will need to add the org.wildfly.swarm Java EE dependencies.
Fractions
Fractions are the individual components that WildFly Swarm can package together and provide for your application in the uber jar. Check out the latest list of fractions such as camel, histrix, JPA, hibernate search/validation, integration, bean, messaging, EJB, CDI, Spring, Keycloak, and more....
Monoliths
Three tiered applications, the typically architecture for microservices, are grouped by front end, service layers, and persistent storage. When decomposing your monolith, use bounded contexts to isolate vertical components of your application into services. Ken recommend going from coarse to fined grained contexts to avoid creating too many services. Luckily these two patterns are not completely mutually exclusive. An architecture can use a single presentation layer, a context designed service, and persistent layers as a stepping stone to a full microservice architecture. This is known as a Hybrid Monolith which can be used to decrease your risk during a migration.
Decompose
Ken then showed the Ticket Monster app running on his local machine in all its monolithic glory. By adding a reverse proxy in the WildFly configuration file he started forwarding all REST calls to a different port on his machine. He then started the decomposition process by running another copy of the same monolith Ticket Monster app (without UI) on the new port. That is the first step in separating out the UI from the back end business service layer. After breaking apart the UI, we can proceed to chip away at the business service layer by creating more copies of the Ticket Monster app with partial functionality grouped by bounded context: One for Booking, Venues, Admin Interface, etc. Routing to these new, different microservices can be done with reverse proxies. However, you will probably want a more robust solution like a service discovery pattern in the UI to get a URL for the needed rest resource (check out the Ribbon project).
WildFly Swarm 1.0.0.Final is now available so check it out! Many thanks to Ken for showing the capabilities of WildFly Swarm and how it brings Java EE to the forefront of microservice design by providing a migration path from existing monoliths along with a solid development foundation.
Last updated: October 17, 2018