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.
Self-Contained Systems (SCS)
When building a big system, a bigger application, a portal, something to support your business case that has a user interface, you first have to decide how many things you want to build. In the past it often happened to be one thing – the often criticized monolith. It’s a common understanding now that monoliths cause trouble and should be avoided, some of the problems seen are complicated, long builds, bad maintainability, lock-in to specific technologies, bad changeability and therefore longer time-to-market and many more. Currently microservices are the talk of the town, but they don’t come without a cost. If you really have microservices ‘doing one thing’ implemented in approximately 100 lines of code (as stated by some people), you’ll have a lot of them, and network traffic, resilience, more complex implementation compared to just calling methods, monitoring, coordination all have to be handled.
Self-contained systems as described and promoted by Stefan Tilkov are not that small. A bigger system is made up of several such self-contained systems, and it’s up to our common sense to cut those systems, but they do more than one thing. Stefan Tilkov lists the following characteristics for self-contained systems:
- Autonomous web application. Each self-contained system is a complete web application that handles its use cases.
- Owned by one team. The self-contained system is small enough to be owned and developed by one team.
- No sync remote calls. To minimize dependencies to other systems a self-contained system doesn’t do sync remote calls. Integration is done via links in the browser, see below. Async remote calls are allowed.
- Service API optional. If needed, a self-contained system may expose functionality via REST endpoints.
- Includes data and logic. A self-contained system stores and handles its data, no other system may access the data directly. Logic, data and UI are not separated in different applications. A self-contained system may duplicate data from other systems. Let’s say a self-contained system for ‘contracts’ needs to display the customer’s name on each page, but the customer belongs to the self-contained system for ‘customers’. One option would be to store the customer’s id and name in ‘contracts’ data repository. If the customer’s name changes, the ‘customers’ system sends out an async message with that info, and everybody listening (for example the ‘contracts’ system) updates the duplicated data in its repository. The other option would be to include an HTML snippet from the ‘customers’ system in each ‘contracts’ page.
- No shared UI. Each self-contained system has its own UI, there is no such thing like a service layer and a common UI layer above it.
- No or pull-based code sharing only. Each team has the full responsibility for its self-contained system, which includes the choice of programming languages, frameworks and libraries. Code sharing should be pull-based, so if the team decides that using some common code is helpful, it may use it, but it’s not forced to use something. Of course there needs to be some kind of macro architecture everybody has to follow to make integration possible, in our (pure) case it’s just the use of HTTP/HTML to integrate applications via links in the browser, the integration of some messaging system to receive and send the async updates and the support of a dedicated Single Sign On mechanism. Of course it may make sense to restrict the usage of certain technologies in a company to concentrate knowledge in some technologies.
One of the main advantages of this approach is the flexibility. When after some years the technology stack used in the first self-contained systems is outdated, it’s no problem to build new systems in another stack without the need to update the existing ones. At every customer I see the situation that people would like to change / update technologies, but they cannot, because that would mean that a lot of existing applications need to be touched, and since there’s no business value in that, new applications / new use cases are also built in outdated technologies.
To be more clear on this one: even if you use the most up-to-date technology today, it will be outdated in five years, so it’s absolutely necessary for an evolvable system that its architecture does not tie the overall system to certain frameworks or, even worse, certain products.
Resource-oriented client architecture (ROCA)
As stated on its website , ROCA is ‘a collection of simple recommendations for decent Web application frontends’. It’s a short list, so before I repeat them here, please read them there .
So now you know the rules, but that doesn’t mean you can instantly imagine how such an application would look like. At least I couldn’t. I learned that there are two important aspects:
RESTful communication is stateless, so we have no session state. We have meaningful bookmarkable URIs for each resource and sub-resource, and a resource ideally represents an object from our domain, or a list of objects from our domain. I say ideally, because that’s not a must. In a lot of use cases, a resource made for a web frontend cannot be mapped 1-on-1 to domain objects, but if it does, our life gets easier. To interact with those resources we use the four HTTP methods GET, POST, PUT and DELETE. So if our domain happens to be a movie database, usage could be:
- GET on /movies for displaying all movies
- POST on /movies for adding a movie
- GET on /movies/42 for displaying the movie with id 42
- PUT on /movies/42 for updating the movie with id 42
- DELETE on /movies/42 for deleting the movie with id 42
A GET returns HTML markup (possibly through a template engine), PUT and DELETE are tunneled through a POST, and POST, PUT and DELETE return a redirect URI to follow the POST/REDIRECT/GET pattern.
Some more sentences about the statelessness, because it has so many implications: Most of the developers are used to do stateful web development, especially when using JSF. It’s easy to store another, and another, and another thing in the session, and suddenly you get pages that work just under specific circumstances, and it’s hard to keep track of all the objects in the session and why they landed there in the first place. Maintainability and testability suffer more and more. For operations things get more complicated with a session, because we either need sticky sessions or session replication, and when rebooting or deploying an application, all users get thrown out the hard way. Implementing a web application in a stateless manner means that all information must be reproducible from the request, that may be the URL, get parameters, hidden inputs, headers. It doesn’t mean you’re not allowed to use caches, you may even use the session as cache, and with ROCA you can use the standard browser cache as well, but it also means that updates to resources get persisted maybe a little bit more often than with stateful web development. The benefits you gain are scalability, zero-downtime-deployments, perfect bookmarkability which includes taking a site directly from one device to the other, no hassle caused by an expired session and more.
An implementation: the movie database
The code for the movie database together with installation instructions can be found on Github . The following diagram desribes the architecture of the overall system.
We have two self-contained systems, one responsible for movies (movie-database-movies), one for actors (movie-database-actors). In addition we have two more applications that serve cross cutting concerns, one for monitoring (movie-database-monitoring) and one for the navigation header (movie-database-navigation). The project is completed by two libraries, movie-database-security for the single sign on (SSO) functionality and the very small movie-database-commons for common functionality. Initial page after signing in looks like this:
It should be easy to install the complete system with the given installation instructions, however, I would like to point you to several details in the implementation.
Integrating self-contained systems
I differentiate here between a non-direct integration via a navigation header / bar and direct integration between two self-contained systems.
If you want to integrate several self-contained systems seamlessly, you’ll have some common components displayed on every page. I chose to restrict it to a navigation header containing links to the movies- and the actors-system, a search field and a log out button. It makes a lot of sense to let the navigation content be served by an own application, because you want to be able to add navigation points to the list without rebuilding every application. That’s what the application movie-database-navigation is for. It delivers pure HTML and is dynamic, you may, for example, specify to which URL the content of the search field shall be posted. When integrating such HTML snippets you roughly have three options:
- Load the HTML snippet on the server’s side in the application and include it in the HTML page before sending the reponse to the browser.
- A proxy builds the page using Edge Side Includes (ESI).
I chose the second option. One reason was a flickering with option one that I couldn’t get rid of. Now getting the navigation snippet is actually a sync remote call, which isn’t allowed according to the SCS characteristics, but I take it here as an exception of the rule. To make the application more resilient I included a static build-time fallback navigation which will be used when the dynamic navigation is not reachable. This has two advantages: whenever the navigation application is down, people can continue to work with a less dynamic, maybe outdated navigation instead of getting 500ers, and while developing we don’t need to start the navigation application to work on just ‘our’ self-contained system.
Direct integration of two self-contained systems
Actors play roles in movies, so I implemented the possibility to display actors that played in a movie from a movie’s resource. It’s just a direct link into the actor’s resource with a search criteria that restricts the result to that movie. I’m using Bootstrap and jQuery to render the content in a modal window. The Thymeleaf template is here , the construction of the link is here . This is a screenshot of a movie resource:
Okay, linking is easy, but what if you’re working in system A and need to create something in system B for your use case, jumping back immediately afterwards? I added the possibility the add an actor to a movie (in my implementation you have to create a new one, but it’s easy to think of an implementation where you may choose existing ones in addition). After creating the actor you jump back to the movie’s page, that’s done by adding a return url when jumping into the actors system. You can see the return url in this screenshot:
When pressing the ‘cancel’ or the ‘save’ button on the ‘add actor’ page, there’s no redirect to the actor but to the return url (see ActorController , methods
Single Sign On / Security
As soon as you have more than one application facing the user you need single sign on (SSO) if you want the system to appear as one thing. I chose a simple approach with an unique SSO-Id persisted in a central repository (Redis). This unique id is saved in a cookie at the client. Of course this only works if the client browser sees the same host for all self-contained systems, but this is usually a requirement anyway. I’m using nginx as a reverse proxy to let the whole system be served under the same host. I implemented the SSO security mechanism in a library using Spring Security (thanks to Rajo Gajic for help), so that everybody can pull it in who thinks it’s helpful. Of course you could implement the mechanism yourself if you want, but for Spring applications it’s convenient to just use it.
Another approach would be to implement an authentication application and redirect everything regarding authentication to it. The dependency is not as strict as to a library, and non-Spring applications could use it, too. The disadvantage is that you add a single point of failure.
Building links and resources
When implementing an application in ROCA style, you have to think in resources. Resources have an unique identifier (an URL), they contain data that’s displayed on the page, and they contain links to other resources. Links consist of the link itself and a relation with the semantic meaning of the link. I’m using Thymeleaf templates to convert objects to HTML, so to bring structure to my implementation I use a Resource class that may contain data and any number of links, and an object of this class is delivered to the templating mechanism. In the template, links are referenced like this, identified by the relation:
For building links the LinkBuilder class is used. This is a small set of classes heavily influenced by Spring HATEOAS (in fact I used Spring HATEOAS before in this project, but I realized that I only could use a very small subset of its functionality, so I chose to duplicate it). Using these classes will bring more structure to building your links and resources. This is the main part of movie-database-commons .
Monitoring with Spring Boot Admin
The more applications you run, the more crucial monitoring becomes. When using Spring Boot Actuator Spring Boot applications expose a lot of interesting monitoring data, from simple health checks to endpoint metrics, from used memory to thread dumps, from environment variables and properties to deployed Spring beans. With the Jolokia endpoint you even can do all available JMX operations. Spring Boot Admin is an open source project by codecentric that provides a user interface to all the data with a lot of extra functionality, for example downloading the log file etc. Here’s a screenshot of the overview page for monitoring the movie-database:
Head over to Spring Boot Admin’s page to see more screenshots! And if you look into the code of movie-database-monitoring , you’ll see that there’s very little to do to start monitoring your own applications.
To have an unique look and feel you have to use the same CSS. That’s easy if you just use Bootstrap, like I did, you just add a webjar dependency and include it into HTML’s head. But even if you have your own CSS, which will be much more likely when doing a real project, you should handle it the same. Build webjars with the CSS and include the dependency in a nice, versioned manner to your project. When developing the CSS further it’s crucial to be as downward compatible as possible.
A few more words on development, build and operations
Let’s say we have a bigger system with ten self-contained systems. How do we actually develop and operate it?
Since we minimized the dependencies between the systems, we’re probably able to do a lot of work without relying on other systems, that’s good. But of course, there’ll be time when integration needs to be tested, and I would argue it’s too late to do it just on integration stages. And we have our own dependencies in our self-contained system, at least the SSO token repository, the messaging system, probably some kind of database etc. It should be easy and convenient to build up a development environment with that infrastructure and the other self-contained systems, if you need them, and it should be built up the same way in test and production. The solution to this is the ‘Docker based runtime environment for developers’ my colleagues at centerdevice introduced in this blogpost (unfortunately just in German) . Docker images for each self-contained system, the cross-cutting applications and the infrastructure make it possible to set up environments in very short time, whether it’s the development environment or the production environment.
Long post, probably my longest until now, so I hope you didn’t just scroll down to the conclusion and skipped the other parts ;-). I hope the terms ‘self-contained system’ and ‘resource-oriented client architecture’ are clear now, and I hope my sample system has shed some light onto possible implementations.
Spring Boot, of course, is just an implementation detail of the self-contained systems, but a very helpful one. While implementing with Spring Boot is nice, the usage here shows once again that operations is where Spring Boot shines – the monitoring capabilities are very convincing, and having a fat jar that bundles application and server is convenient for operations as well. But of course, there’s no constraint to implement every self-contained system in Spring Boot.
If you didn’t do it by now I encourage you to look at the code and let it run, I’m very much interested in feedback!
There’s a follow-up blog post handling a few more interesting topics :
- Adding a non-ROCA self-contained system written in AngularJS.
- Explaining bounded contexts with an example.
- Doing data duplication between self-contained systems.
IT-Mitarbeiter und die Command & Control Architektur
Prämisse Die IT wird in der Zukunft noch wichtiger, als sie jetzt schon ist. Geschäftsprozesse werden immer digitaler, neue rein digitale Geschäftsprozesse kommen hinzu. Outsourcing im großen Stil ist gescheitert. Weil die IT immer näher ans Kerngesch...
10.8.2016 | 5 Minuten Lesezeit
BizDevOps beschreibt eine Organisationsform, in der die Personen, die eine Anwendung schreiben, betreiben, die fachlichen Anforderungen erstellen und das zugehörige Geschäftsmodell weiterentwickeln, in einem agilen Team zusammengefasst sind. Dabei hat...
15.2.2016 | 5 Minuten Lesezeit
Microservices und ESBs
Ein zentraler Enterprise Service Bus ist dafür zuständig, die Kommunikation zwischen Systemen innerhalb eines Unternehmens zu übernehmen. Dabei übernimmt der ESB Routing-, Transformations- und Mapping-Funktionalität und bietet in der Regel eine Fülle...
21.1.2016 | 2 Minuten Lesezeit
Microservices und Legacy-Systeme / Standardsoftware
Eine Microservices-Architektur entsteht selten auf der grünen Wiese. Wie geht man also mit Schnittstellen zu Legacy-Systemen um? Und neben Legacy-Systemen gibt es ja auch noch Standardsoftware, denn manchmal macht es einfach keinen Sinn, etwas selbst...
11.1.2016 | 2 Minuten Lesezeit
Kommunikation von Microservices – Die vier Ebenen der Entkopplung
Wenn man einführende Artikel zum Thema Microservices liest, so heißt es meist lapidar, dass Microservices über REST oder Messaging kommunizieren können (sollten). Die Frage, welche Kommunikation wann sinnvoll ist, wird meist zunächst nicht beantwortet...
9.11.2015 | 4 Minuten Lesezeit
Wer Microservices richtig macht, braucht keine Workflow Engine und kein...
Bernd Rücker und Daniel Meyer schreiben im Fazit von „Wie lässt sich Ordnung in einen Haufen (Micro)Services bringen“ , dass gerade in einer Microservices-Architektur eine Workflow-Engine und BPMN einen festen Platz haben sollten. Das ist eine pauschale...
31.8.2015 | 10 Minuten Lesezeit
Kaffeeküchengespräche – Microservices und Domain Driven Design
Neulich in der Kaffeeküche im Gespräch mit einem Kollegen, der gerade von einem zweijährigen Sabbatical im Dschungel Brasiliens zurückgekehrt ist. Wenn man sich so die aktuellen Programme der Konferenzen ansieht, dann scheint dieses Microservices-Ding...
7.6.2015 | 9 Minuten Lesezeit
Enterprise Java Batch: A best practice architecture
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...
24.11.2014 | 4 Minuten Lesezeit
WJAX 2014 Best Practice Java Batch – Architektur, Probleme und Lösungen
Immer mehr Unternehmen setzen auf Batch-Verarbeitung in Java – nur wie macht man es richtig? Nach einer kurzen Einführung in den JSR-352 / Spring Batch stellen wir in diesem Vortrag die unserer Erfahrung nach optimale Architektur für Batch-Services im...
6.11.2014 | 1 Minuten Lesezeit
Writing JSR-352 style jobs with Spring Batch Part 2: Dependency injection
Spring Batch 3.0 supports writing and running batch jobs that comply with the JSR-352 specification, which is the standard for batch processing also included in JEE7. This article series focuses on three topics: configuration options using Spring Batch...
1.9.2014 | 5 Minuten Lesezeit
Spring XD – Tackling Big Data Complexity
Wenn man von Big Data spricht, redet man häufig über Hadoop oder NoSQL-Datenbanken. Dabei ist Big Data viel mehr als bloße Persistenz. Daten müssen gesammelt, verarbeitet und exportiert werden. Real Time Analytics sind ein weiteres großes Thema. Spring...
3.8.2014 | 1 Minuten Lesezeit
JSR-352 – Ein Standard für die Batchentwicklung
Die Batchverarbeitung gehört zu den ältesten Verarbeitungsformen in der IT überhaupt, und doch gab es im Java-Bereich bisher keinen Standard dafür. Das hat sich nun mit dem finalen Release des Java Specification Requests 352 (Batch Applications for...
30.6.2014 | 1 Minuten Lesezeit
Sind Architekturteams in größeren Unternehmen überflüssig?
Jeder kennt sie, manchmal heißen sie Architekturteam, manchmal Framework-Team, manchmal Methoden und Verfahren. Jede größere Firma mit eigener IT und Software-Entwicklung hat sie. Neben anderen Aufgaben sind diese Teams häufig dafür verantwortlich, Code...
5.6.2014 | 3 Minuten Lesezeit
Five Spring features that I miss in the Java Enterprise Edition (JEE)
During the last years you could read a lot about the rise of the Java Enterprise Edition and the fall of Spring (a.k.a. Spring is the new legacy), only I don’t see it in real life’s work. For more than ten years I’ve been working on long time projects...
18.5.2014 | 4 Minuten Lesezeit
JAX 2014: Ein Standard für die Batch-Entwicklung – JSR-352
Mit dem JSR 352 wurde die Batch-Entwicklung im Java-Bereich standardisiert, und mit der Aufnahme in die Java Enterprise Edition 7 werden in Zukunft alle entsprechenden Application Server die Möglichkeit bieten, Batch-Jobs auszuführen. Diese Session von...
14.5.2014 | 1 Minuten Lesezeit
Enterprise-ready production-ready Java batch applications powered by Spring...
This post introduces a new project we set up – our own Spring Boot starter for Spring Batch: spring-boot-starter-batch-web . Spring Boot is the new kid on the Spring block helping you build Spring applications in a fast convention-over-configuration...
12.5.2014 | 4 Minuten Lesezeit
Spring Batch 2.2 – JavaConfig, Spring-Data-Support und Co.
Dieser im Javamagazin 11/2013 erschienene Artikel beschreibt die Neuerungen in Spring Batch 2.2. Die zwei wichtigsten Neuerungen betreffen zwei starke Entwicklungen der letzten Jahre im Spring-Ökosystem, die jetzt auch in Spring Batch verfügbar sind...
4.5.2014 | 1 Minuten Lesezeit
Spring Batch: BatchStatus state transitions
Have you ever been wondering what it means that your job has ended in UNKNOWN state? Or why your job never seems to finish (state STARTED), although you restarted the server? This short blog post is about the different batch states and the transitions...
2.4.2014 | 2 Minuten Lesezeit
10 criteria for choosing the right implementation of the JSR-352 (Java...
As you might already know, the JSR-352 is the standardization effort for batch processing in Java. It has been released and included in JEE7 this year, which means that every JEE7 application server will have batch processing capabilities. As I pointed...
5.12.2013 | 4 Minuten Lesezeit
Batch processing and the Java Enterprise Edition (JSR-352, JEE7, Spring...
The JSR-352 (Batch Applications for the Java platform) has been released and included in JEE7 over half a year ago, so now I see conference talks and workshops popping up explaining it, and that’s a good thing, people need to know about it. Spring Batch...
28.11.2013 | 2 Minuten Lesezeit
Spring One Wrap-up: Spring Batch, Spring Hadoop and Spring XD
Here it comes, the second part of my Spring One wrap-up, this time not from sunny California but from rainy Germany. The first one was about Spring IO and Spring Boot, and it’ll be all about batch now. I’ll focus on three projects here, one of them ...
15.9.2013 | 5 Minuten Lesezeit
Spring Batch 2.2 – JavaConfig Part 6: Partitioning and Multi-threaded ...
Finally, last part of the blog series! Today we’ll have a quick look at scaled batch jobs, done via partitioning and multi-threaded step. This is the sixth post about the new Java based configuration features in Spring Batch 2.2. Previous posts are ...
7.7.2013 | 4 Minuten Lesezeit
Spring Batch 2.2 – JavaConfig Part 5: Modular configurations
When adding more jobs to an ApplicationContext, you will soon run into problems with the naming and the uniqueness of beans. Normally you define one configuration class or one configuration XML file for each job, and then it feels natural to name the...
29.6.2013 | 2 Minuten Lesezeit
Spring Batch 2.2 – JavaConfig Part 4: Job inheritance
One important feature in XML is the possibility to write abstract job definitions like these: Concrete job definitions may inherit parts of their definition from it: ... In enterprise environments...
22.6.2013 | 7 Minuten Lesezeit
Spring Batch 2.2 – JavaConfig Part 3: Profiles and environments
This is the third post about the new Java based configuration features in Spring Batch 2.2. In the first post I compared the two configuration styles on a non-trivial batch job reading from a file and writing to a database. I used a very simple infrastructure...
15.6.2013 | 3 Minuten Lesezeit
Spring Batch 2.2 – JavaConfig Part 2: JobParameters, ExecutionContext ...
This is the second post about the new Java based configuration features in Spring Batch 2.2. In the first post I compared the two configuration styles on a non-trivial batch job reading from a file and writing to a database. In the first version of...
8.6.2013 | 4 Minuten Lesezeit
Monitoring Spring Batch with AppDynamics
When running Spring Batch in production it’s always good to keep an eye on performance. And in pre-production it’s helpful to have a tool that points to the weak spots. One option you have is to use Application Performance Management (APM) tools, and...
27.4.2013 | 4 Minuten Lesezeit
JAX 2013: Enterprise Java Batch mit Spring
Dennis Schulte und ich haben gestern auf der JAX 2013 in Mainz einen Vortrag mit dem Titel ‚Enterprise Java Batch mit Spring‘ gehalten. Der Vortrag teilt sich in drei Bereiche auf: Im ersten Teil geht es um Grundlagen im Bereich Spring Batch, während...
24.4.2013 | 1 Minuten Lesezeit
A RESTful learning curve: nouns, verbs, HATEOAS and ROCA
I really don’t claim to be a REST expert, but I learned a few things during the last months that I want to share with you. Some things might be trivial for people already working with REST a lot, good for you then, but I guess there are a lot people ...
25.11.2012 | 6 Minuten Lesezeit
Spring Dependency Injection Styles – Why I love Java based configuration
I must admit, when looking at Spring 3.0’s feature list for the first time I didn’t see one thing I wanted to use right away in my next project. There was the Spring Expression Language, the stereotype annotation model, there was some Spring MVC stuff...
21.7.2012 | 8 Minuten Lesezeit
Transactions in Spring Batch – Part 2: Restart, cursor based reading and...
This is the second post in a series about transactions in Spring Batch, you find the first one here , it’s about chunk based transaction handling, batch job vs. business data, a failed batch and transaction attributes, and the third one here , it’s about...
25.3.2012 | 6 Minuten Lesezeit
Transactions in Spring Batch – Part 1: The Basics
This is the first post in a series about transactions in Spring Batch, you find the second one here , it’s about restarting a batch, cursor based reading and listeners, and the third one here , it’s about skip and retry. Transactions are important in...
21.3.2012 | 6 Minuten Lesezeit
A business component architecture with Spring 3.0/3.1 – Part 3: Properties
This is the third post in a series describing a business component architecture using Spring 3.0/3.1 features like Java based configuration, the environment abstraction, bean definition profiles and property sources. After the general structure and ...
19.1.2012 | 9 Minuten Lesezeit
Eine Fachkomponentenarchitektur mit Spring 3.0/3.1 – Part Two: Ressourcen
Im ersten Blogpost dieser Reihe habe ich die Fachkomponentenarchitektur vorgestellt und beschrieben, welche Unterprojekte benötigt werden und welche Funktion sie haben. Für die Konfiguration greife ich dabei auf die Java-basierte Konfiguration von Spring...
6.1.2012 | 4 Minuten Lesezeit
SWT and Spring’s @Configurable – Dependency Injection for the UI
Given the following technology stack: – Java frontend with the Standard Web Toolkit (SWT), started via Java Web Start. – Spring Remoting as the interface to the backend. – Spring web application on a Tomcat as backend. The backend is standard Spring...
16.12.2011 | 5 Minuten Lesezeit
Dein Job bei codecentric?
Agile Developer & Consultant (w/d/m)
An allen Standorten
Gemeinsam bessere Projekte umsetzen
Wir helfen Deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Do you still have questions? Just send me a message.