Ich denke im ersten Schritt wird das, was schon seit jeher zu den Best Practices gehört wichtiger: Lang laufende Aktionen werden in ihren eigenen Thread ausgelagert, damit der Benutzer nicht auf die Abarbeitung warten muss. Aber dies lastet die Prozessoren noch nicht besser aus, denn die lang laufenden Aktionen laufen lange, weil auf Ressourcen gewartet wird: Die Antwort vom Web Service, von der Datenbank oder vom Filesystem. Das ganze wird nur fixer, weil man auf drei Dinge gleichzeitig warten kann. Aber warten kann schon eine CPU mit einem Kern ziemlich gut auf ziemlich viele Dinge.Die eigentliche Frage: Was tun mit den andere Prozessoren / Kernen bleibt also. Ich sehe zur Zeit zwei Alternativen:

•  Wir finden keine gute Antwort auf die Frage. Dies wäre in der Tat fatal, denn das Moorsche Gesetz treibt die gesamte IT Industrie! Warum soll ich mir einen neuen Rechner kaufen, wenn die Software so schnell läuft wie auf dem alten? Warum soll ich mir neue Software kaufen, wenn die auch nicht mehr kann als die alte, da sie die gleichen Ressourcen zur Verfügung hat wie die alte? Ich halte diese Bedrohung für durchaus ernst und wundere mich, dass ich diesen Gedanken noch nirgends so gelesen habe.
• Wir tun komplexere Dinge. Der größte Teil der der Anwendungen, die wir schreiben ist doch erschreckend banal: Benutzer gibt Daten ein, wir schubsen die Daten von hier nach da, drehen sie auf links und schreiben sie schließlich in eine Datenbank. Wirklich komplexe Aufgaben wie Optimierungsprobleme oder Simulationen, anspruchsvolle 3D-Visualisierungen von Daten, stehen bei den meisten Entwicklern nur sehr selten im Pflichtenheft. Das hat zweierlei Gründe. Einerseits sind nur wenige Entwickler von ‘Enterprise Applications’ in der Lage solche Probleme zu lösen, andererseits ist die Hardware schon mit den einfachen Dingen komplett ausgelastet. Aber letzteres wird sich ändern. Auf einem normalen PC werden wir schon bald ein Dutzend Prozessorkerne haben, die nicht richtig ausgelastet sind. Wenn wir dem Kunden neue Versionen unserer Software verkaufen wollen, müssen wir ihm zeigen, dass wir mit dieser Rechenleistung etwas anfangen können. Berechnungen und Optimierungen, die wir bisher als nicht handhabbar abgetan haben, und dem Benutzer überlassen haben, müssen wir uns krallen, in parallel verarbeitbare Algorithmen gießen, nett visualisieren und in die Anwendung integrieren.

Daher meine apokalyptische Prophezeiung: Wer als Software Entwickler in 10 Jahren noch einen Job haben will, sollte hoffen dass Java sich zum nächsten Cobol entwickelt, und für Leute mit veraltetem Wissen viel Geld bezahlt wird, oder sie sollte sich schon mal an nicht triviale Algorithmen herantasten.

Sprachen

Das aktuelle Thema überhaupt ist sicherlich Sprachen. Durch die Allgegenwart von zwei wesentlichen Laufzeitumgebungen (JVM von Java/Sun und der CLR von .NET/Microsoft) ist es extrem einfach neue Sprachen mal auszuprobieren. Zu dem Thema empfehle ich den Artikel von Markus Völter.

Meine persönlichen Erkenntnisse dazu:

• Fast(?) nichts von den Konzepten ist neu. Die Basis für funktionale Sprache z.B. ist das Lambda Kalkül von 1930. Insbesondere das Polyglotte Programmieren ist doch längst Standard. Ich z.B. zähle in den meisten Projekten mindestens Java, SQL, PL/SQL, HTML und CSS zu meinem Handwerkszeug. Was sich ändern könnte, ist warum wir zwei oder mehr Sprachen einsetzen: Weil bestimmte Aspekte in der einen, andere in der zweiten Sprache besser darstellbar sind. Während bisher der Grund der Mangel an Alternativen ist. (Ja ich weiß, man kann auch in Oracle mit Java arbeiten. Aber wer das einwirft hat es noch nicht ernsthaft ausprobiert).
• Wir werden uns damit beschäftigen müssen. Heiße Kandidaten für die praktische Anwendung sind für mich: Groovy und Scala.
  Auch spannend finde ich Haskell. Ich habe vor vielen Jahren an der Uni Miranda gelernt und hätte nie gedacht, dass dies mal im Berufsleben relevant werden könnte.
  Als Physiker, der einmal intensiv mit Fortran gearbeitet hat finde ich auch Fortress sehr beeindruckend. Dies Sprache kann zumindest für Mathematiker und ähnliche sehr leserlich gerendert werden und ist speziell auf (massiv)parallele Ausführung ausgerichtet.

Womit wir bei einem weiteren Thema sind:

Concurrency

Das Moore’sche Gesetz als Basis des Quaketunings (18 Monate Quake spielen, schon ist die Anwendung doppelt so schnell) ist am Ende. Als ‘horizontale Ausweichbewegung’ werden uns von AMD und Intel Mehrkern CPUs auf den Schreibtisch gestellt. Dadurch geraten überall Leute in Panik, existierende Anwendungen würden nun wie die Fliegen von den Wänden fallen, da Threadingprobleme sich nun manifestieren.

Nun ja, ich weiß nicht was für Anwendungen ihr schreibt, aber ich schreibe beruflich entweder Swing oder Webanwendungen, die auf Datenbanken gehen. Nur ein sehr kleiner Teil der Arbeit steckt in komplexen Algorithmen, und ich habe noch nie etwas davon parallelisiert. Datenbanken und Webserver laufen ‘schon immer’ auf Mehrprozessormaschinen. Es sind heute halt 512 statt 16. Die Art und Weise wie dort Parallelverarbeitung eingesetzt wird, ist extrem einfach und daher handhabbar: Jede Anfrage bekommt einen Thread, und darf ihn für sich alleine verwenden, bis die Anfrage abgearbeitet ist. Zumindest sieht es aus der Sicht des Entwicklers so aus.

Nur in Swing muss man typischer Weise mit mehreren Threads arbeiten, da lang laufende Aktionen sonst die Darstellung der Anwendung blockieren. Dies wird man aber wenn irgend möglich minimieren, da jeder der Doug Leas Buch gelesen hat, weiß wie schwierig Concurrency ist.

Viele der neuen Sprachen haben aber Konstrukte, die die Verteilte Ausführung unterstützen und es ist ja nicht so, dass wir die nicht zu nutzen wüssten. Unabhängig von der Anzahl der Prozessoren gibt es nämlich einen Bereich, in dem Concurrency eine Rolle spielen sollte: bei dem Zugriff auf verteilte Ressourcen. Egal ob es die Datenbank oder der entfernte Web Service ist, wenn wir eine Anfrage abschicken und warten, bis die Antwort kommt, bevor wir die nächste Anfrage lostreten verschwenden wir mindestens Zeit, und meist auch wertvolle Ressourcen (mindestens den wartenden Thread). Je nachdem wie knapp die Ressourcen sind, wird man früher oder später genötigt sein, die Anfragen parallel anzustoßen und anschließend die Ergebnisse zusammenzuführen. Schön wenn die Sprache mit der man dies tut, ein solches Vorgehen angemessen unterstützt.

Security

Es gibt immer wieder Stimmen, die meinen, Security würde jetzt DAS große Thema. Vertraut mir, wird es nicht. Genauso wenig wie Gasmasken oder Panzertüren DAS große Thema werden. Aber Security ist ein Dauerbrenner, den niemand ignorieren sollte. Oder schließt ihr euer Auto und eure Wohnung nicht ab? Daher gab es auch auf der JAX Vorträge zu diesem Thema.

Für mich die wichtigsten Punkt waren dabei:

• * Der Deming Zyklus gilt auch hier. D.h.
  • Plant was eure Sicherheitsziele sind und was ihr dafür tun müsst. Wollt ihr euch gegen Skriptkiddies schützen? Oder haltet ihr die NSA für euren Feind? In letzterem Fall könnte aber auch ein Psychater helfen
  • Führt die Maßnahmen durch.
  • Prüft, ob die Maßnahmen wirksam sind.
  • Wenn die Prüfung negativ ausfällt, reagiert darauf.
• Schwierig an dem Security Thema ist, dass selbst gigantische Sicherheitsprobleme nicht von allen erkannt werden. Wenn ich in mein Haus eine Tür aus Pappe einbaue, brauche ich keinen Experten um zu erkennen, dass das eine schlechte Idee ist. Bei Software ist das ganze deutlich weniger offensichtlich. Ich habe die privaten Schlüssel für Zertifikate schon gemailt bekommen. Daher gibt es eine ganz wichtige Aufgabe, wenn eine Anwendung ‘sicher’ werden muss: Awareness schaffen. Alle Beteiligten (Entwickler, Designer, Tester, Administratoren, Anwender, …) müssen in Sachen Security geschult werden. Denn was nützt die schöne Sicherheitsarchitektur, wenn der Benutzer seines Sohnes Namen als Passwort verwendet und das auch noch per E-Mail verschickt und auf den Monitorrahmen schreibt?
• Security heißt nicht einfach Benutzer Authentifizierung und Authorisierung sondern durchdringt den gesamten Entwicklungsprozess.
  • Bei der Analyse müssen die Anforderungen aufgenommen werden.
  • Diese müssen bei der Architektur und dem Design berücksichtigt werden.
  • Es muss natürlich implementiert werden,
  • aber auch getestet,
  • deployed
  • und genutzt

  Und wie ich oben skizziert habe, gibt es auch in den Bereichen Herausforderungen, wo man sie normalerweise vielleicht nicht erwartet.

Architektur

Ist ein weiterer Dauerbrenner, und ähnlich wie bei Security lautet hier mein Hinweis Deming Circle! Eine Architektur hat eine Aufgabe zu erfüllen. Die Aufgabe sollte vorher klar sein und nachher muss geprüft werden, dass die Aufgabe gelöst wurde. Ansonsten ist Architektur ein Unfall oder Selbstbefriedigung des Architekten.

Durch das Thema Nr.1 ‘Sprachen’ gewinnen wir gerade im Bereich Architektur gerade gewaltig an Möglichkeiten:

• Unterschiedliche Sprachen für unterschiedliche Bereiche.
• DSLs für Spezialfälle
• AOP oder spezielle Sprachstrukturen für die Umsetzung von Architekturentscheidungen

SOA und BPM

Viel Hype und (fast) nichts dahinter.

Das 5. Element (Quintessenz)

Die Probleme bleiben die alten. Die Lösungen sind auch nicht neu. Die Zeiten bleiben interessant.