It was year 1999 when EJBoss made it’s debut as an alternative opensource J2EE implementation. 15+ years is more than a lifetime in technology terms and yet the JBoss Application Server project, renamed in 2013 into WildFly has managed to thrive and stay relevant by evolving into the Swiss Army Knife of Application Servers.dandreadis
In this talk we are going to look at the latest developments in WildFly and get an introduction to it’s sister project called WildFly Swarm. WildFly provides a robust, modular, lightweight, fully manageable and fast runtime, implementing the complete set of Java EE7 APIs. WildFly Swarm on the other hand gives you the ability to pick and choose only the server parts you need and bundle them with your application to create fat jars easy to deploy as microservices.
Thus with WildFly & WildFly Swarm you get the richness and maturity of Java EE combined with extreme flexibility about your deployment options in traditional setups or dynamic cloud environments.
Modular Service Container
● Small, lightweight and efficient (˜230 kb jar)
● Highly concurrent & scalable state machine
● Various start-up modes
– Active, Passive,
Concurrent Service ContainerConcurrent Service Container
Service ControllerService Controller
Service RegistryService Registry
Service BuilderService Builder
ServiceService DepsDeps ValueValue ListenersListeners InjectorsInjectors
● WF_ROOT/jboss-modules.jar (365 kb)
– Highly Concurrent Classloading
– Fast O(1) dependency resolution
– See only the modules you import
– No need to break open the jars
java -jar jboss-modules.jar -mp <module-path> <module-spec>
Port Reduction using HTTP Upgrade
Only 2 Ports Open by Default
● 8080 – HTTP for Applications
– Upgradable to JNDI, EJB, JMS
● 9990 – HTTP for Management (Console/JSON)
– Upgradable to Native Management API (CLI/JMX)
What are Microservices?
This slide intentionally left blank
Martin Fowler definition omitted
What are Microservices?
● A bit like SOA (but smaller?)
● Written in any cool programming language
● By (smaller?) two-pizza teams
● Who break monoliths into (small?) services
● That encapsulate fully some (small?) vertical application aspect
● And run them independently in their own (smaller?) containers
● Using fully automated deployment machinery
● Did I say small?
What Enabled Microservices?
● Elastic infrastructure, a.k.a the Cloud
● Linux Containers (Docker, Rocket, etc.)
● Orchestration Technologies (Kubernetes, Mesos, etc)
● Continuous Integration / Deployment
● The DevOps movement
Caused by the need for Internet Scale
Simpler services but more complex environments
A Word of Caution
● Every remote call will likely
be x100 slower than an
● You need to actively code
for failure when crossing
● Sharing state needs to be
well thought of (or avoided)
What is WildFly Swarm?
● WildFly Broken Apart
– Decompose and reconstruct WildFly
around your application
– With additional functionality outside Java EE
like NetflixOSS libraries, etc.
– Just enough app-server for your Microservice
packaged into an UberJar
● Part of the JBoss / Red Hat ecosystem
Why WildFly Swarm?
● Leverage your Java EE expertise
● Build on mature technologies
and a scalable runtime
● Be part of the future of Java EE
and help shape it for the Cloud
Is portability and supportability a thing of the past?
Rightsize your Runtime around your App
Pick up the EE pieces you really need
Plus a lot more components!
● Keycloak (SSO)
● Hystrix (Circuit Breaker)
● Ribbon (client side LB)
● Vert.x (reactive)
● Undertow (web server)
● Camel (integration)
● Hashicorp Consul (discovery)
● Swagger (service contracts)
● LogStash (log aggregation)
● and more...
Self-contained (Uber) Jar
● bundles your application,
● the Fractions to support it,
● an internal Maven repository with
● and Bootstrap code.
● There is also the notion of a
Hollow launch-pad type of jar.
● WildFly Swarm compositional units
● Focus on serving specific usecases
● Define dependencies to other Fractions
● Tie together
– WildFly subsystems
– MSC Services
Fractions layer on WildFly-Core and
● Enable WildFly subsystems (e.g. Infinispan)
● Integrate additional frameworks/services (e.g. Topology)
● Provide deployments (e.g. Swagger, Jolokia)
● Add API dependencies (e.g. JAX-RS)
● Alter deployments (e.g. SSO)
● Expressed as Maven (GAV) coordinates:
– org.wildfly.swarm:<fraction>:<version>, e.g
● 83 fractions currently available
– 48 stable
– 35 experimental
● About 50% wrap WildFly components
● More in the pipeline
Where do I start?
● Absence of dependencies
● In this example JAXRS is
detected, leaving out Bean
Validation, CDI &
● 4.3Mb jar
How Fractions are configured?
● Default configuration with sensible defaults
● System properties to override common settings
● standalone.xml or a fragment of it can override settings
● - or -
● Take control of main() and use the fluent Java API
– Covers all WildFly subsystems
– Generated from the WF configuration schema