Fortsetzung: Verteilbarkeit in Documentum
Branch Office Caching Services (BOCS)
Wenn die Hoheit über den Content bei den Standorten selbst liegen soll, also dort eigene Repositories zum Einsatz kommen, ist der Einsatz von Remote Content Servern nur bedingt sinnvoll. Wenn Standorte A und B jeweils eigene Repositories haben sollen, dann müsste der Content von A nach B und von B nach A repliziert werden, d. h. es müsste an jedem Standort ein Remote Content Server eingesetzt werden, damit der Zugriff für beide Standorte auf das Repository des jeweils anderen Standorts beschleunigt wird.
Auch kann es vorkommen, dass die Entfernungen zwischen dem Remote Content Server und den Client-Standorten immer noch relativ groß sind und ggf. immer noch Netzwerkprobleme für Probleme beim Datentransfer sorgen.
Um den Zugriff auf den Content direkt am Client Standort zu beschleunigen, ist der Einsatz von „Branch Office Caching Services“ (BOCS) Servern vorgesehen.
Der Einsatz von BOCS Servern beschleunigt den Zugriff auf Dokumente, indem ein einmal abgerufenes Dokument auf dem BOCS Server zwischengespeichert wird. Beim nächsten Abruf muss das Dokument nicht noch einmal vom Content Server geladen werden, sondern wird direkt vom BOCS Server abgerufen, der sich möglichst nah am Standort des Clients befinden sollte.
In einem Szenario wie zu Beginn dieses Abschnitts beschrieben, in dem Standorte eigene lokale Repositories besitzen, kann der Einsatz von RCS und BOCS Servern auf beiden Seiten erforderlich sein, um eine hohe Performanz an allen Standorten zu gewährleisten, unabhängig davon, ob auf das lokale oder das Remote Repository zugegriffen wird.
Ein solches Szenario wird in folgender Abbildung dargestellt.
Content Pre-Caching
Der erste Abruf von Content, der sich noch nicht im Zwischenspeicher des BOCS Servers befindet, erfolgt auch hier über den ACS Server. Damit auch für diesen Fall die Vorteile des BOCS Servers zum Tragen kommen, steht das Feature „Content Pre-Caching“ zur Verfügung.
Der Zweck von Content Pre-Caching (auch als Predictive Caching bezeichnet) ist es, den Zugriff auf eine Teilmenge von Dokumenten generell zu beschleunigen. Dies wird erreicht, indem Dokumente auf dem BOCS Server zwischengespeichert werden, bei denen sicher ist, dass besonders häufig auf sie zugegriffen wird.
Um festzustellen, welche Dokumente dafür in Frage kommen, müssen Regeln definiert werden. Diese können entweder mittels eines Pre-Caching Jobs definiert werden, oder sie werden programmatisch hinterlegt. Zur Bildung von Regeln können Kriterien wie Dokument-Eigenschaften, der Standort des Nutzers und die Auswertung von Work Queues dienen.
Pre-Caching Jobs werden mit Hilfe des Documentum Administrator Tools konfiguriert. Sie werden regelmäßig ausgeführt und kopieren regelbasiert Dokumente vom Content Server auf den BOCS Server. Die zu cachenden Dokumente werden definiert, indem entweder Attribut- und Wertepaare oder eine DQL Abfrage hinterlegt werden. Die Definition von komplexeren Regeln erfordert die Erstellung eines eigenen Jobs. Für diesen Zweck stellt die Documentum API (Documentum Foundation Classes, kurz DFC) das Interface „IDfPrecachingOperation“ zur Verfügung.
Accelerated Write
Der BOCS Server kann so konfiguriert werden, dass Content nicht nur gelesen, sondern auch zurück in das Repository geschrieben werden kann.
Es gibt zwei Varianten des „Accelerated Write“.
1. Synchronous Write
Check-In und Import erfolgen direkt über ACS und BOCS. Die Metadaten werden über den Webtop Application Server an den Content Server geschickt.Vorteil: Performance ist besser, da kein Umweg über den Application Server stattfindet. Der importierte bzw. eingecheckte Content steht sofort allen Nutzern zur Verfügung.
2. Asynchronous Write
Check-In und Import erfolgen mit zeitlicher Verzögerung, d. h. der Content wird auf dem BOCS Server „geparkt“ und jobgesteuert an den Content Server übertragen. Die Metadaten werden sofort über den Webtop Application Server an den Content Server geschickt.
Erfordert den Einsatz eines „Documentum Messaging Services“ (DMS) Servers
Vorteil: Sehr hohe Performance am Client-Standort des zugeordneten BOCS Servers. Der Nutzer kann sofort weiterarbeiten, obwohl der Content noch nicht auf den Content Server hochgeladen worden ist. Der Content wird, nachdem er eingecheckt wurde, Bestandteil des BOCS Server Caches. Nutzer, die ebenfalls über diesen BOCS Server arbeiten, haben sofort Zugriff auf diesen Content.
Nachteil: Solange der Content auf dem BOCS Server „geparkt“ ist, können nur Nutzer dieses BOCS Servers darauf zugreifen. Nutzer anderer Standorte haben die Änderung nicht verfügbar. Sie sehen nur den Content, der auf „ihrem“ BOCS Server geparkt wurde, bzw. der sich auf dem Content Server befindet. Erst wenn der entsprechende Job den geparkten Content auf den Content Server übertragen hat, können alle Anwender darauf zugreifen.
Ob das Einchecken von Content synchron oder asynchron geschehen soll, kann entweder innerhalb der Applikation festgelegt werden, oder es wird vom Nutzer mit Hilfe eines entsprechenden Dialogs abgefragt.
DMS
Der bei der Beschreibung des Pre-Caching und Asynchronous Write erwähnte „Documentum Messaging Services“ (DMS) Server ist ein Messaging Routing Server. Er wird für die Verteilung von internen „Nachrichten“ zwischen Content Server, Webtop Application Server und BOCS Server verwendet, wenn die Funktionen „Content Pre-Caching“ und „Asynchronous Write“ eingesetzt werden. Der DMS Server würde wie der Datenbankserver ebenfalls am zentralen Standort installiert werden.
Verschlüsselung
Der BOCS Server kann so konfiguriert werden, dass Dokumente verschlüsselt abgelegt werden. Es steht derselbe Verschlüsselungsalgorithmus zur Verfügung, wie ihn der Content Server verwendet.
Hinweise
Der Einsatz von ACS und BOCS ist für Dokumente, die ein Pre-Processing erfordern, nicht möglich. Ein Pre-Processing ist bei folgenden Arten von Dokumenten erforderlich:
- Virtuelle Dokumente
- XML Dokumente
- OLE Verbunddokumente
- Dokumente, deren Content mittels Type Based Objects (TBO) verändert wird (beispielsweise durch Aufbringen von Wasserzeichen; Ausnahme: Wasserzeichen werden mittels Documentum Compliance Manager (DCM) erzeugt, was seit Documentum 6.5 unterstützt wird).
Die Anforderung des Contents solcher Dokumente wird in diesem Fall direkt an den Webtop Application Server weitergeleitet.
Wenn ACS oder BOCS eingesetzt werden, muss die Documentum WDK/Webtop Applikation im UCF-Modus betrieben werden. Der HTTP-Modus kann nicht verwendet werden.
Zusammenfassung
Abschließend werden die Vor- und Nachteile der zuvor beschriebenen Verfahren und Techniken zum Aufbau einer verteilten Umgebung zusammenfassend dargestellt:
Accelerated Content Service (ACS)
Vorteile
- Content wird direkt vom Content Server zum Webbrowser des Clients übertragen (ohne Umweg über Application Server), dadurch Verbesserung der Performance.
- Ist Bestandteil der Content Server Installation und verursacht keine weiteren Kosten.
Nachteile
- Keine Verwendung für Dokumente, die Pre-Processing erfordern.
Remote Content Server (RCS)
Vorteile
- Performanter Zugriff auf Content aufgrund geografischer Nähe zum Client Standort
- Performanter Einsatz Desktop-basierter Clients möglich
Nachteile
- Administrationsaufwand (Überwachung Replikationsjobs in der Zentrale, Administration am Standort des Remote Servers erforderlich)
- Kosten für Anschaffung und Hosting der Server.
Branch Office Caching Services (BOCS)
Vorteile
- Verbesserung der Performance beim Abrufen von Content direkt am Standort des Clients (weitere Verbesserung durch Content Pre-Caching möglich)
- Beschleunigung von schreibenden Zugriffen mittels „Accelerated Write“. Nochmalige Verbesserung durch Einsatz von „Asynchronous Write“ (Content wird auf den BOCS Server übertragen, der dem Client am nächsten steht; Client kann weiterarbeiten, während der Content auf dem BOCS Server „geparkt“ ist und mittels Job anschließend auf den Content Server übertragen wird.)
Nachteile
- Keine Verwendung für Dokumente, die Pre-Processing erfordern.
- Administrationsaufwand bei Einsatz mehrerer BOCS Server
- Kosten für Anschaffung Server, Hosting und BOCS Server Lizenzen.
Weitere Informationen
