Vor gut einem Jahr hat mein Kollege Jo Ehm hier unsere BPMS-Scorecard vorgestellt, eine Balanced Scorecard, in der wir alle unserer Erfahrung nach wichtigen Kriterien für die Auswahl eines BPMS gesammelt haben. Mit ihr lassen sich einzelne Tools gezielt vergleichen und bewerten, um letztlich eine Entscheidung herbeizuführen. Wer schon weiß, was er will, ist mit diesem Werkzeug gut bedient.

Doch um an diesen Punkt zu gelangen, muss man sich zunächst Gedanken darüber machen, welche Art von BPM-Tool man benötigt. Solche Tools lassen sich grob kategorisieren: es gibt reine Modellierungswerkzeuge, Process Engines zur Automatisierung von Prozessen, komplette Suiten, die beides mitbringen und außerdem umfangreiche Reportingmöglichkeiten bieten und dazwischen praktisch sämtliche Spielarten. Dazu kommt, das solche Tools schnell eine veritable Investition erfordern. Umso wichtiger, sich genau zu überlegen, wie das Einsatzszenario aussieht.

Für die Zieldefinition kann man die bereits genannten Kategorieren zugrunde legen: Modellierung, Automatisierung, Reporting. Wenn Prozesse lediglich modelliert, aber nicht automatisiert werden sollen, genügt ein reines Modellierungstool. Soll dagegen der komplette Prozesslebenszyklus abgedeckt werden, ist ein Tool, das auch Möglichkeiten für Automatisierung und Monitoring bietet, sinnvoll.

Ist das Einsatzszenario definiert, gilt es, tiefer in die drei Kategorien zu leuchten und genauer zu bestimmen, welche Eigenschaften das Tool der Wahl haben soll. Sollen Modelle toolübergreifend ausgetauscht werden können? Benötigt man das BPM-Tool zur Integration verschiedener externer Systeme? Soll das Tool Möglichkeiten zur Verwaltung manueller Aufgaben bieten? Müssen KPIs für das Monitoring im BPM-Tool hinterlegt werden können? Daneben müssen noch einige allgemeine Rahmenbedingungen abgesteckt werden, etwa: Welche Technologien kommen zum Einsatz, wie wichtig sind Testmöglichkeiten?

Pauschale Antworten darauf können wir nicht geben – wohl aber die richtigen Fragen stellen. Diese haben wir nun in einem Whitepaper zur BPM-Toolauswahl übersichtlich zusammengefasst und führen interaktiv in fünf Schritten zum passenden Tool. Das Whitepaper steht auf unserer Website zum Download bereit.

Vergangene Woche hat camunda nun sein eigenes Open Source-Projekt gestartet: camunda.org. Als Fork von Activiti wird aus “camunda fox” nun die “camunda BPM Plattform”, und viele der Enterprise-Features, die bisher nicht von Activiti adressiert wurden, wandern in die neue Open Source Software (wenngleich es für Unternehmen nach wie vor eine kostenpflichtige Enterprise-Edition mit entsprechendem Support, erweiterter Qualitätssicherung und zusätzlichen Features gibt).

In diesem Zug hat auch Holisticon seine Partnerschaft mit camunda vertieft. Als qualifizierter Service-Provider unterstützen wir BPM/SOA-Projekte, die auf camunda BPM als technische Plattform setzen. Jakob Freund, Geschäftsführer von camunda, sagt dazu: “Holisticon ist ein innovatives, leistungsstarkes und zugleich sehr sympathisches Unternehmen. Wir freuen uns über die bereits bestehende, erfolgreiche Zusammenarbeit in Kundenprojekten und natürlich besonders darüber, dass wir mit Holisticon einen kompetenten Partner an unserer Seite wissen, der das camunda BPM-Projekt mit uns voranbringen und die Verbreitung im Markt unterstützen wird.”

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!

Nachdem mir am ersten Tag das Play Framework vorgestellt, Dank des Vortrages von Wesley Hales Lust auf HTML5 und JS gemacht wurde und wir zwischendurch erfahren konnten, dass auch Antwerpen unter der Woche ein Nachtleben hat, habe ich mir am zweiten Tag einen Vortrag zum Java Social JSR und dazu, wie man Webseiten schneller macht, angeschaut. Was ich dabei lernte, wird in dem folgenden Blogbeitrag vorgestellt.

Java Social JSR, it’s alive

Im Vortrag wurde von Antoine Sabot-Durand und Werner Keil eine Implementierung des Java Social JSR vorgestellt – Agorava. Mir selbst stellte sich dabei sofort die Frage, warum ich einen JSR dafür brauche. Social Media-Dienste stellen in der Regel eine schöne REST und JSON API zur Verfügung. Daher kommt natürlich die Frage auf, wozu ein Java Social JSR?

Ziel ist, generische Services für Social Media bereitzustellen, die ermöglichen, sich gegen den Dienst zu identifizieren und Nachrichten zu posten. Die aktuelle Implementierung unterstützt dabei Facebook, Twitter und Linkedin. Zusätzlich dazu wird mit dem SocialMediaXModel eine API zur Verfügung gestellt, mit der man eigene Social-Media-Dienste anbinden kann. Die Entwickler planen auch eine Anbindung von Github, Stackoverflow und Foursquare.

Präsentiert wurde die Implementierung am Besipiel Socializer, das es z.B. ermöglicht, sich mit mehreren Twitter-Accounts und Facebook gleichzeitig anzumelden. Interessant ist auch, dass sie mit ihrer API nicht das Ziel verfolgen, ein neues TweetDeck oder einen Social Media-Client zu Implementieren – es geht ihnen in erster Linie um die Verbreitung von Daten.

Mit dem SocialMediaApiHub ermöglichen sie generische Funktionalitäten über verschiedene Social-Media-Dienste hinweg. Dies wird durch mehrere Sessions erreicht.

Okay, das war der erste Teil der dreistündigen Session. Im zweiten Teil wurde es sehr technisch, und anhand von Klassendiagrammen und Code Snippets wurde auf die Implementierung der java social api eingegangen. Ja, das ist vielleicht nicht das, was man erwartet, wenn man in eine Session dazu geht, aber für mich als alten CDI-Freund war es ein schönes Praxisbeispiel, wie man die Werkzeuge von CDI in der Praxis einsetzen kann. Nebenbei haben sie auch die Funktionalität genutzt, sich eine eigene CDI-Extension zu schreiben.

Faster Websites: Crash Course on Frontend Performance

Was Ilya Grigorik in diesem Slot veranstaltete, war wirklich großes Kino. Und ich sage das als jemand, der nicht zu den Google-Fanboys gehört.

Was machte den Vortrag so außergewöhnlich? Die Herangehensweise. Ilya hatte den Vortrag in drei Teile aufgeteilt:

1. The problem
2. Browser architecture and the hood
3. Best practices with context

Zunächst ging er auf das (in vielen Vorträgen zu diesem Thema) erwähnte Web Search Delay Experiment ein. Hier wurden Webseiten von Amazon, Google etc. bewusst verlangsamt, um zu ermitteln, ab wann das Ganze den Nutzer nervt. Fakt dazu, man sollte unter 250ms bleiben, damit der Nutzer etwas als schnell empfindet. Alles, was länger als eine Sekunde dauert, führt beim Nutzer zum Kontextwechsel.

Kann ich damit nun zum Fachbereich rennen und sagen, wir brauchen Unmassen an Geld, um unsere Webseite schneller zu machen? Nein. Ähnlich dem Ansatz den Wesley Hales und auch mein Kollege Olli Ochs fahren, rät Ilya dazu, Web Performance nicht als technische Metrik zu sehen, sondern als Business-Metrik. Performante Webseiten führen zu mehr Umsatz und das muss man dem Fachbereich auch entsprechend verkaufen.

Nachdem man seinen Fachbereich ggf. überzeugt hat, muss man sich dem Problem widmen, warum die eigene Webseite überhaupt langsam ist. In der Regel steigen die üblichen Vorträge jetzt gleich bei Punkt drei von Ilyas Vortrag ein. Im Gegensatz dazu erklärt er den Zuhörern, wie das Web rein technisch funktioniert und wo man zuerst ansetzen sollte, bevor man sich an den auszuliefernden Code wagt.

Nach dem wir gelernt haben, wie das Leben eines HTTP-Requests verläuft, gibt er den ersten Tipp. Der DNS-Provider spielt eine wesentliche Rolle für die Performance einer Webseite – dort allein können schon 300 bis 400 ms verloren gehen.

Einen Ansatz, der auch zur Optimierung beitragen soll, ist das Öffnen von mehreren TCP-Verbindungen. Klingt ja erstmal gut. Interessant ist aber, dass die Verbindungen dank des TCP slow start erst einmal mit geringerer Kapazität aufgemacht werden und sich dann erst langsam hochschrauben. Ergo: offene TCP Verbindungen weiter nutzen und nicht mehrere aufmachen.

Ein konkreter Tipp für diejenigen unter uns die auf ihrem Linux-Server Root-Rechte haben: auf Lunix ab 2.6.33 updaten, dann erhöht sich der CWND (congestion window size) von 3 auf 10.

Ursache des Problems ist also nicht nur die Qualität unserer Webseiten, sondern auch, wie wir sie bereitstellen. Dass auch HTTP dazu beiträgt, dass wir noch ein paar Einschränkungen haben, zeigt er mit der Vorstellung von SPDY und HTTP 2.0.

Aktuell bedienen wir uns u.a. den folgenden Workarounds, um das Web schneller zu machen:

• wir konkatenieren Dateien
• Spriting von Bildern
• Domain sharding
• Ressource inlining

Mit SPDY könnten wir uns den Spaß sparen, doch um gleich frühzeitig ein wenig die Euphorie zu bremsen. SPDY wird aktuell nur von wenigen Browsern unterstützt. Aber auch dafür ist eine Lösung in Sicht.

SPDY macht u.a. Folgendes:

• nutzt nur eine TCP-Verbindung
• ein Request gleicht einem Stream
• Streams werden multiplext
• Streams können priorisiert werden

Mit SPDY können auch aktive Server-Pushs angestoßen werden und Informationen, die immer mitgesendet werden, wie z.B. der Header einer Seite, können gecached werden.

Alles toll, nur schade, dass es nicht von allen Browsern unterstützt wird. Doch eine Lösung ist in Aussicht: SPDY wird als Basis für den neuen HTTP 2.0-Standard genommen. D.h., all das wird kommen; wir müssen uns nur noch ein wenig gedulden.

Was nun die Browser-Architektur angeht, möchte ich hier nicht weiter ausholen. Wer noch mehr dazu wissen möchte, schaut sich am besten die Folien von Ilya zum Vortrag an.

Nachdem dann eine Stunde Werbung für Google Analytics gemacht wurde, kam er zu Punkt Drei seines Vortrages, den best practices für performate Webseiten – und das sind u.a. die folgenden:

• DNS Lookup
• Redirects vermeiden
• Weniger HTTP-Requests
• CDN einsetzen
• GZIP einsetzen
• Bilder optimieren
• Expires Headers nutzen
• ETags hinzufügen
• CSS am Anfang der Seite einbinden
• Skripte asynchron laden, wo möglich
• Skripte am Ende laden
• Minfizieren und Konkatenieren
• Auf 60 Frames per second achten
• PageSpeed Insights nutzen

Fazit

Die zwei Tage der Devoxx University Days haben sich für mich auf jeden Fall gelohnt. Ich habe gelernt, dass Cookies nicht per se böse sind, dass HTML5 und JS nach wie vor rocken, und dass man wie so oft auch beim Thema Web Perfomance unter die Haube schauen muss, um wirklich etwas zu erreichen.

Was die Devoxx angeht, werde ich definitiv versuchen, nächstes Jahr ein Ticket für die ganze Veranstaltung zu ergattern. Hochkarätige Sprecher, aktuelle Java-Themen und Vorträge in Kinosälen haben mich überzeugt.

Der Artikel in der web & mobile Developer 01/2013 zum Thema “SLM in der mobilen Entwicklung” wurde von den Holisticon-Mitarbeitern Jan Weinschenker und Sven Bunge verfasst. Er vermittelt, warum Software-Lifecycle-Management (SLM) auch für die mobile Entwicklung verwendet werden sollte. Es hilft, die Komplexität von Software beherrschbar zu machen und über verschiedene Arten von automatischen Tests die Qualität zu gewährleisten. Der Artikel “Androiden kontinuierlich integriert” der web & mobile Developer 12/2012 erklärt Continuous Integration für Android-Apps. Dieser Artikel baut darauf auf und erklärt, wie die Software-Qualität der Apps gemessen und erhöht werden kann.

Ein Themen-Überblick:

• Warum ist SLM auch für die mobile Entwicklung sinnvoll?
• Continuous Integration
• Automatisiertes Testen
  • Unit-Tests mit JUnit
  • Integrations-Tests mit Robolectric
  • BDD mit Cucumber
  • UI-Stress-Tests mit Monkey
• Bewertung von Software-Qualität
  • Statische Code-Analyse mit PMD und Findbugs
  • Einheitlicher Code-Style mit Checkstyle
  • Zusammenfassung der Ergebnisse mit Sonar
• Release-Management bei Apps
  • Warum sind Versionen wichtig?
  • Releasen mit Maven

Die Ausgabe 01/2013 der Zeitschrift ist ab jetzt im Zeitschriften-Handel verfügbar.

Vorher ist aber erst einmal Advents- und Weihnachtszeit. Daher planen wir zum Jahresende ein kleines Meetup in gemütlicher Runde. Die Teilnehmerzahl ist aus Platzgründen limitiert.

Nachdem auf dem letzten Meetup Joris Kalz (Microsoft) die Skaliebarkeit von Microsoft Azure an einem praktischen Beispiel demonstrierte und Tillmann Bielefeld (empuxa) & Andre van Hoorn (Uni Kiel) Online Performance Anomaly Detection mit Kieker vorstellten, werden Frank Thelen und ich diesmal etwas zum Thema RUM erzählen: “Rolling out Real User Monitoring at Telefónica Germany”

Diesen Vortrag haben wir beide bereits auf der Velocity Europe Conference in London gehalten.

Ein weiterer Vortag ist noch nicht eingeplant, falls sich aber noch ein Vortragender findet, dann wird sein Vorschlag sicher Wohlwollen finden. Ansonsten können wir auch einen Fishbowl veranstalten und das Jahr Revue passieren lassen.

Das Meetup findet heute, Mittwoch 19.12., ab 19:00 in unseren Räumlichkeiten statt. Anmelden kann man sich über unsere Meetup-Gruppe oder über XING.

© contrastwerkstatt / Fotolia.com

Der Begriff Software Craftsmanship ist gar nicht so leicht zu definieren. “Craftsmanship” legt eine Übersetzung mit Handwerkskunst oder Kunstfertigkeit im Kontext von Softwareentwicklung bzw. Software Engineering nahe. Stark vereinfacht geht es hauptsächlich darum, wie man qualitativ hochwertige Software herstellt. Doch was bedeutet das konkret und wie setze ich das um?

Das Software Craftsmanship Manifesto ist auf einer sehr abstrakten Ebene unterwegs. Dies gilt es in die Praxis umzusetzen. Im Konkreten gibt es zwar grundlegende Konzepte und Ideen – wie Test Driven Development und Metriken, die einzuhalten sind. Wie die Umsetzung tatsächlich geschehen kann, hängt vom jeweiligen Team und Unternehmen ab. Deswegen unterstützen wir unsere Kunden individuell dabei, Software Craftsmanship in ihrem Unternehmen einzuführen. Die Unterstützung reicht von einer Einführung in die Grundlagen und unterschiedlichsten Praktiken bis hin zum Coaching im laufenden Entwicklungsbetrieb. Lesen Sie mehr in unserem Flyer.

Web und Mobile Developer – Ausgabe 12/2012

Kontinuierlich integriert

Jan Weinschenker und Sven Bunge

web & mobile developer 12/2012

Auf diesem Blog wurde bereits in mehreren Artikeln erläutert, welche Vorteile Software-Lifecycle-Management für die professionelle Softwareentwicklung bringt. Die beschriebenen Konzepte und Verfahren lassen sich genau so auch auf die Entwicklung von Apps im Android-Umfeld anwenden.

Ein Werkzeug, das dabei eine zentrale Rolle einnimmt, ist der Build- oder CI-Server. Im Artikel von Jan Weinschenker und Sven Bunge wird beschrieben, wie ein solcher CI-Server mithilfe der freien Werkzeuge Jenkins und Maven speziell für die Android-Entwicklung aufgesetzt wird.

Weiterhin geht der Artikel auf die Vorteile des Software-Lifecycle-Managements, insbesondere im Hinblick auf die Testautomatisierung, ein.

Den kompletten Artikel lesen Sie in der web & mobile developer 12/2012, die seit dem 8.11.2012 erhältlich ist.

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