Modularität und Liskovsches Prinzip in komplexen Systemen

Startseite
> heise Developer Artikel-Foren
> Modularität und Liskovsches Prinzip in k...
> Re: Erfolgreiche Beispiele - jenseits von "sort"

5. Dezember 2012 00:07

Re: Erfolgreiche Beispiele - jenseits von "sort"

Michael9 (mehr als 1000 Beiträge seit 11.01.00)

pbberlin schrieb am 10. November 2012 17:37

> Irgendwie gelingt es aber keinem realen mir bekannten
> Software-Projekt, damit auch nur annähernd austauschbare
> Komponenten zu erschaffen.

Unser aktuelles Projekt basiert von Anfang an auf
OSGI-Interfaces und Services.

D.h. es MUSS für jede Struktur/Modul eine dokumentierte
Serviceschnittstelle geben und die wird zwangsläufig
in verschiedenen Versionen angesprochen. Das ist der
Punkt von OSGI.

Außerdem muss jedes Modul der OSGI-Denke folgen, d.h.
es kann auch während der Laufzeit einfach "ungeloaded"
werden und muss sich dabei "sauber" (Graceful) verhalten.

Bei 20% der Kernkomponenten werden die Diskussionen immer
hässlicher. Sich an OSGI zu orientieren schmeißt viele
(an sich sehr ekelige) Transaktionsoptimierungen über den Haufen,
Prozesse werden unterbrochen, die Architekten
wechseln häufiger als Handtücher in der Sauna. Denen ist das einfach
zu nah am Metall, dass ist nicht "schön".

Aber der "Resilience", der Stabilität hat das extrem gut
getan. Wir kriegen die Software praktisch nicht mehr kaputt
(abseits künstlicher Locks auf Threads, Speicher und
Festplattenplatz, und auch da versucht sie es noch).

Ein netter Seiteneffekt: wir haben eine Menge Mock-Services
die der Spezifikation folgen und die wir bei Last Tests
einfach gegen die originalen Counterparts austauschen können.
Klappt hervorragend, auch gut für die Fehlersuche.

Und ein gutes Modulsystem hat dann automatisch auch was fürs
Marketing. Der Verkauf freut sich auch schon: extra Cash.

Theoretisch KÖNNTEN wir viele Sachen auswechseln. Aber
jetzt muss man sich im Prozess die Frage stellen: wieso
sollte ein Lufthansa-Buchungsservice so geschrieben sein,
dass Air Berlin damit auch arbeiten kann?

Die Austauschbarkeit würde nur dann Sinn machen, wenn
man eine Applikation hat die linuxhaftige Größen erreicht.

Wenn ich etwa 20 verschiedene Banken anspreche, mache ich
dass über ein paar Skripte und XML-Parameter, die dass
in das interne Format konvertiere. Da macht es einfach
keinen Sinn das so "leicht" zu bauen dass man alles damit
machen kann.

Deswegen stelle ich sogar die Forderung in Frage. Wer
braucht so ein grobes Lego? In der Praxis der letzten
Jahre hätte ich andere Komponenten gebraucht, die gibt
es jetzt (etwa autosharding NoSQL-Row/Columnstores).

Oder komplexe Streaming XML->DB Importer die selbst-
ständig auf mehreren Threads laufen. Den Content selbst
tauschen, da sind die offenen Lösungen nicht "tief" genug.
Irgendwo muss die Komplexität stecken.