Skip to content

Warum Java?

Damals als es darum ging den Nachfolger für unser bewährtes Software Projekt zu planen stand auch die Frage nach der Technologie für die nächste Generation im Raum. Der Schwenk von einem VisualC++ lastigen Software Haus zu einer pure Java Schmiede war sicherlich nicht einfach. Damals, so 1997 hatte Microsoft die .NET Techonologie noch nicht ins Leben gerufen, war also noch keine ernsthafte Alternative. Heute wäre die Entscheidung sicher schwerer: .NET ist zu einer Alternative geworden. Solange man sich auf die Microsoft Platform beschränken will bietet .NET mit seinem Frameworks einen vergleichbaren Komfort zu Java. Umso interessanter ist es, sich einmal anzusehen wie die Entwickler Gemeine sich so entschieden hat. Gerade im Bereich der Anwendungen für Unternehmen hatte MS schon immer eine riessige VB PRogrammierer Gemeinde. Wenn man den Zahlen von Forrester trauen kann, so konnte Microsoft diese aber noch nicht ins .NET Lager retten:
According to Forrester survey data and analysis, Java's 66% penetration is the highest among strategic programming languages for enterprise applications. Visual Basic 6 (VB6) and C/C++ have nearly as much penetration as Java, but VB6 is past mainstream support and C/C++ has a comparatively limited ecosystem. The two most strategic .NET languages, Visual Basic .NET (VB.NET) and C#, have 34% and 15% penetration, respectively. If all VB6 users converted to VB.NET, its share would increase to 70%. However, of those who report using .NET as a platform, about 42% are not currently using VB.NET or C#, indicating that Microsoft has yet to fully win over its base to .NET programming.
Von daher sieht es danach aus, dass auch andere Unternehmen unsere Entscheidung teilen. Unser Java Produkt ist erfolgreich, und die anvisierte Ziel neue Kundensegmente zu erschließen ist voll aufgegangen. Gleichzeitig sind wir weiterhin auf der weit verbreiteten MS Platform lauffähig. Zugegeben, der Grad der Integration in das Betriebsystem ist mit Java schwerer zu erreichen, da wir aber keine Desktop Software herstellen ist das kein großes Thema. Update: Bei Richard Monson-Haefel gibt es noch einen Artikel über die Entwicklung von OO-Sprachen mit etwas anderen Zahlen.

Enterprise Anwendungen

Gerade im Bereich Middleware sind Enterprise Anwendungen in der Regel missionskritisch. Der Produktionsbetrieb stellt besondere Ansprüche an Verfügbarkeit und Leistungsfähigkeit dieser verteilten Anwendungen. Schon beim Entwurf der Architektur müssen entsprechende Anforderungen beachtet werden. Dazu gehört insbesondere:
  • RAS Funktionen (Reliability, Availability, Serviceability)
  • Skalierbarkeit
  • Change Management und Auditing
Letzteres insbesondere dann, wenn die Anwendung über lange Zeit von mehreren Abteilungen betrieben werden soll. Wurden die Anwendungen auf diese Gesichtspunkte hin optimiert ist nicht nur die Verfügbarkeit besser (durch Reduktion von Ausfällen, Ausfallzeiten, schnelleren Wiederanlauf und weniger geplante Wartungsintervalle), sondern auch der Betrieb ist einfacher, was sich insbesondere auf die TCO auswirkt. Ein nicht zu vernachlässigender Aspekt von Robusten Anwendungen ist auch die Agilität bei der Umsetzung von neuen Anforderungen. Wenn ein System nicht fragil wie Glas ist, so lassen sich neue Anforderungen auch deutlich schneller umsetzen. (Dass dies oft vernachlässigt wird hatten wir ja schon in der Diskussion zum Thema ERP Ausfälle festgestellt). Ich plane eine Artikelserie zum Thema "Selbstheilung". Dabei gehe ich auf die Details aus dem Alltag eines J2EE Entwicklers ein. Beginnen werde ich mit Artikeln zur Selbstheilung von JNDI, JMS, RMI und JDBC.