Documentum Foundation Services – Fluch oder Segen? Teil II
Apr 22, 2010 | by jgoldhammer | 1 Comments

Im 1. Blogartikel zu Documentum Foundation Services, kurz DFS, wurde das Datenmodell und die enthaltenen Standarddienste von DFS betrachtet. Am Ende des 1. Artikels wurde angedeutet, was in diesem Artikel zur Sprache kommen soll:

  • Wie überhaupt funktioniert DFS?
  • Was muss ich im Vergleich zur Documentum Foundation Classes, kurz DFC, beachten?

Die technische Basis von DFS sind Web Services, ein Begriff für mehrere Technologien, die in diesem Umfeld zum Tragen kommen. Durch den elementaren Unterschied des Kommunikationsprotokolls von Remote Procedure Calls (RPC) bei DFC und dem nachrichtenbasierten Kommunikationsprotokoll bei DFS ist ein Paradigmenwechsel beim Datenaustausch eingetreten. DFS verlangt es, sich mehr Gedanken darüber zu machen, wann welche Daten vom Repository abgerufen und zum Repository verschickt werden, um eine performante Anwendung zu entwickeln. Voraussetzung für diesen Artikel sind Kenntnisse in Web Services. Mehr Informationen zu Web Services sind hier zu finden.

Konfiguration und Installation der Documentum Foundation Services

Die DFS-Anwendung ist eine J2EE-Webapplikation auf Basis von Servlets und kann auf den von EMC unterstützten J2EE-Server installiert werden. Die Zahl der unterstützten Server in den Release Notes ist groß- der JBOSS Application Server 4 wird jedoch von EMC empfohlen und wird auch bereits in einem Installationspaket mitgeliefert.

Da DFS über die DFC kommuniziert (dazu später mehr), müssen in dem Auslieferungspaket Konfigurationsänderungen vorgenommen werden. In der EAR (Enterprise Application Archive)-Datei befindet sich die Konfigurationsdatei dfc.properties, in der alle notwendigen Einstellungen (Docbroker, Global Registry, DFC Einstellungen) vorgenommen werden müssen. Dafür ist es notwendig, das EAR-File zu entpacken, die Änderungen vorzunehmen und dann wieder zu packen. Danach einfach die EAR-Datei auf dem Server deployen, Server starten und fertig. DFS ist jetzt schon bereit, genutzt zu werden. Welche Funktionen genutzt werden können, erfahren Sie im ersten Blogartikel zum Thema DFS.

Kommunikation und Verarbeitung mit den Documentum Foundation Services

DFS als Serverkomponente muss ständig bereit sein, Anfragen einer Clientkomponente entgegen zu nehmen und zu verarbeiten. DFS baut daher auf dem Java-Standard-Webserviceframework JAX-WS (https://jax-ws.dev.java.net/) auf, um die Kommunikation mit Webserviceclients zu ermöglichen und die Umwandlung der ankommenden SOAP-Nachricht nach Java und umgekehrt zu bewerkstelligen.

Innerhalb der DFS-Anwendung ist die eigentliche Logik der einzelnen Dienste wie z.B. dem Queryservice und dem Objectservice implementiert. Diese Logik mappt die Funktionen der Operationen der einzelnen DFS-Dienste auf die Funktionen der DFC. Welche DFC-Funktionen in welcher Art und Weise genutzt werden, bleibt dem Nutzer verborgen. Der Quellcode von DFS liegt nicht offen, d.h. man erkennt nicht, wie die Funktionen umgesetzt sind. Lediglich die Logfiles geben ein wenig Aufschluss darüber, was im Hintergrund passiert.

DFS kann bei einigen wenigen Operationen Caches nutzen, um z.B. die Ergebnisse einer Suchanfrage für eine bestimmte Zeit vorzuhalten und eine erneute Suchausführung zu vermeiden. Dies ermöglicht z.B. ein schnelles Paging der Suchergebnisse.

Die Kommunikation und Verarbeitung mit dem DFS-Webservice soll anhand eines Beispiels in Abbildung 1verdeutlicht werden.

dfs_kommunikation

Abbildung 1: Kommunikationsablauf bei DFS

  1. Eine Java-Applikation möchte z.B. für einen angemeldeten Nutzer die vorhandenen Cabinets in einem Repository per DQL abrufen. Codelisting 1 zeigt, wie von der Java-Applikation aus mit dem Queryservice der DFS kommuniziert werden kann. Es wird dabei ein SOAP-Client im Speicher erzeugt, um über HTTP(S) eine SOAP-Nachricht an den DFS-Service zu versenden und auch die Ergebnisse zu verarbeiten. Die daraus generierte SOAP-Nachricht, die über HTTP(s) an DFS versendet wird, ist in Codelisting 2 dargestellt.
  2. Die SOAP-Nachricht ist nun über ein Servlet der DFS-Anwendung im Applicationserver angekommen und wird durch das Framework JAX-WS in Javaobjekte umgewandelt. Die Anfrageparameter stehen nun in Form von Javaobjekten zur Verarbeitung zur Verfügung.
  3. Nun greift die entsprechende Logik, die per DFC-API die Suche gegen das angegebene Repository ausführt. Dabei wird die Suche unter dem Nutzer ausgeführt, der beim Abruf des Service übergeben wird.
  4. Die Ergebnisse der Suche werden vom Content Server an die DFS-Applikation zurückgegeben und können nun in das entsprechende Java DFS-Datenmodell verpackt werden.
  5. Ob die Suchergebnisse im Cache abgelegt werden, lässt sich beim Abruf von der Javaapplikation aus steuern.
  6. Die Ergebnisse in Form von Javaobjekten werden nun wiederum in XML, genauer gesagt in das SOAP-Schema, umgewandelt und an die Javaapplikation über HTTP zurückgesendet. Die Java-Applikation kann nun die Ergebnisse verarbeiten und z.B. diese dem Nutzer an der Oberfläche darstellen.

listing_11

Codelisting 1: Java-Client zum Abruf der Cabinets mit Hilfe des Queryservice von DFS (Beispiel aus der DFS Dokumentation entnommen und modifiziert)

soap_nachricht

Codelisting 2: Beispiel für eine SOAP-Nachricht der Operation execute im Queryservice via HTTP (Beispiel aus der DFS Dokumentation entnommen und modifiziert)

Unterschiede zwischen Documentum Foundation Services (DFS) und Documentum Foundation Classes (DFC)

Das oben dargestellte Beispiel lässt die Vermutung aufkommen, dass DFS im Prinzip genauso benutzt werden kann wie die DFC, denn schließlich verwendet DFS die DFC im Hintergrund ebenso (wie wir gerade gelernt haben).

Dass dies nicht so ist, wurde schon am Anfang des Artikels deutlich: DFS ist und kann im Standard bei weitem nicht so performant wie die DFC sein. Schließlich ist DFS eine weitere Kommunikationsschicht zwischen dem Content Server, der DFC-Kommunikation und der eigenen Anwendung. Vor allem die Umwandlung der SOAP-Nachrichten, die sehr groß werden können (z.B. Abruf von 37.000 OrdnerobjektIds und deren Ordnerpfade ergibt z.B. eine 1,2 Mb große SOAP-Nachricht) und deren Übertragung kostet Zeit. Jeder Aufruf zum Contentserver bringt einen gewissen Overhead mit, der bei der DFC allein jedoch nicht ganz so stark ins Gewicht fällt.

Die Performance ist sicherlich sehr wichtig, jedoch unterscheiden sich DFS und DFC in anderen Punkten ebenso. Aus diesem Grund werden DFS und DFC in der Tabelle 1 anhand einiger Kriterien zusammenfassend gegenübergestellt.

dfc_dfs_vergleich

Tabelle 1: Gegenüberstellung DFC und DFS

Fazit

Dieser Artikel gibt einen Überblick zur Installation und zur Funktionsweise der Documentum Foundation Services, insbesondere zum Kommunikationsablauf. Deutlich wird, dass zwar einerseits die Komplexität in der Nutzung für Documentum-Einsteiger verringert wird, die DFS-API an sich ist leicht verständlich. Andererseits muss bei der Entwicklung mit DFS von Anfang einige Punkte, vor allem die Performance, beachtet werden. Wie man das Performance-Problem in den Griff bekommen kann und welche Dinge es noch zu beachten gibt, erfahren Sie im letzten Blogartikel zum Thema DFS.