JavaSPEKTRUM Blogosphäre

Die übliche wilde Themenmischung der JavaSPEKTRUM-Blogosphäre: Diverse Cloud Computing-Varianten, Clojure als Lisp-Dialekt für die JVM und verschiedene Fundstücke – das typische Ergebnis eines Web-surfenden Geeks mit der Aufmerksamkeitsspanne eines Dreijährigen.

### Wolken

Wenn es ein Thema gibt, bei dem sich die Anbieter aktuell mit Ankündigungen überschlagen, dann ist es Cloud Computing. Tatsächlich gibt es auch hier schon wieder die in solchen Fällen üblichen Definitionsschlachten – man könnte das Gefühl bekommen, derjenige, dessen Definition sich durchsetzt, glaubt damit auch den größten Anteil vom Kuchen gewinnen zu können … Wenn wir von einer relativ unverfänglichen Definition ausgehen (Cloud Computing als “Nutzung von Rechenkapazität bei einem Dienstleister im Internet”), gibt es diverse spannende Neuigkeiten. Ãœber den aktuellen Stand bei Cloud Computing-Pionier Amazon.com informiert CTO Werner Vogels immer sehr zeitnah in seinem Blog, so z.B. über das Ende der Beta-Phase der “Elastic Computing Cloud (EC2)” und die Verfügbarkeit von Microsoft Windows. Microsoft selbst springt nunmehr ebenfalls voll auf den Zug auf und kündigt mit Azure eine eigene Cloud-Computing-Plattform an. Ãœber Googles AppEngine habe ich schon früher berichtet, ebenso wie über die vielen Dienste rund um die GData-APIs. Weniger bekannt, aber deswegen keinesfalls weniger interessant ist force.com, ein “Platform as a Service”-Ansatz des Online-CRM-Anbieters salesforce.com. Dessen Angebot steht am einen Ende eines Spektrums, auf dessen anderer Seite die eher technischen Dienste von Amazon.com stehen. Für die force.com-Plattform gibt es eine eigene Programmiersprache und IDE, zahlreiche APIs und einen Online-Store für Anwendungen, die für die Plattform entwickelt wurden und auf dieser laufen. Vielleicht lässt sich eine Parallele zwischen Amazon.com EC2 und Individualsoftware-Entwicklung auf der einen und Plattformen wie force.com und Standardsoftware wie SAP auf der anderen Seite ziehen – es gibt gute Argumente für beide Extreme, viele Varianten dazwischen und keinen Grund, anzunehmen, eine von beiden würde die andere vollständig im Markt ersetzen. In jedem Fall jedoch werden sich auch Software-Entwickler mit den Konsequenzen des Cloud Computings auseinandersetzen müssen.

### Clojure

Keine Blogosphäre ohne mindestens eine neue, mehr oder weniger abstruse Programmiersprache – es gibt Traditionen, mit denen ich auch diesmal nicht brechen möchte. Wer Java zu langweilig findet, auf die JVM aber nicht verzichten möchte, außerdem funktionale Sprachen wie Lisp mag und die in Erlang systeminhärente Unterstützung von Parallelverarbeitung schätzt, dem kann ich Clojure sehr ans Herz legen. Wie bei Lisp oder Scheme werden Clojure-Programme selbst in Clojure-Datenstrukturen ausgedrückt (mit den Lisp-typischen Klammern); es ist ein vollständiges Makrosystem enthalten; sowohl ein interaktiver Modus wie auch eine Kompilierung in Bytecode wird unterstützt. Sprachdesigner Rich Hickey begründet in einem sehr verständlichen Designdokument die grundsätzlichen Entwurfsentscheidungen, insbesondere zum Thema Parallelität: Clojure setzt auf eine strikte Trennung von Identität und Status.

Dazu muss man sich den Zusammenhang zwischen der aktuellen Hardware-Entwicklung und der steigenden Popularität funktionaler Programmiersprachen verdeutlichen. Es ist mittlerweile schon ein Allgemeinplatz, wenn man feststellt, dass unserer Rechnersysteme sich nicht mehr primär über steigende Taktfrequenzen, sondern eine steigende Parallelisierung durch mehrere Prozessorkerne weiterentwickeln. Die Programmierung von Anwendungen, die solche Multi-Core-Systeme ausnutzen, ist nicht trivial – nicht umsonst versucht man auch in der Java-Welt z.B. in EJB- oder Servlet-Containern, das Thread-Management dem Applikationsserver zu überlassen. Ideal wäre es aber, wenn nicht nur parallele Requests in einer Client/Server- oder Web-Anwendung, sondern generell alle Berechnungen ohne Zutun des Entwicklers parallelisiert werden könnten. Leider machen uns in Programmiersprachen wie C, C++ oder Java Seiteneffekte einen Strich durch die Rechnung: die Laufzeitumgebung hat keine Chance, Dinge zu parallelisieren, die wir nicht explizit dafür vorbereitet haben.

Funktionale Sprachen eignen sich deutlich besser für eine Parallelisierung, denn in ihrer puren Form gibt es keine Seiteneffekte – die Laufzeitumgebung kann also nach Lust und Laune (bzw. Anzahl und Verfügbarkeit von CPU-Ressourcen) die Aufgaben verteilen. Diesen Ansatz verfolgt auch Clojure: Werte (Status) sind grundsätzlich unveränderlich. Akademisch sind rein funktionale Sprachen interessant, in der Praxis ist jedoch schon die Ausgabe auf die Konsole ein Seiteneffekt (”echte” rein funktionale Sprachen sind daher recht nutzlos). Für die Fälle, in denen man Variablen ändern, d.h. ihnen einen neuen Status zuweisen will, setzt Clojure auf das Konzept von “Software Transactional Memory”: Von der Laufzeitumgebung parallelisierte Berechnungen greifen damit im Fall der Fälle transaktional auf gemeinsame Variablen zu.

Also: alle Programme so schnell wie möglich von Java auf Clojure umstellen? Kaum. Aber einen Blick ist die Sprache auf jeden Fall wert, nicht zuletzt wegen der exzellente Dokumentation und der sehr aktiven Community.

### Fundstücke

Aus der Rubrik “worüber ich sonst noch gestolpert bin”: Software-Entwickler, die ihren Job mit Leidenschaft ausüben (und dazu zählen natürlich alle Leser dieser Publikation), sind in der Regel nicht mit einem Mangel an Selbstbewusstsein ausgestattet, wenn es um ihre Fähigkeiten geht. Aber fast alle sind sich darin einig, dass es gewisse Dinge gibt, die man als “echter” Programmierer (und natürlich auch als echte Programmiererin) gar nicht können darf. Dazu zählt an vorderster Front die visuelle Gestaltung, sei es von Anwendungs-UIs oder Webseiten. Stefano Mazzochi befasst sich mit diesem Phänomen in zwei hervorragenden Blogposts. Im ersten erklärt er, wie man auch als normalsterblicher Geek besser zueinander passende Farben finden kann; der zweite enthält eine detaillierte und sehr verständliche Anleitung zum Design einer Webseite mit HTML und CSS.

Auch dieses Jahr gibt es für die OOP 2009 wieder ein Gemeinschaftsblog, das aus den Blogs verschiedener Teilnehmer aggregiert wird. Ein beispielhafter Beitrag, der mir persönlich aus der Seele spricht, stammt von Ralf Westphal: Er kommentiert einen Artikel von Rolf Unterberger, in dem eine Reihe von Skills aufgezählt werden, die ein Software-Entwickler heutzutage mitbringen müsse.

### Farewell

Damit sind wir wieder einmal am Ende – und zwar nicht nur dieser Ausgabe, sondern auch der Kolumne: die Blogosphären der vergangenen zwei Jahre haben Sie hoffentlich zum Verfolgen der Links motiviert (die sie auch diesmal wieder in der Online-Version unter http://www.sigs.de/blog/js/ finden), aber wenn es am schönsten ist, soll man bekanntlich aufhören. Wie immer freue ich mich über Kommentare!

REST, DDD, Content-basierte Entwicklung, das Semantic Web mit RDF und SPARQL, abgerundet mit etwas XMPP für die Würze – so lautet das Rezept für diese Ausgabe der Blogosphäre.

“Der SOAP-Stack wird im allgemeinen als ein peinlicher Fehlschlag eingestuft” – mit dieser Aussage hat Sun-Mitarbeiter und XML-Miterfinder Tim Bray sich bei den Anhängern der Spezifikationen aus dem Web-Services-Universum nicht eben beliebt gemacht. Ob man seine Meinung nun teilt oder nicht: In jedem Fall ist es rund um SOAP, WSDL und die vielen Spezifikationen aus dem WS-*-Universum relativ still geworden. Zwei mögliche Gründe drängen sich auf: 1.) Die Luft ist raus und es interessiert sich niemand mehr dafür oder 2.) die Technologien sind so ausgereift, dass man gar nicht mehr darüber reden muss. Beide sind wahrscheinlich gleich falsch: Web-Services haben mittlerweile in vielen Architekturen einen festen Platz und werden nicht einfach von heute auf morgen verschwinden, so sehr sich das die Anhänger der häufig (aber deswegen nicht unbedingt richtig) als einfacher eingestuften REST -Variante wünschen mögen. Auf der anderen Seite gibt es immer noch genügend Stellen, an denen die Web-Service-Spezifikation selbst – ganz zu schweigen von den Implementierungen – alles andere als ausgereift sind.

Wie dem auch sei, die Blogosphäre (im doppelten Sinne, als Menge aller Weblogs ebenso wie als Bezeichnung für diese Kolumne) beschäftigt sich in der Tat mehr mit den Alternativen zu Web-Services, und hier vor allem mit REST. Nicht nur der JSR 311 (JAX-RS, Java API for RESTful Web Services), die von Sun angeführt Aktivität zur Standardisierung einer API für die Entwicklung von REST-Services in Java, nähert sich der Finalisierung (inkl. der Referenzimplementierung namens Jersey ), auch Alternativen dazu werden immer zahlreicher. Dazu zählt neben der Open Source-Bibliothek Restlet , für die es auch eine eigene JAX-RS-Implementierung gibt, auch das noch sehr junge Projekt Apache Sling . Sling ist ein Web-Framework, das sich vom Grundsansatz her von Struts, JSF, Spring MVC etc. stark unterscheidet, weil es zum einen stark Content-orientiert arbeitet, zum anderen stark auf die Konformität zum REST-Ansatz geachtet wird. Letzteres ist wenig verwunderlich, denn Sling würde ursprünglich von der Firma Day Software entwickelt, bei der auch ein gewisser Roy T. Fielding , seines Zeichens Erfinder von REST, tätig ist.

Die “Content-Orientierung” ist ein interessanter Gegenentwurf zu häufigen Entwicklungsansätzen für Web-Anwendungen: hier wird häufig die transaktionale Verarbeitung nach einem klassischen Modell in den Mittelpunkt gestellt – im Prinzip also eine ähnliche Architektur, wie sie vor 15 Jahren auf Basis von Transaktionsmonitoren realisiert wurde. Der Content, also (halb-)statische Inhalte, wird in der Regel in einem anderen System verwaltet und in die Lösung integriert. Beim über OSGi modularisierten Sling steht der Content im Mittelpunkt – alles unterwirft sich dem Prinzip von Ressourcen, und wenn diese im Wesentlichen über CRUD- (Create, Read, Update, Delete)-Funktionalität verfügen müssen, ist man mit dem Framework außerordentlich schnell am Ziel. Man hat dennoch die notwendige Flexibilität, eigene Logik zu implementieren. Ein Einsatz lohnt sich also besonders dann, wenn viele Inhalte, viel CRUD-Funktionalität benötigt werden. Und in vielen Anwendungen macht dieser Ausnahmefall durchaus die Mehrheit der Anforderungen aus. Sling beinhaltet auch andere spannende Ideen, wie zum Beispiel den Einsatz von JavaScript auf der Server-Seite – und der Einsatz ein und derselben Programmiersprache für Client und Server birgt durchaus einen Reiz …

Ein anderes, häufig noch zumindest teilweise zu Unrecht als sehr akademisch betrachtetes Thema mischt JBoss-Urgestein und Java-Guru Rickard Öberg mit Content Management, REST und Domain Driven Design (DDD) zusammen: Das Semantic Web, genauer: RDF und die Abfragesprache SPARQL . Öberg hat ein Framework namens Qi4j entwickelt, das zwar auf Java 5 basiert, aber ein relativ revolutionäres Programmiermodell einführt: “Composite Oriented Development”. Kernidee ist dabei, anstelle von üblichen Klassen zusammengesetzte Einheiten – Composites – zu entwickeln, die mehrere Interfaces implementieren. Stark von Eric Evans’ DDD-Ansatz beeinflusst, steht dabei ein Domänenmodell im Mittelpunkt. Und eben dieses Modell kann Qi4j nun ohne weitere Programmierung automatisch mit einem REST-Interface versehen, das RDF (das Resource Description Framework) als Format für die Repräsentationen verwendet. (Und hier die kürzeste RDF-Einführung der Welt: anstatt immer neue, spezifische Datenstrukturen zu entwickeln, wird in RDF alles mit der gleichen Datenstruktur repräsentiert: Irgendetwas steht in irgendeiner Beziehung zu irgendetwas anderem – und alles kann ein “Irgendetwas” sein, sogar eine solche Aussage selbst). SPARQL – ein rekursives Akronym für “SPARQL Protocol and RDF Query Language” – ist eine Abfragesprache, eine Art SQL für RDF. Wie auch immer man Qi4j sonst einschätzt: auf jeden Fall erreicht man in kurzer Zeit eine sehr hohe Dichte an neuen und spannenden Technologien.

Sie können REST schon nicht mehr hören? Einverstanden: REST ist Schnee von gestern – das zumindest suggeriert der Titel “Beyond REST? Building data services with XMPP” einer Präsentation von Evan Hanshaw-Plath und Kellan Elliot-McCrea. Tatsächlich schlagen die beiden Herren mit den komplizierten Name nicht vor, HTTP oder REST abzulösen, aber sie beschreiben sehr detailliert, wann das für viele Fälle gut geeignete Modell an seine Grenzen stößt und wie das offene Messaging-Protokoll XMPP – ursprünglich konzipiert für Instantmessaging, genauer: Jabber – in die Bresche springen kann. Welche der Kommunikations- bzw. Integrationsvarianten – Web-Services, REST, XMPP oder vielleicht AMQP – die “beste” ist, lässt sich nur im Kontext der involvierten Systeme und Partner beantworten. Was uns wiederum zu der alten Weisheit bringt, dass man am besten fährt, wenn man das richtige Werkzeug einsetzt, anstatt mit einem Standardhammer ausgestattet alles zum Nagel zu erklären …

Wie immer finden Sie die Online-Variante der Blogosphäre unter http://www.sigs.de/blog/js/

Nicht nur die übliche Ansammlung mehr oder weniger exotischer Programmiersprachen, sondern Skalierbarkeit und Performanz sind diesmal die Themen unserer Blogosphäre. Und nach dem wir mit der Kenntnis von Microblogging schon belegen, dass wir total “in” sind, erfinden wir gleich auch noch eine neues Akronym: CSDD.

Schon in der letzten Kolumne habe ich eine Lanze für die Kenntnis von mehr als einer Programmiersprache gebrochen, ohne mich auf eine davon festzulegen. Das möchte ich auch diesmal aufrecht erhalten. Aber falls Sie nach einer umfassenden Liste von Argumenten für und wider “klassische” Sprachen wie Java auf der einen und “dynamische” Sprachen wie JavaScript (sic!) oder Ruby auf der anderen Seite suchen, möchte ich Ihnen einen sehr langen und ausführlichen Beitrag des Google-Mitarbeiters Steve Yegge mit dem Titel “Dynamic Languages Strike Back” ans Herz legen, in dem er seine Meinung darstellt (Kurzfassung: dynamische Sprachen sind die Zukunft, gewöhnen Sie sich dran). Aber ebenso interessant ist die Erwiderung seines Kollegen Cedric Beust: Unter der Ãœberschrift “Return of the statically typed languages” bemüht er sich, Yegges Argumente zu entkräften. Lesenswert sich auch die Kommentare zu beiden Artikeln, ebenso wie die Reaktion von anderen Bloggern wie z.B. Ola Bini (”A New Hope: Polyglotism”). Yegge ist übrigens nach anfänglich großer Skepsis ein JavaScript-Fan, genauer gesagt, ein Fan von Rhino, der JavaScript-Implementierung für die JVM, die auch Bestandteil von Java 6 ist. Wem also die Auswahl mit Groovy, JRuby, Jython und Scala noch nicht groß genug ist: vielleicht überzeugt das Argument, dass man in einer Web 2.0-Ajax-Social-Computing-Cloud-Anwendung (ein Scherz! Verzeihung) auf Client- und Server-Seite die gleiche Programmiersprache verwenden kann? Neu ist die Idee nicht unbedingt – serverseitiges JavaScript gab es bei Netscape (sagt Ihnen das noch etwas?) schon 1996.

Die Skalierbarkeit eines Systems hängt von seiner Architektur ab. Die Programmiersprache spielt dabei eine eher untergeordnete. Anders verhält es sich mit der Performanz, auf die die gewählte Sprache einen sehr starken Einfluss hat. Aber in vielen Anwendungen kommt es vielmehr darauf an, eine größere Anzahl paralleler Benutzer bedienen zu können, mit angemessenen Steigerungen in der Hardware-Ausstattung. Ob ein Request eines einzelnen Benutzers dabei nun in 50, 200 oder 300 Millisekunden abgewickelt wird, ist eher sekundär (zumal ein erheblicher Anteil der tatsächlichen Antwortzeit häufig für den Datentransfer über das Netz verloren geht). Skalierbarkeit und Performanz sind also orthogonale Themen.

Diese Einsicht ist jedoch nicht sonderlich verbreitet. Zwei Blog-Postings des vergangenen Monats beschäftigen sich mit dem – vermeintlichen – Verhältnis von Programmiersprache und Skalierbarkeit. Peter Williams bringt es auf den Punkt: Java skaliert nicht besser oder schlechter als jede andere allgemein einsetzbare Programmiersprache; es kommt darauf an, wie man sie einsetzt. Der JRuby-Entwickler Ola Bini berichtet in seinem nicht ganz ernst gemeinten Beitrag von der vergeblichen Suche nach der Skalierbarkeits-Implementierung, die er in seine Programmiersprache gerne einbauen würde.

Während man Ruby vorwirft, nicht skalierbar zu sein, hat Scala die Skalierung ja schon in den Namen eingebaut – so könnte man zumindest meinen. In Wirklichkeit jedoch meint Scala-Erfinder Martin Odersky etwas anderes: “Seine” Programmiersprache eignet sich sowohl für kleine Skripte wie auch für riesengroße Systeme, wobei für letzteres der Beweis noch aussteht. Ãœberhaupt, Scala – ich hatte schon begonnen, an meinen intellektuellen Fähigkeiten zu zweifeln, als ich im oben bereits erwähnten Rhino-Artikel über folgende Anekdote stolperte: Steve Yegge berichtet von einem Doktoranden mit dem Schwerpunkt Programmiersprachen, der großer Fan von Haskell und ML ist und beim ersten Blick auf Scala zugab, ein wenig eingeschüchtert zu sein … offensichtlich bin ich also damit nicht allein. Aber wer weiß, vielleicht ist der Eindruck der übergroßen Komplexität nur auf mangelndes Wissen über diese Sprache zurückzuführen.

Ebenso wie Odersky bei Skalierbarkeit weniger über die Laufzeitaspekte als über die Anwendbarkeit in der Entwicklung spricht, lässt sich auch Performanz nicht nur zur Laufzeit, sondern auch zur Entwicklungszeit betrachten. Wenn Sie vor der Wahl stehen, ein System mit höherer Performanz zu entwickeln – sagen wir, in der Hälfte der Zeit – und dafür zu “bezahlen”, indem sie später auf gleicher Hardware nur eine halb so gute Laufzeitperformanz haben: Wäre es Ihnen das wert? Wahrscheinlich schon, wenn die Kosten für die doppelte Hardware deutlich geringer sind als die für die Entwicklung. Dies wird häufig, aber nicht immer der Fall sein – es kommt halt, wie immer, ganz darauf an …

Das aktuell in der Blogosphäre am meisten diskutierte Beispiel für ein Skalierungsproblem ist Twitter, ein Microblogging-Service, dessen Sinn man durchaus in Frage stellen darf, sich aber trotzdem mittlerweile so enormer Popularität erfreut, dass er massive Skalierungsprobleme hat. Große Wellen schlug die Theorie, das Problem liege im eingesetzten Ruby on Rails-Framwork, popularisiert von der Boulevard-Zeitung der Startup-Szene, dem Techcrunch-Blog von Michael Arrington und von Twitter-Gründer Evan Williams stilgerecht in einer Twitter-Nachricht bestritten. Während Dare Obasanjo sich schon allein darüber bestürzt äußert, dass Twitter keine Messaging, sondern eine klassische, datenbankbasierte Web-Architektur hat, klärt ein Blogposting der Twitter-Entwickler selbst, dass sogar nur eine einzige MySQL-Instanz eingesetzt wird. Über Skalierungsprobleme muss man sich dabei in der Tat nicht wundern …

Ich sehe meine wenig provokante Theorie bestätigt: Gute ebenso wie schlechte Systeme lassen sich mit jeder Programmiersprache und -plattform realisieren, und keine Technologie wird über eine architekturelle Schwäche hinweg helfen. Gesunder Menschenverstand ist gefragt – nicht mehr und nicht weniger. Vielleicht eine Gelegenheit für einen neuen Trend: Common Sense-Driven Development – kurz: CSDD?

Haben Sie es sich mit “Ihrer” Haus-und-Hof-Programmiersprache gemütlich gemacht? Vielleicht ist die Zeit gekommen, sich neu und breiter zu orientieren – glaubt man zumindest dem Tenor zahlreicher Blog-Postings, stehen wir vor der Zeit der “polyglotten Programmierer”.

EJBs sind vollkommen unbrauchbar; nur blutige Anfänger oder BWLer programmieren in Visual Basic; statisch geytpte Sprachen sind ein Relikt des vergangenen Jahrhunderts; Web-Services und die vielen WS-*-Standards ertrinken in ihrer eigenen Komplexität — bei welcher dieser Aussagen haben Sie zustimmend genickt, bei welcher die Stirn gerunzelt? Mit diesem Thema beschäftigt sich .NET- und Java-Guru Ted Neward. Es geht dabei gar nicht darum, welche dieser Aussagen nun richtig ist (oder ob überhaupt eine davon richtig ist), vielmehr liegt ihm am Herzen, dass wir uns Mehrheitsmeinungen nicht automatisch zu eigen machen, sondern kritisch hinterfragen sollten. Interessant an seinen Beispielen ist, dass sie schon bei der Betrachtung aus deutscher (oder deutschsprachiger?) Perspektive zeigen, wie unterschiedlich derartige Wahrnehmungen sind. So ist EJB, auch in den immer noch weit verbreiteten 2.x-Versionen, in unserem Umfeld häufig vertreten – man macht sich, so ist zumindest meine Erfahrung, in keiner Weise lächerlich, wenn man eine Lösung auf Basis dieser Architektur vorschlägt. Ganz anders die Reaktion schon in den Benelux-Staaten oder Groß-Britannien: dort wird man bei der beiläufigen Erwähnung von EJB angesehen, als habe man einen gemeinsamen Nacktspaziergang vorgeschlagen … dabei hat Ted Neward zweifelsfrei recht: es gibt nahezu keine Technologie, die nicht ihren Platz hätte – und Denkverbote helfen niemandem.

Auch aus meiner Lieblingsabteilung “wildes Sprachgemenge” gibt es Neues zu berichten. Von Ola Bini, einem der Core-Entwickler der JVM-Variante von Ruby, JRuby, kommen gleich zwei interessante Neuigkeiten. Zum Einen hat er – halten Sie sich fest – das Java-API von Erlang OTP benutzt, um eine Erlang-Integration für Ruby zu implementieren. (Mein Lieblingszitat: “There is no erlang.rb yet, so I made one.“). Damit können Erlang-Prozesse in Ruby implementiert werden und auf der JVM ablaufen … Eine Spur weniger exotisch und sehr praxisrelevant ist JTestR. Dabei handelt es sich um eine Menge von Ruby-Bibliotheken für Unit-Testing und Behavior Driven Development, eine Art Weiterentwicklung von Test Driven Development – gedacht zum Testen von Java-Code. Tests für Java-Code können damit sowohl in JRuby geschrieben werden (was sie sehr viel übersichtlicher macht als ihr Java-Äquivalent) oder aber in der eigenen Story-Sprache des Ruby RSpec-Frameworks (das meiner unmaßgeblichen Meinung nach allein schon ein guter Grund für den Einsatz von Ruby ist).

In der Tat lohnt es sich zu hinterfragen, wie viel Code, der nicht in Java implementiert ist, in typischen Enterprise-Anwendungen ohnehin schon enthalten ist – die Grenzen zwischen Programmen, Konfiguration und Daten sind schließlich fließend. Eine Ablaufbeschreibung, die Variablen- bzw. Klassennamen aus dem Quellcode referenziert, ist auch in ihrer deklarativen Form durchaus mit einiger Berechtigung als Programmcode zu bezeichnen. Oder versionieren Sie Ihre struts-config.xml etwas nicht? Warum also sollte man kein Problem damit haben, halb gare, oftmals schlecht spezifizierte ad-hoc-Sprachen zu akzeptieren und sich andererseits gegen vollwertige, etablierte Programmiersprachen sperren? Vielleicht besteht der richtige Weg zum “Einschmuggeln” von Ruby oder anderen dynamischen Sprachen wie Groovy, Python, Jython oder anderen darin, sie als Konfigurationsdaten zu etikettieren …

Von Ola Bini stammt auch eine Klassifizierung von Programmiersprachen anhand ihrer Eignung für unterschiedliche Schichten einer Applikation. Er unterscheidet zwischen der stabilen, untersten Schicht einer Applikation (einem eher kleinen, aber zentralen Bestandteil), der dynamischen Schicht, die den Großteil der Anwendungslogik beherbergt, und schließlich der Domain-Schicht. Für den stabilen Teil sieht er statisch getypte Sprachen wie Java oder Scala als perfekt geeignet an, für die dynamische Schicht JRuby, aber auch Rhino (Javascript für die JVM) oder Jython; die Domain-Schicht schließlich ist der natürliche Ort für DSLs (Domain Specific Languages, Domänen-spezifische Sprachen). Ob nun genau diese Aufteilung die richtige ist, sei dahingestellt – bemerkenswert ist aber, dass Ola Bini, ebenso wie die Entwickler anderer Sprachen, für “seine” Sprache keinen Absolutheitsanspruch erhebt und sie stattdessen als eine von vielen auch gleichzeitig sinnvollen Optionen sieht.

Ob Groovy, Python/Jython, Ruby/JRuby, Erlang, Scala oder Scheme: Ein Blick über den Tellerrand lohnt sich in jedem Fall. Klar ist aber auch, dass ein wildes Sprachgemenge (XML-Konfigurationsdialekte zählen mit!) zu babylonischer Verwirrung führen kann und man die Anzahl unterschiedlicher Sprachen pro Projekt beschränken sollte – wo genau die Grenze liegt, ist Ermessensfrage.

Zwei weitere spannende Entwicklungen haben für zahlreiche Reaktionen gesorgt: Die Plattform-Neuigkeiten von Google und Amazon.com. Mit “AppEngine” hat Google eine auf Python basierende Programmierumgebung vorgestellt (die Unterstützung weiterer Sprachen ist in Planung); Anwendungen, die damit entwickelt werden, dürfen nur über eine eingeschränkte Menge an APIs auf ihre Umgebung zugreifen – sind dafür aber auf der Google-Plattform lauffähig. Bis zu einem recht großzügigen Limit (z.B. 10GB eingehenden und ausgehenden Datenvolumens, 2000 E-Mails pro Tag, 500 MB Speicherplatz) bleibt die Nutzung kostenfrei, danach fallen nutzungsabhängige Kosten an. Hardware- und Infrastrukturkosten werden somit variabilisiert – ein ideales Modell für Startups. Amazon.com stellt mit zahlreichen Diensten (z.B. SimpleDB, SQS, S3) schon seit geraumer Zeit ähnliche Dienste zur Verfügung. Nahezu zeitgleich mit der Google-Ankündigung wurde eine der wesentlichen Einschränkungen des EC2-Dienstes aufgehoben: Dieser Dienst erlaubt das Betreiben von virtuellen Maschinen auf der Amazon-Infrastruktur, nun auch inklusive “normalen” persistenten Speicherplatzes. Schöne neue Welt – andere kümmern sich um die Plattformprobleme, Anwendungsentwickler können sich auf die Fachlichkeit konzentrieren. Allerdings nicht ohne Hintergedanken: so darf man bei Google seine Benutzer gern über einen Google-Account identifizieren, in einer Web 2.0-Welt, in der die registrierten Benutzer oft den zentralen (wenn nicht sogar einzigen) Wert einer Anwendung darstellen, eine durchaus kritische Entscheidung …

Die Online-Version der Blogosphäre finden Sie wie immer unter http://www.sigs.de/blog/js/.

In dieser Ausgabe der Blogosphäre beschäftigen wir uns ausnahmsweise mit eher geschäftlichen Aspekten … zumindest am Rande: Gleich drei große Akquisitionen bzw. Merger laden zum Kommentieren geradezu ein: Sun kauft MySQL, Oracle kauft BEA, Microsoft macht Yahoo! Avancen.

Meine Lieblingsanalogie zum potenziellen Microsoft/Yahoo!-Merger liefert der Journalist Daniel Lyons, der seit geraumer Zeit ein Weblog als “Fake Steve Jobs” führt (übrigens Pflichtlektüre für jeden Mac-Liebhaber oder -Hasser): Der Microsoft/Merger sei vergleichbar mit der Idee, den Zweiten und Dritten beim 100m-Lauf an den Beinen zusammenzubinden und ein neues Rennen zu verlangen, im Glauben, beide zusammen seien nun schneller … Wie dem auch sei, widmen wir uns eher den für die Java-Gemeinde spannenderen Entwicklungen.

Sun hat den Datenbankanbieter MySQL AB, nach eigenen Angaben Anbieter der populärsten Open Source-Datenbank der Welt gekauft - für den stolzen Preis von einer Milliarde US-Dollar. Die Hauptmotivation scheint zu sein, dass Sun die eigene Position im als zukunftsträchtig empfundenen Web 2.0-Markt stärken möchte - MySQL als Teil des “LAMP-Stacks” (Linux, Apache, MySQL und Perl/PHP) ist hier verbreiteter als Java. Die Sun-Geschichte von Software-Akquisitionen ist jedoch nicht eben ruhmreich: Wer erinnert sich noch an Forté, NetDynamics oder iPlanet? Zugegebenermaßen ist die Open-Source-IDE NetBeans immer noch weit verbreitet, die Sorge um MySQL wahrscheinlich eher unbegründet. Die offizielle Meinung von Sun findet man - ganz Web 2.0-konform - im Blog von Sun-Chef Jonathan Schwartz.

Am interessantesten jedoch erscheint die Akquisition von BEA durch Oracle (erwartete Größenordnung des Kaufpreises: 8,5 Milliarden US-Dollar), bringt sie doch große Unruhe in den Markt der J2EE- bzw. Java EE-konformen Applikationsserver (und in geringerem Maße in die Welt der SOA-Produkte). Mit Oracle auf der einen und IBM auf der anderen Seite stehen sich zwei Giganten gegenüber, die von der Datenbank bis zum Applikationsserver und zur SOA-Suite alles bieten bzw. bieten möchten - und aller Wahrscheinlichkeit beide sehr geringes Interesse daran zeigen werden, mit den Produkten des jeweils anderen zu interoperieren. BEA- und Oracle-Kunden warten gespannt auf die Entscheidung, welcher Applikationsserver (Weblogic oder OC4J) und welcher SOA-Stack (AquaLogic oder Oracle SOA Suite) am Ende übrig bleiben wird. Für viele große Kunden einer Kombination aus BEA-, IBM- und Oracle-Produkten wird sich die Frage stellen, ob man dauerhaft den Applikationsserver des Einen mit der Datenbank des Anderen im Hintergrund betreiben möchte …

Was bedeutet das für den Java EE-Standard? Folgt man der Meinung von Antonio Goncalvez, hat es Java EE schon schwer genug: Zwar ist der J2EE-Nachfolger ohne Frage leichtgewichtiger und sehr viel einfacher zu benutzen als sein Vorgänger, aber er leidet unter mehreren Problemen: Er kommt zu einem Zeitpunkt, zu dem viele Endanwender schon auf Alternativen gesetzt haben (typisches Beispiel: die Kombination aus Spring und Hibernate), aus Gründen der Abwärtskompatibilität wird der komplette EJB 2.1-Ballast immer noch “mitgeschleppt”, für EJB 2-Entwickler ist der Wechsel zu EJB 3 ähnlich groß wie zu Alternativen … kombiniert man diese durchaus nicht unberechtigte Kritik mit der Zukunft der großen kommerziellen Applikationsserver, liegt die Frage nah, wie relevant diese Standards noch sind. Die Akzeptanz des Spring-Frameworks leidet sicher nicht darunter, dass es dem Java EE-Standard nicht folgt - nicht zuletzt belegt durch das gerade frisch erfolgte 10-Millionen-Dollar-Investment in die Firma hinter Spring, SpringSource (früher Interface21). JBoss missioniert Seam, ein zwar auf Java EE aufsetzendes, letztlich aber proprietäres Framework für die Anwendungsentwicklung. Als Hüter der Standards bleibt dauerhaft vielleicht nur der mittlerweile sehr gute, aber immer noch recht wenig verbreitete Glassfish-Server von Sun übrig.

Vielleicht ist diese Entwicklung aber auch genau die richtige: anstelle eines CDD (kennen Sie nicht? Kurzform für “Committee-Driven Design“) werden Lösung vorzugsweise als Open Source-Implementierung veröffentlicht, müssen sich in der Praxis beweisen und setzen sich durch, wenn sie es verdient haben - um dann vielleicht im Nachhinein formal standardisiert zu werden. Und vielleicht verlassen wir uns nur deswegen so häufig auf Standards, weil wir vermeiden möchten, uns festzulegen. Mit zweifelhaftem Erfolg - wann haben Sie zum letzten Mal tatsächlich Ihre Datenbank oder Ihren Applikationsserver ausgewechselt? Meiner Meinung nach sollten wir uns vielmehr auf die Interoperabilität zwischen Applikationen als auf die Portabilität der Applikationen selbst konzentrieren.

Wie immer freue ich mich über Ihre Kommentare, die sie uns bei der Online-Version dieses Beitrags unter http://www.sigs.de/blog/js/ hinterlassen können.

Nachdem wir uns in den letzten Jahren schon daran gewöhnt hatten, dass die tatsächlichen oder empfundenen Vor- und Nachteile unterschiedlicher Programmiersprachen bestenfalls von akademischem Interesse zu sein schienen und man mit einer Sprache wie Java oder C# sehr gut auskommen konnte, erleben wir eine echte Renaissance der Vielfalt. Programmiersprachen wie Perl, Python oder Ruby, ursprünglich bewusst als “Skriptsprachen” für einfache Aufgaben positioniert, werden nun als “dynamisch” bezeichnet — und es ist ja ganz klar, das etwas Dynamisches besser sein muss als etwas Statisches … Die Verfechter von mehr oder minder typsicheren Sprachen wie C++, Java und C# fragen sich, was schlecht daran sein soll, Fehler schon beim Kompilieren zu bemerken, während die “Gegenseite” über die Geschwätzigkeit, die durch die Notwendigkeit zur Typdeklaration entsteht, den Kopf schüttelt.

Auch unsere JavaSPEKTRUM-Blogosphäre spiegelt die aktuelle Diskussion wieder — berichtet habe ich hier neben (natürlich) Java schon über Ruby, Perl, Python, Scala, Erlang, Lisp, Scheme und Smalltalk. Wem diese Auswahl noch nicht reicht, dem kann ich noch [Lua](http://www.lua.org/), eine hochperformante Skriptsprache aus Brasilien ans Herz legen. Lua ist dynamisch getypt und für die Einbettung in Anwendungen vorgesehen; verwendet wird Lua unter anderem in [Adobe Lightroom](http://labs.adobe.com/technologies/lightroom/) und im Online-Spiel [World of Warcraft](http://www.worldofwarcraft.com/) (aber auch in vielen anderen mehr oder weniger bekannten Anwendungen). Lua gibt es bereits seit 1993, die aktuelle Version ist 5.1. Meine zweite Neuvorstellung, [”Nu”](http://programming.nu/), ist da schon etwas neuer, quasi noch im Säuglingsstadium: Die [Willkommensseite](http://programming.nu/posts/2007/10/01/welcome) auf der Nu-Website stammt vom 1. Oktober 2007. Nu ist eine interpretierte, objektorientierte Sprache mit Lisp-Syntax und Ruby-Anleihen, die in [Objective-C](http://de.wikipedia.org/wiki/Objective-C) implementiert ist (und aktuell daher nur unter Mac OS X lauffähig ist). Falls Sie wider Erwarten Objective-C nicht zuordnen können: Das wiederum ist die Programmiersprache, in der die aktuellen Mac OS X-Frameworks (”[Cocoa](http://developer.apple.com/cocoa/)”) und die meisten neuen Mac-Anwendungen implementiert sind, eine Mischung aus C und Smalltalk. Auch Objective-C hat eine große Fangemeinde, wirkt aber in mancher Beziehung etwas archaisch, z.B. weil à la C und C++ Speicher vom Programmierer selbst verwaltet werden muss. “Nu” bietet einen sehr direkten Zugriff auf Cocoa und stellt damit eine interessante Alternative dar (oder wird diese vielleicht einmal darstellen, wenn es “erwachsen” wird). Und eins ist sicher: Wenn Sie in Nu programmieren, sind Sie sicher der interessanteste Gesprächspartner auf der nächsten Party. (OK, auf einer ganz bestimmten Art Party … aber lassen wir das.)

Hinter der Beschäftigung mit unterschiedlichsten Programmiersprachen steckt jedoch auch ein anderer als ein rein akademischer Sinn: Natürlich sind alle Sprachen im Prinzip austauschbar (sofern sie Turing-vollständig sind — aber das ist nun wieder akademisch): Jedes beliebige Programm können Sie prinzipiell in Assembler, C++, Java oder COBOL realisieren. Das bedeutet aber nicht, dass die Aufgabe die gleiche ist — jede Sprache hat andere Stärken, und gerade die eher als exotisch empfundenen Außenseiter werden gerade deswegen im Moment wiederentdeckt. [Eine sehenswerte Präsentation](http://www.parleys.com/display/PARLEYS/The+future+will+be+about+programming+languages) von .NET- und Java-Guru [Ted Neward](http://blogs.tedneward.com/) dazu finden Sie bei [Parleys.com](http://www.parleys.com/).

Das beste Beispiel für eine Sprache, die aus diesem Grund gerade einen echten “Hype” durchläuft, ist Erlang. Die Stärke von Erlang liegt vor allem in der Unterstützung einer leichtgewichtigen Multi-Prozess-Architektur. Da mittlerweile sogar im Low-End-Bereich Systeme mit mehr als einem Prozessorkern zur Norm werden und im High-End-Bereich abzusehen ist, dass Leistungssteigerungen eher über zusätzliche Prozessoren als über eine weitere Erhöhung der Taktfrequenzen erfolgen wird, stellt sich die Frage nach der effizienten Parallelisierung von Programmen. Ein interessantes Experiment dazu betreibt aktuell [Tim Bray](http://www.tbray.org/ongoing/): Unter dem Namen “[WideFinder](http://www.tbray.org/ongoing/When/200x/2007/09/20/Wide-Finder)” versucht er, ein kleines Ruby-Skript, das die Log-Dateien seines Web-Servers durchsucht, möglichst effizient mit Hilfe unterschiedlicher Ansätze zu implementieren. Zumindest in der Theorie sollte sich durch die Parallelisierung der Verarbeitung ein erheblicher Performance-Gewinn erzielen lassen.

[Seine Implementierung in Erlang](http://www.tbray.org/ongoing/When/200x/2007/09/21/Erlang) [leidet unglücklicherweise](http://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang) unter Schwächen der Standard-Bibliotheken im Regexp- und Ein-/Ausgabebereich, aber da es sich bei Tim Bray um einen sehr populären Blogger handelt, lassen Alternativlösungen nicht lang auf sich warten. [Pete Kirkham](http://www.tincancamera.com/blog/) liefert [eine Implementierung in C++](http://www.tincancamera.com/blog/2007/09/wide-finder-parallelism-and-languages.html), Microsoft-Guru und SOAP-Vater [Don Box kontert mit C#](http://www.pluralsight.com/blogs/dbox/archive/2007/10/09/48719.aspx). Die [erste Erlang-Lösung](http://steve.vinoski.net/blog/2007/09/23/tim-bray-and-erlang/) von CORBA-Guru [Steve Vinoski](http://steve.vinoski.net/blog/) funktioniert am besten mit 2400 (!) Erlang-Prozessen, liest allerdings die gesamte Datei in den Speicher. [Seine verbesserte Lösung](http://steve.vinoski.net/blog/2007/09/29/more-file-processing-with-erlang/) beseitigt dieses Problem. Martin Probst liefert [die Scala-Variante](http://www.martin-probst.com/2007/09/24/wide-finder-in-scala/), [Santiago Gala](http://memojo.com/~sgala/blog/2007/09/29/Python-Erlang-Map-Reduce) verwendet Python und den bereits in der letzten Kolumne erwähnten [MapReduce](http://labs.google.com/papers/mapreduce.html)-Algorithmus. Natürlich gibt’s auch eine [Alternative in Lua](http://thread.gmane.org/gmane.comp.lang.lua.general/42142/focus=42168). [Sehr schön auch die Variante](http://www.tbray.org/ongoing/When/200x/2007/09/27/WF-Meta#c1191270394.675213), die die Aufgabe mit Standard-Unix-Kommandos und der Shell löst (und dreimal so schnell wie die Ruby-Ausgangsversion ist).

Sollten wir nun alle unsere Programmiersprache durch Erlang (oder eine der Alternativen) ersetzen? Sicher nicht — aber wie Tim Bray [sehr schön formuliert](http://www.tbray.org/ongoing/When/200x/2007/09/27/Beautiful-Erlang): “This stuff is pure brain candy.”

In diesem Sinne — Süßigkeiten fürs Gehirn — ist auch unser eigener Wettbewerb zu sehen, den wir zur OOP 2008 ins Leben gerufen haben: In unserem großen “Dynamic Language Shootout” lassen wir eine ach so altmodische Java-Lösung gegen Ihre Alternative in der dynamischen Programmiersprache Ihrer Wahl antreten. Im Pflichtteil gilt es, zunächst eine korrekte Lösung für unsere Aufgabe (eine Art Scrabbleâ„¢-Variante) zu liefern. In der Kür kommt es nur auch auf den wichtigsten objektiv selbstverständlich exakt zu bemessenden Faktor an: _Coolness_. Wir freuen uns auf Ihre Einsendungen — neben Ruhm und Ehre gibt es Sachpreise und natürlich die Teilnahme an der Konferenz selbst zu gewinnen. Wenn das kein Grund ist, [die Online-Version dieser Kolumne](http://www.sigs.de/blog/js/) für den [Link auf die Wettbewerbs-Website](http://www.sigs-datacom.de/sd/kongresse/oop_2008/index.php?cat=dls_competition) zu bemühen …

Mashups als EAI 2.0, Atom, REST, Hadoop, Jabber und Erlang/OTP — dieses Mal wagen wir mit der Blogosphäre einen Blick in die Kristallkugel.

Sam Ruby zeigt, wie man auch ohne XML und SOAP elegant “Web Services” bauen kann. Der Hintergrund: Ruby pflegt eine Variante der Open Source-Software “Planet” namens “Venus“, die zur Aggregation von News-Einträgen im Atom- und RSS-Format dient. (Ãœbrigens sehenswert: Beispiele für “Planeten”, die diese Software benutzen, sind Planet Apache oder der Planet OOP 2007). Ein solcher Planet “abonniert” Newsfeeds von Blogs oder beliebigen anderen Seiten, und die Liste dieser Abonnements wird in einer Datei gepflegt. Das ist natürlich wenig benutzerfreundlich, gerade wenn mehrere Personen die Liste der Subscriptions gemeinsam verwalten möchten. Die Lösungskomponenten: 1.: Google Spreadsheets, die Online-Variante der allseits beliebten Tabellenkalkulationsprogramme, 2.: das Google API, das in diesem Fall auf Bedarf einen einfachen CSV-Export produziert und 3. ein paar Zeilen Python, die den eingebauten CSV-Parser nutzen — fertig ist die Integration einer verteilten, kollaborativen Anwendung … “Mashups” nennt das der Web 2.0-Fachmann, und EAI-Guru Gregor Hohpe fragt sich, ob Mashups vielleicht EAI 2.0 sind.

Die APIs von Google für die “Office”-Anwendungen (Calendar, Notebook, Spreadsheet und Documents List) unterstützen natürlich auch XML, insbesondere das Atom-Format bzw. -Protokoll (AtomPub). Letzteres ist mittlerweile ebenfalls kurz vorm offiziellen RFC-Status und damit ein “richtiger” Internet-Standard. Was das hier in der Blogosphäre zu suchen hat? Sowohl das Atom-Format als auch AtomPub sind ursprünglich einmal gestartet worden, um ordentlich standardisierte Nachfolger für RSS und die vielen mehr oder weniger brauchbaren Weblog-APIs zu erstellen. Dass sich deren Anwendung auf immer mehr Applikationstypen ausdehnen würde, hätten sich damals nur wenige träumen lassen. Wir statten in der aktuellen Projektarbeit unsere Anwendungen mittlerweile immer häufiger mit Atom-APIs aus und können diesen Ansatz nur empfehlen …

Von Sam Ruby stammt ein weiterer Impuls für eine interessante Blog-Diskussion: in einem Beitrag prognostiziert er einer Reihe von Technologien eine glorreiche Zukunft. Das ist nicht das erste Mal: einige “Hypes” hat er schon sehr früh vorhergesagt, vor zweieinhalb Jahren: REST, Ajax, Continuations, Ruby on Rails und GreaseMonkey. Mindestens für REST, Ajax und Ruby on Rails hat sich seine Prophezeiung als durchaus verlässlich erwiesen; GreaseMonkey, ein Plugin für Firefox, dass die transparente Modifikation von Webseiten erlaubt, ist noch eher unbekannt (aber einen Blick wert!). Closures, sozusagen Continuations für Arme, finden wahrscheinlich Eingang in eine der nächsten Java-Versionen.

REST ist in Sam Rubys neuer Liste immer noch enthalten; neu dazugekommen sind Hadoop, Erlang/OTP, Jabber und Microformats.

Hadoop ist ein Open Source-Projekt bei Apache, das das von Google erfundene Programmiermodell “MapReduce” in Java umsetzt. Selbiges erlaubt es, mit Hilfe einer einfachen Abstraktion sehr große Datenmengen zu bearbeiten. Dazu implementiert man eine map-Funktion, die eine Schlüssel-Wert-Liste in Segmente aufteilt und eine reduce-Funktion, die die Zwischenergebnisse für den gleichen Schlüssel wieder zusammenführt. Die Implementierung ist nun in der Lage, die Aufgabe massiv zu parallelisieren. Und zwar wirklich massiv - Google-massiv, sozusagen. Hadoop implementiert sowohl MapReduce als auch ein GoogleFS-ähnliches Dateiystem namens HDFS (Hadoop File System).

Ãœber die aus dem Telekommunikationsumfeld stammende, verteilte Programmiersprache Erlang habe ich schon in der letzten Ausgabe kurz berichtet. Erlang/OTP ist eine Open Source-Implementierung, die nicht nur Erlang, sondern auch die verteilte Datenbank Mnesia beinhaltet (die übrigens auch über Schnittstellen zu C/C++ und Java verfügt). Mnesia ist — ebenso wie Erlang — nicht mehr neu, wird aber diskutiert, weil für Systeme von Google-, Yahoo!- oder Amazon.com-Dimensionen (und solche, die es werden wollen) die Idee einer zentralisierten, normalisierten, transaktionen relationalen Datenbank nicht mehr passt — und wenn man einmal beginnt, Aspekte wie Transaktionalität in Frage zu stellen, kann man auch gleich ganz neue Modelle evaluieren …

Jabber ist eine Instant-Messaging-Plattform à la AIM oder ICQ, die auf dem offenen Standard XMPP als Protokoll basiert und ebenfalls Open Source ist. Mit XMPP lässt sich nicht nur eine Kommunikation zwischen Menschen, sondern auch effiziente Anwendungs-zu-Anwendungs-Kommunikation realisieren.

Hinter Microformats schließlich verbirgt sich die Idee, strukturierte Inhalte nicht mit immer neuen XML-Vokabularen auzudrücken, sondern in XHTML einzubetten (indem HTML-”class”-Attribute verwendet und mit vordefinierten Werten belegt werden). Die Informationen sind dabei sowohl menschenlesbar als auch für die maschinelle Auswertung geeignet. Beispiele für Microformats sind hCard (für Adressinformationen) oder hCalendar (für Kalendereinträge).

Wie verlässlich sind Sams Prognosen? Kommentare dazu kommen zum Beispiel von Dare Obasanjo, der insbesondere Hadoop kritisiert, und Tim Bray der außer REST eigentlich alles anzweifelt und seine eigenen Prognosen dagegenhält. James Snell dreht den Spieß um und erklärt, warum weder RDF, noch Microformats, noch irgendeine Programmiersprache aus seiner Sicht sonderlich wichtig sein können. Die meisten Reaktionen hat Sam Ruby wiederum in seinem Blog kommentiert.

Meine persönliche Sicht? REST predige ich selbst gebetsmühlenartig seit geraumer Zeit, hier ist von mir kaum Widerspruch zu erwarten. Hadoop — oder vielmehr: das darunter liegende MapReduce-Prinzip — ist hochinteressant, wenn der Anwendungsbereich vielleicht auch für normalsterbliche Entwickler noch ein wenig exotisch ist. Bei Erlang/OTP ist vor allem Mnesia, die Datenbank, einen Blick wert. Erlang selbst ist intellektuell enorm stimulierend, aber Zweifel an der Durchsetzbarkeit in der Breite scheinen angebracht: Wenn sich die aus intellektueller Sicht beste Programmiersprache durchsetzen würde, dann würden Sie hier gerade das LISPspektrum lesen …

Wie immer finden Sie die Online-Version der Kolumne - inklusive der Links - unter http://www.sigs.de/blog/js/.

Dieses Mal führt uns die Tour durch die Blogs dieser Welt über die mehr oder weniger vertrauten Pfade verschiedener Programmiersprachen zu alternativen Client-Technologien und der Suche nach der endgültig richtigen Technologie für die Realisierung verteilter Anwendungen – und wie immer ist für jede Meinung die passende Unterstützung vorhanden.

Auch diese Ausgabe der Blogosphären-Kolumne kommt nicht ohne Werbung für Ruby aus. Zunächst einmal ist JRuby – die Implementierung von Ruby für die JVM – nun in der Version 1.0 verfügbar; Details dazu finden sich bei Chef-Entwickler Charles Nutter. Tor Norbye berichtet fortlaufend über die Unterstützung für Ruby in der NetBeans-IDE; für Eclipse-Fans gibt es neben dem bekannten RadRails noch das Eclipse DLTK (Dynamic Languages Toolkit for Eclipse Platform), über dessen Fortschritt man sich im Blog von Andrey Platov informieren kann. Das DLTK ist insbesondere deswegen interessant, weil es eine Navigation durch Ruby-Code ermöglicht (oder vielmehr: ermöglichen wird), die man eigentlich nur bei statisch getypten Sprachen für möglich halten würde (sehr schön zu beurteilen in einer Reihe von Screencasts).

Doch auch wer für seine Hauptentwicklungsarbeit nicht nur der JVM, sondern auch der Sprache Java die Treue halten will oder muss – was wahrscheinlich für die Mehrheit unter Ihnen zutreffen wird – kann sich mit Ruby beschäftigen, ohne dass sich diese Interessen widersprechen müssen: Assaf Arkin hat nach einigen frustrierenden Erlebnissen mit Maven2 nach einer Alternative gesucht – und diese auf Basis von Rake, dem Buildwerkzeug für Ruby, unter dem Namen Buildr realisiert. Rake ist eine in Ruby implementierte “Internal DSL”, also eine domänenspezifische Sprache, die die Syntax der Wirtssprache verwendet; Buildr fügt den deklarativen Ansatz aus Maven hinzu. Und siehe da: Obwohl Ruby sehr viel langsamer ist als Java, ist der Build-Prozess deutlich schneller. Bei genauerem Hinsehen verwundert dies auch nicht weiter, schließlich wird bei Maven (ebenso wie bei Ant) nicht nur Java-Code ausgeführt, sondern zur Laufzeit eine Konfiguration interpretiert – was im Prinzip auch nichts anderes ist, als die Interpretation eines Programmes. Die Grenzen zwischen Code und Daten sind nun einmal viel weniger scharf, als Viele glauben …

Natürlich wäre diese Kolumne nicht vollständig, ohne eine neue Programmiersprache zu erwähnen – wobei es diesmal weniger um eine neu erfundene, sondern eine wiederentdeckte Sprache geht: Erlang. Nein, Sie haben sich nicht verlesen: es gibt tatsächlich eine Renaissance der vor 20 Jahren erfundenen Sprache, die von der Firma Ericsson für massiv parallele, hoch verfügbare Telekommunikationssysteme entwickelt wurde und seit 1998 Open Source ist. Grund ist ein Buch von Erlang-Vater Joe Armstrong, das im Verlag der “Pragmatic Programmers” erschienen ist. Einer von ihnen, Dave Thomas, hat aus diesem Anlass eine mehrteilige Serie zu Erlang in seinem Blog gestartet - sehr empfehlenswert. Sie glaube, das ist alles nur etwas für Programmiersprachentheoretiker oder Nostalgiker? Falsch: ein Beispiel für eine Erlang-Anwendung ist das Web 2.0-Startup SlideAware, das von Python auf Ruby on Rails und schließlich auf Erlang umgestellt hat; mehr dazu im Blog von Mitgründer Wolfgang Mathurin. Wenn Ihnen Erlang (zu Unrecht) zu altmodisch erscheint: viele Einflüsse daraus haben ihren Weg in die JVM-Sprache Scala gefunden, die es erlaubt, in sehr wenigen Zeilen ausgesprochen spannende Applikationen zu programmieren, z.B. einen Clone der Online-Plattform Twitter in 884 Zeilen.

Es scheint, als ob in den vergangenen Wochen jeder Anbieter, der etwas auf sich hält, mit einer eigenen, bahnbrechend neuen und revolutionären Technologie für die Erstellung von Rich-Client-Anwendungen auf den Market gekommen ist: Adobe mit AIR (früher “Apollo” genannt), Microsoft mit “SilverLight” (früher: WPF-E, von Mono-Vater Miguel de Icaza in 21 Tagen für Linux implementiert), Sun mit JavaFX (inkl. JavaFX Script, früher bekannt als F3). Neben einer gewissen Unentschlossenheit in Bezug auf die Namensgebung verbergen sich hinter all diesen Lösungen Versuche, Alternativen zu AJAX für die Erstellung von komfortablen Web-Benutzeroberflächen zu bieten. Erinnert sich eigentlich noch jemand an XUL? Brendan Eich betont, dass trotz aller schönen Features alle diese Alternative-Plattformen proprietär und geschlossen sind; Simon Morris klassifiziert die unterschiedlichen Ansichten dazu als drei Religionen mit ihren jeweils eigenen Glaubensrichtlinien. (Ich persönlich halte es eher mit Mark Pilgrim und neige dazu, Web-Anwendungen, bei denen selbst Javascript und Ajax optional ist, zu favorisieren – und empfehle sehr einen Blick auf den wunderbar kryptisch benannten Ansatz “Unobtrusive JavaScript”.)

Ein anderes immer wiederkehrendes Thema ist die Diskussion um REST (“REpresentational State Transfer”) als Alternative zu Web-Services auf Basis von SOAP und WSDL. Handelte es sich dabei bis vor einiger Zeit um ein Thema, bei der man hauptsächlich auf verständnislose Blicke stieß, scheint es sich nun als neuer Hype zu etablieren. Das lässt sich zumindest aus einer enormen Zahl von Reaktionen schließen, unter anderem hervorgerufen durch das (sehr lesenswerte) Buch “RESTful Web Services” von Leonard Richardson und Sam Ruby (mehr dazu auch in einem Interview mit den Autoren). Nachdem Google bereits vor einiger Zeit bei allen neuen APIs auf REST setzt, hat nun auch Microsoft mit dem Projekt Astoria und Web3S diesen Schritt getan (wobei Web3S als Alternative zum Atom Publishing Protocol zu heftigen Diskussionen geführt hat). Die eher für ihre Tendenzen in Richtung Web-Services bekannte Analystin Anne Thomas Manes sieht die Zukunft in REST; Kritik an Web Services gibt es mittlerweile sogar von einem Vice President der Gartner Group. Neben Axis2 verfügt auch das Web-Service-Framework CXF über eine Unterstützung für REST, ebenso wie die nächste Version von Microsoft WCF. Mehr dazu findet man auch bei Richard Monson-Haefel, der WS-* mit Intelligenz und REST mit Weisheit vergleicht und bei Joe Gregorio, der eine Java EE-Benchmark-Anwendung, DayTrader, exemplarisch nach REST-Prinizipien umsetzt. Auch der JSR 311, “Java API for RESTful Web Services”, ist mittlerweile ein Stück weiter: es gibt eine Referenzimplementierung (“Jersey”) des aktuellen Standes der Spezifikation, die von der Expert Group veröffentlicht wurde, um Feedback einzuholen – zum Ausprobieren ist sie auf jeden Fall schon geeignet. Im November hatte REST-Fan noch ein Posting mit dem Titel “They can’t hear you” geschrieben und sich damit darauf bezogen, dass das Thema nicht wahrgenommen würde, weil niemand darüber spricht – zumindest das scheint sich zu ändern …

Wie kann man schlechte Programmierer von Anfang an heraussieben - und sollte man das überhaupt? Womit beschäftigt man sich, wenn man Ruby on Rails schon wieder leid ist? Was gibt es neues bei JRuby? Wo liegen die Grenzen der Meinungsfreiheit? Dieser wilde Themenmix beschäftigt uns diesmal in unserem Blogosphären-Report.

FizzBuzz

Wie findet man heraus, ob jemand der sich um einen Job als Software-Entwickler bewirbt, dafür geeignet ist? Lässt man ihn oder sie eine hochkomplexe Aufgabe lösen, konzentriert man sich auf Zeugnisse, auf Fragen zu den Tätigkeiten der Vergangenheit oder setzt man eher auf das “Bauchgefühl”? Ein Blogger namens Imran ist der Meinung, das leider viel zu häufig die Probleme schon bei den absoluten Grundlagen beginnen und schlägt einen trivialen Programmiertest namens FizzBuzz als erste Hürde für ein Gespräch vor. Die Aufgabe: Schreiben Sie ein Programm, das die Zahlen von 1 bis 100 ausgibt, aber für jede Zahl, die durch 3 teilbar ist, “Fizz” ausgibt, für jede durch 5 teilbare Zahl “Buzz” und für jede durch 3 und 5 teilbare Zahl “FizzBuzz”. Er behauptet, das ein ganz erschreckend großer Teil von Kandidaten nicht in der Lage ist, diese Aufgabe zu lösen. Hochgradig lesenswert sind die über 200 Kommentare, die dieser Beitrag ausgelöst hat: Die Mehrzahl der Kommentatoren fühlt sich genötigt, die Aufgabe in der Programmiersprache ihrer Wahl zu implementieren, von Python, Ruby und Java über OCaml, Scheme, Common Lisp zu XSL, VB, forth und Haskell. Amüsant finde ich, dass einige der Lösungen leider das falsche Ergebnis produzieren … Neben den Macho-mäßigen “Meine Programmiersprache ist besser als deine”-Reaktionen gab es jedoch auch grundsätzliche Zustimmung zur These der mangelnden Qualifikation, aber auch harsche Kritik: Shelley Powers ist der Meinung, dass hier die Stresssituation in einem Bewerbungsgespräch dramatisch unterbewertet wird und die Diskussion nur perfekt illustriert, was in der IT alles falsch läuft. Ein Blick auf die Kommentare sowohl zu ihrem Beitrag als auch zur Antwort von Reg Braithwaite lohnt sich.

Meine Lieblingslösung übrigens:

print $_%3?$_%5?$_:'Buzz':$_%5?'Fizz':'FizzBuzz',"n" for 1..100;

Ruby on Rails-Alternativen

Dass ich ein großer Fan von Ruby und Ruby on Rails (RoR) bin, wird niemandem entgangen sein, der diese Kolumne schon einmal gelesen hat. Aber ich bin offen für Alternativen - und derer gibt es immer mehr: Auf Grails, die Ãœbertragung vieler Ideen aus RoR auf die dynamische, JVM-basierte Sprache Groovy habe ich schon vor einiger Zeit hingewiesen; eine weitere Option für die Python-Fans ist Django. Obwohl diese Frameworks die Produktivität deutlich steigern, sind sie immer stark auf die “klassische” Web-Entwicklung ausgerichtet, bei der man sich der Tatsache, dass man mit HTTP-Anfragen und -Antworten umgeht, deutlich bewusst ist. Das muss man nicht als negativ empfinden, aber man kann. So kommt man zu einer Alternative, bei der die Entwicklung mit vielen klassischen Ideen von Web-Anwendungen bricht. Die Rede ist von Seaside, einem in Smalltalk (!) implementierten Framework, das Avi Bryant entwickelt hat. Hier programmiert man mit dem Paradigma einer Desktop-Anwendung - und auch Anhänger des reinen Web-Ansatzes sollten durchaus mal einen Blick auf Avis DabbleDB riskieren: eine absolut beeindruckende Webapplikation, die jedwede Zweifel an der Eignung des Webs für fortgeschrittene Anwendungsfälle ausräumen sollte. Selbst RoR-Chefentwickler David Heinemeier Hansson zollt Avi und Seaside großen Respekt. Wenn Sie schließlich nach der Kombination dieser Ideen mit Java und einer statisch getypten, aber trotzdem dynamischen Sprache suchen, dann ist vielleicht lift das Richtige: ein durch RoR und Seaside inspiriertes Webframework, implementiert in Scala.

JRuby

Für die Integration von Ruby und RoR in die Java-Welt ist das in vorherigen Kolumnen ebenfalls schon mehrfach erwähnte JRuby-Projekt sehr interessant: JRuby ist ein Ruby-Interpreter für die JVM, der die nahtlose Integration von Ruby in die Java-Welt ermöglicht. Die drei Chef-Entwickler, Charles Nutter, Thomas Enebo (beide Sun) und Ola Bini (Thoughtworks) kommen der 1.0-Version immer näher; aktuell stehen massive Performance-Verbesserungen im Vordergrund. Mit genügend Energie scheint es absolut realistisch zu sein, dass JRuby nicht nur für Java-Entwickler mit Integrationsbedürfnis, sondern auch für die klassische Ruby-Fraktion eine Alternative sein wird. Die Entwicklung erfolgt, Open-Source-typisch, sehr transparent - sei es eine 100%-Performance-Verbesserung beim Datenbank-Zugriff, Unicode-Integration, die Integration der Java-Monitoring-Möglichkeiten oder auch eher seltsame Ideen wie Ruby on Grails: der Fortschritt lässt sich sehr leicht mitverfolgen.

Code of Conduct

Zum Abschluss noch ein Thema jenseits der Technik, das die Blogosphäre vor kurzem bewegt hat wie kaum ein anderes seit langem: Die Frage nach dem richtigen Kompromiss zwischen Anonymität und Offenheit auf der einen und Verantwortung und Moral auf der anderen Seite. Kathy Sierra ist in der Java-Welt bekannt durch ihre “Head first” Buchserie, z.B. “Head first Design-patterns” (auf Deutsch sehr holprig übersetzt mit “Entwurfsmuster von Kopf bis Fuß”). Außerdem betreibt sie ein sehr lesenswertes Blog mit dem Namen (und Motto) “Creating Passionate Users”. Aufsehen haben Todesdrohungen und frauenfeindliche Angriffe erregt, die gegen sie in Blogeinträgen und persönlichen Emails ausgesprochen wurden - oder als solche interpretiert werden können, ganz nach Standpunkt. Kathy Sierra hat daraufhin eine Konferenzteilnahme aus Angst abgesagt und das Bloggen vorerst aufgegeben. Eine Welle der Solidarisierung in ihrem Blog und durch die gesamte Blogszene hinweg wurde kurz danach überschattet durch die Reaktionen der Beschuldigten, die sich auf einmal einem gar nicht mehr so virtuellen “Mob” ausgesetzt sahen. Verlagschef und Blogger Tim O’Reilly hat daraufhin eine Art freiwilligen Verhaltenskodex für Weblogger erstellt - und damit das Unfassbare erreicht, nämlich die gesamte Blog-Gemeinde zu einer einhelligen Meinung zu bewegen … nämlich zur universellen Ablehnung. Es ist schwer, in den vielen Beschuldigungen, Rechtfertigungen und Entschuldigungen die Wahrheit auszumachen; die Diskussion über Meinungsfreiheit und deren Grenzen ist aber sehr lesenswert - meine persönlichen Lesetipps zusätzlich zu den oben genannten sind die Beiträge von Tim Bray und Elliotte Rusty Harold.

Damit wären wir auch schon wieder am Ende. Wie immer können Sie den Links in der Online-Ausgabe dieser Kolumne folgen, die Sie unter http://www.sigs.de/blog/js/ finden. Viel Spaß!

Dieses Mal führt uns die Tour durch die Blogosphäre von REST und SOAP über einen neuen JSR zur REST-Unterstützung in Java vorbei an Java-Properties zu einem fehlgeschlagenen Software-Patent und dem Business-Case für SOA.

### REST und SOAP

Ãœber die Debatte “REST vs. SOAP” habe ich schon einige Male berichtet. Dabei geht es darum, ob Web-Services und das gewaltige Universum der Spezifikationen (knapp über 60 nach letzter Zählung) auf der einen Seite oder “korrekt”, d.h. nach den Prinzipien von “REST” angewandtes HTTP auf der anderen Seite besser für die Entwicklung lose gekoppelter Systeme geeignet sind. In den Blogs, die sich mit den Themen SOA und Web-Services beschäftigen, ist dieses Thema ein Dauerbrenner — und immer wieder für lange Diskussionen gut. Für Entwickler und Architekten mit SOA- und CORBA-Hintergrund erklärt Steve Vinoski die wesentlichen Aspekte von REST in einem Artikel für das Magazin IEEE Internet Computing. Web-Services sind nicht mehr “cool”, findet auch sein Ex-Kollege, IONA-CTO Eric Newcomer, meint dies aber nicht unbedingt negativ: Seiner Meinung nach haben Web-Services den Status “Mainstream” erreicht. Newcomer ist auch Organisator eines Workshops, den das World Wide Web-Consortium (W3C) zum Thema “Web of Services” veranstaltet. Die Dokumente, die für diesen Workshop eingereicht wurden, spiegeln den aktuellen Stand der REST-vs.-SOAP-Debatte hervorragend wider; in einem kurzen Artikel für InfoQ habe ich die wichtigsten kurz beschrieben. Ebenfalls interessant für alle, die sich mit dem Thema REST befassen möchten: Ein Interview mit Paul Prescod, einem REST-Guru, der eine Vielzahl von Beiträgen dazu geschrieben hat und sich in den letzten Jahren rar gemacht hatte.

### JSR 311, “Java API for RESTful Web Services”

Aus der Java-Perspektive spannend ist, dass sich mittlerweile nicht nur diverse Hersteller darum bemühen, REST zu “unterstützen”, sondern auch Sun selbst. Im Rahmen des Java Community Process (JCP) hat man mit dem JSR 311, “Java API for RESTful Web Services” die Standardisierung eines neuen APIs eingeleitet hat, dessen Implementierung Bestandteil von Java SE werden soll. Elliotte Rusty Harold (den ich für diese Ausgabe gleich mehrfach bemühe), hat sich dazu sehr kritisch geäußert — seiner Meinung nach ist die Standardisierung etwas, was erst erfolgen sollte, nachdem sich eine Lösung (z.B. auf Open Source-Basis) bereits bewährt hat. Positives Feedback kommt dagegen von Jérôme Louvel, Autor des RESTlet-Frameworks — wenig verwunderlich, ist er doch eingeladen worden, bei der Standardisierung mitzuwirken. Eine lange Diskussion zum Thema findet sich auch in der (für REST-Interessierte sehr empfehlenswerten) REST-Mailingliste: Zustimmung und Ablehnung scheinen sich in etwa die Waage zu halten.

### Properties in Java

Eine gewaltige Debatte hat JavaSE-Plattform-Chef Danny Corward mit seinem Vorschlag angestoßen, Java um das Konzept von Eigenschaften (Properties) zu erweitern, den Zugriff auf “öffentliche” Attribute also nicht über die JavaBean-Konvention von get- und set-Methoden, sondern über eine spezielle Syntax zu kapseln. Vielfach wird die konkret vorgeschlagene Syntax - ein Pfeil (”->”) wie beim Zeigerzugriff in C++ - kritisiert, so z.B. von Kirk Pepperdine. Weniger syntaktisch, sondern inhaltlich betrachtet Cay Horstmann das Thema. Er zeigt, wie sich 64 Zeilen Code auf 12 zusammenschrumpfen lassen und versucht, die typischen Gegenargumente (”meine IDE generiert die Bean-Methoden für mich”, “Getter und Setter sind sowieso schlechtes Design”) zu entkräften. Elliotte Rusty Harold beschreibt, wie Java Properties aussehen sollten — aber auch, warum man sie seiner Meinung nach gar nicht braucht: Seiner Meinung nach reichen die bestehenden Sprachmittel völlig aus. Zustimmung dazu gibt es von Dave Megginson (Achtung Schockgefahr: Er vergleicht den Vorschlag mit einer kosmetischen Operation und illustriert die Analogie mit einem Bild eines Popstars, das man Minderjährigen lieber ersparen sollte.) Megginsons und Harolds Ansicht nach sollte man aufhören, Java um immer neue Elemente zu erweitern. Wer andere Konzepte will, möge doch einfach eine andere Sprache verwenden. Mike Champion, bei Microsoft für XML-Standards verantwortlich, verweist in einem Kommentar auf die Analogie zu C#: Völlig unwichtig, welche Merkmale Microsoft zu Visual Basic hinzufügt, C#-Entwickler fragen immer nur danach, wann sie diese auch in ihrer Umgebung nutzen können. Wer all den Links gefolgt ist, die unzähligen Kommentare gelesen hat und immer noch nicht befriedigt ist, dem seien die Diskussionen bei InfoQ und JavaLobby empfohlen.

### Microsoft patentiert BlueJ-Ideen (doch nicht)

Wie ernst mittlerweile auch die größten Unternehmen die PR-Wirkung der Weblog-Szene nehmen, hat sich am Beispiel einer Microsoft-Patentanmeldung gezeigt. Michael Kölling von der University of Kent hatte in seinem Blog darüber berichtet, dass Microsoft BlueJ (bzw. dessen Konzepte) patentieren wolle. BlueJ ist eine interaktive Java-Umgebung, die eine sehr einfache, für Anfänger hervorragend geeignete Benutzerschnittstelle bietet und für den Einsatz in der Lehre gedacht ist. Dan Fernandez, Visual C#-Produktmanager, hatte vor geraumer Zeit schon über die in Visual Studio 2005 enthaltene Object Test Bench berichtet. Deren Konzepte zum interaktiven Testen von Objekten weist fatale, um nicht zu sagen peinliche, Ähnlichkeit mit denen in BlueJ auf — was schon damals von den BlueJ-Machern bemerkt wurde (und von Fernandez sogar bestätigt). Nun wurde ein Patentantrag bekannt, mit dem Microsoft die Konzepte auch noch schützen lassen wollte. Wie zu erwarten, stürzte sich die versammelte Anti-Microsoft-Gemeinde auf den Eintrag, inkl. Slashdot-Posting (ein Link von dort hat schon so manchen Web-Auftritt an seine Grenzen gebracht). Es dauerte gerade einmal bis zum darauffolgenden Tag, einem Sonntag (!), bis Microsoft-Managerin Jane Chu Prey sich entschuldigte und ankündigte, den Patentantrag zurückzuziehen.

### Quickies

Für eine ausführliche Behandlung reicht der Platz nicht mehr, aber zumindest erwähnt werden soll noch: das Release von Ruby on Rails 1.2, eine Diskussion über Java auf dem Desktop sowie eine Debatte über die Vor- und Nachteile von XML und JSON.

### Just for fun

Zum Schluss noch etwas weniger Ernstes: Für alle, die auf der Suche nach dem Business Case für SOA sind, bietet sich businesscase.com an: Dort kann man unter dem wunderbaren Namen “Casebuilder SOA” eine fertige Argumentation in Word, eine Business-Case-Kalkulation in Excel und die passende Management-Präsentation zum SOA-Business-Case herunterladen — zum Preis von 149 Dollar! Wenn das kein Angebot ist … und dieses Video, das die Spracherkennung von Windows Vista im Einsatz für die Perl-Programmierung zeigt, sollten Sie keinesfalls ansehen, wenn Sie gerade einen Schluck von Ihrem Kaffee genommen haben.

Den Links (35 an der Zahl) können Sie wie immer in der Online-Ausgabe dieser Kolumne folgen, die Sie unter http://www.sigs.de/blog/js/ finden. Viel Spaß!