This post is about architectural concepts for web applications – self-contained systems (SCS) and resource-oriented client architecture (ROCA) – and their implementation with Spring Boot, Spring MVC, Spring Security, Thymeleaf, Bootstrap, jQuery, nginx and Redis. Self-contained systems aim at building software systems without ending up in a big monolith and provide an answer to the question ‘How micro should a micro service be?’. The resource-oriented client architecture (ROCA) provides some rules for implementing web applications that comply with how the web works – not working against the web.

Two years ago I built a ROCA prototype using Spring MVC, Spring Hateoas, Thymeleaf, Bootstrap and jQuery, and since Spring Boot appeared since then I decided to update the code. But then I did a lot more than just updating it to Spring Boot.

Let’s start with the concepts. By the way, if you read it and think ‘hey, there’s nothing brand new in here’, that’s okay. People built systems and web applications like this probably since the beginning of the web. Giving it names may be the new thing.
(read more…)

In the previous blog post we looked at a best practice architecture for Java Batch applications that is running successfully a lot.

Still, we see challenges that affect productivity and costs, three of them are the following:

1. Monoliths
2. Application server
3. Meta framework

Let’s a look at them now.

Monoliths

Conway’s law states that

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

We noticed that often organization units start out with one batch application, and then it grows and grows and more and more batch jobs are deployed to it. You end up with one big application per organization unit. It’s somehow natural, because it’s far easier to just add another job to an existing application that create a new one. The pain comes later, and it comes with a vengeance. When updating code or a library, all jobs have to be tested, even if the changes are only for one job. And in general are batch jobs hard to test and don’t change a lot, so unnecessary testing is really painful.

So what do you do about it? One application per job – and you make it really easy to create a batch application. You may call this a Micro-Batch-Service if you want.
(read more…)

More and more companies are doing their batch processing in Java these days – but how do you do it the right way? This is the start of a series on Enterprise Java Batch about how we think it should be done. Today we will start with some simple questions that need to be answered if you want to establish Java Batch in your company, leading to a best practice architecture that’s still agnostic of specific frameworks. Next up is a post about challenges.
There are a lot of ways to write and run batch jobs, and this series’ goal isn’t to list all of them. Here we are talking about the best way according to our experience with a lot of enterprise customers. And then we want to clear up what micro services have to do with it.
When introducing Java Batch to your company you have to answer three questions:

1. Should a framework be used? If yes, which?
2. How should the batch jobs be operated?
3. How should the batch jobs be integrated into the company? Who is starting them?

(read more…)