Kann das, was Thomas gesagt hat, bestätigen.
Wir benutzen DXL in einem größeren Projekt zur Archivierung.
In DXL - also xml mit Domino.dtd - werden alle Elemente eines Notes Dokuments (inklusive Hot-Spots, Attachments, eingebettete Objekte, etc) in xml umgesetzt. Diese Datei kann dann in das Archiv geschoben werden.
Dies kann im einfachsten Fall das Dateisystem sein.
Diese dxl Datei kann problemlos und jederzeit in ein Notes-Dokument zurück konvertiert werden.
Eingebettete Objekte und Attachments stehen dabei auch zwischen bestimmten tags in dem dxl und zwar als base-64 encoding der binären Daten.
Für Generierung von DXL und erstelle_Notes-Element_aus_DXL existieren Klassen und Methoden und ich schau jetzt nicht extra nach (vielleicht später).
Jedenfalls brauchst du nicht das xml Toolkit, weil das nur für 5 war.
Allerdings ist die menschenlesbarkeit von xml sehr anstrengend. Wir setzen deshalb zusätzlich zur Ansicht (und zur Archivierung von zahlreichen Dateitypen wie MS-Word, MS-Excel, Visio, noch einiges mehr) PDF-Generierung ein.
Darüber hinaus haben wir noch einige für Archivierung vermutlich generell interessante Zusatzfeatures dabeigebaut:
Wir speichern ausserdem die Attachments und eingebetteten Objekte noch einmal separat und konvertieren viele Dateitypen in PDF und jagen die vorher durch einen Volltextsuche-Indexierer.
Bestimmte Felder des Notes Dokuments werden auch durch den Indexierer gejagt (für Schlagwortsuche).
Vom Notes Dokument wird auch ein PDF Abbild gezogen.
Eine Suche geht also über vordefinierte Schlagwörter und über Volltext. Dafür gibt es eine Notesmaske, die Webservices, einen IE als OLE-Objekt, etc. benutzt. Ja, es läuft stabil.
Die Kommunikation zwischen den Notes Datenbank und den Archivierungsservices läuft über Webservices.
Die Archivierungsservices selbst laufen auf Tomcat, benutzen viele Java openSource Geschichten (Volltextsuche, XML-Datenbank, Webservices, Webframework, Scheduling von Prozessen) und 2 nicht unbedingt triviale Anwendungen von uns selber.
Der Nachteil von DXL (und unserer Lösung allgemein) sind,
- dass man ziemlich viel Speicherplatz benötigt (DXL allgemein, viel Information redundant als dxl und PDF). Speicherplatz wird aber immer billiger und ist schon ziemlich billig.
- Webservices sind auch nicht gerade ein Performancekiller auch wenn man den übertragenen Stream zippt. Für viele Archivierungsaufgaben benötigt man aber keine Killer-Performance.
Der Bedarf des Kunden für Archivierung liegt vornehmlich in einer größeren Übersichtlichkeit der Anwendung für die User und nicht im Sparen von Speicherplatz
Die Vorteile von dieser Lösung sind,
- dass für den Anwender eine Wiederherstellung aus dem Archiv leicht möglich ist und es eine sehr komfortable Archivsuche gibt mit PDF als Vorschau.
- sehr lose Bindung zwischen Notes DB und Archivierungsservice und der Komponenten untereinander bietet eine flexible Architektur, wo auf Änderungen der Archivierungspolitik der Organisation gut reagiert werden kann (s.u.). Bestimmte Funktionalität kann auch isoliert von den anderen benutzt werden (z.B. serverseitige PDF Generierung)
Es läuft soweit sehr stabil. Wir versuchen jetzt noch die Skallierungs-Constraints-Grenzen nach aussen zu verschieben. Bei sehr, sehr vielen DXL-Konvertier Operationen hintereinander, existiert möglicherweise ein Memory Leak auf Notes Seite. Das lässt sich aber managen und beruht - wenn ich das Mittwoch in meinem urlaubsreifen Kopf richtig verstanden habe - auf einem offiziellen Notes-Bug.
Aus Sicht der Anwendung extrem große Attachments (größer als 300 MB) sind bisher auch noch nicht getestet.
Wg. der langfristigen Archivierungs-Politik des Kunden sollen nun die Archivdokumente nicht mehr in einer xml DB abgelegt werden, sondern in IBM Storage Server (oder wie das heisst). Dadurch dass Client-Seite und Server Seite der Archivierung nur durch standardisierte Webservices gekoppelt sind, lässt sich dies relativ leicht nachträglich erweitern.
Gruß Axel
