Multi Tier in einer 24/7 Umgebung implementieren, aber wie?

[alzaimar]

Hallo,

ich habe das Problem, eine Mehrbenutzer-DB mit einer Mittelschicht in Delphi zu implementieren. Ach, eigentlich läuft das Teil seit Jahren und ist soweit stabil. Aber nun Folgendes:

Es gibt immer wieder kleinere Änderungen, Buggies, Erweiterungen an der Datenbank, den Tabellen, den Geschäftsregeln usw. Dann stellt sich das Problem, das die Mittelschicht immer wieder überarbeitet werden muss. Also: Alle Clients runterfahren, Mittelschicht austauschen, Clients wieder anwerfen und fertig. Das System läuft in einer Fabrik, die mittlerweile im 3-Schicht Betrieb an 7 Tagen in der Woche und 365 Tagen im Jahr läuft. Für vorbeugende Wartung und Upgrades ist da einfach keine Zeit mehr.

Nun ist das wirklich stressig, sodass ich dazu übergegangen bin, soviel Logik wie möglich auf den SQL-Server zu verfrachten. Bei den o.g. Erweiterungen muss ich dann nur noch die entsprechende Stored Procedure o.ä. anpassen. Das geht natürlich im laufenden Betrieb aber auch zu Lasten der Performance, da nun das System als Ganzes ca. 10-15% langsamer ist (wegen dem SQL Overhead im Server).

Nun meine Frage: Geht das nicht Anders? Welche Architektur sollte ich verwenden, um Codeteile, Geschäftsregeln etc. on-the-fly zu ändern, OHNE den Betrieb zu stören?

Ach ja: Ich habe es mit Sockets und DataSnap implementiert. Unter D6. Enterprise.

Danke für alle Kommentare!

[Robert_G]

Ich habe mir letztlich das RemObjects SDK gesaugt und ein wenig damit rumgespielt.
Alle Achtung, das Ding ist teilweise komfortabler als Webservices in .Net.
btw: die .Net Variante ist aufgrund des binären Fomates auch noch merklich schneller als jede Remoting variante von .Net.
Zusammen mit ihrem Data Abstract scheint das eine ziemlich coole Lösung zu sein.

Das hätte ich zu meinen D32-Zeiten kennen sollen...

Den Irrweg von zuviel DB-seitiger Logik bin ich selbst lange gefolgt.
Es gibt immer Dinge, die man innerhalb einer DB am simpelsten und effizientesten lösen kann.
Solange die DB nicht Oracle oder SQL Server 2005 heißt, dürfte sich dieser Anteil wohl bei knapp über null einpendeln.
Aber selbst darin ist es teilweise ein Krampf. PL/SQL ist zwar IMHO die produktivste und lesbarste DB-Sprache, aber sie ist trotz allem nur eine dumme Scriptsprache, der man mit einem Vorschlaghammer versucht hat, OOP einzuhämmern.
Verglichen mit einer Implementierung in einer OO-Hochsprache wie Delphi, .Net, Java, ... im MiddleTier ist es einfach nicht effektiv zuviel in einer DB-Sprache zu wurschteln...
SQL CLR scheint eine ziemlich coole Sache zu sein, der Code selbst ist (.Net-like ) rasent schnell. Dumm ist nur, dass die Zugriffe auf die eigentlichen Daten nicht so schnell wie in bloody TSQL ablaufen (verglichen mit Bulk collects aus PL/SQL sind sie sogar lachhaft).
Und ab dem Punkt schlägt ganz schnell meine @-Allergie zu...

Um auch ein wenig zum eigentlichen Problem zu sagen ( ): Wäre es nicht mindestens genauso einfach Packages zu tauschen statt DDL absetzen zu müssen?

[alzaimar]

Danke Robert_G, aber muss ich bei Packagewechsel nicht auch die Mittelschicht stilllegen?
Die RemObjects hab ich mir auch mal (rein optisch) reingezogen, aber noch nicht getestet. Meinst Du, damit gehts?

[Robert_G]

Zitat von alzaimar:

Danke Robert_G, aber muss ich bei Packagewechsel nicht auch die Mittelschicht stilllegen?

Müsstest du das beim Einspielen neuer Prozeduren nicht auch?
In Oracle werden ja (verständlicherweise ) sämtliche Package variablen für alle aktiven Sessions invalidiert.
Sicher kann man den "Ora-0XXX Package XXX has been discarded" beim ersten Zugriff schlucken und den Initialisierungsteil robuster gestalten, aber ich würde nicht meine Hand dafür ins Feuer legen...
Wenn du zum Beispiel Interfaces auf die Klassen in den Packages verwendest, könntest du diese in ein getrenntes "fixes" Package ablegen.
Dieses kannst du statisch in deiner App verlinken, wodurch du fast normal weiterprogrammieren kannst.
Sämtliche Implemetierung hast du nun in austauschbaren Klassen. Beim Austausch der Packages musst du IMHO alle Instanzen zerstören, die auf die alte Version zeigen. Ein simples nil-Setzen der Referenzen genügt hier ja bei Interfaces.
Nun wirfst du die geladenen MetaClasses weg. Das sollte im finalization jedes Packages passieren (UnRegisterClass).
Ein FinalizePackage gefolgt von UnloadPackage sollte dann ausreichen.
Jetzt lädst du die Packages wieder und stellst einen gewissen status quo in der App wieder her.
Das ist alles andere trivial, sollte aber zur Laufzeit nicht mehr als Sekundenbruchteile benötigen.

Zitat von alzaimar:

Die RemObjects hab ich mir auch mal (rein optisch) reingezogen, aber noch nicht getestet. Meinst Du, damit gehts?

Na dann probier's aus.
Das schöne an RO SDK + DataAbstract sind die typisierten DataSets und die Tatsache, dass fast alles über Interfaces gelöst wird.
Das macht das Programmieren angehmer (Du kannst ja Properties verwenden anstatt stupider Field[XX] -> Compilerprüfung!) und die Interfaces helfen dir bei Aktualisierungen...
Schaue auch in den NGs vorbei, Alessandro und Marc werden dir sicher besser weiterhelfen können, als ich nach meinen kleinen Spielereien damit.