Java EE 7 in Production: Keeping the Lights (and the Lotto) On

One of the most important things to do at this stage of the lifecycle of Java EE is highlight successful adoption stories at a regular cadence. The community has been doing just that for a long time, including at JavaOne. A number of these stories are curated at Zeef.

Sayo Oladeji recently agreed to share a very cool such adoption story on a mission-critical system for Eko Electricity — one of Lagos' largest utilities providers. Sayo had a number of insightful things to say about Java EE worth paying attention to. I have highlighted specific passages that really stand out.

Can you kindly introduce yourself?

I am Sayo Oladeji, a software engineer at Crown Interactive and co-founder at Hextremelabs. I started programming only 10 years ago and over the years, I’ve had opportunities to work on Java SE, ME, and EE, and other JVM languages, like Groovy and Kotlin, as well as non-Java technologies like C# and Javascript.

I manage a lot of integrations with third-party systems like lotto engines, payment gateways, business support systems, and so forth.

Can you describe the application that uses Java EE? What does your company do?

Crown Interactive is a major technology provider in the utilities space in Nigeria. We currently provide the end-to-end revenue cycle management (RCM) technology for Eko Electricity Distribution PLC (EKEDP), which serves half of Lagos. To put it in perspective, Lagos has a population of 21 million (2016) and growing at about 85 people per hour! Besides utilities, we also have a lottery system, an on-demand media service, and a few other applications.

Why did you choose Java EE?

When we started building out our systems, we had a lot of Java EE experience on board. Our consultant was also a JBoss partner. Java EE is a proven standard and JBoss EAP provides us with many things out of the box. These include support for web services, clustering, transactions, concurrency, caching, messaging, as well as a rich ecosystem of tools; most being open source. It wasn’t a very hard decision to make.

How does the application use Java EE?

We started building the system in a multi-tenant, service-oriented manner from day one. We are now breaking some of the modules down into microservices as needs arise.

• We use JAX-WS quite heavily due to the kind of integrations we do. JAX-WS + NetBeans makes SOAP integrations a pleasant experience, probably even more pleasant and definitely quicker than REST due to SOAP’s self-documenting nature (WSDL). Handler chains allow us to perform cross-cutting concerns like reading incoming SOAP envelopes and extracting metadata like authentication and tenant information.
• We use JPA across the board for data access.
• We use JMS for reliable, loosely coupled communication between services with ActiveMQ as a message broker and a resource adapter installed for WildFly so that WildFly manages the connections to the broker.
• We use JAX-RS for the REST APIs, which back our AngularJS web frontend.
• We use EJB for handling our core business logic and also for communication between our microservices. For example, our unified collections gateway (UCG) is a module made up of 8 microservices. One of these publishes an EJB that coordinates the interactions between the remaining ones. The hierarchical relationship between these modules is also neatly represented in the source code as a Maven multi-module project.
• Above all, we use CDI heavily. For example, our configurations are centrally managed in a database. We read this into an Infinispan cache (ships with WildFly) on startup, and from there, CDI producers inject them into beans using qualifiers. This is done in a type-safe manner. The C in CDI is the coolest thing. Bean members are injected based on the context, very important for a multi-tenant system. A JAX-RS filter or JAX-WS handler chain sets up contextual information before execution reaches our beans and the producers being context-aware inject context-specific configuration. We don’t want to bill the wrong partner or load the wrong message template for example.

How was your general experience with Java EE? Would you use it again?

My general experience with Java EE has been very good. Java EE + Maven + NetBeans + IntelliJ IDEA is a really good combination. There are appropriate plugins to configure our server and handle our deployments, generate API docs from REST endpoints, generate JPA entities from database schema and so forth.

It’s very quick and easy to get a working project up and running with Java EE 7. Almost everything is POJO and annotation-driven and the generated WAR files are tiny.  EE 7 is indeed lightweight. Prior to using a full Java EE server, I have used Java-based platforms like AppEngine and Tomcat, but I’ve generally found full EE servers like WildFly to be far more productive.

In fact, with the WildFly Maven plugin + Docker plugin, it is very easy to make a fully functional and cloud-ready environment all from the pom.xml file. We try to have as many of our deployment tasks (such as downloading and installing JDBC drivers, configuring datasources, logging, cache containers, etc.) as possible in the project’s pom.xml file so that our CI (BitBucket Pipelines) build file simply runs mvn clean install –P prod.

This is also great for the purpose of documentation. Simply looking at the sources, you can confidently tell how the application is going to run. I have had a great time developing with Java EE 7, and I will make new projects with it.

How can people contact you if they have questions?

I am available on Twitter as @oluwasayo_, and I can also be reached via email at oladejioluwasayo at gmail dot com.

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do reach out.