Sonstiges > Offtopic

unbestätigtes Gerücht: LSA wird endgültig 2004 eingestellt

(1/2) > >>

Axel Janssen temp:
Hi,

LSA hat ja sowieso keine wirkliche Relevanz mehr seit einigen Jahren.

Mit einem weit verbreiteten LSA hätten wir wohl heute eine deutlich andere Unternehmens-IT. Ich hab mich mit dem Thema immer nur sehr oberflächlich beschäftigt.

Mich würde brennendst, v.a. von Leuten, die sich intensiver damit beschäftigt haben, interessieren, was zum letztendlichen Scheitern von LSA geführt hat.  ???

Keine Weltverschwörungstheorien, bitte.

Gruß Axel

Semeaphoros:
LISA , wie die Dame unterdessen heisst, ist dem Vernehmen nach gestorben, als es von Lotus Deutschland an Lotus International gewechselt und dort nur halbherzig weitergeführt wurde.

Meiner Meinung nach gibt es mehrere Probleme: Zu komplex, dadurch zu Resourcenhungrig, und viel zu teuer (Lizenzen! Sowas müsste schon OpenSource sein, wenn es wirklich verbreitet werden sollte). IT-Factory hatte ja einen ganz ähnlichen Ansatz, auch das ist gescheitert (so gut wie die Firma ja selber auch).

War das jetzt genügend Verschwörungstheoriefrei?  :D

Axel Janssen temp:

--- Zitat von: Semeaphoros am 04.11.03 - 18:21:49 ---
War das jetzt genügend Verschwörungstheoriefrei?  :D

--- Ende Zitat ---

Ich stand da ein bischen unter dem Eindruck des Gesprächs mit einer Person hier. Damit war mein Bedarf an Verschwörungstheorien erstmal gedeckt.  

Danke. Komplex. Ressourcenhungrig (oder skaliert nicht so gut) sind schon mal die Dinge, die ich erwartet habe.
Davon ist ja alles framework-artige tendentiell bedroht. Ein weiterer typischer Kandidat ist zu geringe Flexibilität. Entity Beans werden wohl letztlich an den 3 Gründen scheitern (Session Beans sind o.k). Auch bei Webservices ist Skalierbarkeit/Performance ein großes Problem. Für Batch-mässige Dinge ist es sehr gut. Für alles, was mit Userinteraktion zu tun hat, ist die Performance Umwandlungsprozesse Objekt --> xml --> Objekt immer tendentielle show-stopper.
Hab auch letztens einen sehr kritischen Beitrag bzgl. MS-Longhorn gelesen (MS OS, das aber erst 2006/7 deployed wird).

Das mit dem OpenSource sehe ich genauso. Nicht nur, um die Schwelle der User, das zu nutzen zu senken, sondern auch um den code einer ständigen review durch kompetente Fachleute zu unterziehen (dies funktioniert imho bei den Java-frameworks sehr gut).  

Gruß Axel

Semeaphoros:
Ja, das sehe ich genauso, was Du da jetzt ergänzt hast (soweit ich da schon Erfahrungen gesammelt habe :-)

Axel Janssen temp:
Als wir letzte Woche die Performance des user-Interaktions-Webservice mit wenigen Dokumenten und mit 512MB Arbeitsspeicher auf dem Test-Client von 25 sec Laufzeit auf sensationelle 11 sec geboostet haben, wusste ich, dass ich da nach Alternativen suchen sollte.

Himmel. Unterschätzt niemals die Belastung von clientseitiger xml-Serialisierung/De-Serialisierung.   ::)
Das gilt für jeden (!) Datenaustausch mit xml (inkl. Robert Basics auf seinem Blog veröffentlichte Idee, Notes-server mit flash client über xml zu integrieren (interessanter Ansatz).

Für batch-artige Prozesse ist es eine Klasse-Technologie. Aber Userinteraktionen, die Rechner im Netzwerk ansprechen?

... ist es vielleicht einfach der falsche Hammer. Erinnert mich an damals, wie ich den LScri Web-Agenten für die Navigation durch eine "treat-content-as-html"- view ersetzt habe...

Gruß Axel

Navigation

[0] Themen-Index

[#] Nächste Seite