© pixelio.de, Mari Mansikka

Das Fuse-Kernelmodul erlaubt es, Dateisysteme im Userspace zu schreiben. Die Autoren dieses Artikels nutzen Fuse, um NFS auf die Höhe der Zeit zu bringen – für die Client-Server-Kommunikation setzen sie auf Webservices mit SOAP. In einem Aufwasch entwickeln sie Client und Server ihres WSFS.

Komplexe Client-Server-Applikationen sind ohne Hilfsmittel schwer zu entwickeln. Seit langem lindern RPCs (Remote Procedure Calls) diese Qual: Der Entwickler nutzt Funktionsaufrufe, egal ob sich deren Implementierung im Client oder im Server befindet. RPCs begegnen Linux-Anwendern heute noch in Form des Network File System (NFS, [1]). Als moderne Form der RPC-Idee boomen Webservices. Sie arbeiten objektorientiert und verwenden offene Standards wie XML und HTTP. Es liegt also nahe, eine NFS-Alternative auf Webservice-Basis zu entwerfen, kurz ein WSFS (Webservice-Filesystem).

Das in diesem Artikel vorgestellte Dateisystem ist als Beweis der Machbarkeit und nicht für den produktiven Einsatz gedacht. Viel versprechend ist der Ansatz vor allem, wenn eine Applikation bereits Webservices nutzt. So könnten eine Web-Groupware oder ein CMS ihre Inhalte per WSFS feilbieten. In diesem Fall würde WSFS als virtuelles Dateisystem fungieren. Im Folgenden arbeitet die Server-Komponente aber nach NFS-Vorbild mit lokalen Dateien.

Dateisysteme können im Kernel- oder im Userspace angesiedelt sein; deutlich einfacher zu programmieren ist das zweite. Mit Fuse (Filesystem in Userspace, [2]) existiert die passende Schnittstelle, die für das WSFS ebenfalls zum Einsatz kommt. Der Artikel verfolgt damit zwei Ziele: Er zeigt die Verwendung von Webservice-Technologien unter Linux an einem konkreten Beispiel und er erläutert die Grundlagen von Fuse.

So funktioniert Fuse

Abbildung 1 zeigt den Aufbau eines Dateisystems bei Verwendung von Fuse. Letzteres bringt zwei wesentliche Bestandteile mit: die Fuse-Bibliothek Libfuse sowie das Kernelmodul »fuse.ko«. Das Modul sorgt dafür, dass die Schicht des Virtual-File-Systems (VFS) Fuse als eigenen Dateisystemtyp erkennt und Anfragen, die dieses Dateisystem betreffen, an »fuse.ko« weitergibt.

Abbildung 1: Mit Fuse stehen Programmierern weitreichende Möglichkeiten offen, ein Dateisystem im Userspace zu implementieren. Die Fuse-Architektur dient als Grundlage für das Webservice-basierte Dateisystem aus diesem Artikel.

Bei einem Dateisystem wie Ext 3, das vollständig im Kernel residiert, genügt ein einziges Kernelmodul. Bei Fuse kommt noch die Kommunikation mit der Implementierung hinzu, die im Userspace läuft. Für diese Kommunikation sorgt Libfuse zusammen mit der Gerätedatei »/dev/fuse«. Libfuse agiert dabei als Zwischenschicht, die unter anderem den direkten Kontakt der Dateisystem-Implementierung mit der Gerätedatei unnötig macht.

Mittelsmann

Die Userspace-Implementierung wird mit der Libfuse gelinkt und ruft aus ihr eine Einstiegsmethode auf. In einer C-Umgebung lautet deren Funktionsname »fuse_main()«, in Java kümmert sich die Methode »FuseMount.mount()« um die Initialisierung. Im Hintergrund führen beide Aufrufe dazu, dass Fuse den bekannten Linux-Systemcall »mount()« ausführt. Als Typ des einzuhängenden Dateisystems setzt die Bibliothek »fuse« in das Mount-Kommando ein.

Anschließend pollt die Dateisystem-Anwendung über die Fuse-Bibliothek die Datei »/dev/fuse«, um aus ihr Befehle zu erhalten. Jede Operation auf dem gemounteten Dateisystem – etwa von »ls« oder »mkdir« – reicht die Glibc an den Kernel weiter, der sie via VFS an das Fuse-Kernelmodul übergibt. Dieses legt die Anfragen in der Datei »/dev/fuse« ab, von wo sie via Libfuse zur Implementierung gelangen, die sie bearbeitet. Deren Ergebnisse, etwa eine Verzeichnisliste, gelangen auf dem umgekehrten Weg zurück zum Ausgangspunkt.

Für WSFS greift die Userspace-Komponente via Webservice auf einen passenden Server zu. Ähnlich wie RPCs sollen Webservices eine einfache Kommunikation zwischen verteilten Anwendungen ermöglichen. Dabei gehen Webservice-Technologien über RPCs in vielen Bereichen hinaus und adressieren explizit auch Anwendungen, die über das Internet kommunizieren. Dafür benötigen sie einerseits ein offenes und plattformübergreifendes Datenformat, andererseits eine ebenso offene Form der Datenübertragung.

Webservice-Grundlagen

Die Webservice-Standardisierer haben sich im ersten Punkt für XML entschieden und verwenden als Transportprotokoll meist HTTP. Programmierer müssen sich allerdings nicht darauf beschränken, ebenso gut können sie andere Transportmechanismen wie SMTP oder gar reines TCP benutzen [4].

Eine Webservice-Kommunikation beinhaltet deshalb in der Regel zunächst die Kodierung der zu sendenden Daten in ein XML-Format, das der SOAP-Standard vorgibt. Im zweiten Schritt erfolgt der Versand bei HTTP über einen »POST«-Request. Die Empfängerseite packt die Daten aus und verarbeitet sie. Damit alles funktioniert, müssen beide Kommunikationspartner aber die gleiche XML-Sprache sprechen.

Die Beschreibung der Daten und der Methoden, die der Empfänger zur Verfügung stellt, geschieht üblicherweise explizit. Hierfür steht mit der Webservice Description Language (WSDL) ein etabliertes Werkzeug auf XML-Basis bereit. Abbildung 2 stellt die Zusammenhänge vereinfacht dar. Der Absender einer Anfrage wird oft als Consumer bezeichnet, da er die Dienste des Empfängers (Producers) in Anspruch nimmt.

Abbildung 2: In einer Webservice-Anwendung nutzt der Consumer die Dienste des Producers. Die Daten kodieren beide Parteien per SOAP als XML. Via WSDL klären sie die Bedeutung der Daten.

Über die in Abbildung 2 skizzierten SOAP und WSDL hinaus haben sich viele Standards für Webservices entwickelt. So gibt es Verfahren, um Transaktionen zu nutzen [5] oder eine sichere Datenübertragung zu gewährleisten [6].

Sprachfragen

Als typische Programmiersprachen für die Implementierung dienen sich Java, C/C++ und Skriptsprachen wie Python an. Der Consumer läuft dabei häufig als Stand-alone-Anwendung, der Producer fungiert als Dienst innerhalb einer SOAP-Engine wie Apache Axis [7] oder Codehaus Xfire [8]. Axis und Xfire arbeiten wiederum als Webapplikationen in einem Application Server, etwa Tomcat. Da diese SOAP-Engines heute auch eine erhebliche Menge an zusätzlichen Webservice-Standards enthalten, heißen sie auch Webservice-Stacks.

Für die Implementierung eines Web-basierten Dateisystems gilt es, die Technologien Fuse und Webservice zu kombinieren. Die Autoren benutzen dazu Java. Sowohl Apache Axis als auch Codehaus Xfire sind native Java-Lösungen und es gibt eine Fuse-Java-Anbindung namens Fuse-J [3]. Sie besteht aus der Bibliothek »libjavafs.so«, die mit Hilfe des Java Native Interface (JNI) den Zugriff aus Java-Anwendungen auf den C-Code von Fuse ermöglicht, sowie aus der Schnittstellen-Beschreibung für ein Dateisystem in Java. Diese Beschreibung enthält zum Beispiel das Java-Interface »fuse.Filesystem« mit Methoden wie »open()«, »getattr()« und »read()«.

Den Zusammenhang zwischen Fuse, Fuse-J und der Webapplikation verdeutlicht Abbildung 3. Die Userspace-Implementierung des Dateisystems besteht zum einen aus einer lokal vorhandenen Java-Anwendung, die als Java-Client für den Webservice-Anteil fungiert und das Mounten übernimmt. Auf einem entfernten Rechner liegt dann die zweite Komponente, der eigentliche Webservice, der die Anfragen über SOAP-Nachrichten vom Java-Client entgegennimmt, sie bearbeitet und die Ergebnisse als SOAP-Nachrichten zurücksendet.

Abbildung 3: Der Aufbau des Web Service File System (WSFS): Auf Client-Seite sorgt Fuse für die Einbindung der Java-Applikation ins Filesystem. Die Kommunikation mit dem Server läuft über SOAP.

Der passende Server

Das hier gezeigte WSFS basiert auf Xfire, das zwar weniger bekannt ist als Apache Axis, aber eine interessante und vor allem einfach zu bedienende Alternative darstellt. Die prinzipielle Vorgehensweise gestaltet sich in beiden Umgebungen analog.

Bei allen Entwicklungen von Webservices stehen zwei Ansätze zur Auswahl: Beim ersten definiert der Entwickler zunächst die öffentlich sichtbare Schnittstelle des Webservice. Dazu gehört die Struktur der ausgetauschten Daten und der verfügbaren Operationen. Diese Definition findet sich normalerweise in einer WSDL-Datei. Da die Beschreibung plattformunabhängig ist, erreicht der Programmierer damit weit gehende Interoperabilität zwischen verschiedenen Umgebungen.

Werkzeuge erzeugen aus der WSDL-Datei Codegerüste, die Programmierer dann mit der jeweiligen Implementierungslogik füllen. Dieses Vorgehen bezeichnen Entwickler oft als Contract First – sie beschreiben den Vertrag (die WSDL-Beschreibung) zuerst [9].

Wer kommt zuerst

Dem Contract First gegenüber steht der pragmatische Ansatz des Code First, den viele Entwickler bevorzugen. Sie kodieren wie bisher Java-Schnittstellen sowie deren Implementierungen und verwenden dann die Engines, um eine WSDL-Datei bei Bedarf zu erzeugen. Diese WSDL-Datei nutzen sie im nächsten Schritt bei der Erzeugung von Clients. Auch dieser Artikel folgt dem Ansatz des Code First, da Fuse und Fuse-J schon alle notwendigen Definitionen und Interfaces mitbringen und eine direkte Weiterentwicklung nahe legen. Die beginnt mit der Erstellung des Webservice, der Dateisystem-Anfragen über SOAP entgegennimmt und bearbeitet. Listing 1 zeigt einen Ausschnitt aus dem Interface, das der Webservice implementiert und das den oben beschriebenen Schnittstellen eines Dateisystems entspricht.

01 package wsfs;
02 [...]
03 public interface WsFsInterface {
04        public void chmod(String path, int mode) throws WsFsException;
05        public WsFsStat getattr(String path) throws WsFsException;
06        public long open(String path, int flags) throws WsFsException;
07        public byte[] read(String path, long fh, long offset, int size) throws WsFsException;
08        public void mkdir(String path, int mode) throws WsFsException;
09        [...]
10 }

Diese Methoden passen weitgehend zu denen, die das zentrale Interface von Fuse-J »Filesystem« nennt. Als einzige Abweichung verwenden sie Byte-Arrays statt »ByteBuffer«, da sie sich einfacher über Webservice-Aufrufe abbilden lassen [10]. Die Definition der Methoden findet sich in der Klasse »WsFs«, deren Grundstruktur Listing 2 zeigt.

01 package wsfs;
02 [...]
03 public class WsFs implements WsFsInterface {
04 
05    final String mountpath = "/tmp";
06 
07    public WsFsStat getattr(String path) throws WsFsException {
08       File file = new File(mountpath + path);
09       if(file.exists()) {
10          WsFsStat stat = new WsFsStat();
11          stat.mode = file.isDirectory() ? FuseFtype.TYPE_DIR | 0755 : FuseFtype.TYPE_FILE | 0644;
12          stat.nlink = 1;
13          stat.uid = 500;
14          stat.gid = 500;
15          stat.size = file.length();
16          stat.atime = stat.mtime = stat.ctime = (int) (file.lastModified() / 1000L);
17          stat.blocks = (int) ((stat.size + 511L) / 512L);
18 
19          return stat;
20       }
21       throw new WsFsException("No Such Entry").initWsFsErrno(FuseException.ENOENT);
22    }
23    [...]
24 
25    public void mkdir(String path, int mode) throws WsFsException {
26       File f = new File(mountpath + path);
27          if(!f.exists())
28             f.mkdir();
29    }
30 
31 }

Bean-ähnlich

Die Implementierung in Listing 2 verwendet die Klasse »WsFsStat«, die exemplarisch für einige Klassen steht, die Erweiterungen der entsprechenden Fuse-J-Klassen darstellen. Sie enthalten zusätzliche Setter- und Getter-Methoden, die für einen reibungslosen Einsatz im Webservice-Umfeld, speziell die Serialisierung von Java-Objekten in XML-Ströme, notwendig sind. Nahezu alle Webservice-Werkzeuge erwarten ein solches Bean-ähnliches Verhalten.

Die Implementierung des Servers gestaltet sich von nun an recht simpel. Der Mount-Pfad befindet sich zum Beispiel hart kodiert in der Klassendefinition (hier »/tmp«). Fast alle der benötigten Dateizugriffe lassen sich schon mit Hilfe der Java-Standardklassen umsetzen. Allerdings erlaubt es Java nicht, Datei-Attribute direkt auszulesen. Dieses Problem löst zwar das JNI [11], doch steht dies nicht im Fokus dieses Artikels. Der Code in Listing 2 zeigt daher nur eine Dummy-Implementierung, die feste Wer- te für Berechtigungen vergibt.

Um das Konstrukt schließlich als Webservice verfügbar zu machen, muss die Implementierung noch in Xfire eingebettet werden. Letzteres arbeitet selbst als Framework in einem Servlet-Container. Dazu bringt Xfire den Jetty-Server mit [12], alternativ steht Apaches Tomcat [13] zur Verfügung. Da die Xfire-Jetty-Variante einfacher zu konfigurieren ist, verzichten die Autoren auf die Beschreibung einer Tomcat-Installation.

Installation

Das Deployment des WSFS-Service verlangt mehrere Schritte. Zunächst gilt es, den kompilierten Code bereitzustellen sowie einige XML-Konfigurationsdateien zu erzeugen. Dazu zählen die von den Servlet-Containern bekannte »web.xml« und eine Xfire-spezifische Konfigurationsdatei namens »services.xml« [14]. Bei Jetty geschieht die Konfiguration ausschließlich über Java-Code.

Zunächst ist auf Server-Seite der HTTP-Server zu starten; das übernimmt der Code aus Listing 3. Die Service-Factory erstellt aus der übergebenen Schnittstelle »WsFsInterface« automatisch die WSDL-Datei und ruft bei Bedarf die Methoden aus der übergebenen Implementierungsklasse »WsFs« auf.

01 import org.codehaus.xfire.XFire;
02 import org.codehaus.xfire.XFireFactory;
03 import org.codehaus.xfire.server.http.XFireHttpServer;
04 import org.codehaus.xfire.service.*;
05 
06 import wsfs.WsFs;
07 import wsfs.WsFsInterface;
08 [...]
09 
10    WsFs wsfs = new WsFs();
11 
12    // Service erstellen ...
13    ObjectServiceFactory serviceFact = new ObjectServiceFactory();
14    Service service = serviceFact.create(WsFsInterface.class);
15    service.setInvoker(new BeanInvoker(wsfs));
16 
17    // ... und registrieren
18    XFire xfire = XFireFactory.newInstance().getXFire();
19    xfire.getServiceRegistry().register(service);
20 
21    // Server starten
22    XFireHttpServer server = new XFireHttpServer();
23    server.setPort(8191);
24    server.start();
25 ...

Nach dem Kompilieren und Starten des Java-Code lauscht der Server auf Port 8191. Unter der URL »http://Host:8191/WsFsInterface?wsdl« sollte der Server die WSDL-Beschreibung des WSFS zeigen, die der Client braucht, um mit dem Server zu kommunizieren.

Implementierung des Clients

Der Client bedient sich ebenfalls bei Fuse-J und Xfire. Einen Ausschnitt aus seinem Code zeigt Listing 4. Diese Codestrecke verwendet Xfire-spezifische Aufrufe. Unter Axis bliebe lediglich der zentrale Aufruf »FuseMount.mount(args, new ClientFS(wsfs));« gleich, mit dem der Programmierer das Dateisystem dann einhängt.

01 ...
02    public static void main(String[] args) {
03       new WsFsClient(args);
04    }
05 
06    public WsFsClient(String[] args) {
07 
08       ObjectServiceFactory serviceFactory = new ObjectServiceFactory();
09       Service serviceModel = serviceFactory.create(WsFsInterface.class);
10 
11       XFireProxyFactory proxyFactory = new XFireProxyFactory();
12       WsFsInterface wsfs = (WsFsInterface) proxyFactory.create(serviceModel,"http://SERVER:8191/WsFsInterface");
13 
14       FuseMount.mount(args, new ClientFS(wsfs));
15       [...]

Das Objekt der Klasse »ClientFS«, das der Client in Listing 4 instanziiert, dient als Proxy für den Webservice. Es nimmt die Anfragen entgegen und gibt sie als SOAP-Nachrichten an den Webservice-Server weiter. Listing 5 zeigt ein Beispiel für diese Arbeit, die nur aus einem angepassten Wrapping besteht, um etwa – wie oben erwähnt – Daten des Typs »ByteBuffer« in einfache Byte-Arrays umzusetzen.

01    [...]
02    public FuseDirEnt[] getdir(String path) throws FuseException {
03       return wsfs.getdir(path);
04    }
05  
06    public void read(String path, long fh, ByteBuffer buf, long offset) throws FuseException {
07       byte[] b = wsfs.read(path,fh,offset,buf.limit());
08       buf.put(b);
09    }

Wer sich als Programmierer nur ungern mit der ziemlich aufwändigen XML-Verarbeitung herumschlägt, darf sich freuen: Die gesamte Verwaltung der XML-Nachrichten und des SOAP-Protokolls geschieht durch die Engine, hier also Xfire. Diese komfortable Schnittstelle hat sehr stark dazu beigetragen, dass Engines wie Axis und Xfire eine breite Akzeptanz gefunden haben.

Erster Testlauf

Zum zusammenfassenden Test des WSFS startet der Entwickler nur noch die zentrale Client-Klasse »WsFsClient«, danach sollte der »mount«-Befehl ein weiteres Dateisystem anzeigen. Kommandos wie »ls« leitet der Client ab dann über SOAP an die WSFS-Server-Implementierung »WsFs« weiter, die sie anhand der Verzeichnisse und Dateien, die auf dem Server-Rechner liegen, beantwortet.

Komfortable Entwicklung

Die Entwicklung eines einfachen Webservice-basierten Dateisystems unter Linux gestaltet sich sehr bequem. Zum einen existieren mit Fuse und Fuse-J fertige Schnittstellen, um Dateisysteme im Userspace zu entwickeln. Zum anderen gibt es unter Linux leistungsfähige Umgebungen wie Xfire und Axis, die die Arbeit mit Webservice-Standards erheblich erleichtern und einen großen Teil der andernfalls nötigen Programmierarbeit sparen helfen.

Dennoch geht das hier gezeigte Beispiel bewusst nicht über einen Prototyp hinaus. Dafür sind vor allem zwei Gründe ausschlaggebend: Zunächst lassen sich nur Read-only-Dateisysteme schnell und vergleichsweise einfach implementieren. Ein ausgewachsenes Dateisystem, das beliebige Schreibvorgänge zulässt, hat dagegen deutlich höhere Ansprüche (etwa bei der Synchronisation der Zugriffe auf gemeinsame Daten [15]).

Der zweite Grund leitet sich aus den systematischen Schwächen von Webservices ab, die sich gerade am Beispiel eines Dateisystems zeigen. Der Prototyp verhielt sich im Test beim Datentransfer über das Loopback-Device sehr behäbig – mehr dazu verrät der Kasten “Geschwindigkeit im Vergleich”.

Kein Sprinter

Diese Zahlen weisen auf einige bekannte Probleme bei der Performance von Webservices hin [16]. So sind viele kleine Systemcalls, wie sie beim Aufruf »ls« erzeugt werden, Gift, wenn sie wie hier jedes Mal zu einem aufwändigen XML-Parsing führen. Auf der anderen Seite können sehr große Datenpakete ebenfalls zu einer Belastung führen, insbesondere wenn sie innerhalb der XML-Nachricht und nicht als Anhang übertragen werden [17].

Spielt die Performance der Anwendung aber keine zentrale Rolle, dann verspricht die WSFS-Idee viele praktische Anwendungen. Hier ist vor allem die Kreativität der Entwickler gefragt. (mwe)