W-JAX 2014

10.11.2014
Kristine Jetzke

Die W-JAX-Konferenz für Enterprise-Technologien, agile Methoden und Softwarearchitekturen - war voll gepackt mit interessanten Sessions und stand unter den Themen DevOps, Internet of Things, JavaScript, Microservices, Reactive und natürlich Docker, Docker, Docker.

Eröffnung

In der ersten Keynote Rethink IT: The Day After Tomorrow plädierte Michael Nygard, der Autor von Release It!, dafür, die Entwicklungsabteilungen nicht mehr dem IT Department zuzuordnen, sondern sie näher mit der Business-Entwicklungs-Abteilung zusammen arbeiten zu lassen. Ich persönlich war von dieser ersten Keynote etwas enttäuscht, da ich finde, dass das für eine Konferenz, die als zweiten Schwerpunkt "Agile Methoden" hat, keine sonderlich neue Erkenntnis ist.

Weiter ging es dann für mich mit Programmiertechniken mit Lambda-Ausdrücken und Interfacemethoden. Hier ging es darum, wie man die neuen Java 8 Sprachmittel für "elegante API-Designs und neue Implementierungstechnisken einsetzen" kann. Der Vortrag gefiel mir sehr gut, da tatsächlich der Fokus nicht darauf lag, die neuen Sprachfeatures vorzustellen, sondern wie man sie geschickt einsetzt. Die gewählten Beispiele waren aus der ebenfalls mit Java 8 eingeführten Stream-API gegriffen, so dass man die Beispiele leicht verstehen konnte und nebenbei ebenfalls auf dessen Vorzüge eingegangen werden konnte.

Danach hab ich Hypermedia-APIs - Der Rest von REST besucht, da ich mich schon länger gefragt habe, ob es sich lohnt, den HATEOS Teil der REST-Architektur konsequent umzusetzen. Kurz zusammengefasst geht es bei HATEOS darum, dass es bei einer REST API keine Liste von verfügbaren Endpunkten gibt, sondern nur eine Einstiegs-URL, die alle weiteren möglichen Aktionen liefert. Der Client baut sich also nach dem initialen Einstieg nie selbst URIs zusammen, sondern navigiert durch die API über die vom Server gelieferten Resource Repräsentationen. Der Hauptvorteil liegt demnach darin, dass existierende Clients durch Änderungen nicht kaputtgehen, solange sie robust genug implementiert sind. So muss man nicht zwingend mehrere API Versionen pflegen, sondern kann eine immer weiter entwickeln. Das Fazit des Vortragenden lautete "Aufwand, der sich lohnt", wobei er den Aufwand auf Client-Seite als deutlich höher bewertete als den auf Server-Seite. Leider hat er nicht im Detail erläutert, ob sich der Aufwand in allen Situationen lohnt. Ich denke, dass dem nicht so ist. Besonders, wenn man nur wenige Clients und keine umfangreichen Workflows hat, ist es vermutlich Overhead. Diese Betrachtung fehlte mir etwas in dem Vortrag. Denoch war er durch das gewählte Beispiel und die Code-Beispiele sehr anschaulich und ich werde von nun an beim API-Design berücksichtigen, ob es Sinn macht, HATEOS umzusetzen.

Hypermedia APIs

Nach einer weiteren Keynote und Vorträgen zum Thema reactive blieb ich bim Thema APIs mit Tipps und Tricks zum Test von APIs, SOA-Services und Schnittstellen, da natürlich auch bei uns immer wieder Thema ist, wie wir unsere eigenen APIs und das Zusammenspiel unserer Systeme mit externen APIs geschickt und mit wenig doppelter Coverage auf verschiedenen Teststufen testen. Leider bot der Vortrag fast ausschließlich bekannte Erkenntnisse, wie z.B. dass es nicht die beste Idee ist, APIs auf GUI-Ebene zu testen. Ein interessanter Gesichtspunkt des Vortragenden war allerdings, dass er keine guten Erfahungen mit der Test Pyramide gemacht hat und in vielen Fällen doch eher den "Test Cone" bevorzugt, da seiner Erfahrung nach viel Aufwand in die Infrastruktur von Unit Tests gesteckt wird, die dann schlussendlich doch keine Fehler finden und häufig angepasst werden müssen. Auch wenn ich seine Ansicht nicht genau so teile, finde ich es immer gut, die landläufige Meinung in Frage zu stellen. Und es bleibt meiner Meinung nach dabei, dass in jeder Situation immer wieder neu evaluiert werden muss, was die beste Teststrategie ist.

Mittwoch stand unter anderem unter dem Thema Microservices und begann für mich deshalb mit dem Vortrag Microservices - weder Micro noch Service?, in dem versucht wurde, eine Definition des allgegenwärtigen Begriffs zu finden und ihn auch gegen SOA abzugrenzen. Die beiden Hauptaussagen waren für mich: Ein Service sollte so klein sein, dass er von einem Team bearbeitet werden kann. Und: Er sollte in sich geschlossen sein, das heißt er sollte auch die GUI beinhalten. Darauf folgte später am Tag CQRS-basierte Architekturen mit Microservices, in dem die Empfehlung ausgesprochen wurde, CQRS aus Performancegründen nur mit Event-Sourcing zu benutzen. Abgerundet wurde der Tag durch das Panel zur Zukunft des Java Application Servers. Leider fehlte hier für eine richtig spannende Diskussuion eine starke Pro-Application-Server Seite.

App Server Panel

Weitere Highlights aus dem restlichen Mittwochsprogramm und dem Donnerstag:

Deploy (as often as it makes sense), Collaborate (even if you think you don't have to) and Listen (to problems and experiences of your coworkers).

Alles in allem war es eine sehr umfangreiche, vielseitige Konferenz, die eine gute Mischung aus Architektur-, Prozess und code-nahen, technischen Themen bot, die aber leider für mich einen etwas zu starken Schwerpunkt auf "Enterprise-Technologien" und zu wenig auf "agile Methoden" hatte.

Kristine Jetzke

Kristine has been working as a software developer, tester, and architect for more than 8 years. Her experience isn't limited to software development, though; she has also worked in project management and requirements engineering.

Read More ...
comments powered by Disqus