Java Magazin 4.17
Java-Magazin-4-17_Cover_595x842_v2

APIs

Erhältlich ab: März 2017
Umfang: 100 Seiten
Autoren / Autorinnen:
Rodion Alukhanov, Adam Bien, Thilo Frotscher, Hans-Peter Grahsl, Tam Hanna, Peter Hruschka, Michael Jacoby, Vadym Kazulkin, Niko Köbler, Simon Kölsch, Lars Röwekamp, Dr. Hylke van der Schaaf, Marco Schulz, Jan Stamer, Dr. Gernot Starke, Patrick Steiner, Manfred Steyer, Eberhard Wolff

95,00 134,80 

Abonnement Typ
Auswahl zurücksetzen

9,80 

Heft bestellen

Magazin

News

Bücher: Swift 3

Java Core

Stärken und Schwächen
Teil 1: Hardware-Memory-Modelle reloaded
Rodion Alukhanov und Vadym Kazulkin

Java to Go
Google Go für Java-Entwickler
Jan Stamer

Tools

Kampf der Giganten
Java Tooling für NetBeans, IntelliJ und Eclipse
Marco Schulz

Enterprise

Realistisch und pragmatisch
Microservices mit Java EE
Adam Bien

Kolumne: EnterpriseTales
Responsive Design vs. Multi-Channel
Lars Röwekamp

Titelthema

Eigentlich ganz einfach
Fallstricke beim Design von Web-APIs
Thilo Frotscher

Die Drehscheibe
API Gateway
Niko Köbler

Einfach mächtig
OGC SensorThings API: Sensordaten im Internet der Dinge
Michael Jacoby und Dr. Hylke van der Schaaf

Architektur

Kolumne: Knigge für Softwarearchitekten
Die API-tektin
Peter Hruschka und Dr. Gernot Starke

Daten richtig behandeln
Datenarchitekturen nicht nur für Microservices
Eberhard Wolff

Schlüsselkasten 2.0
Microservices mit Vault absichern
Simon Kölsch

Web

Hier kommst du nicht rein
Teil 1: Authentifizierung und Autorisierung mit Angular 2.0
Hans-Peter Grahsl und Manfred Steyer

Internet of Things

Vermittlungsinstanz einer IoT-Architektur
Teil 2: Aufbau des Smart Gateways und seiner Logik
Patrick Steiner

APIs: Kein alter Wein in neuen Schläuchen

Kühner Gedanke: Wir könnten Anwendungsteile großer Softwaresysteme voneinander entkoppeln und das Internet für den Datentransfer nutzen. Damit bei der losen Koppelung von Services kein Chaos entsteht, sollten wir das Ganze richtig verwalten: Services müssen sich zentral registrieren und eine zentrale Instanz steuert Routing, Berechtigungen, Datenkonvertierung usw. Nennen wir diese Instanz den Enterprise Service Bus (ESB) und die Registrierungsstelle UDDI (Universal Description, Discovery, Integration). Für Protokolle und Servicebeschreibung wählen wir ein sehr mitteilsames Format, weil Komplexität ja besonders ausschweifende Erläuterungen erfordert: XML. Nennen wir das Ganze schließlich SOA: Service-oriented Architecture!

Dieser Gedanke ist aus heutiger Sicht natürlich keineswegs kühn. Aber er repräsentierte damals – vor 1,5 Jahrzehnten als er in Mode war – den ersten validen Ansatz, das Internet als intrinsischen Bestandteil der Systemarchitektur mitzudenken. Warum wurde SOA dann aber durch Konzepte wie API-Management und Microservices abgelöst? Weil SOA zwar das Internet als Potenzial erkannt, das klassische OO-Denken dabei aber noch nicht überwunden hat: Alle Maßnahmen zur Konsistenzsicherung eines Systems basierten auf der Annahme, dass sich letztlich auch im Netz der gleiche Zustand herstellen lässt wie innerhalb eines geschlossenen Systems.

Kleiner Exkurs: Als der Ottomotor erfunden war und sich rasch verbreitete, verstanden die großen Hersteller von Pferdekutschen schnell, welche Bedeutung dieser ab sofort für die Mobilität der Menschen haben würde. Sie entfernten die Pferdedeichseln und bauten Verbrennungsmotoren in ihre Kutschen ein. Aber wer hat letztlich die automobile Revolution angeführt? Die Newcomer, die erstens Autos und nicht motorgetriebene Kutschen bauten, und die zweitens lernten, in neuen Maßstäben zu skalieren und auch das erfanden. Die Kutschenhersteller hatten aus ihrer Sicht indes nichts falsch gemacht und dennoch die Zeichen der Zeit nicht erkannt.

SOA war im Kern ebenso richtig gedacht, berücksichtigte aber die vielen Details zu wenig, die in offenen, internetbasierten Umgebungen einfach anders sind. Heutige Ansätze, bei denen stets das Web-API im Zentrum steht, sind daher nicht alter Wein in neuen Schläuchen, sondern eine wichtige Neuinterpretation des Themas im Sinne einer SOA 2.0.

Thilo Frotscher gibt ab Seite 46 einen guten Überblick über die Herausforderungen beim Einsatz API-basierter Systeme, Niko Köbler analysiert die Aufgaben eines API Gateway (Seite 54) und Michael Jacoby und Dr. Hylke van der Schaaf zeigen anhand eines spannenden Beispiels, wie ein generisches API im Internet der Dinge beschaffen sein sollte (Seite 60).

Viel Spaß bei der Lektüre wünscht

Sebastian Meyen, Chefredakteur


Weitere Ausgaben

X
- Gib Deinen Standort ein -
- or -