Java Magazin 8.14

Umfang: 116 Seiten

Erhältlich ab: 2014-07-02 00:00:00

Autoren: Philipp Bayer, Sven Ewald, Oliver B. Fischer, Timmo Freudl-Gierke, Peter Friese, Arno Haase, Dominik Helleberg, Peter Hruschka, Denny Israel, Stephan Klevenz, Holger Kraus, Klaus Kreft, Christian Laboranowitsch, Arne Landwehr, Angelika Langer, Arne Limburg, Željko Marković, Jan Mischlich, Michael Müller, Achim Nierbeck, Lukas Pustina, Moritz Rebbert, Christian Robert, Lars Röwekamp, Matthias Schaff, Daniel Schneller, Gernot Starke, Eberhard Wolff

Sie werden zu unserer Partnerseite entwickler.de weitergeleitet

Magazin

Bücher
BeagleBone für Einsteiger
Jan Deters

JCF +
Java Collections à la Goldman Sachs
Moritz Rebbert

Komplexität managen
Rückblick zur JAX 2014
Claudia Fröhling und Hartmut Schlosser

Apache Olingo
OData-Implementierung für Java und JavaScript
Stephan Klevenz

Java Core

I have a Stream…
Stream-Erzeugung und Stream-Operationen
Klaus Kreft und Angelika Langer

Kolumne: Java-Trickkiste
Nebenläufig – und auch schnell? Concurrency mit und ohne Locks
Arno Haase

Titelthema

Microservices
Lösen sie alle unsere Probleme?
Eberhard Wolff

Microservices in der Praxis
Nie wieder Monolithen!
Timmo Freudl-Gierke

Hystrix: Mehr Stabilität in verteilten Anwendungen
Damit Ihnen rechtzeitig die Sicherung durchbrennt
Holger Kraus und Arne Landwehr

Enterprise

Kolumne: EnterpriseTales
Custom Resource Loading mit Java 8
Lars Röwekamp und Arne Limburg

Tutorial

JavaFX – von der Klasse zur EXE
Tutorial zur Erstellung ausführbarer JavaFX-Anwendungen
Denny Israel

Architektur

Weg vom Schichtenmodell!
Command Query Responsibility Segregation
Oliver B. Fischer

Kolumne: Knigge für Softwarearchitekten
Der Domäniker
Peter Hruschka und Gernot Starke

Desktop

Data Binding – optimiert!
Annotationsgesteuertes Data Binding in Rich-Client-Applikationen
Jan Mischlich

Web

Ein neuer Blick auf XML
Datenprojektion mit XMLBeam
Sven Ewald

Frontend-Modularisierung mit JSPs
Fragmente, Komponenten, Module
Christian Robert

Frischzellenkur
Moderne Weboberflächen mit JSF und Bootstrap
Christian Laboranowitsch und Philipp Bayer

Cloud Computing

Privatsache
Mit OpenStack eine eigene Cloud aufbauen
Dr. Lukas Pustina und Daniel Schneller

Agile

Verhaltensregeln für Anwendungen
Teil 1: Einführung in Behavior-driven Development mit JBehave
Željko Markovic

Android360

Android wird andersARTig
Technische Evolution der Plattform
Dominik Helleberg und Matthias Schaff

Android-Logging-Framework
Das kleine Logging-1×1
Lars Röwekamp und Arne Limburg

Mauersegler

Und plötzlich war sie da, die neue Programmiersprache Swift. Obwohl Apples Geheimniskrämerei eine schallende Ohrfeige für alle ist, die an einen offenen Entwicklungsprozess glauben, fasziniert die neue Sprache, und zwar über alle technischen Lager hinweg. Swift, das seit Jahren hinter verschlossenen Türen entwickelt wurde, vereint Elemente aus den meisten Sprachen, die heute den Ton angeben – dort ein wenig Java, hier ein paar Elemente aus Scala, nebst ein paar Zutaten von Groovy, dort noch etwas Ruby, C# und Go und schließlich noch je eine Prise Kotlin und Rust. So in etwa könnte das Kochrezept lauten, das Chris Lattner, Urheber der Sprache bei Apple, seit 2010 entwickelte.
Welchen Zweck also hat die neue Sprache mit dem Mauersegler („Swift“) im Wappen? Zunächst galt es für Apple, für das in die Jahre gekommene Objective-C eine moderne Alternative anzubieten. Zweitens wäre Apple nicht (mehr) Apple, wenn es auf eine der existierenden Sprachen gesetzt und etwa Offenheit gegenüber der „Außenwelt“ demonstriert hätte. Das Gegenteil ist weiterhin der Fall: Die Sprache, der von vielen Experten ein ausgereiftes Design bescheinigt wird, ist rein für die Apple-Welt gemacht und wird für andere Communitys keine Relevanz haben. Drittens macht Apple üblicherweise kein großes Federlesen, wenn es um das Abstellen „veralteter“ Technologien geht. Genau so, wie ab Herbst die softwareseitige Unterstützung für das iPhone 4 beendet wird, wird auch Objective-C in vermutlich zwei bis drei Jahren ganz lautlos von der Bildfläche verschwinden. Die langwierige Pflege von Altlasten ist Apples Sache noch nie gewesen.

Sprachen im Mittelpunkt

Welche Bedeutung hat Swift also für den Rest der Welt? Die Beschäftigung mit (alternativen) Programmiersprachen und allgemeiner Sprachinnovation ist keine akademische Spielerei, sondern essenziell in einer Industrie, in der die technische Beschreibung von Problemen praktisch im Mittelpunkt steht. Trotz immer reifer werdender Tools, Plattformen und Automatisierungsmechanismen ist die Sprache für den Entwickler zentral. Das hat immerhin auch Apple erkannt und einen Sprung in die Gegenwart vollführt.
Übrigens stand nur wenige Tage nach dem Swift-Release eine neue Betaversion von Groovy bereit – das erste Groovy, das sich auch für die Android-Entwicklung verwenden lässt! Somit hat auch Android demnächst seine neue Sprache, wenn es auch gewiss nicht um die Abschaffung der „alten“ Sprache Java geht.

Das Ende der Monolithen?

Microservices heißt ein neues Konzept, das seit geraumer Zeit von sich reden macht. Die Grundidee ist schnell erzählt: Wenn Applikationen nicht als Monolithen ausgeliefert, sondern als Bündel autonomer Services deployt werden, so kann das verschiedene Vorteile haben. Aber Achtung: Niemand sagt, dass Sie jetzt Microservices verwenden müssen! Es handelt sich in erster Linie um einen Architekturstil, wie Martin Fowler schreibt, und ob dieser Stil die angemessenen Antworten auf eine gegebene Fragestellung hervorbringen kann, muss jeder für sich selbst entscheiden. Während es in der Geschichte der Informatik schon viele Konzepte der Entkoppelung von Einheiten gegeben hat – denken Sie an die Objekttechnologie, die Komponenten, die Services im Sinne einer SOA – scheint die Pointe bei den Microservices darin zu liegen, dass einzelne Entwickler oder ganze Teams Verantwortung für „ihren“ Service nicht nur für die Dauer der Entwicklung, sondern für den gesamten Lebenszyklus tragen.

Vom Projekt zum Produkt

In klassischen Softwareprojekten besteht das Ziel darin, eine gegebene Aufgabe unter Einhaltung von Budget- und Zeitvorgaben „fertigzustellen“. Was danach passiert, obliegt dem Betrieb. Die Idee eines „Produkts“ legt nahe, dass, ganz im Sinne von DevOps, ein Team Verantwortung für seine Software trägt, ein ganzes Leben lang.
Dass wir damit elegant die Brücke zu DevOps geschlagen haben, liegt auf der Hand. Aber lassen Sie mich noch einen weiteren Aspekt von Microservices anfügen: Durch die Konzentration auf die fachlichen Belange, nicht die technischen, wird die Bildung crossfunktionaler Teams, die in die Lage versetzt werden, stärker im Businesssinne mitzudenken, begünstigt. Alles kann, nichts muss – und selbst der große Martin Fowler mag nicht ausschließen, dass die genannten Ziele nicht auch mit monolithischen Systemen zu erreichen sind. Mit Microservices lassen sich keinesfalls veränderte Architekturen oder gar Entwicklungskulturen erzwingen – es bleibt ein Stil, und es bleibt dabei: Finden Sie selbst heraus, was zu Ihnen, Ihren Produkten und Ihren Kunden am besten passt.

Sebastian Meyen, Chefredakteur