Managing Break Parts For Cars With Java EE 7

Tim, please introduce yourself

Hello Adam. My name is Tim Brückner, I am 34 years old and work as IT consultant and software developer. I live close to the lovely city of Marburg (Germany). About five years ago I took the chance to start my own business (a cup of software) as a freelancer and since then I was able to build up a small team of 4 developers.

What are you building with Java EE?

We are developing a B2B platform for the automotive sector. Our application helps dealers and garages to improve the process of ordering spare parts at their suppliers. For some cars one can choose from more than 30 different brake pads for example. Looking up every brake pad at every supplier manually in order to compare them is way too much work to do and that is where our application comes into play.
The application can be used to provide quotes to customers as well as to order spare parts at various suppliers. It helps identifying and comparing parts and connects to third party software like ERP systems.
Our frontend is written in JSF using PrimeFaces. Our backend is built with Java EE 7 and Java 8 running on Wildfly. We are using Groovy to connect to the web services of spare part suppliers in order to fetch prices and check the availability of articles, as well as to place orders from within the application.
The platform provides a REST API which is used by third party companies to integrate the application into the business processes of their customers. We have written Android and iOS clients which utilize the same API.
We started building the application as a monolith, but as the number of installations rose, we decided to pull out parts of the application which could be hosted as a centralized service. So we are currently in the process of moving from a monolith to SCSs (self contained systems).
Our latest addition to the platform is the implementation of a spare parts catalogue based on TecDoc data. It is used to lookup and identify spare parts in the context of a specific car.

Can you share with us some geeky numbers like e.g. TX per seconds, heap sizes etc -- whatever Java EE devs might find interesting.

We run multiple instances of the application - one for each customer. Each instance runs on a dedicated Wildfly application server and utilizes about 2GB of heap memory average. There are currently about 50 parallel user sessions per instance. Each instance of the application holds around 11 to 16 million article entries (about 50-75GB) containing supplier specific information like prices and order numbers. The spare parts catalogue holds about 3.8 million articles and about 125GB of images and documents.

Are you happy with Java EE so far? Is Java EE productive?

I am happy with Java EE and I think Java EE is very productive. Thanks to principles like convention over configuration and context and dependency injection one can easily focus on implementing the business logic instead of writing boilerplate code. This leads to a leaner implementation of features and therefore this boosts the readability and maintainability of the code as well. Since Java EE is a vendor neutral specification it is possible to stay flexible and switch the implementation behind an API or to switch the application server (what we did). Searching for answers and help is straight forward since the spec is well documented and the community is great. Java EE is like a swiss army knife for enterprise projects: There is an API for almost every aspect of an enterprise application and the container takes care of most of the technically complex aspects like transaction management or connection pooling for example.
In terms of productivity I am a big friend of PrimeFaces. Since our customer agreed on using the PrimeFaces components we could implement most views of our application pretty easily. We did some CSS skinning though, but most of the time we do not have issues with PrimeFaces updates.

Which application servers, tools or IDEs are you using?

We started with Java EE 6 and Glassfish 3 then migrated to Java EE 7, Java 8 and Wildfly. We used Netbeans for a while (we still use the Netbeans profiler) but switched to IntelliJ about two years ago. I like both IDEs. I think Netbeans has the better Maven integration. We are using the Atlassian suite (JIRA, Confluence, Bitbucket and Bamboo) in order to stay organized, as Git repository and as CI system. We are using PostgreSQL with JPA. Redis and MongoDB are being accessed natively. Docker is the newest addition to our tool stack.

You are using the Boundary Control Entity pattern to structure your applications. What were your experiences, challenges and findings so far?

Well we committed on using BCE in our project as a rule of thumb for structuring the application. BCE works great so far, but we also had some challenges to master like for example to determine where static helpers belong which may be accessed throughout the application. Or how to handle rather technical implementations which are not part of a business component or used by multiple business components like a factory for REST clients for example. What about CDI events? We made most of them part of the boundaries since they observe them. Should REST endpoints be boundaries or access boundaries themselves? We decided to make them access boundaries since the boundary could then be used from within the JSF presentation layer as well as from within the REST endpoint without the need to use DTOs within JSF.
The most difficult part was to identify the business components and to omit cyclic dependencies between them. We are using CDI events to decouple the components.

How important are standards for you? Does your application depend on application server specific APIs?

Since we are a small team it is very important for us to focus on standards because we want to spend our time implementing features for our customer instead of evaluating vendor specific libraries or frameworks. Introducing vendor specific libraries also introduces risks. We do not have the time to maintain those libraries if they are no longer supported for example. We don't want to refactor the application with every update of a library because method signatures change. We do not want to get into dependency hell if transient dependencies of libraries clash with with the libraries implementing the Java EE APIs.
Of course it is not always possible to stick to the standard, but we try to do it whenever possible.
We are using some server specific APIs for example the ResteasyClientBuilder in order to set the timeout on the REST client and in order to use the BrowserCache feature. We are using Eclipselink as persistence provider on Wildfly instead of Hibernate and of course the Eclipselink specific properties within the persistence.xml.

Which Java EE APIs are you using in your products?

We are mainly using JSF, CDI, EJB, JPA, JAX-RS and Servlet.

Take a look at the Java EE 8 APIs. Which of the APIs are most interesting / important to you?

Security (JSR 375), JAX-RS (JSR 370), JSON-B (JSR 367), CDI (JSR 365)

Can you share any resources (blogs, etc feel free to promote yourself) with us?

Whenever I search the web in order to solve some Java EE riddle I stumble upon posts of Arjan Tjims ( or Bauke Scholz aka Balus C ( I like to follow the Netflix tech blog ( And since server side JavaScript development becomes more and more relevant I can recommend reading the following article:


Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments