Domino 9 und frühere Versionen > Entwicklung

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

(1/2) > >>

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.  ;D

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. ;D

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

--- Zitat ---
    ...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

--- Ende Zitat ---

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  ;D

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  ;D

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  ;D), 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

Navigation

[0] Themen-Index

[#] Nächste Seite