NU2000053001

Geschichte der Applikation Server Fertigprodukte werden als "Applikation Server" oder "Dokumentmanagementsyteme" angeboten. Erstere sind eher ein Framework, der geeignet ist, letztere zu implementieren. DMS werden häufig ohne Applikation Server angeboten. Beide versuchen, Daten- bzw. Dokumentströme bedienergerecht zu erfassen, zu automatisieren und lenkbar zu machen. Geschichte Pionier war das Hypertextsystem Xanadu, es wurde 1999 als Udanax, unter GPL freigegeben. (Dieser Schritt erfolgte, als es modern wurde. Warum erst dann? Schnelle Vermutung, er hat sich um den Mechanismus gekümmert, nicht aber um die gesellschaftlichen Auswirkungen, sonnst wäre er zumindest eher auf den Zug gesprungen.) Geringe Marktrelevanz. Schlechtes Marketing? Goliath der Appserver, SAPR3?. Ein Framework für betriebswirtschaftliche Anwendungen. Viele Anwendungen. Nachteile: hohe Einführungs- und Betriebskosten, intensive Bindung an Anbieter, hoher Aufwand bei Änderungen am Prozeß. Marktführer bei Großunternehmen mit relativ stabilen Strukturen. Ist das richtig? Flexibler, träge, wenige Benutzer: die kleine Variante dazu wurde später Lotus Notes. (Dessen Entwickler Xanadu als Vorbild anführt.) Wiederum ein Framework, der es gestattet kundenspeziefische Anwendungen zu entwickeln. Nachteile: Nicht vetrauenswürdig, Replizierkonflikte, Langlebigkeit in Frage, da keine Quelltexte verfügbar sind. Hintertüren offen. Dazu proprietäre Scriptsprache, sehr komplex und unübersichtlich. Seit 1998 entstand eine große Anzahl Applikation Server, die sich im wesentlichen alle dadurch auszeichnen, daß sie eine bestimmte, als gut postulierte Technologie implementieren. Mit wrapbit kam 1997/8 meine auf angewandter Philosophie begründete Variante dazu. Erste Dokumente dazu lassen sich übrigens bis in's Jahr 1993 zurückverfolgen. Bis in's Jahr 1999 blieb sie eine reine clean room Entwicklung. Dafür gibt's zwei Gründe: 1. verhindern von Betriebsblindheit 2. verhindern von Patentproblemen. Mit der Definition einiger Standards (W3), die in wrapbit offengelassene Punkte (durch fremde Standards zu definieren) auszufüllen vermochten, ließ sich das docstore für I B M entwickeln. Verbindet man die letzten beiden, bekommt man einen Framework, der unabhängig von der unterliegenden Technologie ist. Aussicht Die Goliathsysteme haben zunächst den Markt prinzipiell vorbereitet, aber auch de facto besetzt. Die 20MByte??-Klasse besetzt Nieschen, in die das off the shelf Produkt Lotus Notes nicht skaliert, R3 nicht flexibel genug bedienen kann. Z. B.: Shopping-Syteme, Internet-Banking, E-Commerz-Anwendungen. Beide Goliaths benötigen erhebliche Ausbildung mit entsprechenden Kosten. Änhliche Ausbildungskosten entstehen mit der 20M Klasse. Allerdings kann ein normaler Fachmann (Informatiker) sich das selbst aneignen, da mehr Schnittstellen detailierter beschrieben sind. Der Markt ist damit vorbereitet, daß Applikation Server zum "Commodity Good" werden können. Damit rückt der Nutzen für den Anwender in den Vordergrund. Mithin benötigt der Anwender Vergleichskriterien, Modelle und Methaphern zur Bedienung etc. Der Anwender möchte damit seine Informationsflut bewältigen (siehe mein Uraltpapier, das solcherart Anwendungen als Ziel beschreibt). Dazu muß er die wichtigste Fähigkeit seines Nervensystems, das Erinnerungsvermögen, zuverlässig modelliert bekommen. Darum benötigt er "elektronisches Papier" und nachvollziehbar (mathematisch, nicht computerbezogen) definierte Funktionalität