Ralph Soika

Great article!

One thing about checked exceptions is that your code becomes much more expressive and is better understandable. I know that I am fighting a losing battle with this argument. Today, most people find it particularly cool to write short functional code without adding a single line of comment.
I think that the founders of Java really thought that expressive code would be a step forward from the then dominant C and C++ language style.

This is once again the usual list of Amazon's marketing promises.
Fargate is a comparatively costly solution that makes you completely dependent on AWS. It is not difficult to run your own Kuberenetes cluster - save money and stay in control.

There are a lot of tutorial like https://mkyong.com/tutorials/jsf-2-0-tutorials/

and Books : https://www.amazon.de/Definitive-Guide-Jakarta-Faces-Applications/dp/1484273095

Yes, where authentication/authorization is part of jakarta EE, Microprofile provides microservice specific aspects like healthcheck, metrics, configuration, fault tolerance, tracing, openapi... of course a lot of them where inspired by spring ;-)

As long as you write your code cleanly against the API and not against the implementation, this is almost not the case. At Spring, you often implement against the implementation, which can lead to problems.

Great article!
Your argument of better performance of JSON vs. XML is not always valid in my eyes.
Processing a complex JSON structure, a developer can make many faults affecting the performance. On the other hand XSLT is a high end processing technology to analyse, extract and transform even very complex XML data structure in a very fast way. It is not guaranteed that an unexperienced JSON developer can process data faster.

Why did you have miss Eclipse Microprofile?

What is the reason for setting:

net.bridge.bridge-nf-call-iptables=1

Thanks for this great article!
I had never thought about the possibilities of using Optional in Java. What is interesting is that Optional only provides a partial solution. The hint that a method returning optionals should never return null should also apply to a good API design in general, which fixes the problem of the NPE too.

I have written an article describing how to solve the problem using the Imixs-Workflow Microservice: https://dzone.com/articles/microservices-and-business-transactions

Yes, I think the global option did not work in this case.

It is important that you take care of the 'node-exporter' job description in the prometheus.yml file. You need to add the service name from every node. Also you may take a look here.

I like your article, but I think you have overlooked the rquirement of Business Transactions.

Business Transactions are the hidden dependencies between loosely coupled services.

I wrote this article about how to solve this kind of problem with the Microservice Saga Pattern.

See also the Blog from BJ Hargrave: I am an Incrementalist: Jakarta EE and package renaming. I am hopuflly that things will be solved at the end. In my eyes Oracle's position was and still is idiotic.

I'm sorry, but I think you're telling again the same fairy tale about Docker Swarm compared to Kubernetes.

Kubernetes was designed for very large environments and is ideal for this. Docker Swarm offers all those who operate less than 200 containers a lightweight but highly professional solution to manage containers. See an example here.

...An Oracle Database Cluster scales much better, but that's not an argument against MySQL...

DMN is a good place to model parameter-based decision trees. This article is more about complex rules for process control within a BPMN model.

There is also a github-site plugin which can be used to automate the deployment process into a gihub repo. See this blog.

I agree with the authors concept. It is not wrong to store maven artefacts in github because you typically have no changes in the artifacts itself.

See also the sequel: "How to Design a Business Process Service Architecture"

You may also take a look at Ben.JS. It's a plain small and minimalistic JavaScript framework for single-page-applications. Take a look if other solutions seem too be to heavy for your problem.

Yes you are right, each module has indeed its own workflow. However, these workflows depend also on the parent process. In my next blog I will explain how to couple services by modelling main and subprocesses. But the core idea is to keep out the process logic from the individual service layers.

Working with generic value objects and jpa is shown by the implementation of the ImixsEntityService EJB. This service ejb is provided by the Imixs Workflow Project. It can be used to store objects independent from a specific Entity Bean. Also queries with JPQL are possible. See: http://www.imixs.org/jee/examples/entityservice.html