Praktisches & Grundsätzliches zur Informatik

Anwendungsarchitektur, Softwarearchitektur, Schichtenstruktur

Anzustrebende Applikationsarchitektur

Moderne (Standard-) Applikationsarchitektur kombiniert

  • unterschiedlichste Datenbanken
  • mit Application Services (technisch sind das per REST ansprechbare SOA Services)
  • und client-spezifische, in HTML5 und JavaScript implementierte Endanwender-Schnittstellen:





    Applikationsarchitektur im Unternehmen und darüber hinaus





    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 auf­rufen 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 Implemen­tierung sich jederzeit optimieren lässt  o h n e  dass Anwendungen sich anpassen müssen).



    Information Hiding (Definition)




    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 Anwen­dung. 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 archi­tectural 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 appli­cation 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




    stw4897APISMAPI . Service . MicroservicesNews?

    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