Noch ein paar Punkte (und ich möchte hiermit nicht provozieren):
1. Viele "Vergleiche", die in dieser Branche so beliebt sind, sind absolut populistische Nonsens-Aussagen.
Z.B. Vowe mit seiner Aussage auf Ed Brill, dass sich Notes zu Workplace verhält wie das Windows Fenster in OS/2. Viele haben vielleicht noch nie OS/2 gesehen und andere kennen die Fachwörter besser als ich. Er meint damit (in meinen nicht-korrekten Worten): In OS/2 gibt es eine Windows-Emulation, in der man MS-Windows-Programme starten kann. Das hatte aber viele Haken und Ösen. Ich war ein frühes Opfer, da man da z.B. 95% aller Windows-Spiele nicht laufen lassen konnte, wozu ich damals Lust hatte.
Das ist aber ein absolut unwissenschaftlicher Äpfel und Birnen-Vergleich, weil
a) die technischen Details völlig anders aussehen und
b) wir nicht wissen, wie gut Notes-Anwendungen in Workplace laufen werden und ich vermute das wird deutlich unproblematischer als damals dieses Windows-Fenster in OS/2.
2. Man kann diesen Versuch des Reinwachsens von Domino in einen J2EE basierten Technologie-Stack auch wesentlich positiver sehen. Diese positiven Aspekte vermisse ich bei so Aussagen wie von Vowe (Apple ist einfacher und damit besser) und auch teilweise hier. Wobei das jetzt auch nicht als Belehrung gemeint ist, sonder in echt.
Was war von Anfang an der Punkt der voll J2EE-Server von Sachen wie Tomcat positiv abhob und wo Websphere auch gegenüber Konkurrenten qualitativ sehr gut ist?
Der Manager für verteilte Transaktionen. Das Kernstück von EJB.
Wofür ist der gut?
Ich hab in einem Unternehmen in den Jahren ein paar zuverlässige, teure und auf die Bedürfnisse des Unternehmens gut abgestimmte Backend-Anwendungen angesammelt. Manche sind auf Host mit Cobol, DB2-Datenbanken, SAP uvam. Nun möchte ich in einer Anwendung diese Backendanwendungen als Ressourcen nutzen, dh. ich lese aus ihnen, ich schreibe in sie, usw.
Dafür ist dieser Manager für verteilte Transaktionen sehr sinnvoll:
Ich kann nämlich eine Transaktion programmieren, die ein update auf verschiedene Backend-Systeme durchführt. DAS KANN NOCH NICHT MAL DAS SPRINGFRAMEWORK.
Greift die Transaktion etwas auf Cobol-Programm A und auf SAP zu und Cobol-Programm A ist z.Zt nicht erreichbar, dann wird auch der Update gegen SAP-Daten nicht durchgeführt, weil der Transaktionsmanager merkt, dass die andere Anwendung nicht läuft. Und dies alles ohne eine Zeile Code zu schreiben. Die Integration verschiedener Backendsysteme wäre ohne diesen verteilten Transaktionsmanager wirklich kompliziert.
Der verteilte Transaktionsmanager muß sehr zuverlässig sein und es ist komplexe Software. Man kann das auch nicht so einfach selber programmieren. Das muß auch gegen Fälle gesichert sein, wo der Transaktionsmanager selbst ausfällt, nachdem eine verteilte Transaktion bereits begonnen hat. Und das ist nicht einfach code, den man an einem Nachmittag schreibt. IBM konnte bei diesen verteilten Transaktionsmanager auf Sachen zurückgreifen, die in den 60er Jahren begonnen wurden (CICS) und immer wichtig für IBM waren (u.a. in der Ära, wo viel in CORBA entwickelt wurde).
Es ist gut, dass es diesen verteilten Transaktionsmanager in Workplace gibt. Das öffnet Chancen für neue Anwendungen. Die Verdrängungswirkung von Websphere auf Notes ist auch nur teilweise. Notes wurde zwar v.a. 1999 bis 2001 auch in wirklich großen Projekten als Integrationsfrontend für SAP stärker genutzt als heute, aber Notes wurde nie für verteilte Transaktionen genutzt. Wobei verteilte Transaktionen natürlich ein logisches Erweiterungs-Feature sind. Grinsender Kunde: Können wir da nicht noch schnell diese gute alte Cobol-Anwendung ranpflanschen. Solche Leute wissen nix von der Komplexität verteilter Transaktionen.
Auf SAP Daten wird natürlich noch heute von neuen Notes-Anwendungen zugegriffen. In bestimmten Teilbereichen macht es Sinn.
Es ist aber auch nicht der Kernbereich für Notes Anwendungen.
Also was ich sagen will ist, dass dieser ganze Diskurs ein tieferes technisches Niveau benötigt.
Und v.a. ist J2EE nicht nur Bedrohung sondern oft sehr sinnvoll und so schwierig ist das alles nun wirklich auch nicht.