Data Processing vs. Process Management vs. AI?

In today’s data-driven business landscape, managing data effectively is crucial for achieving organizational goals. While data processing systems play a vital role in collecting and organizing data, it is often overlooked that data should not be managed solely for its own sake. The true value lies in understanding how data can be leveraged to achieve business objectives, which is where the concept of process management comes into play.

Today we live in a world where data is everywhere and every enterprise knows about the value of data. But how do we handle data? How do we create, collect, and analyze it? This is the area of data processing software. We all use databases, spreadsheets, and data management systems to manage all kinds of data. Many software systems are built around specific data domains and we use this software to create and maintain the data.

BPMN 2.0 and Jakarta EE: A Powerful Alliance

A BPMN Workflow engine based on the Jakarta EE Framework forms a powerful and effective combination for developing enterprise applications with a focus on business process management. Both, Jakarta EE and BPMN 2.0 are standardized and widely supported. The scalability of Jakarta EE provides a secure foundation for building enterprise applications with robust business process management capabilities. This enables developers to leverage the strengths of both technologies to create efficient, interoperable, and maintainable BPM solutions. In the following, I will explain the aspects in more detail.

Standardization

Jakarta EE provides a standardized platform for building enterprise applications, offering a set of specifications and APIs. This standardization ensures portability and interoperability across different Jakarta EE-compliant application servers. This allows developers to work within a unified framework without the need to learn proprietary techniques. This not only streamlines the development process but also promotes a broader ecosystem where developers can focus on leveraging the standardized features, thus enhancing the overall efficiency and maintainability of the applications.

Why Should I Comment My Code?

 Today I want to write about why comments are so important in software development and how you can improve them. For me, the most disappointing thing about good source code is when it is insufficiently commented on. And this happens with closed code in the same way as with Open Source code. In the worst case, and this is usually the most common, the source code is not commented on at all. Especially in open-source projects, this is a disdain against the community reading your code. But even in internal software projects, I consider missing comments to be bad behaviour towards your colleagues, which should be avoided.

Of course, we all know the funny answers in this context. “Good code doesn’t need any comments” or “Take a look into the source code if you don’t understand something.” Is it laziness or ignorance not to write comments? No, I believe that many developers simply do not know how to write good comments. For this reason, I would like to explain here a very simple rule on how to really improve your source code through comments.

Are You Crazy Still Using JSF?

JSF stands for Java-Server-Faces, which is a web technology that is underestimated by many people. I wonder why is that. And are you actually crazy if you still use JSF? I don’t think so, and I will share some of my thoughts. 

The Specification

First of all, JSF is a specification which is an important advantage over all the other technologies that JSF is usually compared to. The specification is an open process that is accompanied by many developers for years to define a general solid standard for web applications. This specification process has recently taken place in the Eclipse Foundation, which sets up rules that follow very high-quality standards. This is one of the biggest advantages, as it guarantees that your web application is built on a solid core. Of course, other web frameworks also have large communities, but often these are represented by a single company that does not always take the developers into account. Angular from Google is just one example.

Jakarta EE8, EE9, EE9.1, …. What???

Jakarta EE is the new Java Enterprise platform as you’ve probably heard. There is a lot of news about this application development framework and also about the rapid development of the platform. Version 9.1 was released in May last year and version 10 is already in a review process. But what does this mean for my own Java project? Because I was also a bit confused about the different versions, hence my attempt to clarify things.

First, the good news: As an application developer, you don’t have to worry. The most important thing that will change besides improved support by the community is the Java package names. The package name javax.* will be replaced by jakarta.*.

Is Spring Boot Still State of the Art?

In the following blog post, I want to take a closer look at the question of whether the application framework Spring Boot is still relevant in modern Java-based application development. I will take a critical look at its architectural concept and compare it against the Jakarta EE framework. I am aware of how provocative the question is and that it also attracts incomprehension. Comparing both frameworks I am less concerned about the development concept but more with the question about runtime environments. 

Spring Boot and Jakarta EE Logos

Both – Spring Boot and Jakarta EE – are strong and well-designed concepts for developing modern Microservices. When I am talking about Jakarta EE and Microservices I always talk also about Eclipse Microprofile which is today the de-facto standard extension for Jakarta EE. Developing a Microservice the concepts of Spring Boot and Jakarta EE are both very similar. The reason is, that a lot of technology of today’s Jakarta EE was inspired by Spring and Spring Boot. The concepts of “Convention over Configuration“, CDI, or the intensive usage of annotations were first invited by Spring. And this is proof of the innovative power of Spring and Spring Boot. But I believe that Jakarta EE is today the better choice when looking for a Microservice framework. Why do I come to this conclusion?

PostgreSQL HA and Kubernetes

In the following, I will share my thoughts about how to set up a PostgreSQL Database in Kubernetes with some level of high availability. For that, I will introduce 3 different architectural styles. I do not make a recommendation here because, as always every solution has its pros and cons.

1. Running PostgreSQL Outside of Kubernetes

In the first scenario, you run PostgreSQL outside form Kubernetes. This means Kubernetes does not know anything about the database. This situation is often a result of a historical architecture where PostgreSQL was long before Kubernetes in an evolving architecture.

Spring Boot or Jakarta EE – What’s Better?

No – I don’t want to start a new flame war in which I put one framework above the other. Both, Spring Boot and Jakarta EE are great frameworks to build great modern Java applications. Some developers prefer this, others prefer that. Why is that? I think it’s often just because the one developer has collected more experience with Spring Boot, the other one with Java EE. These technologies are developing very fast and it is difficult to learn and be able to apply everything correctly. It is a kind of protectionism that you put one over the other so that you don’t appear stupid and ignorant. But there is a certain noise around Spring Boot that gives the impression that Spring Boot would be the far better system.

I am personally working with Java EE since the beginning – 20 years ago! So – yes I know the one much better than the other and I don’t have a deep understanding about Spring Boot that others may have. 

Kustomize Your Kubernetes Deployments

When  you start working with Kubernetes, you may get to a point where you’re shocked at how complex your YAML files have become. For a complex application consisting of different containers your YAML files will become very very long and it will become harder to change a single piece of configuration like the name of your application without breaking things. This is also known as the YAML hell. 

A lot has already been written about how to work around this. Bash programmers write their own scripts and you may have already heard of the tool Helm Charts. I myself am not a very good Bash programmer and also I am not a friend of Helm Charts, because they only make the topic worse. The good news is that there is already an official solution called Kustomize. This declarative approach was originally a separate project which has become a part of Kubernetes since version 1.14. So there is no longer any reason to deal with endlessly long YAML files or Helm Charts if you just want to customize some details of your Kubernetes deployments. And you don not need to install any additional tools for this! 

Managed Scheduled Executor Service vs EJB Timer

Over the past years, I always used EJB Timer Service to implement scheduled tasks in my Java Enterprise applications. Since Java EE7, the ManagedScheduledExecutorService is a new pattern to implement a scheduler service. The ManagedScheduledExecutorService is part of the SE ScheduledExecutorService and provides methods for submitting delayed or periodic tasks for execution.

Implementing a ManagedScheduledExecutorService is quite simple. See the following example:

Monitoring Docker Swarm

In one of my last blog posts, I explained how you can set up a lightweight Docker Swarm environment. The concept, which is already an open-infrastructure project on GitHub, enables you to run your business applications and microservices in a self-hosted platform.

Today, I want to explain how you can monitor your Docker Swarm environment. Although Docker Swarm greatly simplifies the operation of business applications, monitoring is always a good idea. The following short tutorial shows how you can use Prometheus and Grafana to simplify monitoring.