Hi,
Ungefähr genau was ich vor 4 Jahren prognostiziert habe (wobei ich heute deutlich EJB-feindlicher bin)
Für IBM wird es einfach vergleichsweise zu teuer all diese features 100% abwärtskompatibel von Release zu Release zu schleppen und gleichzeitig neue features zu produzieren.
Webservices machen für mich immer weniger Sinn, da im gegenwärtigen Zustand die Webentwicklung immer unattraktiver wird. Ich kann inzwischen kaum noch eingebaute Dominofunktionen nutzen und muß alles von Hand coden.
Webservices hat fast
nichts mit Web zu tun.
Webservices hat fast
nichts mit Web zu tun.
Webservices hat fast
nichts mit Web zu tun.
Webservices ist backend integration.
Webservices ist backend integration.
Webservices ist backend integration.
Nicht mal eine normale Tabelle kann ich noch verwenden weil Domino sofort Spaghetti Code generiert und je nach Lust und Laune ungefragt ecblank.gif plaziert.
IMHO hat das was damit zu tun, dass Domino als monolythische Anwendung geschrieben wurde. Die Öffnung gegenüber den Standards ist ein addOn. Wenn die in Domino gehaltenen Daten eine saubere Datenstruktur hätten, würde es einfacher sein, dort die entsprechenden GUI-Layers zu schreiben. Der entsprechende html gui code wird deshalb nicht geschrieben, weil es sich für IBM nicht lohnt. Grund: Das zugrundeliegende Datenmodell ist über die Jahre zu sehr überladen worden.
Was die Java Unterstützung betrifft ist das doch alles rumgelogen. IBM kann Java 1.5 integrieren. Solange ich dauernd wahlweise rumrecyclen muß und mir die Agenten regelmäßig um die Ohren fliegen ist das für mich nur in Notfällen interessant. Irgendwelche C++ Funktionen mit einem Java Wrapper zu umgeben und sich dann selber feiern ist mir zu wenig.
Selbst das kann ich inzwischen verstehen. Bei SWT (GUI-Api von ua. Eclipse, IBMs anti-Swing Version) gibt es auch eine Art recycle() (heisst dispose(), aber genau gleich). Man muß eben sauber programmieren, aber das muß man bei Java sowieso.
Auf der anderen Seite glaube ich sowieso, dass RDBMS viele Vorteile hat. Übrigens sind die meisten heute verwendeten JDBC-Treiber nicht vom Typ4 und die restlichen sind nix anderes als wrapper um C-code. Wg. der unterschiedlichen Architektur von RDBMS-Zugriffen über JDBC braucht es da zwar kein recycle(), wohl aber ein connection.close(). Und letzteres auch für Typ4-Driver.
UND: Bei RDBMS Zugriffen aus Java gibt es eine Menge, Menge, Menge Ansätze, um die low-level Details dieser Zugriffe zu kapseln. (EJB, Hibernate, JDO, etc. pp.). Und zwar explizitst u.a. auch um z.B. vergessene .close() auszuschliessen.
Vielleicht sind die Leute, die über die "unnötige" Komplexität von solchen Mappern lästern, genau die, die sich später semi-cholerisch über die Folgen ihrer so smarten und "einfachen" low level Entscheidung beschweren.
Dies ist und bleibt für mich einer der großartigsten Seiten, die im Internet je produziert worden sind:
http://russellbeattie.com/notebook/1007886.html. V.a. die Kommentare. Und noch mehr v.a. Michael Glögl + Gavin King.
Aber irgendwie codet anscheinend sowieso jeder weiterhin unbeirrt mit Script, einerseits weil man es kann aber auch weil es teilweise immer noch besser funktioniert.
Ich auch. Viele Aufgaben in Domino sind einfach Skript und brauchen keine OO-Sprache. Find aber, dass man eine Menge Dinge heute einfacher in Java/J2EE machen kann.
Und warum gibt es immer noch keine UI Unterstützung für Java?
Lotus Workplace ist die UI Unterstützung für Java. Ich mag das nicht, weil das so wenig modular ist (mein Eindruck). Man muß den ganzen Elefanten essen und für den Serverteil braucht man einen 2-CPU Rechner, was lachhaft ist. Sehe das deshalb in der Praxis auch nicht für tauglich.
Monitoring Sachen brauche ich nicht. Das was ich habe reicht aus. Monitoring wird in dem Moment uninteressant, wo man nur noch 99,9% Uptime feiern möchte.
Kommt drauf an. Du erweiterst/betreust eine Anwendung, die ein Rechenzentren mehreren Banken zur Verfügung stellt. Die Banken haben eigene Administratoren für die Anwendung/Notes insgesamt. Bzgl. des Zustands der Server erlebt man da die tollsten Sachen. V.a. braucht es immer ziemlich viel Zeit für die Fehlerfindung, da ich keinen Direktzugriff habe. Die Bankadmins selbst sind alles mögliche und sicher nicht blöd, nur eben keine hauptberuflichen Notes-Admins. Das ist für die eben eine Teilaufgabe.
Schnittstellen, wo man mit code auf bestimmte Server-Events reagieren kann, sind sicher sehr gut. Braucht kein Administrator dann mehr einzugreifen.
Tivoli war in den letzten Jahren der immer am stärksten expandierende IBM Zweig. Vielleicht gibt es dafür Gründe.
@Martin: Ich habe irgendwo mal einen Artikel gelesen, den ich nicht mehr widerfinden kann, wo jemand sagt, dass sich Microsofts Strategie bzgl. Abwärtskompatibilität mit .NET stark geändert hat. Vorher war das ein super-duper-wichtiges Prinzip von Microsoft. Angeblich gibt es im Source Code von Win95, Win2000, etc. Stellen nach der Art:
if (app.isMemberOf (importantApps)) {
// emuliere nicht-dokumentiertes Win3.1 feature, dass von neuer Version nicht mehr unterstützt wird
}
Genau das läuft nun mit .NET scheinbar nicht mehr so.
Man erhofft sich durch eine so aufgeräumte Architektur insgesamt geringere Betriebskosten in der Zukunft.
Mir wurde gesagt, dass eine der wichtigsten grundlegenden Änderungen von Office 2003 die dolle xml Unterstützung ist :-)
Ein gewaltiges Problem für hardcore Domino-DXL Programmierer (etwa für eine automatische Konvertierung nsf->j2EE) ist wirklich letztlich die unaufgeräumte Datenstruktur von
Lotus Notes (v.a. RichText Felder, aber auch Masken, Ansichtsspalten-Definitionen, etc.). Microsoft mußte da wohl ein paar Features rausschmeissen.
Find ich völlig normal. Wenn ich umziehe, Frühjahrsputz, etc. machen, müssen auch immer ein paar Bestandteile meines Haushalts dran glauben.
Für mich sind das gute Nachrichten. Ich lese lieber sowas wie "Transaction-, Interoperability and Security in SOAP Environment" als "150 Productivity Tricks für Power MS Office User".
Gruß Axel
