Hallo,
ich habe hier eine Frage zur Softwarearchitektur, die am Rande mit Linux/Perl zu tun hat. Aber weil ihr hier alle so schön interdisziplinär zusammensitzt, kann doch was draus werden ;-) Also:
Eine vorhandene, in Perl implementierte Middleware verarbeitet XML-Dateien. Diese werden umgeformt, geteilt und letztenendes an ein anderes System weitergereicht. Das kennen wir ja schon, ich habe euch deswegen schon gelöchert. Nun kommt es gelegentlich zu Laufzeitproblemen derart, das die Information in einem XML sich auf das Vorhandensein der Info in einem anderem XML verlässt. Also A hat eine Ergänzung zu B. Es wird vorrausgesetzt, dass B irgendwann schonmal durch die Middleware gegangen ist und somit im Zielsystem vorhanden ist. Möglicherweise steckt jetzt aber B in einem XML, was in einer halben Stunde vorbeikommt. Die Information A wird somit vom Zielsystem verworfen.
Meine Idee ist jetzt, in irgendeiner Art ein Logbuch zu führen, welches z.B: die Antworten vom Zielsystem auswertet ("B noch nicht vorhanden") und somit die Zustellung von A später wiederholt. Dazu habe ich zwei technische Realisierungen im Auge, kann mich aber für keine entscheiden: 1. Es werden nur die Transactionsinfos in einer Datenbank vorgehalten. Die eigentlichen XMLs stehen bis zur vollendeten Übertragung im Dateisystem. 2. Ich setze eine XML-DB ein (Berkeley DB XML), packe das ganze XML dortrein und ergänze es jeweils um die Transactionsinfos. Wenn die Übertragung perfekt ist, fliegt es wieder raus.
Die zweite Variante scheint mir technisch sauberer und interessanter zu sein. Allerdings scheint diese nach einigen Tests nicht die performanteste zu sein. Die erste Variante ist wohl die klassische Variante und schneller, ich befürchte aber, das es u.U. zu Inkonsitenzen zwischen LOG-Db und wirklich vorhandenen Dateinen kommen kann. Ausserdem muss ich neben den DB-Queries noch eine Reihe von Filesystemoperationen durchführen. Es gibt also mehrere Fehlerquellen.
Kann mir jemand helfen, mir Variante 1 oder 2 ein- oder auszureden ??
Danke.
Mit freundlichen Grüßen
Jens Puruckherr
Hallo Jens,
vielleicht versuchst du einen Mittelweg. Da du die XML Dateien ja in keiner Weise in deinem Transaktionssystem verändern mußt, speichere die doch einfach ganz normal als BLOB oder TEXT in der releationalen Datenbank. Die XML DB ist doch erst dann wirklich interessant, wenn ich schnell/einfach auf einzelne Bestandteile des Dokuments zugreifen will. Du hast damit sowohl die Dateioperationen weg als auch die Konsistenz zwischen Transaktions-Daten und vorhandenen XML-Dokumenten gesichert.
Frank
Jens Puruckherr wrote:
Hallo,
ich habe hier eine Frage zur Softwarearchitektur, die am Rande mit Linux/Perl zu tun hat. Aber weil ihr hier alle so schön interdisziplinär zusammensitzt, kann doch was draus werden ;-) Also:
Eine vorhandene, in Perl implementierte Middleware verarbeitet XML-Dateien. Diese werden umgeformt, geteilt und letztenendes an ein anderes System weitergereicht. Das kennen wir ja schon, ich habe euch deswegen schon gelöchert. Nun kommt es gelegentlich zu Laufzeitproblemen derart, das die Information in einem XML sich auf das Vorhandensein der Info in einem anderem XML verlässt. Also A hat eine Ergänzung zu B. Es wird vorrausgesetzt, dass B irgendwann schonmal durch die Middleware gegangen ist und somit im Zielsystem vorhanden ist. Möglicherweise steckt jetzt aber B in einem XML, was in einer halben Stunde vorbeikommt. Die Information A wird somit vom Zielsystem verworfen.
Meine Idee ist jetzt, in irgendeiner Art ein Logbuch zu führen, welches z.B: die Antworten vom Zielsystem auswertet ("B noch nicht vorhanden") und somit die Zustellung von A später wiederholt. Dazu habe ich zwei technische Realisierungen im Auge, kann mich aber für keine entscheiden:
- Es werden nur die Transactionsinfos in einer Datenbank
vorgehalten. Die eigentlichen XMLs stehen bis zur vollendeten Übertragung im Dateisystem. 2. Ich setze eine XML-DB ein (Berkeley DB XML), packe das ganze XML dortrein und ergänze es jeweils um die Transactionsinfos. Wenn die Übertragung perfekt ist, fliegt es wieder raus.
Die zweite Variante scheint mir technisch sauberer und interessanter zu sein. Allerdings scheint diese nach einigen Tests nicht die performanteste zu sein. Die erste Variante ist wohl die klassische Variante und schneller, ich befürchte aber, das es u.U. zu Inkonsitenzen zwischen LOG-Db und wirklich vorhandenen Dateinen kommen kann. Ausserdem muss ich neben den DB-Queries noch eine Reihe von Filesystemoperationen durchführen. Es gibt also mehrere Fehlerquellen.
Kann mir jemand helfen, mir Variante 1 oder 2 ein- oder auszureden ??
Danke.
Mit freundlichen Grüßen
Jens Puruckherr
Lug-dd maillist - Lug-dd@schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
lug-dd@schlittermann.de on Dienstag, 20. Juli 2004 at 11:28 +0100 wrote:
vielleicht versuchst du einen Mittelweg. Da du die XML Dateien ja in keiner Weise in deinem Transaktionssystem verändern mußt, speichere die doch einfach ganz normal als BLOB oder TEXT in der releationalen Datenbank. Die XML DB ist doch erst dann wirklich interessant, wenn ich schnell/einfach auf einzelne Bestandteile des Dokuments zugreifen will.
Doch, ich verändere die XMLs derart, dass ich aus einem XML je nach Inhalt 2 oder 3 Stück mache und diese dann getrennt übertrage. Wenn das getan ist, wird pro XML noch eine "Fertig"-Tag hinzugefügt, dass ich es nicht noch mal umwandle. Aber das funktioniert ja jetzt auch schon.
Probleme bereiten mir die Syncronisation der Übertragung. Es handelt sich zum Beispiel um Artikel und deren Zubehörartikel. Im Zielsystem kann keine Verknüpfung zu einem Zubehör erfolgen, wenn das Zubehör dort noch nicht existiert. Wenn das Zielsystem jetzt eine Liste von Zubehörverknüpfungen bekommt, kann es vielleicht 2 von 10 Verknüpfungen nicht ausführen, weil die Zubehörartikel noch fehlen. Das sagt es mir und ich putzel mein XML so zurecht, dass nur noch die 2 Verknüpfungen drinne stehn, lege es in die Ecke und sage: du bist erst in 2 Stunden wieder dran! Oder es kommt ein Preisupdate für einen Artikel, der aber noch in seinem XML in der anderen Warteschlange steht und im Zielsystem ebenfalls noch nicht existiert. Das Preisupdate wird jetzt verworfen. Ich will mir das aber merken, das es noch nicht ausgeführt werden konnte, und will es ebenfall in einer halben Stunde nochmal probieren.
Letztenendes muss ich diese ganzen Transaktioninfos und Änderungen an den übertragenen Daten mir nicht in XML merken. Das das Zielsystem aber ebenfalls XML versteht, wäre es auch Quark, das XML in eine interne Form zu bringen und es erst bei der Übertragung ins Ziel wieder zu generieren. Darum meine Überlegung, das mit einer XML-DB zu machen (und natürlich meiner Neugier, wie sowas geht)
Mit freundlichen Grüßen
Jens Puruckherr
Am Do, 22. Jul 2004 08:06:32 +0200, schrieb Jens Puruckherr:
Letztenendes muss ich diese ganzen Transaktioninfos und Änderungen an den übertragenen Daten mir nicht in XML merken. Das das Zielsystem aber ebenfalls XML versteht, wäre es auch Quark, das XML in eine interne Form zu bringen und es erst bei der Übertragung ins Ziel wieder zu generieren. Darum meine Überlegung, das mit einer XML-DB zu machen (und natürlich meiner Neugier, wie sowas geht)
Ich sehe hier zwei sinnvolle Möglichkeiten: 1. XML-Manipulation im Skript und relationale DB o.ä., wie beschrieben. 2. Keine Veränderungen im Skript und alle Manipulationen in der XML-DB machen.
Alles andere ist insofern quatsch, als jede Instanz, die XML manipuliert erstmal die Daten in eine geeignete Form bringen muss. Und auch das Parsen kostet seine Zeit.
Welche der beiden Varianten sich als günstiger erweist, hängt nun wieder von Deinem konkreten Problem ab. Je weniger Manipulationen am XML notwendig sind, umso stärker würde ich 1. als performanter erwarten. Hier kannst Du mit der Wahl Deiner Bibliotheken großen Einfluss auf die Geschwindigkeit nehmen. Hast Du aber große Staus, die Du in vielen kleinen Schritten abbauen musst, kann die XML-DB ihre Stärken wesentlich besser ausspielen. Dann wäre aber auch zu überlegen, ob nicht alle Daten auch schon vor dem Transport in der DB gespeichert werden können.
Tobias.
lug-dd@mailman.schlittermann.de
-
Frank Wenzke -
Jens Puruckherr -
Tobias Schlemmer