Anzustrebende Applikationsarchitektur
Moderne (Standard-) Applikationsarchitektur kombiniert.png)
Applikationsarchitektur im Unternehmen und darüber hinaus
.png)
Die alte (aussterbende) und
die neue — nun sehr modulare, integrationsfreundliche — Schichtenstruktur
Letztere besteht aus:
End-Benutzer-Schnittstelle (= Webportal)
darunter einer Menge durch das Portal per REST API ansprechbarer Services
zur Pflege und Verarbeitung von Daten
sowie (als unterster Schicht) Datenbanken
Damit die Services sich auch untereinander so einfach und so performant wie nur irgend möglich aufrufen lassen, sollte jeder Service auch Teil einer Programmbibliothek sein, als der er dann per API in den Code der ihn aufrufenden Services eingebunden sein kann. Sein REST API ist einfach nur Wrapper um jenes direktere API.
Hatte man noch bis etwa 2012 als Datenformat fast immer XML gewählt, wird man heute — um etwas performanteren Code zu bekommen — eher JSON wählen. Optimal implementiert sind Services, die dem Aufrufer gestatten, das Format, in dem der Service sein Ergebnis abliefert, per Parameter zu spezifizieren (einzeln für jeden Serviceaufruf). Dies macht zudem noch den Code, welcher den Service implementiert, transparenter und kostengünstiger wartbar.
Sehr wichtig:
Jede der Komponenten — und ganz besonders jede, die einen Service implementiert (und wenn es nur einer ist, der Daten verwaltet) — muss so implementiert sein, dass bestmögliches Information Hiding gegeben ist. REST kommt dem sehr entgegen, denn alles, was der Aufrufer abrufen kann, ist einfach nur per URL identifiziert. Dies gilt für Daten ebenso wie für Funktionalität jeder Art (so dass ihre Implementierung sich jederzeit optimieren lässt o h n e dass Anwendungen sich anpassen müssen).

Man lese auch:
- Why EAI is necessary
- EAI vs. SOA vs. ESB vs. Microservices (as of 2014)
- Microservices Architecture: What, When, and How
Heute (2016) hört man recht oft sagen, SOA sei durch Microservices überholt. Das aber ist falsch, denn:
Microservices sind einfach nur ein Spezialfall von SOA, über den man zunächst kaum gesprochen hat. Tatsache ist: Es kommt immer darauf an, die Granularität der Services geeignet zu wählen. Microservices als konkurrenzlos zu sehen, wird selten zu einer wirklich optimalen Lösung führen.
Microservices sind kleinstmögliche eigenständige, einzeln ersetzbare Software-Module (aus Anwendersicht nur Implementierung einer einzigen Funktion). Erst wenn sie über APIs mit anderen Microservices verbunden werden, ergibt sich die Gesamtfunktionalität einer Anwendung. So sind regelmäßige Updates einzelner Funktionalitäten möglich, ohne dass ein System als Ganzes abgeschaltet werden muss. Im Ergebnis entstehen Softwaresysteme, die sich — wie bologische Lebewesen auch — in ständiger Fortentwicklung befinden.
Bei recht grober Granularität der Services, werden Clients die Services häufig über einen ESB ansprechen, bei eher kleiner Granularität aber direkt per REST. Wo nichts dagegen spricht, Client und Service im selben Prozess zu haben, den Service also einfach in Form einer direkt aufrufbaren Klasse oder Code-Bibliothek zu implementieren, wird diese Lösung natürlich stets die beste sein.
Martin Fowler (der erstmals von Microservices sprach) definiert: "The microservices architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP REST API. These services are built around business capabilities and independently deployable by fully automated deployment machinery."
A Microservice (or 'service') is any piece of a system regardless of size that has a consistent interface and is independent. Each piece can stand on its own at deployment and runtime.
Lies auch Fowlers Notiz Microservices and SOA.
In a world with constantly changing business requirements and a growing number of application clients, centralized infrastructures are getting too expensive to operate and scale towards unpredictable load or load peaks. The key idea with microservices is supporting their independence from the rest of the application landscape so that they can evolve quickly. They are to scale independently and will require fewer resources than application server-based applications.
- Integration Guide 2016
- Integration Guide 2017
- API Style Guides
- APIs versus Services – what is the difference?
- APIs are controlled (proxy) views on the data and capabilities of a domain, optimized for the needs of the API consumer.
As long as it is very cheap to create and maintain proxy APIs, such APIs are the means by which you can re-render a domain in multiple forms
optimized for each group of API consumers.
- Cloud Native Applications will soon become the rule.
- Martin Fowler on so-called Serverless Computing
stw4897APISM — API . Service . Microservices — News?
Mehr + B G E + S H A + More
RESTful Architecture
Microservices
Microservices — What you should know
Microservice-Umgebungen brauchen Monitoring
The Reactive Manifesto
Will Actor Models replace Java EE (?)
Reactive Microsystems
Progressive Web Apps seem to be the Future
Cloud-based Serverless Computing
Serverless: Vor- und Nachteile, und was genau es bedeutet
Serverless Frameworks
Software Systems Architecture Checklist
Security Frameworks
Best Practices for Building Secure APIs