Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

Architecting Large Enterprise Java Projects by Markus Eisele

Markus Eisele - profile pic: @myfear

Recently, the Virtual JUG has the pleasure of hosting Markus Eisele, Red Hat Developer Advocate, JBoss Middleware expert and a famous consultant, conference speaker and book author on topics like Java EE, software architecture and large projects. Having dealt with enterprise applications for over 14 years, Markus has the knowledge of the problem base, the experience to validate that knowledge and the passion to share it with us in the session called “Architecting Large Enterprise Java Projects”. It was an extremely interesting talk and you you certainly should take some time to experience it.

Here’s the recording of the session in full:

At the same time, let’s dive into what was the session about.

How did we do it years ago?

When we hear the words Java EE deployment, many of us imagine a monolithic application, like the one in the image below: a single Java EE application server stuffed with multiple heavy EARs that communicate with each other and are replicated across the cluster for resilience.

Monolithic Java Architecture, legacy approach

Developers built a lot of applications like that some time ago and even present day! These applications are still working and need maintenance. So we see them sometimes and call them legacy. They tend to have a release cycle of once or twice a year, depend on a proprietary application server environment and most importantly have a single database schema for all data. Naturally, you cannot move very fast with such a beast on your shoulders and must have a large team and QA department even just to maintain it.

The next step in the architecture design was the Enterprise Service Bus age. Understanding that changes have to be incorporated into even the oldest and the most legacy applications. We (Java developers) started breaking the huge apps into smaller ones. The biggest challenge was to integrate it all together, so the service bus seemed the best solution.

The change wasn’t that big for the operations teams, as they still have everything under their control and centralized, although it was a much more flexible approach. However, the same centralization that adds value, creates a raft of problems that the engineering team had to solve: most importantly challenges with testing and the single point of failure (SPOF).

We’re now we’re moving even further away from the monolithic apps and towards the trending buzzword of Microservices.


Microservices is currently very hyped up of course, and everyone is/thinks they’re doing them or wants to! Even if you’re not, there’s a good chance you’re still talking about them and how great they are.

However, let’s look past the hype and try to understand exactly what smaller deployments bring to the table: isolation, better resilience and fault tolerance, maintainability and easier deployment operations.

If you cannot start a fresh project or don’t want to reduce every service to it’s smallest size, consider a modern architecture, where the main application sits on the application server and is integrated via a REST API or whatever other transport your services prefer.

Java Architecture Aimed Towards Microservices

If you do have a carte blanche on the technological solutions you can pick and want to break the functionality into smaller pieces that you can deploy as individual services, consider the following points:

  • Domain driven designs
  • Bounded contexts
  • Automation of operations
  • Failure resistance
  • Independence of deployments

Microservices architecture aggregator pattern

Then there’s a number of patterns you can use to organise the communication between your microservices, like the aggregator or the chain (images are clickable):

Microservices Architecture Pattern - the Chain

Be sure to watch the full video, Markus talked what problems you can have with these and how successful architectures are usually a balanced mixed of the two. Be sure to understand the problems you’re solving or your efforts can easily go in vain.

Resources to check out

Markus’s presentation slides are available on slideshare: Architecting Large Enterprise Projects with Java slides. Besides that, if you’re interested in software architecture and want to try some of the tools and libraries mentioned during the session and the interview, here is a short list with descriptions.


Vert.x logo
Vert.x is a lightweight application platform for the JVM, supporting Java, JavaScript and Groovy, that’s designed for modern web and enterprise applications. It’s event driven and fully non-blocking, so it’s appropriate for building reactive apps.


WildFly is the JBoss Java EE certified application server, which is fast, powerful, modular and lightweight. In fact some time ago, when we wrote the Great Java Application Server comparison, the JBoss application server came out on top.


One of the main benefits of having the lightweight application server is that you can test your code your runtime of choice, i.e. your actual application server, without mocked contexts. Arquillian is a brilliant JVM testing platform that can manage external application servers and deploy your tests directly into them. So writing functional or integration tests has never been easier.

Apache Camel

Apache Camel is a versatile open-source integration framework, which has tons of Enterprise Integration Patterns components implemented and easily customisable. If you ever dreamed of programming by dragging components and putting them together with a mouse, you should look into Camel. It probably won’t do miracles for you, but the common Transport API, DSLs and communication interfaces between components that Camel provides can make life much easier.


Fabric 8 logo

Fabric 8 is an open-source integration platform for JVM. Think provisioning, automatization, configuration, and management of multiple JVM containers from one spot with a nice UI. It can provide you with a solution for load balancing, failover, monitoring and so forth. Integrations with Docker, OpenShift make it even more powerful and ready to use.

When we asked Markus was other projects he mentioned in the presentation our readers should look into, he mentioned these JBoss projects:

  • Infinispan – a 100% Java distributed and highly concurrent key/value datastore. If you need a cache, maybe you should look into it.
  • Undertow – a lightweight and fast http server written purely in Java and providing you with both blocking and non-blocking capabilities
  • Apiman – an API management solution that can take care of security and billing, and metrics and quotas for you.

I hope that this is a good entry point into the world of enterprise architecture. If you want further pointers, just ask in the comments section below or find us or Markus on Twitter: @ZeroTurnaround or @myfear. We’ll be happy to talk to you!

Interview and final words

After the session, Markus answered a couple of questions in the now regular RebelLabs interview. If you haven’t seen them before, make sure you’ll find some time to watch the previous ones, including Aleksey Shipilev and Arun Gupta.

We asked Markus about the best development setup for Java, why Java conferences are useful for developers and how to pick which ones to attend. Also, if he thinks we’ll have trouble when refactoring microservices back into larger applications in a couple of years and, naturally, I couldn’t resist to ask which is better Spring or Java EE?

You can see what Markus thinks about all these things in the video below. Spoiler alert: the worst habit a programmer can have is not learning. And, if may I add, not being curious about things.

As always, It’d be really cool if you’d subscribe to our newsletter, we’ll send you an occasional email about our blogposts, reports, or ongoing surveys that we run once in a while. Just enter your email below and we’ll stay in touch.