Der erste Teil des Vortrags richtete sich an Enterprise-Enwickler (meist mit einem Java-EE-Hintergrund), die sich für JS interessieren, sich schnell darin einarbeiten wollen und Tipps suchen, dieses Ziel zu erreichen. Dabei wurden einige Grundlagen der Sprache vorgestellt. Dieser Teil des Vortrags sollte eher Lust auf mehr machen als fundamentales Wissen in aller Tiefe zu vermitteln.

Geschichte

JS wurde 1995/1996 von Brendan Eich als Mocha bzw. LiveScript für den Netscape Navigator entwickelt. 1996 wurde die Script-Sprache in JavaScript 1.0 im Zuge der Sun-Netscape-Alliance, einer Marketing-Kampagne, umbenannt. Auch Microsoft zog mit JScript, einem JS-Dialekt für Internet Explorer 3.0 nach. JScript wurde nicht JavaScript genannt, um keine Markenrechte von Sun zu verletzen (dies ist auch der Grund, warum heute viele Entwickler lieber von JS als von JavaScript sprechen, denn die Rechte am Namen JavaScript liegen heute bei Oracle). Schließlich wurde der Kern der Sprache als ECMAScript von der ECMA standardisiert.

Brendan Eich schwebte ein Scheme im Web-Browser vor – eine Sprache, um HTML über Skripte zu manipulieren. Seine Aufgabe war es, JS wie Java aussehen zu lassen, allerdings ähnelte das Ergebnis eher C und AWK. Zudem wurden einige Fehlentscheidungen, die sich auf den Versuch zurückführen lassen, LISP-Konstrukte in JS einzuführen, schon früh eingefroren.

Seine Designziel war u.a., eine Script-Sprache zu schaffen, die es einem Web-Designer ermöglicht, Code-Snippets zu kopieren und in den eigenen HTML-Code einzufügen. Darum toleriert JS Fehler wie fehlende Semikolons. Das ursprüngliche Event-Handling (onclick, onmouseover) war sehr einfach und orientierte sich an HyperCard von Apple. Eich wählte einige mächtige Grundelemente (First Class Functions aus AWK und Scheme und prototyp-basierte Objekte aus Self) und ließ viele andere, in anderen Sprachen übliche, Sprachfeatures weg.

Self – ein Vorbild für JS – war eine Sprache, die in den 1980er Jahren von Xerox PARC & Sun Microsystems entwickelt wurde. Ziel von Self war es, mehr Freiheiten als Smalltalk (eine damals beliebte objektorientierte Sprache) zu bieten. Self verwendet nur wenige Konstrukte wie Slots, Traits und Prototypen, aber keine (statischen) Typen und Klassen. Diese Konstrukte finden sich auch in JS wieder.

Self unterscheidet nicht zwischen dem Verhalten eines Objekts (Methoden einer Klasse) und dem Zustand des Objekts (Eigenschaften einer Klasse). Ein Objekt besteht aus Slots, die einen Namen haben und Methoden oder Attribute aufnehmen können. Objekten können zur Laufzeit Slots hinzugefügt werden. Objekterzeugung erfolgt vollständig ohne Klassen. Neue Objekte erzeugt man durch das Klonen existierender Objekte. Einzelne Slots können an einen Parent delegieren, indem sie den Slot aus dem Parent-Objekt nicht überschreiben. Trait-Objekte sind abgespeckte Implementierungen (Mixins).

Brendan Eich begründet die Existenz der beiden Programmiersprachen – Java und JS – mit dem Argument der Arbeitsteilung: Java war für hochpreisige Komponenten und Widgets vorgesehen, die in Java Applets laufen sollten. JS war für den Massenmarkt und Web-Designer gedacht, die lediglich Glue-Code zwischen Komponenten schreiben, Java Applets ansprechen oder Form-Validierungen bzw. Image-Rollovers implementieren möchten. Allerdings ist in der letzten Dekade Java aus der Client-Seite des Webs fast komplett verschwunden.

Im Jahr 2000 wurde ECMAScript 3rd Edition (ES3) spezifiziert. Dies ist der JS-Dialekt, den heute nahezu alle Browser sprechen. Erst zehn Jahre später wurde der Nachfolge-Standard ES5 fertiggestellt. Dies liegt daran, dass sich das Konsortium um ECMAScript nicht über die Features von ES4 einigen konnte, das u.a. Klassen und eine statische Typsierung bieten sollte. Ideen aus ES4 werden jedoch in ES6 einfließen, das voraussichtlich noch in diesem Jahr fertiggestellt wird.

Dynamische Typisierung

Als Java Enterprise-Entwickler ist man oft der Meinung, dass sich nur in einer statisch typisierten Sprache zuverlässiger Code schreiben lässt. JS kennt aber keine statische Typisierung, sondern Typen werden dynamisch zur Laufzeit ermittelt.

JS kennt fünf Basistypen. Diese sind Zahlen (number), Strings (string), Booleans (boolean), null und undefined. Wenn diese als Literale verwendet werden, sind sie unveränderlich (immutable).

Objekte

Obwohl es Basistypen gibt, so könnte ein Java Enterprise-Entwickler einwerfen, ist JS lediglich eine Script-Sprache. Eine strukturierte, objektorientierte Programmierung ist ohne Objekte nicht möglich.

In JS sind alle Datentypen außer Basistypen Objekte. Dies sind Arrays, Funktionen, Reguläre Ausdrücke (Funktionen) und Objekte selbst.

Prototypen

Der Java Enterprise-Entwickler könnte nun dagegen halten, dass eine objektorientierte Programmierung nur klassenbasiert möglich ist, da man ansonsten kein eigenes Typsystem entwickeln kann. JS bietet keine Klassen und damit kein eigenes Typsystem.

Schon ES3 bietet Konstruktor-Funktionen. Objekte werden über das new-Keyword und eine Konstruktor-Funktion gebildet. Letztere beginnt per Konvention mit einem Großbuchstaben (im Gegensatz. zu „normalen“ Funktionen). Ruft sie der new-Operator auf, wird ein Objekt vom Typ der Konstruktorfunktion erzeugt und kann innerhalb dieser angereichert werden.

Für Verebung gibt es Entwurfsmuster. Wem diese zu unbequem sind, kann eine Meta-Sprache wie TypeScript verwenden, die voraussichtlich ES6 ähneln wird, aber zu lesbarem ES3 kompiliert. Üblicher als die Verwendung von Vererbung ist aber das Benutzen von Mixins, die den Traits von Self ähneln.

Funktionale Programmierung und Closures

Java wird erst mit Java SE 8 Closures bekommen, die einem Konzept der funktionalen Programmierung aus den 1970er Jahren entstammen, das JS von Scheme geerbt hat.

In JS sind Funktionen sind gleichwertig zu Objekten (eine Funktion ist ein Objekt). Funktionen können als Parameter eine andere Funktion übergeben und auch als Rückgabewert ausgegeben werden. Dies illustriert dieses Script, das der Standard-Sortierfunktion von Arrays eine Sortiervorschrift als Funktion mitgibt.

Bei der Verwendung von JS ist das Scoping für Java-Entwickler sehr gewöhnungsbedürftig. Auf den aktuellen Kontext (Scope) greift man über this zu. Dies ist der globale Namensraum bei einem Funktionsaufruf, ein Objekt-Namensraum beim Aufruf einer Konstruktor-Funktion mit dem new-Operator, ein Objekt-Namensraum bei einem Methodenaufruf, das Aufrufer-Objekt bei Events (im Browser) und (hier wird es interessant) definierbarer Namensraum durch call und apply. Durch call und apply lassen sich Methoden eines Objektes im Kontext eines anderen Objekts wiederverwenden. Scoping illustriert dieses Code-Snippet.

Eine Funktion wird stets in einem Funktionsgeltungsbereich ausgeführt, der auch dann gilt, wenn in einer Funktion eine weitere, innere Funktion definiert wird. Letztere hat dann Zugriff auf die Variablen der äußeren Funktion. Dieses Verhalten wird als Closure bezeichnet. Ausnahmen sind hier this und der Bonusparameter arguments, da diese Parameter von jeder Funktion selbst überschrieben werden.

function outherFunction() {
	var x = 'Hello';
	function innerFunction() {
		return x;
	}
	return innerFunction();
}
outherFunction(); // Hello
outherFunction.x; // undefined

Im oben aufgeführten Beispiel wäre es möglich, Closures zur Implementierung privater Variablen zu nutzen.

Namespaces und Module

Ein Java Enterprise-Entwickler könnte der Ansicht sein, dass sich in JS Objekte und Konstruktoren definieren lassen – und mit Closures können sogar Konstrukte, die private Variablen ersetzen können, gebaut werden. Allerdings kennt JS keine Packages, ohne die sich Code nur schwer organisieren lässt. Allerdings kann man JS-Objekte als Namespaces benutzen. Dies illustrieren folgende Code-Snippets:

• http://jsfiddle.net/oochs/AA7TV/
• http://jsfiddle.net/oochs/pECUe/

Über Packages hinaus muss Code in Libraries und Modulen gepflegt werden. In Java existieren dafür JARs, OSGI-Module und demnächst das standardisierte Java Module System. Die Unterstützung von JS dafür ist, was den ECMA-Standard bis Version 5 angeht, mangelhaft. Allerdings spezifiziert CommonJS ein Modulsystem, das u.a. durch AMD (require.js) implementiert wird. Dazu möchten wir diesen Blog-Post empfehlen.

Zusammenfassung und Ausblick

Zusammenfassend für den ersten Teil lässt sich sagen, dass JS als Script-Sprache für den Browser entwickelt wurde. Die Wurzeln von JS sind nicht Java, sondern exotische Sprachen, deren Konzepte niemand kennt. JS ist dynamisch typisiert, funktional und objektorientiert. Packages lassen sich über Objekte nachbilden, und für Module existieren etablierte Ansätze.

Enterprise-Entwicklung ist in der Regel Teamarbeit. Eine umfangreiche Codebasis, wie sie ein großes Team erstellen wird, muss wartbar bleiben. Im zweiten Teil des Vortrags wurden Techniken und Tools vorgestellt, die dabei helfen können, eine geeignete Codequalität zu erreichen und zu wahren. Dieser Teil des Vortrags wird in einem folgenden Blog-Post beschrieben.

Der Trend bei Web-Frameworks pendelt zwischen Request-Response-orientierten und Komponenten-basierten Frameworks. (Bild: “world-movement” cc-by rosmary)

Das Web hat eine eigene Architektur, die durch das HTTP-Protokoll vorgegeben wird und stellt eine Implementierung des REST-Architekturmusters dar.

Das HTTP-Protokoll ist zustandslos. Zustände werden zwischen Konsumenten (z.B. einem Browser) und  Produzenten (z.B. einem Server) transferiert. Sie werden dargestellt durch Ressourcen (Dokumente). Die Kommunikation erfolgt über das Request-Response-Muster. Da keine Zustände gespeichert werden müssen, sondern Zustände übertragen werden, ist eine Web-Architektur theoretisch beliebig skalierbar.

Klassische Web-Frameworks basieren ebenfalls auf dem Request-Response-Muster. Das Programmiermodell eines klassischen Web-Frameworks entspricht also dem Programmiermodell des HTTP-Protokolls. Ein einfaches Beispiel für ein solches klassisches Web-Framework ist die Java Servlet-API.

Auch das angegraute Apache Struts basiert auf dem Request-Response-Muster, strukturiert aber eine Web-Anwendung, indem das MVC-Entwurfsmuster angewendet wird. Ein Controller ist ein Bindeglied zwischen einer Web-View und dem Datenmodell der Anwendung. Wenn ein Request am Java Web-Container (z.B. Tomcat) ankommt, wird dieser vom Struts-Front-Controller engegengenommen. Dieser ruft beispielsweise anhand eines URL-Musters eine Action-Klasse auf. Diese Action-Klasse liest das im Request übertragene Model aus, wendet auf dieses Model Applikations-Logik an, verändert es damit und delegiert schließlich an eine Web-View, die das Model zur Darstellung bringt und im Response zurück an den Browser überträgt. Das Modell wird bei Struts in der Regel in JavaBeans – sogenannten FormBeans – gehalten, die bei jedem Request neu aufgebaut und nach dem Response zerstört werden. Zwar steht eine serverseitige Session zur Verfügung, um in dieser nutzerbezogene Zustände der Anwendung zu speichern, allerdings fügt sich diese bewusst nicht in das Konzept des Frameworks ein. Auch neuere Web-Frameworks wie Ruby on Rails, ASP.NET MVC, Grails von Springsource, Spring-MVC oder Play aus dem Typesafe-Stack folgen diesen Wurzeln.

Dieses zustandslose Programmiermodell war jedoch für Entwickler, die aus der Desktop-Entwicklung kommen, fremd. Eine Desktop-Anwendung wurde schon damals aus UI-Komponenten zusammengesetzt. Daher entstanden Web-Frameworks, die dieses UI-Komponentenmodell auf Web-Anwendungen übertragen.

UI-Komponenten haben den Vorteil, dass sich auch komplexere UI-Widgets zusammensetzen und dann konsistent verwenden lassen. Während HTML seit 1997 (bzw. 1999) mit dem 4.01-Standard stagnierte, konnten reichhaltigere UI-Widgets durch komponentenorientierte Frameworks auch von Enterprise-Entwicklern ohne fortgeschrittene Kenntnisse von HTML, JavaScript und CSS benutzt werden.

Der Zustand einer komponentenorientierten Anwendung wird üblicherweise in einem Baum organisiert. Eine Änderung des Zustands der Anwendung wird über Events und nicht über Requests ausgelöst. Meist wird der Zustand des Baums auf dem Server gehalten. Events lösen implizit HTTP-Requests aus, ohne dass sich der Entwickler darum kümmern muss.

Komponentenorientierte Web-Frameworks abstrahieren also sowohl das HTTP-Protokoll als auch HTML, Stylesheets und JavaScript und bieten statt dessen ein höheres Programmiermodell an. Beispiele für solche komponentenorientere Web-Frameworks sind JSF, ASP.NET, Apache Wicket, Lift oder das Google Web Toolkit und Vaadin.

Grundsätzlich lassen sich Web-Frameworks also stark verallgemeinert in zwei Klassen unterteilen: Web-Frameworks, die auf dem Request-Response-Muster basieren und Web-Frameworks, die dieses Muster abstrahieren und auf Komponenten basieren. Während sich bei Web-Frameworks, die auf dem Request-Response-Muster basieren, der Entwickler selbst um den Zustand der Web-Anwendung und um die Präsentationsschicht kümmern muss, wird bei Web-Frameworks, die auf dem Komponenten-Modell basieren, der Zustand meist in einem Baum auf dem Server gehalten und UI-Komponenten werden zur Verfügung gestellt.

Der Trend ging früher von Request-Response-basierten Web-Frameworks hin zu komponentenorienterten Web-Frameworks. Subjektiv beobachte ich allerdings in letzter Zeit einen Trend hin zurück zu Request-Response-basierten Web-Frameworks. Dies hat mehrere Gründe.

• Webentwicklung ist schon lange nicht mehr exotisch. Die meisten Entwickler sind inzwischen Web- und nicht mehr klassische Anwendungsentwickler. Der Request-Response-basierte Ansatz einer Webanwendung erscheint vielen Entwicklern heute natürlicher als die eventbasierte Entwicklung in Komponenten-Frameworks.
• Durch HTML5 und ECMAScript 5 ist der Stillstand im Bezug auf HTML, CSS und JavaScript im Webbrowser überwunden. Reichhaltige Benutzeroberflächen lassen sich mit HTML5 (und hilfreichen Bibliotheken wie Twitter Bootstrap) viel leichter realisieren als mit HTML 4.01 oder XHTML. Komponentenorientierte Frameworks entwickeln sich inzwischen sogar langsamer als Webbrowser es tun. Modernere UIs lassen sich jetzt also mit den Basistechnologien leichter entwickeln als mit Komponenten-Frameworks. Der komponentenorientierte Ansatz fühlt sich inzwischen schwerfällig an.
• Skalierung ist heute wichtiger denn je, da viele Anwendungen inzwischen auf virtuellen Servern in der “Cloud” gehostet werden, in denen klassisches Clustering keine Option ist. Daher ist es nicht mehr State-of-the-Art, den Zustand einer Anwendung in einer Session zu speichern.

Zwar ist ein Trend zurück zu Request-Response-basierten Web-Frameworks zu beobachten, allerdings sind dies nicht mehr unbedingt die gleichen Frameworks wie aus der Urzeit der Webentwicklung. Hier gibt es zwei Strömungen, die sich allerdings nicht unbedingt widersprechen und beide auf dem REST-Ansatz basieren:

• Web-Frameworks, die auf Partial Page Rendering und Progressive Enhancement basieren, und
• SPA-Frameworks (Single Page Applications), die MVC (bzw. MVP / MVVM) direkt im Browser implementieren.

Bei den erstgenannten Frameworks bietet der Server ein Backend, das den REST-Prinzipien folgt. Alle Logik findet auf dem Server statt. Der Browser bringt lediglich vom Server gelieferte HTML-Fragmente (HTML-Snippets) zur Darstellung, gestaltet sie mit CSS und reichert sie durch unobstrusives JavaScript an. Auf dem Server lässt sich hier JAX-RS mit einer dünnen UI-Schicht (Jersey bietet solche Features) oder ein klassisches MVC-Framework wie Spring MVC oder eine neueres Framework wie Play, das auf serverseitige Sessions verzichtet, einsetzen. Im Browser genügt eine etablierte JS-Bibliothek wie jQuery mit entsprechenden Plugins wie das jQuery-Form-Plugin und jQuery-UI. Ein echtes browserseitiges UI-Framework wird nicht benötigt. Anforderungen an eine Beispiel-Architektur, die diesem Muster folgt, definiert der ROCA-Style (ROCA = Ressource Oriented Client Architecture).

Bei den zweitgenannten Frameworks wandert das MVC-Muster vom Server in den Browser. Dies kann zu sehr leichtgewichtigen Server-Anwendungen führen. Eine Server-Komponente liefert lediglich eine per URL eindeutig identifizierbare Ressource in einem angeforderten Format (z.B. als JSON-Objekt) aus bzw. persistiert sie. MVC-Frameworks auf dem Browser kümmern sich sowohl um die Logik als auch um die Darstellung. Der Zustand der Anwendung wird im Client gehalten. Die Komplexität der Anwendung wandert also vom Server in den Browser. Daher ist ein echtes UI-Framework im Browser hilfreich. Als Beispiel für leichtgewichtige MVC-Frameworks im Browser können Ember.js, Knockout, AngularJS oder JavaScript-MVC dienen.

Neben leichtgewichtigen SPA-Frameworks gibt es auch schwergewichtigere, komponentenbasierte Frameworks wie Senchas Ext.js, die eher einem JSF oder GWT im Browser als einer angereicherten Website gleichen. Es lässt sich nur schwer beantworten, ob ein solches Framework eher das Beste aus beiden Welten bietet oder sämtliche Nachteile beider Ansätze vereint.

Auch in Enterprise-Anwendungen sollten moderne Architektur-Ansätze, die aus dem Web-Umfeld kommen, zumindest ausprobiert werden. Vorteile wie Skalierbarkeit und leichtgewichtige Anwendungen (zumindest auf dem Server) sprechen für sich. Entsprechende Frameworks sind in diesem Artikel verlinkt. Bei der Auswahl eines Web-Frameworks sollte darauf geachtet werden, dass das Framework von der Architektur her zur Architektur des Webs und seines Protokolls, dem Hypertext Transfer Protocol,  passt.

Viel Spaß beim Ausprobieren!

Working software over comprehensive documentation.

agilemanifesto.org

Heißt das, wir brauchen gar nichts zu dokumentieren, solange unsere Anwendung funktioniert?

Nein, wenn man genau hinschaut, sieht man, dass dort nicht steht, man solle nichts dokumentieren. Gemeint ist viel mehr, dass man nicht unbedingt umfangreiche Doku verfassen muss, wenn man funktionierenden Code hat. Der Aufwand, den man in die Dokumentation steckt, muss dem Nutzen angemessen sein.

Außerdem drückt sich das Agile Manifest hier etwas vor dem Henne-Ei-Problem: Aufgrund welcher Vorgaben soll ich denn meinen funktionierenden Code erstellen? Als seriöser Entwickler kann ich mich ja nicht auf Basis von mündlichen Überlieferungen des Auftraggebers an die Arbeit machen. Ich brauche irgendwas Handfestes, Schriftliches, mit dem ich anfangen kann, meine Anwendung zu bauen.

Es gibt in jedem Projekt auch Wissen, das man nicht in Form von Programmcode konservieren kann. Zu dieser Erkenntnis sollte man schon deswegen gelangen, weil Dokumentation stets in einer Zielgruppen-kompatiblen Form vorliegen sollte und nicht jedes Projektmitglied zwangsläufig Programmcode lesen kann.

Dokumentation soll dazu beitragen, dass alle Beteiligten ein gemeinsames Verständnis vom Projektziel und vom Weg dorthin bekommen.

Auch in einem agilen Projekt wird man nicht darum herumkommen, dafür Informationen in menschlich lesbarer Form aufzuschreiben. Das Mittel dar Wahl ist dafür meist ein Wiki, auf das jeder Beteiligte Zugriff hat.

Was wird dokumentiert?

Zunächst natürlich die User-Stories. Muss hier bis in kleinste Detail ausformuliert werden? Nicht zwangsläufig. Die Mindestanforderung ist natürlich, dass das Team versteht, was der Product Owner haben möchte. Weitere, im Prozess des Story-Tellings gewonnene Erkenntnisse sollten ebenfalls schriftlich festgehalten werden.

Architekten und Entwickler werden im Verlauf der Implementierung einige kritische Entscheidungen treffen und diese im Wiki dokumentieren. Gab es mehrere Alternativen, von denen einige verworfen wurden, sollte auch dieser Entscheidungsprozess nachvollziehbar aufgeschrieben werden.

Überhaupt sollten wichtige Entscheidungen immer schriftlich dokumentiert werden. Schon allein, um langwierige Diskussionen zu Entscheidungsfindungen nicht mehrfach führen zu müssen.

Wird die erstellte Anwendung noch durch externe Tester geprüft, sind diese ebenfalls auf eine vorhandene Dokumentation angewiesen, um auf deren Basis Testfälle formulieren zu können.

Eine Kulturfrage

In agilen Projekten, die nach Scrum oder einem vergleichbaren Vorgehensmodell geführt werden, sind alle Team-Mitglieder gleichermaßen für den Projekterfolg und die Qualitätssicherung verantwortlich. Dazu gehört, wie gerade dargelegt, auch die Dokumentation.

Diese entsteht leider nicht von selbst und nicht jedes Team-Mitglied wird mit großer Freude drauflosschreiben. Insbesondere wenn Budget und Zeit gegen Ende einer Iteration knapp werden, wird die Schreibbereitschaft allgemein abnehmen.

Dennoch sollten Projektverantwortliche, Scrum-Master und/oder Architekten sicherstellen, dass die notwendige Dokumentation auch trotz widriger Umstände erstellt wird.

Dabei hilft es sehr, wenn sie diese Dokumentationskultur selbst vorleben und sie nicht ausschließlich vom Team einfordern.

Die Software ist die Dokumentation

Gerade in kleineren Projekten wird gerne gesagt, dass die Software selbsterklärend ist und keiner Dokumentation bedarf. Das mag sogar sein: Gut strukturierte Software zeigt dem geneigten Betrachter, wie sie aufgebaut ist und wie sie funktioniert. Was einem die Software aber selten verrät, ist, warum sie so ist wie sie ist. Schon gar nicht können wir herauslesen, warum bestimmte Dinge nicht getan wurden, da diese ja nicht in der Software enthalten sind. Wichtig ist also, Entscheidungen und Begründungen zu dokumentieren, für Dinge die in die Architektur und Software eingeflossen sind, wichtiger noch für Dinge, die nicht eingeflossen sind.

Zwischen den Zeilen lesen und hören

Kommen wir zu den Politiker-Interviews. Eigentlich bräuchte man die nicht durchzuführen. Schließlich steht in den Parteiprogrammen, welche Positionen die Partei – und damit ihre führenden Köpfe – vertreten. Warum sollen sich die Journalisten also die Mühe machen, Politiker zu befragen? Meistens sagen sie in den verschiedenen Interviews ja dasselbe. Viel interessanter ist eigentlich, wie der Mensch etwas sagt, warum er es sagt und was er nicht sagt. Dies herauszuarbeiten, ist die eigentlich spannende Aufgabe des Journalisten. Ebenso wichtig ist es für den Software-Architekten, herauszuarbeiten, warum die Software-Architektur so gewählt wurde und was – hoffentlich ganz bewusst – nicht in die Architektur eingeflossen ist. Auch wenn es vordergründig langweilig und unnötig erscheint, lohnt es sich, auf der Suche nach dem Warum und den Hintergründen sowohl Politiker zu interviewen als auch Software-Architektur zu dokumentieren – wenn es gut gemacht ist.

Alle ihre Handlungen sollten auf technischem und wissenschaftlichem Wissen aufbauen und sich an den Projektanforderungen orientieren. Die Bedeutung des Teams, demokratischer Willensbildung oder von Diskussionen rückt in den Hintergrund, da die Experten sowieso am besten wissen, was genau zu tun ist. Man fährt am besten, wenn man einfach nur umsetzt, was die sich ausgedacht haben.

Schlimme Vorstellung?

Irgendwie schon.

Gibt’s in Wirklichkeit nicht!

Doch — allzu oft.

Muss das sein?

…

Nein natürlich nicht.

Der Imperativ des letzten Wortes

Aber es ist nicht einfach, mit solchen technokratischen Anwandlungen umzugehen. Das Know-how in einem Projekt-Team ist niemals gleich verteilt. Man braucht erfahrene Architekten und Projektleiter im Team. Doch deren Verantwortung sollte es nicht nur sein, gute Ideen und Konzepte zu entwickeln und voranzutreiben.

Ebenso wichtig ist es, die guten Ideen so zu kommunizieren, dass das restliche Team sie nachvollziehen, eigenständig umsetzen und weiterentwickeln kann. Eine gute Idee ist nur so gut, wie ich sie Anderen verständlich vermitteln kann.

Die Aufgabe des Architekten ist es, wichtige technische Entscheidungen im Projekt zu treffen und diese auch durchzusetzen. Dabei kann ein guter Architekt sein Team von seinen Ideen begeistern, sie gemeinsam mit seinem Team diskutieren und weiterentwickeln.

Andere Architekten setzen ihre Ideen mit dem Imperativ des letzten Wortes durch – “Macht das so, ich erkläre euch später, warum das so gemacht werden muss“. Man kann sein Team kaum besser demotivieren.

Auch für Architekten selbst wird letzterer Ansatz selten zu einem langanhaltenden Arbeitserlebnis führen, das frei von Verdruss ist.

Wenn ich nicht dafür sorge, dass meine Ideen und Konzepte vom Team verstanden werden, muss ich sie ständig neu erklären. “Das Team ist echt dusselig, jedes Mal muss ich mein Konzept von vorne für die durchkauen“. Hier könnte man auch die Vermutung anstellen, dass der Architekt jedesmal aufs Neue versagt, wenn er es nicht schafft, mit seinen tollen Ideen bleibenden Eindruck und Verständnis beim Team zu hinterlassen.

Erfolgsrezept? Mehr Überzeugungsleistung!

Gute Ideen werden von den Leuten angenommen. Oft genug ist es so einfach. Steigt der Aufwand an notwendiger Überzeugungsleistung, so ist das möglicherweise ein Hinweis darauf, dass der eingeschlagene Weg noch nicht der optimale ist. Entweder müssen dann Wissenslücken geschlossen oder gemeinsam mit dem Team eine geeignetere Lösung gefunden werden.

Und wenn es mal nicht so einfach ist, sollte man sich als Architekt immer vor Augen führen, dass man außer dem Team niemanden sonst hat, der die Arbeit erledigt.

Realistisch betrachtet gibt es keine Alternative dazu, dem Team eine Lösung an die Hand zu geben, mit der es gut zurechtkommt und die es auch eigenhändig umsetzen kann. Ein Architekt, der mit seinem Team auf Augenhöhe arbeiten will, muss hier vermitteln, verhandeln und zuhören.

Der Architekt ist verantwortlich für die Erstellung und Umsetzung der Software-Architektur. Dazu braucht er das Team. Im Verlauf größerer Projekte wird ein Architekt auf viele externe Widerstände stoßen. Er wird sich das Leben sehr viel einfacher machen – und den Projekterfolg wahrscheinlicher, wenn er es schafft, das Team von seiner Sache zu überzeugen.

SOA macht keine Vorgaben zur technischen Umsetzung. Häufig erfolgt die Umsetzung auf Basis von SOAP-Webservices. Dabei werden Dienste, deren Schnittstellen, Operationen und Datenobjekte mithilfe der WSDL definiert.

Da diese wiederum unabhängig von der technischen Realisierung ist, können über WSDL definierte Dienste miteinander kommunizieren, auch wenn einer von ihnen in Java implementiert ist und der andere in C# oder PHP. Die Integration von Diensten über Technologiegrenzen hinweg ist dadurch relativ einfach möglich.

Integration mit RESTful Services

Implementiert man seine Services als RESTful Services, hat man keine WSDL zur Schnittstellendefinition. Was gäbe es auch groß zu definieren? Da REST auf dem HTTP-Protokoll aufsetzt, sind die möglichen Operationen für alle Dienste dieselben: GET, PUT, POST, DELETE, usw.

Was bei REST notwendig ist, ist die Beschreibung der Ressourcen, auf denen die genannten Operationen ausgeführt werden. Ressourcen sind beispielsweise die Repräsentation eines Kunden, eines Vertrages oder einer Bestellung. Es muss definiert werden, wie eine solche Ressource strukturiert ist. Formate wie XML oder JSON bieten sich dafür an. Der Zugriff auf eine Ressource erfolgt, durch HTTP vorgegeben, über einen URI. Zuletzt ist definiert, welche Operationen an einem URI erlaubt sind.

Eine Service-Landschaft, die auf RESTful Services basiert, lässt sich in etwa mit dem World Wide Web vergleichen. Dort finden sich unzählige Webseiten (vgl. Ressourcen), die über ihren URI eindeutig identifiziert werden können. Dieser URI ist ebenfalls die Basis für die Verlinkung der Ressourcen untereinander.

Über Suchdienste wie Google kann man sich nun auf die Suche nach einer bestimmten Ressource machen:

Web Suche nach Sheldon Cooper

Alle gefundenen Ressourcen lassen sich ohne spezialisierte Client-Software korrekt interpretieren. Man benötigt lediglich einen HTTP-Client, ein Anwendungs-spezifisches Set an Operationen existiert nicht. Die hier gefundenen Daten liegen nicht in einem einzelnen Informationssystem, sondern auf tausenden von getrennten Webservern. Da sie jedoch alle über das HTTP-Protokoll erreichbar sind, können sie von einem einzelnen Dienst durchsucht und die Suchergebnisse in einheitlicher Form dargestellt werden.

REST im Unternehmen

Man stelle sich das im Unternehmens-Umfeld vor: Alle Ressourcen, sprich Kunden-, Auftrags- und sonstige Stammdaten können über REST-Operationen abgefragt und auch manipuliert werden. Auch für die Maschinen-zu-Maschinen-Kommunikation ist das eine große Vereinfachung im Vergleich zu SOAP. Das Heraussuchen von Ressourcen, also beispielsweise Kundendaten, über mehrere Anwendungen hinweg, kann so einfach werden wie eine Suche in Google.

Sofern die RESTful-Services geeignete Meta-Informationen liefern, sich also im geeigneten Umfang selbst beschreiben und sofern es Service- und Daten-Repositories gibt, kann eine IT-Service-Landschaft zu ungeahnter Transparenz gelangen.

Wer viel misst…

Ohne große Worte ein Beispiel aus der relationalen Welt:

select log_level, count(*) as log_level_count from log_entry group by log_level

Zählen mit SQL ist kinderleicht. Mit MongoDB musste man bislang auf MapReduce-Algorithmen setzen, und das könnte z.B. so aussehen:

db.logEntries.mapReduce(
	function() {emit(this.logLevel, {logLevelCount: 1});},
	function(k, vs) {
		var r = {logLevelCount: 0};
		vs.forEach(function(v) {r.logLevelCount += v.logLevelCount;});
		return r;
	},
	{"out": {"inline": 1}}
)

Gut, Soll erfüllt. Zwar ist der MapReduce-Code “lauter” als die SQL-Abfrage, aber dafür ist dieses Feature auch sehr mächtig und spielt erst in verteilten Systemen seinen Trumpf aus – die leichte Parallelisierbarkeit.

Mit dem Aggregation Framework sieht dieselbe Abfragesemantik so aus:

db.logEntries.aggregate({"$group": {"_id": "$logLevel", "logLevelCount": {"$sum": 1}}})

Diese Abfrage ist deutlich lesbarer (oder nicht?!). Aber natürlich muss man sich an dieser Stelle die Frage stellen, warum das Aggregation Framework überhaupt eingeführt wurde, wenn man doch per MapReduce zum gleichen Ergebnis kommt. Die Antwort ist simpel: Performance.

MapReduce in MongoDB ist teuer. Das ist darauf zurückzuführen, dass solche Algorithmen in JavaScript geschrieben werden. Eine Script-Evaluierung für jeden zu verarbeitenden Datensatz ist eine schlechte Abfrage und eine gute Heizung. Aggregation Framework-Abfragen hingegen kommen ohne JavaScript aus und das wirkt sich (ein kleines bisschen) positiv auf die Performance aus.

Zum Vergleich

In einem Test habe ich aus einem Pool von Log-Levels („trace“, „debug“, „info“, „warn“, „error“ und „fatal“) 800.000 Datensätze in eine MongoDB-Collection geschrieben. Die Collection ist in acht Shards unterteilt und kann auf meinem Notebook echt-parallel MapReduce abgefragt werden (danke, großer Micro-Prozessor-Konzern, für den ich keine Schleichwerbung mache).

Ein Datensatz sieht in etwa so aus:

{"_id": ObjectId("50a9f5b6e8d4f7906f71aee1"), "shardAnchor": 1, "logLevel": "fatal"}

Bis auf das „shardAnchor“-Feld ist kein Schnickschnack enthalten (das „shardAnchor“-Feld dient für diesen Test einfach nur dazu, die Chunks gleichmäßig auf die Shards zu verteilen).

Wenn wir jetzt die oben stehenden Abfragen abfeuern, bekommen wir folgendes Ergebnis (ich habe den Test in Java implementiert und den Treiber org.mongodb mongo-java-driver-2.9.3 verwendet):

Found 800000 records; not removing or creating anything
Invoking MapReduce
MapReduce took 5870 milliseconds
MapReduce result:
	debug: 133663.0
	error: 133230.0
	fatal: 132868.0
	info: 133244.0
	trace: 133563.0
	warn: 133432.0
Invoking aggregation
Aggregation took 452 milliseconds
Aggregation result:
	warn: 133432
	debug: 133663
	fatal: 132868
	error: 133230
	info: 133244
	trace: 133563

Die Zahlen sprechen für sich: 5,87 Sekunden vs. 0,452. Frage: Wer zählt noch mit MapReduce? Quizfrage: Wer wird auch in Zukunft mit MapReduce zählen?

Ach ja, für die ganz nerdierigen unter uns ist hier der Code des Tests:

package noorg;

import java.util.LinkedList;
import java.util.List;
import java.util.Random;

import com.mongodb.AggregationOutput;
import com.mongodb.BasicDBObject;
import com.mongodb.DB;
import com.mongodb.DBCollection;
import com.mongodb.DBCursor;
import com.mongodb.DBObject;
import com.mongodb.MapReduceCommand.OutputType;
import com.mongodb.MapReduceOutput;
import com.mongodb.Mongo;

public class MongoDbTest {

	public static void main(String[] args) throws Exception {
		Mongo m = new Mongo();
		DB db = m.getDB("test");
		DBCollection c = db.getCollection("logEntries");
		c.ensureIndex(new BasicDBObject("logLevel", Integer.valueOf(1)));

		final int chunks = 100, chunkSize = 8000, totalRecordCount = chunks * chunkSize;
		long start;

		DBCursor cursor = c.find();
		if (c.count() != totalRecordCount) {
			System.out.println("Collection " + c.getName() + " record count is not " + totalRecordCount + "; Removing and re-creating everything");
			System.out.println("Removed " + c.remove(new BasicDBObject(0)).getN() + " records from collection " + c.getName());

			String[] logLevels = new String[] {
				"trace",
				"debug",
				"info",
				"warn",
				"error",
				"fatal"
			};
			Random r = new Random();

			int shardAnchor = -1;
			start = System.currentTimeMillis();
			for (int i = 0; i < chunks; ++i) {
				List<DBObject> os = new LinkedList<>();
				for (int y = 0; y < chunkSize; ++y) {
					DBObject o = new BasicDBObject(2)
						.append("shardAnchor", Integer.valueOf(++shardAnchor))
						.append("logLevel", logLevels[r.nextInt(logLevels.length)])
					;
					os.add(o);
					if (shardAnchor >= 7)
						shardAnchor = -1;
				}
				c.insert(os);
			}
			System.out.println("Created " + totalRecordCount + " records in " + (System.currentTimeMillis() - start) + " milliseconds");
		} else {
			System.out.println("Found " + totalRecordCount + " records; not removing or creating anything");
		}
		cursor.close();

		System.out.println("Invoking MapReduce");
		start = System.currentTimeMillis();
		MapReduceOutput mrOutput = c.mapReduce(
			"function() {emit(this.logLevel, {logLevelCount: 1});}",
			"function(k, vs) {var r = {logLevelCount: 0}; vs.forEach(function(v) {r.logLevelCount += v.logLevelCount;}); return r;}",
			null,
			OutputType.INLINE,
			null
		);
		System.out.println("MapReduce took " + (System.currentTimeMillis() - start) + " milliseconds");
		System.out.println("MapReduce result:");
		for (DBObject o : mrOutput.results()) {
			System.out.println("\t" + o.get("_id") + ": " + ((DBObject) o.get("value")).get("logLevelCount"));
		}

		System.out.println("Invoking aggregation");
		start = System.currentTimeMillis();
		AggregationOutput aOutput = c.aggregate(
			new BasicDBObject(
				"$group", new BasicDBObject()
					.append("_id", "$logLevel")
					.append("logLevelCount", new BasicDBObject("$sum", Integer.valueOf(1)))
			)
		);
		System.out.println("Aggregation took " + (System.currentTimeMillis() - start) + " milliseconds");
		System.out.println("Aggregation result:");
		for (DBObject o : aOutput.results()) {
			System.out.println("\t" + o.get("_id") + ": " + o.get("logLevelCount"));
		}
	}
}

Fazit

Das Aggregation Framework finde ich toll. Es ist extrem mächtig (siehe Referenz) und flexibel, da es als Pipeline realisiert wurde (mehrere Aggregationen in Reihe). So lassen sich Daten leicht und vor allem schnell verdichten.

Warum diese Vorteile ignorieren und stattdessen REST benutzen?

Representational State Transfer

REST-Schnittstellen erschließen sich dem Entwickler einfacher als SOAP-Schnittstellen. Anstelle der WSDL und dem Wissen um den Sinn und Zweck der darin definierten Operationen, benötigt man bei REST nur die URI der Ressource (z.B. http://www.acme.com/basedata/customers/). Um diese Ressource bearbeiten zu können, verwendet man die wohlbekannten Methoden des HTTPs:

• GET – zum Abfragen einer Ressource
  • z.B. GET http://www.acme.com/basedata/customers/4711 zum Abfragen des Kunden mit der Kundennummer 4711
• POST – zum Neu-Anlegen einer Ressource
  • z.B. POST http://www.acme.com/basedata/customers/4712 zum Anlegen des Kunden mit der Kundennummer 4712. Die Kundendaten werden im Body des HTTP-Requests übertragen.
• PUT – zum Neu-Anlegen oder Aktualisieren einer Ressource
  • z.B. PUT http://www.acme.com/basedata/customers/4713 zum Aktualisieren des Kunden mit der Kundennummer 4713 (z.B. neue Post-Adresse). Die Kundendaten werden auch hier im Body des HTTP-Requests übertragen.
• DELETE – zum Löschen einer Ressource
  • z.B. DELETE http://www.acme.com/basedata/customers/4711 zum Löschen des Kunden mit der Kundennummer 4711.
• Weiterhin existieren noch die Methoden PATCH, OPTIONS und HEAD. Siehe dazu z.B. Wikipedia

In der Java-Welt existieren eine Reihe brauchbarer Frameworks, mit denen sich RESTful-Services implementieren lassen (u.a. Spring MVC und Jersey [1]).

Vorteile von REST

Bezogen auf die Ausnutzung der Bandbreite bei der Datenübertragung ist REST leichtgewichtiger als SOAP. REST verwendet mit den Methoden direkt Bestandteile des HTTPs, mit denen die Semantik eines Requests festgelegt wird. SOAP verwendet normalerweise nur HTTP-POST-Requests. In seinem XML-Payload sind also die reinen Nutzdaten enthalten und zusätzlich alle notwendigen Meta-Daten (z.B. Name der aufgerufenen Operation). Anstelle dieses umfangreichen Payloads kann REST das schlankere JSON-Format allein für die Übertragung der Nutzdaten verwenden.

SOAP kann auch aus Sicht eines Firewall-Administrators problematisch sein, da er einem SOAP-Request erstmal nicht ansehen kann, ob er Unternehmensdaten manipulieren wird, also potentiell gefährlich ist, oder ob er nur lesend auf Daten zugreift.

Bei REST kann dazu einfach der Protokoll-Header ausgelesen werden. GET-Requests greifen lesend auf Daten zu, POST, PUT und DELETE manipulieren den Datenbestand. Auch Entwickler können davon profitieren, da man sicherheitsrelevante Mechanismen auf die Netz-Infrastruktur auslagern kann und nicht selbst implementieren muss.

Auch das Caching von Service-Ressourcen wird durch die direkte Verwendung von HTTP erleichtert. Responses auf GET-Requests können durch Webserver, wie z.B. Apache, relativ einfach gecached werden, ohne dass sich die Software-Entwickler damit auseinandersetzen müssen.

Und zu guter Letzt ist die Client-seitige Entwicklung im REST-Umfeld wesentlich einfacher. Der HTTP-Aufruf einer Ressource ist mit einem einfachen HTTP-Client möglich. Das Arbeiten gegen eine SOAP-API beinhaltet normalerweise die Nutzung spezieller Bibliotheken mit größerem Entwicklungsaufwand.

Nachteile von REST

REST bietet im Bereich der Typ-Sicherheit weniger Möglichkeiten als SOAP. Die dort normalerweise verwendete WSDL, der “Schnittstellen-Vertrag”, ist bei REST nicht vorgesehen. Das Serialisieren und De-Serialisieren ist bis heute in SOAP sehr viel einfacher als mit den gängigen REST-Frameworks.

Das Server-seitige Anbieten einer SOAP-Schnittstelle ist mit Bibliotheken, wie beispielsweise Apache CXF, wesentlich einfacher zu realisieren als eine entsprechende REST-Schnittstelle.

Fazit

Besteht die primäre Anforderung darin, dass Schnittstellen-Definitionen eindeutig und Typ-Sicherheit in jedem Fall gegeben sein muss, ist SOAP das Mittel der Wahl. Frameworks wie beispielsweise Apache CXF nehmen dem Entwickler hier viel Arbeit ab und erledigen die entsprechenden Prüfungen und Transformierungen automatisch im Hintergrund.

Doch was ist heutzutage der ausschlaggebende Faktor, mit dem man eine gut gemachte Webservice-Schnittstelle, sowohl Server- als auch Client-seitig, beurteilt?

Performance und Bandbreitennutzung. Beim Zugriff von mobilen Geräten sind diese Faktoren von essentieller Bedeutung. Bei der Kommunikation über mobile Netze kostet jedes unnötig übertragene Byte bares Geld. Dasselbe gilt für stark frequentierte Webservices, ganz unabhängig davon, über welche Art von Netzwerk die Daten abgerufen werden. Unnötig ausgenutzte Bandbreite ist unnötig ausgegebenes Geld, da kommerzielle Web-Provider und CDN-Anbieter ihre Leistungen nach Aufwand abrechnen.

Hier ist REST eindeutig überlegen und deswegen immer dann die bessere Wahl, wenn Performance der bestimmende Faktor ist.

Verweise

• [1] Ein Vergleich von Spring MVC und Jersey http://www.infoq.com/articles/springmvc_jsx-rs

Ein Portal bildet einen zentralen und persönlichen Zugangspunkt in die Informationswelt eines Unternehmens. Relevante Informationen aus Intranet und/oder Internet, Geschäftsprozessen und Applikationen werden gebündelt und einer definierten Zielgruppe über einen Webbrowser oder ein mobiles Endgerät zur Verfügung gestellt.

Wie aber findet man das richtige System, das die vielfältigen fachlichen, technischen und strategischen Anforderungen des Unternehmens optimal unterstützt?

Die Antwort finden Sie in unserem Flyer.

Thema des Abends ist: Behavior Driven Development (BDD) mit Jasmine

Bei BDD handelt es sich um es sich um eine spezielle Form testgetriebener Entwicklung, bei der die Spezifikation anhand von natürlichsprachlichen Beispielen auf ausführbare Tests abgebildet wird. Fokus liegt dabei vornehmlich auf der Sicherstellung funktionaler Anforderungen und dem Verhalten der Zielsoftware, das sich jeweils ändert, wenn man  Features hinzufügt oder ändert. Dabei ist Jasmine ein BDD-Framework, das sich im Umfeld der JavaScript-Entwicklung großer Beliebtheit erfreut.

Ich habe mich kurzfristig entschlossen, an diesem Abend einen kurzen Einführungstalk dazu zu geben.

Ziel des Abends ist es, einen Einblick in die Welt von BDD jenseits von Java zu bekommen. Daher wird es vom Format her nicht unbedingt ein formaler Abendvortrag sein, sondern es soll in lockerer Runde die Möglichkeit zum Fragen und zum Austausch über dieses Thema geben. Wer einen Laptop mitbringt, kann Jasmine praktisch in einem Hands-on in der Gruppe ausprobieren.

Es wird selbverständlich wieder für das leibliche Wohl in Form von Schnittchen und Getränken gesorgt sein.

Man kann sich sowohl bei Meetup als auch bei XING anmelden.