Das Request for Comments (RFC 2518), in dem WebDAV beschrieben wird, stammt noch aus dem letzten Millennium. In Jahr 1999 wurde der RFC freigegeben und danach durch eine Reihe von Erweiterungen ausgebaut. Die Grundidee von WebDAV erweitert das HTTP-Protokoll um die Fähigkeit, Dokumente nach der Bearbeitung zurückschreiben zu können. Letztlich lassen sich mit WebDAV Dateisysteme aufbauen, die eben HTTP für den Transport der Daten nutzen. Hierzu gehören auch Funktionen, welche etwa die Verwaltung von Ordnerstrukturen, Dateieigenschaften und die Verwaltung eines Mehrbenutzerbetriebs ermöglichen.

Die Windowsbetriebssysteme ab Windows 2000 unterstützen WebDAV mit den so genannten Webordnern; Mac OS X bietet ein eigenes Dateisystem (WebDAV FS) und auch viele Linux- und Unix-Installationen können mit teilweise Open Source-basierten Dateisystemen erweitert werden. Daneben existiert eine Vielzahl von Anwendungen, die WebDAV direkt unterstützen, wie etwa MS Office oder sämtliche Adobe-Produktreihen. Neben diesen Client-Anwendungen findet sich WebDAV auch in Serveranwendungen, wie etwa dem MS IIS, dem Apache Webserver und Produkten wie MS Sharepoint Portal Server. Eine Liste von Anwendungen finden Sie z.B. auf www.webdav.org.

Bevor wir nun mit der konkreten Arbeit für die Implementierung eines WebDAV-Clients beginnen, sollten Sie sich mit einigen Begrifflichkeiten und Details des technischen Aufbaus von WebDAV beschäftigen.

Ressourcen und Collections

Grundsätzlich verwaltet WebDAV so genannte Ressourcen, die sich in Collections zusammenfassen lassen. Eine Collection ist dabei letztlich eine besondere Form der Ressource. Sie können Ressourcen mit Dateien und die Collections mit den Verzeichnissen in einem Dateisystem vergleichen. Oft existiert hier auch ein physikalischer Zusammenhang, aber ein WebDAV-Server kann seine Ressourcen natürlich auch anders verwalten, z.B. in einer Datenbank. Ähnlich einem Dateisystem entsteht damit auch in WebDAV eine Baumstruktur, die sich aus Collections mit Unter-Collections und Ressourcen zusammensetzt.

Beide Grundelemente besitzen jeweils eine Reihe von Eigenschaften. Neben dem Namen und dem Pfad (in WebDAV durch einen URL dargestellt) lassen sich die Eigenschaften auch benutzerbezogen beliebig erweitern. Die WebDAV-Properties sind daher unterteilt in die Standard-Eigenschaften und die so genannten Custom Properties. Die Eigenschaften werden entweder als zusätzliche Header-Felder in einer HTTP-Response dargestellt oder erscheinen als XML-Entitäten im Payload.

Für die Verwaltung der Grundelemente steht eine Reihe von Befehlen zur Verfügung, wie MKCOL zum Anlegen von neuen Collections oder PROPFIND bzw. PROPPATCH für Aufruf bzw. Änderung von Eigenschaften. Hinzu kommen Funktionen zum Abrufen, Löschen bzw. Ändern von Ressourcen- bzw. Collection-Inhalten (GET, DELETE, PUT/POST). Schließlich gibt es Funktionen, welche das Kopieren bzw. das Verschieben von Inhalten direkt auf der Serverseite ermöglichen (COPY und MOVE).

Da die Befehle sich teilweise auf Teilbäume der Struktur beziehen können, kann die rekursive Tiefe jeweils angegeben werden. So ruft der PROPFIND-Befehl, angewendet auf die Wurzel einer WebDAV-Struktur ohne die Angabe der rekursiven Tiefe alle Eigenschaften der jeweils tiefer liegenden Elemente und deren Unterelemente ab.

Kollaboration und Versionierung

Für eine Zusammenarbeit mehrerer Benutzer an einem einzigen Dokument muss eine Möglichkeit zur Sperrung von Ressourcen gegeben werden. Hiefür gibt es die Befehle LOCK und UNLOCK, um einem Benutzer den exklusiven oder geteilten Zugriff zu gewähren. WebDAV nutzt dabei so genannte Locktoken, die jeweils die Sperrung eines bestimmten Elements kennzeichnen und die durch den Server vergeben werden. Clients müssen das Token als zusätzliche Eigenschaft bei jeder nachfolgenden Befehlsanforderung beifügen.

Ein WebDAV-Server sollte das Überschreiben einer Ressource zulassen und muss dabei keine Versionierung durchführen. Das RFC 3253 beschreibt hierzu eine Erweiterung von WebDAV, die die typischen Funktionen wie Checkout und Checkin beschreibt.

Die Basisfunktionen und die Arbeit in einem Mehrbenutzersystem (Locking) unterteilt WebDAV in die so genannten Compliance-Klassen. Die Basiselemente gehören zur Class 1, die erweiterten Funktionen wie das Locking werden nur von Class 2-Systemen unterstützt.

Sicherheit

Ein Sicherheitssystem wird von WebDAV selbst nicht realisiert. Da WebDAV eine Erweiterung des HTTP-Protokolls darstellt und sich ein Serversystem oft auf einer vorhandenen Infrastruktur abstützt (Plugin im Webserver), nutzt WebDAV die vorhandenen Sicherheitsmechanismen. So kommen hier letztlich die HTTP-eigenen Mechanismen zum Tragen (Basis-Realm, NTLM etc.). In Bezug auf ASP.NET macht die Nutzung von Forms Authentication sicherlich keinen Sinn, da die Client-Anwendungen zwar auf HTTP aufsetzen, in der Regel aber keine HTML-Formulare verarbeiten können.

HTTP intern

Das HTTP-Protokoll ist technisch gesehen ein reines Textformat. Die Technologie ist so gewählt, dass die Verbindung zwischen einem Client und einem Server möglichst kurz geöffnet bleibt, sodass ein Server in der Lage ist, eine Vielzahl von Clients quasi parallel mit Dokumenten zu versorgen.

Möchte ein Client eine HTTP-Anfrage (Request) an einen Server senden, beginnt der Ablauf mit dem Aufbau einer TCP-Verbindung zum Server. Standardmäßig wird die Anfrage dabei an den Port 80 gerichtet. Der Server nimmt die Verbindungsanfrage entgegen, sendet aber keinerlei Bestätigung oder Ähnliches. Nun sendet der Client einen so genannten HTTP-Request an den Server:

1. GET /dokuments/index.html HTTP/1.0
2. User-Agent: theClient, v1.0
3. SomeHeader: 123

Dieser Request besteht aus einer Reihe von Textzeilen, die jeweils mit Carriage Return abgeschlossen sind. Das Ende wird dabei mit einer Leerzeile markiert. Die erste Zeile enthält nach dem Befehl (hier GET) den URL der angeforderten Ressource. Die nachfolgenden Zeilen enthalten jeweils die so genannten Header: Schlüssel/Wertpaare jeweils durch Doppelpunkt getrennt:

1. POST /scripte/register.aspx HTTP/1.0
2. Content-Length: 24
4. myField=Eingabe&ID=12345

Aufgrund der Angabe des Headers Content-Length und einer Zahl liest der Server nach dem Abschluss des Request-Blocks die entsprechende Anzahl von Zeichen; hier etwa die geposteten Daten eines HTML-Formulars an eine ASPX-Seite.

Nach dem Einlesen des Requests beginnt der Server mit der Verarbeitung und sendet dem Client einen entsprechenden Response-Block zurück. Dieser Block teilt sich in den Response-Header und oft in einen zusätzlichen Payload-Bereich:

1. HTTP/1.0 200 OK
2. Content-Type: text/html
3. Content-Length: 123
5. <html><head> ...

Im Response-Header enthält die erste Zeile das Ergebnis der Anforderung (hier 200 OK).Sicherlich kennen Sie aber auch den berüchtigten 404 Fehler, eigentlich nur ein simpler Response-Code. Danach folgen die einzelnen Headerzeilen, eine Leerzeile und schließlich der Payload-Bereich. Der Header Content-Length ist zwar eigentlich vorgeschrieben, wird aber nicht immer gesetzt. Dynamische Seiten haben ja unter Umständen keine feste Länge und für eine Angabe der richtigen Länge müsste die Seite komplett gepuffert werden, bevor Daten gesendet werden könnten. Das Fehlen der Längenangabe ist aber nicht wirklich problematisch, da der Server nach der Übergabe der Payload-Daten die Verbindung kappt.

Nun tritt in der Regel die Anwendung in Erscheinung und wird die Payload-Daten dem Benutzer präsentieren. Im Falle eines Webbrowsers werden die Daten als HTML geparst und sämtliche zusätzlichen Ressourcen (wie Bilder, Skripte etc.) jeweils mit separaten HTTP-Anforderungen nach dem gleichen obenstehenden Schema abgerufen.

XML und HTTP

Beginnen wir nun damit, eine WebDAV-Anwendung mittels .NET zu realisieren. Dabei beschränken wir uns auf eine Client-Anwendung. Wie bereits angedeutet ist WebDAV nichts anderes als die Erweiterung des HTTP-Protokolls, dem hier eine Reihe neuer Befehle hinzugefügt wurde. Daneben wurde die Semantik einiger bestehender Befehle erweitert. Wenn Sie bisher keine Erfahrungen mit dem technischen Aufbau von HTTP sammeln konnten, lesen Sie bitte zuerst die Ausführungen im Kasten HTTP intern.

WebDAV definiert ein Set von neuen Befehlen, die mittels einer HTTP-Anforderung versendet werden. Daneben kommen eine Reihe von Request- bzw. Response-Headern hinzu, die entweder bestimmte Eigenschaften von Elementen darstellen oder die Befehle parametrisieren. Grundsätzlich gilt, dass alles, was HTTP kann, auch durch WebDAV möglich ist. Für den Abruf einer Datei etwa wird einfach ein normales HTTP-GET verwendet. Hierbei ist dann z.B. der URL einfach einer der Parameter des GET-Befehls.

Einige der zusätzlichen Befehle erfordern allerdings die Angabe von weitaus komplexeren Parametern. Hierbei kommt dann auch zum Tragen, dass sich Befehle teilweise auf ganze Gruppen von Ressourcen beziehen können. Für die Angabe der Parameter wird dann ein XML-Fragment genutzt, das im Payload-Bereich des HTTP-Requests übergeben wird. Ebenso antwortet der Server mit einem XML-Fragment im Response. Für die Weitergabe von Status-Informationen bzw. Fehlern wird eine Vielzahl von neuen Response-Codes definiert, die entsprechend von einer Client-Anwendung verarbeitet werden müssen.

Hallo Server - Ein WebDAV-Client

Im Rahmen dieses Artikels ist eine Menge an Beispielcode entstanden, der als Basis für Ihre weiteren Entwicklungen dienen kann und den Sie auf der Heft-CD finden. Für die Nutzung von WebDAV auf der Clientseite wurde eine Library erstellt, die die internen Abläufe weitgehend kapselt. Wenn Sie mit der Bibliothek experimentieren möchten, brauchen Sie einen WebDAV-Server, den Sie vermutlich durch den Microsoft IIS bereits besitzen. Bei der Einrichtung sollten Sie hier ein virtuelles Verzeichnis anlegen und diesem auch die Rechte Schreiben und Durchsuchen zuordnen. Hier ist es dann wahrscheinlich auch sinnvoll, die Verzeichnissicherheit (Basic oder Windows Integriert) zu aktivieren. Dem Aufbau einer serverseitigen WebDAV-Implementierung werde ich mich in einer der nächsten Ausgaben widmen.

Die Idee der WebDAV Client Library war es, ein Interface zu schaffen, das sich im Wesentlichen an den .NET-Klassen FileInfo bzw. DirectoryInfo orientiert. Hiermit kann eine Anwendung, welche mit Hilfe der beiden .NET Klassen auf das Dateisystem zugreift, mit geringem Aufwand auch einen WebDAV-Server nutzen. Eine schematische Darstellung des öffentlichen Teils der Library finden Sie in Abpictureung 1. Die Klasse WebDavServer stellt mit Open() die Verbindung zum WebDAV-Server her. Danach kann über die Eigenschaft RootCollection auf die Collection in der Wurzel zugegriffen werden. Dabei liefert RootCollection ein Objekt vom Typ WebDavCollectionInfo zurück. Die Klasse WebDavCollectionInfo erbt von FileSystemInfo und ist selbst die Basisklasse von WebDavItemInfo. Dieser Weg der Vererbung wurde gewählt, da sich dadurch die Implementierung deutlich vereinfacht hat. Letztlich ist der Unterschied zwischen einer WebDAV Collection und einer so genannten Non-Collection WebDAV-Ressource minimal - und die Fallunterscheidung in der Collection vorzunehmen, war deutlich einfacher. Vom Standpunkt der Objekt-Orientierung aus vielleicht ein wenig unsauber, pragmatisch in Bezug auf die Implementierung allerdings durchaus in Ordnung. Bezogen auf die implementierten Methoden ähneln die Interfaces den entsprechenden Methoden von DirectoryInfo bzw. FileSystemInfo, allerdings gibt z.B. die Methode GetFiles( ) von WebDavCollectionInfo ein Array von WebDavItemInfo Objekten zurück. Sprich: In einer Anwendung, die die Client Library nutzen soll, müssen die Typen entsprechend angepasst werden. Die Methoden-Aufrufe einer Anwendung, die zuvor direkt mit einem Dateisystem gearbeitet hat, müssen allerdings nicht angepasst werden. Jedoch müssten eine Reihe von Abläufen angepasst werden. Beachten Sie hier bitte, dass eine Reihe von Funktionen (z.B. die Nutzung von searchPattern) bisher noch nicht vollständig implementiert wurden. Ebenso ist die Methode Create einer Collection nicht implementiert, hierzu muss CreateSubDirectory genutzt werden. Daneben ist zu beachten, dass die Daten einer Collection oder einer Ressource (WebDavItem) grundsätzlich erst auf Anfrage (siehe Methode Load bzw. Refresh) geladen werden, da hier jeweils ein Round Trip zum Server erforderlich ist. Auch die Änderung von WebDAV-Properties ist bisher noch nicht implementiert (siehe CommitProperties). In Listing 1 finden Sie ein Code-Fragment, welches die Client Library nutzt. Hierbei wird zuerst die Verbindung zum WebDAV-Server hergestellt und dann das Root-Verzeichnis in einer TreeView dargestellt. Ein vollständiges Beispiel für die Nutzung der Client Library finden Sie im Projekt WebDavClientWindows und im Projekt WebDavClientPPC. Bei letzterem wurden die Library und der Client für einen Pocket PC erstellt (siehe dazu auch Abb. 2). Listing 1

1. Public Sub Connect(ByVal serverUrl As String, ByVal username As String, ByVal password As String)
2. m_webdavserver = New WebDavServer
3. m_webDavRootCollection = m_webdavserver.Open(serverUrl, username, password, false, "")
4. Me.m_tree.Nodes.Clear()
5. If Not m_webDavRootCollection Is Nothing Then
6. RefreshTree()
7. End If
8. End Sub
10. Public Sub RefreshTree()
11. Dim rootItemNode As New TreeNode
12. rootItemNode.Text = m_webDavRootCollection.URL
14. m_tree.Nodes.Clear()
15. m_tree.Nodes.Add(rootItemNode)
16. RefreshCollection(m_webDavRootCollection, rootItemNode.Nodes)
17. End Sub
19. Private Sub RefreshCollection(ByVal WebDavCollection As WebDavCollectionInfo, ByVal nodesList As TreeNodeCollection)
20. Dim subCollections() As WebDavCollectionInfo
22. WebDavCollection.Load()
23. subCollections = WebDavCollection.GetDirectories()
25. Dim Coll As WebDavCollectionInfo
26. For Each Coll In subCollections
27. nodesList.Add(New CollectionTreeNode(Coll))
28. Next
30. Dim items() As WebDavItemInfo
31. items = WebDavCollection.GetFiles()
33. Dim Item As WebDavItemInfo
34. For Each Item In items
35. nodesList.Add(New ItemTreeNode(Item))
36. Next
37. End Sub

Let's talk WebDAV

Interessanter wird es nun bei der Betrachtung der internen Klassen. Hier wird nun wirklich das WebDAV-Protokoll auf der Clientseite implementiert. Auch hierzu finden Sie eine schematische Darstellung, und zwar in Abpictureung 3. Das .NET Framework bietet bereits Klassen für die Realisierung von HTTP-Anfragen (HttpWebRequest und HttpWebResponse). Beide leiten sich von zwei generischen Klassen ab (WebRequest bzw. WebResponse). Wenn Sie mit diesen Klassen bereits gearbeitet haben, wissen Sie, dass für die Initiierung einer Anfrage immer ein Objekt vom Typ WebRequest genutzt wird. Anhand des Protokollanteils (http://) wird hier ein entsprechendes Request- bzw. Response-Objekt erzeugt. Die Idee ist dabei, dass über die gleichen Klassen auch andere Protokolle bedient werden können, wobei zurzeit nur FTP direkt unterstützt wird. Das Modell lässt sich allerdings beliebig erweitern. In der vorliegenden Implementierung, habe ich ein neues Protokoll-Präfix (webdav://) definiert, welches dann mit WebDavRequest- bzw. WebDavResponse-Objekten arbeitet. Für die Registrierung müssen das Interface IWebRequestCreate definiert und ein entsprechendes Objekt mit RegisterPrefix registriert werden. Sinnvollerweise geschieht dies in der Methode Open der WebDavServer-Klasse. Durch diesen Aufbau kann das Protokoll perfekt in die .NET-Architektur eingefügt werden. Da das Rad nicht neu erfunden werden soll, nutzen beide WebDav-Klassen allerdings intern wiederum Instanzen von HttpWebRequest bzw. -Response.

Das Absetzen der Anfrage ist relativ trivial. Es gilt hier lediglich, die entsprechenden HTTP-Methoden zu setzen und eventuell mittels eines zu generierenden XML-Payloads eine Response vom Server anzufordern. Die Methode entspricht dabei dem WebDAV-Befehl.

Die beiden WebDav-Klassen stellen hierbei lediglich die richtige Übergabe der Informationen sicher. Für den Request stellen wir einen XmlTextWriter bereit, mit dem das XML-Fragment für die Anfrage formuliert werden kann. Daneben kann mittels der Eigenschaft Method der gewünschte Befehl gesetzt werden. Der Aufruf der Methode GetResponse setzt dann aus dem XmlTextWriter den Payload zusammen und sendet die Anfrage an den Server. Das Ergebnis ist ein Objekt vom Typ WebDavResponse, das die Entgegennahme des Payloads übernimmt. Hier wird im Wesentlichen ein XmlDocument bereitgestellt, welches aus dem Payload generiert wird.

Die echte Implementierung der WebDAV-Befehle wird bei den entsprechenden Methoden der Klasse WebDavCollectionInfo und partiell in WebDavItemInfo geleistet. Welche WebDAV-Befehle sind nun wann zu verwenden? Solange wir die Informationen für Collections bzw. Ressourcen lediglich abrufen möchten, reicht der PROPFIND-Befehl. Die gelieferten Informationen könnte man vielleicht mit einem rekursiven Directory-Listing vergleichen. Ein einfaches Transkript finden Sie in Listing 2, das im Folgenden erläutert werden soll.

Listing 2

1. -- REQUEST --
2. PROPFIND /container/ HTTP/1.1
3. Depth: 1
4. Content-Type: text/xml; charset="utf-8"
5. Content-Length: 98
7. <?xml version="1.0" encoding="utf-8" ?>
8. <D:propfind xmlns:D="DAV:">
9. <D:prop>
10. <D:displayname/>
11. </D:prop>
12. </D:propfind>
14. -- RESPONSE --
15. HTTP/1.1 207 Multi-Status
16. Content-Type: text/xml; charset="utf-8"
17. Content-Length: 366
19. <?xml version="1.0" encoding="utf-8" ?>
20. <D:multistatus xmlns:D="DAV:">
21. <D:response>
22. <D:href>http://www.test.de/container/</D:href>
23. <D:propstat>
24. <D:prop xmlns:R="http://www.foo.bar/boxschema/">
25. <D:displayname>Example collection</D:displayname>
26. </D:prop>
27. <D:status>HTTP/1.1 200 OK</D:status>
28. </D:propstat>
29. </D:response>
30. </D:multistatus>

Beginnen wir hier mit dem Request. Zunächst wurde der HTTP-Befehl auf PROPFIND gesetzt; der nachfolgende URL (hier /container/) definiert den Pfad. Der Header Depth: 1 besagt, dass sich der Befehl auf die Ressourcen und deren direkte Kinder auswirken soll. Sprich: Hier erhalten wir Informationen über die Ressource selbst und eventuell darin liegende andere Ressourcen oder Collections. Da wir den Payload in Form eines XML-Fragments liefern, wird der Content-Type-Header entsprechend gesetzt, ebenso ist die Angabe von Content-Length erforderlich.

Zum Abschluss folgt das XML-Fragment im Payload. Das Root-Element des Fragments (propfind) enthält hier eine Liste von Eigenschaften, die zurückgeliefert werden sollen. Möglich sind auch die Anfrage nach allen unterstützten Eigenschaften oder der Abruf einer Liste mit den Namen der Eigenschaften. In unserem Beispiel beschränken wir uns auf den displayname, den Dateinamen einer Ressource.

Untersuchen wir nun die Response des Servers. Eine PROPFIND-WebDAV-Anfrage liefert eine so genannten Multistatus-Response mit dem Code 207 zurück. Im Payload finden wir daher eine XML-Struktur, die die Ergebnisse beschreibt. Das Root-Element ist hier multistatus und enthält eine Anzahl von response-Knoten. Jeder dieser Knoten beschreibt eine WebDAV-Ressource. Je nach gewählter Tiefe erhalten Sie hier eventuell eine größere Menge von response-Knoten. Eine weitere Hierarchieebene existiert allerdings nicht, sondern kann auf Basis der einzelnen URLs der Ressourcen herausgerechnet werden.

Betrachten wir einen Response-Knoten, so besteht dieser aus einem Unterknoten mit dem Namen href. Dieser enthält den URL der Ressource; hier http://www.test.de/container. Daneben erhalten wir propstat-Knoten, die jeweils für eine Gruppe von Eigenschaften (prop) mit gleichem status zusammengefasst sind. Der Status HTTP/1.1 200 OK zeigt dabei an, dass dem Benutzer der Abruf der Eigenschaften erlaubt ist. Daneben sind auch andere Status möglich (not found, access denied etc.).

Haben wir, wie in unserem Beispiel, nur bestimmte Eigenschaften angefragt, erhalten wir die entsprechenden Knoten unterhalb des prop-Knotens (im Beispiel also lediglich den displayname der Elemente). Beim Parsing des empfangenen XML-Fragments sollten Sie beachten, dass nicht sichergestellt bzw. definiert ist, in welcher Reihenfolge die Knoten href und propstat gesendet werden. Das gleiche gilt auch für prop und status unterhalb von propstat.

In der - zugegebenermaßen recht vereinfachten - WebDAV Library finden Sie die Nutzung von PROPFIND etwa in der Methode Refresh von WebDavCollectionInfo. Die Extraktion der Eigenschaften übernimmt die Klasse WebDavPropertySet mit der Methode MergeFromPropstat. Letztere wandelt die XML-Entitäten in eine Hashtable um, welche dann dem Zugriff auf die einzelnen Eigenschaften dient. Die genauen Details für die einzelnen Abläufe, sprich: Welche XML-Fragmente bei welchem WebDAV-Befehl zu nutzen sind, finden Sie im RFC 2518. Allein die Nutzung des Propfind-Befehls reicht aus, um die gesamte Funktionalität für die Abfrage von Collections und darin liegender Unter-Collections bzw. Ressourcen zu implementieren.

Die WebDAV Library nutzt daneben eine Reihe von weiteren WebDAV-Methoden (MKCOL, DELETE, MOVE), deren Implementierung sich aber darauf beschränkt, den entsprechenden HTTP-Aufruf zu tätigen und eventuell einen Fehlercode entgegenzunehmen.

Für den Abruf von Ressourcen (sprich: Dateien) kann ein normales GET verwendet werden. In den meisten Fällen überlässt ein WebDAV-Server dies ohnehin einem Webserver, da der Vorgang einer normalen HTTP-Anfrage entspricht. Für einen solchen Abruf können Sie die Methode DownloadToFile der WebDavItemInfo-Klasse nutzen. Respektive kann der Upload mit der Methode UploadFromFile programmiert werden.

Schlussbemerkungen

Die Implementierung von WebDAV für eine Client-Anwendung lässt sich mit relativ geringem Aufwand realisieren. Durch die Abstützung auf HTTP können Client-Anwendungen für Endgeräte unterschiedlichster Plattformen entwickelt werden. Insbesondere für die Nutzung auf der Serverseite ergibt sich aber noch eine Vielzahl von Anwendungsfeldern, mit denen sich wiederum auch unterschiedliche Plattformen auf der Client-Seite unterstützen lassen.

Carsten Harnisch ist freier Systemberater im Bereich Dokumentenmanagement, Content Management, Knowledge Management und Customer Relationship Management. Sie erreichen ihn mit Fragen und Anregungen unter c.harnisch@harnisch-consulting.de.