L(I)SA. Was soll man dazu sagen?

[Marinero Atlántico]

Hi,

jemand Lust zum Lisa-bashing?
Oder ist das zu un-produktiv/theoretisch/was-auch-immer.

Ich hab damals bei der Lisa Schulung gefehlt, mit der Entschuldigung, dass ich mich für die Java2 certification vorbereiten muss.
Ich hatte Recht. Das Produkt ist auch gestorben.

Nun bin ich in einer Umgebung gelandet, wo es viel Lisa gibt, das aber abgebaut werden soll.
Recht so.

Folgende Dinge sind mir jetzt aufgefallen. Ich kenne natürlich nicht alle Aspekte von Lisa, sondern nur denen ich hier begegne:
- Es gibt offenbar ein zentrales Repository an unternehmensglobalen Konfigurationsdaten, dass nach ähnlich unübersichtlichen Schlüsseln abgelegt ist, wie in der Windows-Registry.
- Viele dieser Konfigurationsdaten sind als Collections und nicht als einzelne Werte angelegt. Man muss dann wissen, dass some_kind_of_super_important_App(0) den Server bezeichnet und some_kind_of_super_important_App(1) den Datenbankpfad.
Das Ablegen von Konfigurationsdaten in Variant-Datentyp-Collections ist übrigens laut Fowler "Enterprise Application Patterns" ein eindeutiges anti-Pattern.
- diese Konfigurationsdaten werden offenbar nach mir nicht transparenten Regeln gecached. Da mein LSA-erfahrener Kollege jetzt weg ist, hat mich das extrem verwirrt und sogar veranlasst, die gecachten Konfigurationsdaten lokal zu überschreiben, was ich jetzt wieder wegtun muss.

Sind unternehmensglobale Konfigurationsdaten überhaupt gut?
Oder ändert sich das nicht sowieso ständig? --> Mergers & Aquisitions, neue Backendsysteme, etc.
Zwar funktioniert der Query gegen das zentrale Repository nicht einfach über einen Skript-Lookup, es gibt da irgendwelche hoffentlich optimierten extra-LSA-Funktionen.
Trotzdem habe ich den Verdacht, dass diese ständigen Zugriffe auf das zentrale Repository eine ernstzunehmende Performance-Bremse darstellen.

Naja. Vielleicht finde ich noch was.  

Interessanter Job.

Gruß Axel

[elajen]

Hallo,

wir haben seit 3 Jahren LSA im Einsatz. Ich war damals ein Gegner und das hat sich im Laufe der Zeit auch bewahrheitet.

Performance
Die Performance ist im Zugriff auf die Orga-DB eine absolute Katastrophe. Der Zugriff auf die Zentrale Konfigurations-DB ist aber recht performant. Das Repository haben wir nicht eingesetzt. Da habe ich ein eigenes in Zusammenhang mit einem komplexen Info-Management-System erstellt.

Zum Thema zentrale Konfiguration.
Die Philosophie der lsacfg ist genial, aber durch die verwirrenden Ansichten nicht zu durchschauen. Die Bedienung ist, wie überall in den LSA-DBs besch... Der Ansatz vieles in einer DB (repl. auf alle Server) abzulegen, hat sich bei uns in einer Bank mit 130 Filialen bewährt. Ich würde es auch empfehlen.  Besser ist aber aus meiner Sicht eine Eigenentwicklung.

LSA-Eigenheit
LSA bringt neue @Formeln und eigene LS-Klassen mit. Beide nutzen über LSX externe DLL's, die im Notes-Prog-Verzeichnis auf JEDEM Rechner installiert sein müssen.

Bis hier hin erst mal.

Fazit aus 3 Jahren LSA
L(i)SA NICHT EINSETZEN!

Vielleicht kann ich noch weiterhelfen.

Gruß von Ekki.

[Marinero Atlántico]

Danke für das Angebot, aber bislang geht es.
Irgendwie erscheint das mir LISA light, hier.
Ich glaub die Entwickler hatten selbst keinen Bock auf eine Menge der Features. Ausser für den Zugriff auf die zentrale Konfigurationsdatenbank sehe ich keine speziellen Lisa @Formeln oder Skript-Funktionsaufrufe. Vielleicht liegts auch daran, dass ich wg. der Hitze so schlecht schlafe.

Passend zu der ganzen (gescheiterten) Geschichte ein Zitat von Linus Torvald, dass ich heute morgen auf javablogs gefunden habe:

    ...open source does tend to be more stable software. It's the right way to do things. I compare it to science vs. witchcraft. In science, the whole system builds on people looking at other people's results and building on top of them. In witchcraft, somebody had a small secret and guarded it -- but never allowed others to really understand it and build on it.

Linus Torvalds

[Glombi]

Schade eigentlich, dass L(i)SA sich nicht so recht etabliert hat. Aber eigentlich kein Wunder, schließlich hat es ja ein Mathematiker bei Lotus - und dann noch ein Deutscher - entwickelt.
Es ist wie mit den Computerspielen: Die deutschen Spiele sind einfach zu kompliziert für den Rest der Welt (das habe ich jedenfalls vor kurzem irgendwo gelesen).
Vielleicht sollte man die Pisa-Kriterien modifizieren und dann wären wir endlich wieder die Nummer 1  

Andreas

[Glombi]

Noch was zum Hintergrund von LSA: Es wurde so ab 1993 entwickelt. Damals war gerade Notes 3 gekommen und man konnte endlich tolle Sachen machen - z.B. Schaltflächen verwenden und es gab revolutionäre neue @Functions: @DbLookup, @DbColumn  

Dann kam die Zeit der richtig tollen Anwendungen von allen möglichen Business Partnern. Was früher in einer Datenbank und Vererbenmechanismus gemacht wurde, wurde nun in diverse Datenbanken ausgelagert: Adressen, Korrespondenz, Organisation,....
Jeder BP hatte natürlich seine eigene Implementierung, wie man von einer Datenbank auf die andere zugreift.
Wenn man dann bspw. die zentrale Adressdatenbank woanders hin kopiert hatte, musste man an N Stellen (N = Zahl der von BP implementierten Lösungen + C + A (C = Anzahl der verschiedenen Implementierungen EINES BP  ), A = Anzahl der Datenbanken mit @DbLookup etc.) das ändern.
Also wurde die Idee von Lotus Deutschland geboren, ein Standardverfahren zu entwickeln, dass den Zugriff auf andere DBs vereinheitlicht. Da jeder Kunde jedoch seine Eigenheiten hat und diese jenem nicht unbedingt auszutreiben waren, uferte es aus.

Frage: Wenn jetzt LSA wieder abgeschafft wird: Wie wird sichergestellt, dass es nicht wieder N Konfigurationsmöglichkeiten gibt.

Andreas

[Marinero Atlántico]

So richtig glücklich geworden, ist die Menschheit mit Lisa ja nicht.
Ist die Menschheit zu dumm für das Framework?
Oder war das Framework doch nicht so gut?
Ich würde solche Fragen generell mit der 2. Frage beantworten.

Eine zentrale Konfiguration ist doch eine gute Sache.
Wenn das Framework aber als solches zu starke Performance-Kosten hat (Orga DB), dann ist das immer schlecht. Ähnliches galt ja lange Zeit auch für die remote-Aufruf-Seeligkeit von Enterprise Java Beans.

Ansonsten hab ich die Einstellung, dass Frameworks dazu da sind, dass ich mich über die unfähigen Programmierer, die das erstellt haben, aufrege.
O.k. ausser vielleicht 3 bis 4 Frameworks, vor denen ich wirklich tiefen Respekt habe (teilweise, weil ich sie in großen Teilen nicht verstehe).

Gruß Axel

[Glombi]

Du hast recht, L(i)SA ist zu sehr ausgeufert.

Warum die Performance bei der Orga so schlecht ist, weiß ich nicht. Ist das eigentlich die gleiche Orga-DB wie bei Lotus.Workflow? In letzter Konsequenz müsste das ja so sein.
Ich kann mich dunkel an die Entstehen von LSA erinnern. Es war schon kompliziert gemacht, aber sehr dynamisch. Um von DB A nach DB B zu gelangen, wurden einige Umwege gemacht. Das beeinträchtigt natürlich die Performance.

Es gab da auch die sog. UDF (User Defined Function). Das ist wohl das Teil, was überallhin verteilt werden muß. Die stellt dann eigene @Funktionen zur Verfügung. Da es API ist, sollte das eigentlich schnell sein.

Wie dem auch sei. Im meiner langen Laufbahn ist mir L(i)SA nicht so wirklich bei den Kunden über den Weg gelaufen.
Einige hatten IT Factory, aber das ist so ähnlich einzustufen.

Andreas

[LuckyMan]

Ich muß zugeben...wir haben Lisa im Einsatz...und so wie es aussieht können wir es auch in nächster Zeit nicht loswerden.

Denn unser UHD-Tool setzt darauf auf. Gott sei Dank habe ich mich mit Lisa noch nicht intensiv befassen müssen...wir hatten zwar vor 3 Jahre mal einen ganzen Tag mit dem Schöpfer....aber danach mussten wir es nicht anwenden...und wie das mit dem Wissen so ist...

Was man nicht anwendet, vergisst man recht schnell...

Gruß

LuckyMan