unser Newsletter befasst sich diesmal mit dem Thema "Java und Web Applikationen" sowie der Frage "Was kommt nach Java?" Als Flugreisender könnte die Antwort lauten: "Ungefähr zwei Stunden nach (der Insel) Java kommt Australien." Aber dies ist hier selbstverständlich nicht gemeint.
Es geht vielmehr um Java-Applikationen, webbasierte Rich-Client-Anwendungen als vorherrschendes Paradigma (Stichwort Ajax) und dynamische Skriptsprachen als Alternative in der Webentwicklung.
Da ich viele unserer Leser kenne, ist mir bewusst, dass der eine oder andere jetzt darüber nachdenkt, ob er diese Mail schließen soll, da in den ersten ca. 50 Wörtern dieses Newsletters einfach zu viele "böhmische Dörfer" vorkamen, mit welchen er oder sie im Tagesgeschäft vordergründig nichts zu tun hat.
Ich möchte Sie bitten weiterzulesen! Dies, weil ich der Überzeugung bin, dass nicht nur die IT-Abteilungen in den meisten Unternehmen sich mit den Auswirkungen dieser Thematik auseinandersetzen bzw. zeitnah auseinandersetzen werden.
Um Sie möglichst optimal auf die weiteren Inhalte vorzubereiten, möchte ich an dieser Stelle einige der genannten Begriffe erläutern (Unterstützung fand ich hierbei bei Wikipedia) - Experten bitte ich, die nächsten vier Absätze zu überspringen:

Java ist eine objektorientierte Programmiersprache und als solche ein eingetragenes Warenzeichen der Firma Sun Microsystems. Sie ist eine Komponente der Java-Technologie. (Aber dies wussten Sie natürlich!)

Ajax ist ein Apronym für die Wortfolge "Asynchronous JavaScript and XML". Es bezeichnet ein Konzept der asynchronen Datenübertragung zwischen einem Server und dem Browser, welches es ermöglicht, innerhalb einer HTML-Seite eine HTTP-Anfrage durchzuführen, ohne die Seite komplett neu laden zu müssen. Das eigentliche Novum besteht in der Tatsache, dass nur gewisse Teile einer HTML-Seite oder auch reine Nutzdaten sukzessiv bei Bedarf nachgeladen werden, womit Ajax eine Schlüsseltechnik zur Realisierung des Web 2.0 darstellt.

Skriptsprachen sind Programmiersprachen, die vor allem für kleine, überschaubare Programmieraufgaben gedacht sind. Sie verzichten oft auf bestimmte Sprachelemente, deren Nutzen erst bei der Bearbeitung größerer Projekte zum Tragen kommen. So wird etwa in Skriptsprachen auf den Deklarationszwang von Variablen verzichtet - vorteilhaft zur schnellen Erstellung von kleinen Programmen, bei großen hingegen von Nachteil, etwa wegen der fehlenden Überprüfungsmöglichkeit von Tippfehlern in Variablennamen.

Der Begriff Web Engineering bezeichnet die Entwicklung von Webanwendungen, wie beispielsweise Portalsystemen, Shopping-Seiten oder anderer komplexer Websites. In der Regel ist Web Engineering nicht nur die Entwicklung, sondern auch die Fortentwicklung und Erweiterung von vormals erstellten Websites.

Und in den folgenden Artikeln werden Sie auch noch erfahren, wie "Ruby on Rails" und "Seaside" im Gesamtkontext zu sehen sind - und natürlich, wie wir die Zukunft der Anwendungsentwicklung sehen!

Wir wünschen Ihnen viel Spass beim Lesen, einen schönen restlichen Juni und …
immer die richtigen Menschen in Ihren Projekten!

Herzliche Grüße

Innovation is about People

Wovon hängt die Innovations-Performance, d.h. der gemessene Innovationserfolg ab, d.h. der Erfolg eines Unternehmens, neue Produkte und Services erfolgreich zu vermarkten, bestehende Produkte an geänderte Kundenanforderungen anzupassen oder in neuen Märkten bzw. bei neuen Kundengruppen zu platzieren?

In einer Studie bei deutschen IT-Dienstleistungsunternehmen analysierten wir die Voraussetzungen für eine erfolgreiche Service-Innovation und welche Handlungsoptionen den Innovationserfolg steigern können. Die Studie untersucht die Hypothese, dass die Innovations-Performance, d.h. der gemessene Innovationserfolg eines Service-Unternehmens, von den vier Innovationsmanagement-Dimensionen Positionierung, Potenziale, Prozess und Portfolio abhängt.

1. Position: Die Positionierungs-Dimension beinhaltet alle notwendigen Elemente zur Berücksichtigung der Anforderungen der Kunden bzw. der Marktentwicklung bei der Entwicklung neuer Services bzw. Erschließung neuer Geschäftsfelder sowie die Maßnahmen zur Erreichung des Markterfolgs.
2. Potential: Die Potenzial-Dimension bestimmt den Einsatz geeigneter Ressourcen, Werte, Innovationskultur, Incentive-Systeme, Netzwerke, Budgetmittel sowie Informations- und Kommunikationssysteme für Entwicklung und Leistungserbringung.
3. Process: In der Prozess-Dimension werden alle Faktoren eines erfolgreichen Service-Innovationsprozesses von der Ideen-Generierung, -Sammlung und -Bewertung über die eigentliche Service-Entwicklung bis zur Service-Vermarktung beschrieben.
4. Portfolio: Die Portfolio-Dimension umfasst die Steuerung des gesamten Leistungs-Portfolios wie den Lebenszyklus, strategische Geschäftsfelder, Breite und Dichte des Portfolios (Full Service Provider vs. Nischenanbieter).

Abb.: Einflussfaktoren auf die Innovations-Performance

Im Detail wurden folgende Fragen untersucht:

• In welchem Maße beeinflussen Positionierung, Portfolio, Potenziale und Prozess die Innovations-Performance?
• Welches sind die Haupt-Treiber für den Innovationserfolg?
• Gibt es Unterschiede bzgl. der beeinflussenden Faktoren für unterschiedliche Unternehmenskategorien, z.B. abhängig von der Größe oder des Leistungs-Portfolios?

Was kommt nach Java?

Eine kleine "historisierende" Einleitung Würden wir uns nicht im Bereich der IT bewegen, könnte man sagen: "Es ist noch gar nicht solange her..." - 14 Jahre, um genau zu sein, sind vergangen, seit SUN die ersten Versionen von Java zum Download bereitstellte.

Der Newcomer zeichnete sich durch strenge Typisierung und große syntaktische Nähe zu C++ aus, versprach aber konsequente Objektorientierung & automatisches Speichermanagement; kurz und gut: er lag ein wenig zwischen den gängigen "religiösen Lagern", die im wesentlichen durch die Frontlinie C++ vs. Smalltalk geprägt war (die vereinzelten Jünger von Eiffel, Objective-C, CLOS etc. wurden auch damals schon eher als - mehr oder minder elitäre - Sekten aufgefasst).

Als Smalltalker war ich damals pflichtgemäß ein wenig skeptisch, nichtsdestotrotz aber auch hinreichend neugierig, um 1996 die erste Java-Schulung für meinen damaligen Brötchengeber zu erstellen und zu halten - anfangs nur intern vor einen Publikum altgedienter Smalltalk-Recken.

Das Fazit war das zu erwartende:

Klein & kompakt? - Ja, wenn ich mal die (damals doch beachtlichen) 15 MB Laufzeitsystem ignoriere...

Konsequent objektorientiert? - Ja, aber mit dem Makel der strengen Typisierung (warum soll ich denn meinen Compiler davon überzeugen, dass ich mein eigenes Typsystem verstanden habe?)

Virtuelle Maschine? - hat Smalltalk schon lange... (ebenso wie Just-in-time-Compilierung, aber das Feature kam für Java ja erst später.)

Eigentlich wurde Java nur als nettes Spielzeug angesehen, welches vor allem den Nutzwert hatte, dass man Applets auch in IBMs Smalltalk-Umgebung einbinden konnte, um so den gerade aufkommenden webbasierten Applikationen eine - nach damaligen Maßstäben - "vernünftige" GUI zu verpassen...

Der Siegeszug
Wurde noch das gloriose Scheitern von IBMs San Francisco Framework (das erste kommerzielle Applikation-Framework für Java überhaupt) von uns Smalltalkern nicht ohne Häme beobachtet - in der Erstellung gigantischer Frameworks hatten wir schließlich reichlich Erfahrung - so hat doch der nachfolgende Siegeszug von Java auf dem Server uns alle nachhaltig eines Besseren belehrt.

Angetreten als Lösung für die Rollout-Probleme der Fat-Client-Systeme (das Applet als "Slim Client"), entwickelte sich Java alsbald über das Servlet als CGI-Ersatz zu einer universellen Programmierplattform, deren unbestreitbarer Vorteil die völlig unproblematische Portabilität ist. Spätestens mit EJB als "Standard-Architektur" für unternehmensweite Anwendungen war Java nicht mehr aufzuhalten - und von "klein & kompakt" sprach ohnehin schon niemand mehr...

Nur zurecht, wie man sagen muss, denn bald schon hatte ein Entwickler kaum noch eine Chance, mit der rasant steigenden Zahl neuer Standard-Bibliotheken, Schnittstellen, Open-Source-Frameworks rund um die Sprache schritt zu halten; kaum ein Monat verging ohne einen neuen JSR, eine neue Standard-Library, oder eine neue Version irgend eines Frameworks - Irrwege eingeschlossen (einige davon recht teuer, man denke nur an die Entity Beans vor EJB 3.0). Eines der wichtigsten Schlüsselwörter in Java ist meines Erachtens seither "deprecated" (die Deklaration, dass eine bestimmte Bibliotheksfunktion innerhalb der nächsten Versionen abgängig sein wird...)

Heute ist Java sicherlich eine der "fettesten" (sprich: unübersichtlichsten) Programmierumgebungen der IT-Geschichte. Nichtsdestotrotz ist es aber auch die erste Wahl, wenn es um Backend-Programmierung geht; hier hat es unbestreitbar dem guten, alten Cobol den Rang abgelaufen (was C++ nie geschafft hat) - und nicht zuletzt deshalb gelten Vielen nun die Java-Applikationen als "Legacy von morgen".

Fat Clients, Webclients, Rich Clients...
Interessanterweise hat Java bei seinem Siegeszug auf dem Server, den Client verloren. Das Applet als - vermeintlich - unproblematischer "Slim Client" erwies sich bald als unpraktikabel (nicht zuletzt aufgrund der damals eher behäbigen Ladezeiten, sowie aufgrund von Inkompatibilitäten der jeweils in den Browser eingebetteten JVM). Andererseits gingen mit der steigenden Präsenz des Internet auch die Ansprüche der User an die GUI zurück, so dass alsbald Servlets begannen, HTML zu generieren.

Da diese enge Koppelung von Funktionalität und GUI aus architektonischer Sicht nicht wirklich das Gelbe vom Ei war, folgten "hybride" Ansätze wie JSP, die es erlaubten, die HTML-Seite qua "GUI" unproblematisch mit serverseitig zu interpretierenden Funktionsaufrufen zu annotieren. In einem weiteren Schritt wurde nach Möglichkeiten gesucht, die dialogischen Fähigkeiten der browserbasierten GUI in Richtung des guten alten Fat Client zu erweitern; dies geschah mittels rein clientseitigen Skriptsprachen wie JavaScript bzw. ECMAScript. Heute können webbasierte "Rich Clients" auf Basis von Ajax als vorherrschendes Paradigma der Client-Entwicklung angesehen werden.

Das Web auf Schienen
Das Web ist seit je her ein Spielfeld für allerlei Skriptsprachen, sei es das altbewährte CGI mit Perl, oder auch PHP, welches als "leichtgewichtige" Alternative zu herkömmlichen Sprachen viele Freunde (nicht nur im "semi-professionellen" Umfeld) gewonnen hat. Die vor allem auch publizistische Prominenz der großen Java-Frameworks (Struts, Spring und Konsorten) hat dies zwar ein wenig verdeckt, Java konnte aber diese Sprachen nie wirklich verdrängen. Erst in jüngerer Zeit treten Skriptsprachen in der Webentwicklung (auch publizistisch) wieder in den Vordergrund, allen voran Ruby, für das sich seit 2004 das Framework Ruby on Rails (RoR) als wahre Killer-Applikation entwickelt hat.

Ruby gehört wie Smalltalk zu den dynamisch typisierten Sprachen: Im Gegensatz zu Java und C++ hat eine Variable hier keinen expliziten Typ, d.h. der Entwickler muss sich nicht mehr um Typkonversionen ("Casting") kümmern - freilich um den Preis, dass er genau wissen muss, was er tut, da sein Compiler keine statische Typüberprüfung mehr vornehmen kann. Solche Sprachen haben den Vorteil teils erheblich kompakteren Codes, sowie oftmals einfacherer und umfassenderer Möglichkeiten generischer Programmierung, als sie etwa die Reflexion-API von Java bietet. Statistisch gesehen, benötigt ein Smalltalk-Entwickler nur 17 Codezeilen zur Realisierung eines Function Point, ein Java- oder C++-Entwickler braucht hingegen typischerweise hierfür 45 Codezeilen (vgl. Capers-Jones). Die Anwendungen müssen allerdings besser durchgetestet werden, da die meisten Fehler erst zur Laufzeit auftreten. Nicht ohne Grund hat daher die heute weit verbreitete Nutzung von Unittests ihren Ursprung in der Smalltalk-Entwicklung.

Der Vorteil der Kompaktheit der Sprache wird in Rails nochmals verstärkt, indem in großem Umfang Codegeneratoren zum Einsatz kommen. Den in Java-Frameworks üblichen "Konfigurationsorgien" (hier hat sich XML systematisch zu einer zweiten Programmiersprache entwickelt, ohne die Java gar nicht mehr denkbar ist) wird das Prinzip "Konvention vor Konfiguration" entgegengesetzt: viele Prozesse werden über Namenskonventionen gesteuert (die freilich auch wieder konfiguriert werden können). Herausgekommen ist ein Framework, welches es z.B. erlaubt, mit nur 70 selbst erstellten, aber über 12.000 generierten Codezeilen eine vollständige kleine Webapplikation in einer Stunde zu erstellen (nachzulesen z.B. in iX 5/2009, S. 40 ff.). Mittlerweile ist Rails auf dem Weg zur Version 3.0 den Kinderschuhen hinreichend entwachsen, dass auch große Applikationen (z.B. - teilweise - Xing) hiermit erstellt werden können. Ein Blick lohnt sich also auch, wenn man eher nicht zu den "Early Adopters" gehört.

Die Konzepte von Rails haben auch in andere Sprachen & Frameworks Eingang gefunden, etwa in Symphony für PHP, oder in Groovy on Grails. Letzteres ist ein Java-basiertes Framework für die Sprache Groovy, ihrerseits eine Erweiterung von Java um einige dynamische Sprachelemente, die zu den wesentlichen Merkmalen von Ruby oder auch PHP gehören (wir sehen, Java hat den Kampf keineswegs aufgegeben...)

Hart am Wind
Rails und Konsorten haben die Karten am Markt der Webentwicklung nachhaltig neu gemischt - und davon profitieren auch einige alte Bekannte, wie etwa Smalltalk mit Seaside. Abgesehen davon, dass ich als altgedienter Smalltalker zweifellos den Zorn der gesamten Smalltalk-Gemeinde auf mich zöge, würde ich Seaside hier übergehen, so hat dieses Framework auch einige spezifische Merkmale, die einen tiefergehenden Blick wert sind - auch wenn man nicht zu den Smalltalk-Jüngern gehört.

Seaside basiert auf sogenannten Continuations, ein Sprachelement, welches aus Scheme stammt, aber auch in Smalltalk und Ruby zu finden ist (nicht aber in Java!). Vereinfacht beschrieben, wird bei dem Aufruf einer Continuation der gesamte relevante Kontext der Ausführung implizit mit übergeben, was das Sitzungsmanagement in Webanwendungen erheblich erleichtert. Klar, das kann man auch mit Cookies erreichen - aber dann erledigt man das Sitzungsmanagement quasi zu Fuß. Seaside liefert es dagegen für den Entwickler luzide mit; er kann seine Anwendung ebenso aufbauen, wie jede andere dialogische Client-Server-Anwendung auch.

Seaside ist - wie auch Rails, Grails, Symphony und die meisten "klassischen" Java-Webframeworks - Open Source, allerdings gilt dies nicht durchgängig für die Sprache selbst. Es gibt zwar einige freie Smalltalk-Umgebungen, darunter mit Squeak die Referenzumgebung für die Entwicklung von Seaside selbst, aber ob diese dem Einsatz in unternehmenskritischen Umfeldern gerecht werden können, mag bezweifelt werden. Die Alternative ist in erster Linie Cincoms VisualWorks, eine Smalltalk-Umgebung der ersten Stunde, die zweifellos auch großen & kritischen Anwendungen gerecht werden kann, allerdings zu teilweise empfindlichen Lizenzkosten. Dafür gibt's dann aber auch mit Heegs seaBreeze einen komfortablen graphischen Editor für die Dialoge...

Und was ist mit Java?
Keine Sorge, Java ist nicht tot, und es riecht auch noch nicht so schlecht, wie es einige gerne hätten! Im Gegenteil, die Stabilität & ubiquitäre Verfügbarkeit der JVM ist ein Argument, an dem auch die VertreterInnen der div. Skriptsprachen nicht vorbei kommen.
Zudem haben vor allem kommerzielle Anbieter immer noch ein Problem damit, dass sie - bei den meisten (oft interpretierten) Skriptsprachen kaum umgehbar - immer den vollständigen Quelltext ausliefern müssen. Infolgedessen hat sich für einige dieser Sprachen eine "Java-Version" etabliert, die es erlaubt, aus dem Code der Skriptsprache Java-Classfiles zu generieren. Der m.W. älteste Vertreter dieser Gattung ist Kawa, ein in Java geschriebener Scheme-Interpreter/Compiler. Heute jedoch erheblich bedeutsamer dürfte JRuby sein, welches auch den Betrieb von Rails-Applikationen auf der JVM erlaubt (und Groovy erzeugt von Hause aus bereits Java-Classfiles).
Selbst wenn Java den "Kampf um das Frontend" tatsächlich manifest verlieren sollte - als Wirt für die möglichen Sieger dieses Kampfes wird es uns sicherlich noch lange begleiten!

Links
Struts: http://struts.apache.org
Spring: http://www.springsource.org
Ruby on Rails: http://www.rubyonrails.de, http://www.rubyonrails.org
Symphony: http://www.symfony-project.org
Groovy on Grails: http://grails.org
Seaside: http://seaside.st
Squeak: http://squeak.org
Cincom VisualWorks: http://www.cincomsmalltalk.com/userblogs/cincom/blogView
seaBreeze: http://seabreeze.heeg.de
Kawa: http://www.gnu.org/software/kawa
JRuby: http://jruby.codehaus.org


top

Interner Partner
Ulrich Blancke, its-people Hochtaunus GmbH

Ulrich Blancke verstärkt seit 01.05.2009 das Team der its-people Hochtaunus. Er ist ein ausgewiesener Experte in unserem Portfoliobereich Business Intelligence und Data Warehouse und verfügt über weitreichende Erfahrung in den Themen Data Warehouse Architektur und Konzeption, Projektleitung und Daten Management. Kenntnisse der maßgeblichen DWH-Tools wie Informatica, Data Stage, Business Objects, SAS und Cognos sowie Oracle und DB2 kombiniert mit viel Erfahrungen in Pre-sales und Business Development Aktivitäten ergänzen seinen Erfahrungsschatz. Er arbeitete mehrere Jahre in und für namhafte Unternehmen wie IBM, PwC Unternehmensberatung und Deutsche Post AG. Ulrich Blancke verfügt über ein erfolgreich abgeschlossenes Studium der Physik, absolviert an der Universität Hamburg. Weitere Informationen erhalten Sie gerne unter ulrich.blancke@its-people.de

top