Open-Office-Dokumente mit Java verarbeiten

Office-Suiten, hier ist Open Office zuerst zu nennen, sind Funktionsmonster: Der Anwender braucht zwar nur fünf Prozent aller Funktionen - aber jeder andere fünf Prozent. Bei recht speziellen Aufgaben in Firmenumgebungen - und das ist nicht selten - reichen selbst die vielen in Open Office eingebauten Funktionen nicht. Wie beim Stiefbruder von Microsoft hilft gewöhnlich ein Basic-Programm, das innerhalb des Office-Programms abläuft.

Das Verfahren setzt aber einen Benutzer voraus, der Office manuell bedient - widersinnig eingedenk der Automatisierungsfreundlichkeit und Flexibilität von Linux. Das "Open Office Software Development Kit" bringt Abhilfe, denn es schafft die Möglichkeit, sowohl interne Funktionen (beispielsweise zusätzliche Import/Export-Filter) zu erweitern als auch Office aus Fremdprogrammen heraus fernzusteuern.

Dieser Coffee-Shop erklärt am Beispiel eines Java-Programms, das ein einfaches Spreadsheet-Dokument erzeugt, die zugrunde liegende Architektur. Eine Erweiterung zu einem Servlet, das komplexere Szenarien abbildet, ist mit geringem Aufwand machbar.

Open Office muss als Objekt-Server laufen

Damit eigene Programme mit ihm kommunizieren können, muss Open Office im Servermodus laufen (siehe unten). Als Server stellt Office seine Funktionalität über Objekte bereit, deren Methoden remote aufrufbar sind. Die Objekte und Methoden bilden das API des Open-Office-SDK. In Open-Office-Sprache heißen diese Objekte Universal Network Objects, kurz UNO. Wer RMI und insbesondere CORBA kennt, bemerkt sofort die große Ähnlichkeit.

Genau genommen ist die UNO-Architektur nur eine proprietäre Version der CORBA-Architektur. Das geht so weit, dass UNO seine Objekte wie auch CORBA über eine Interface Definition Language (IDL) definiert. Programmierer haben damit die Wahl zwischen Java, C++, Open Office.org Basic, Python und OLE für die Implementation (Language Bindings).

Eigene Begriffe im API für Factories & Co.

Das Open-Office-API bedarf der Gewöhnung, weil es eine ganze Reihe eigener Begrifflichkeiten verwendet: Factories heißen darin zum Beispiel Service Manager. Ein »context« ist die logische Ablaufumgebung von Objekten. Wie bei allen verteilten Anwendungen muss das lokale Programm einen lokalen Stub für ein entferntes Objekt erzeugen, damit dies die Methodenaufrufe für den Programmierer transparent weiterleitet. Die erwähnten Service Manager haben dazu geeignete »create«-Methoden.

Erster Schritt jedes UNO-Programms ist es daher, einen Service Manager für Remote-Objekte zu erhalten. Weitere Remote-Objekte sind dann über dessen Factory-Methoden zugänglich. Auch wenn die Architektur im ersten Moment kompliziert klingt: Die Praxis ist einfach, insbesondere bei vorhandenen Codebeispielen. Den Beweis dafür will dieser Coffee-Shop antreten. Der vorgestellte Code ist hauptsächlich per Cut & Paste entstanden, die Vorlagen sind Teil des Developer-Guide des SDK.

Abbildung 1: Konfiguration der JVM für Open Office per »jvmsetup«.