Integration von Web Services in Microsoft-Office-Applikationen

Web Servicing the Office
Kommentare

Dem EDV-Anwender stehen zwei Welten gegenüber: Auf der einen Seite der PC mit seinen hochfunktionalen, aber wenig informativen Desktop-Anwendungen. Auf der anderen Seite das Internet mit zahlreichen Webseiten, aber wenigen Webanwendungen, die dieselbe Funktionalität wie die gewohnten Desktop-Anwendungen bieten. Die Integration von Web Services in Standardapplikationen verbindet diese beiden Welten und realisiert 11 Jahre später Bill Gates Vision von „information at your fingertips“.

Die Vision von Scott McNeally lautete hingegen: „The net is the app“. An die Stelle der wartungsintensiven und plattformgebundenen Desktop-Anwendungen sollten Webanwendungen auf Basis von HTML und Java treten, die von Application-Service-Providern (ASP) lokal auf deren Servern gepflegt werden. Doch die hierzu notwendige Clientanwendung (der Browser) und die zugrunde liegende Technologie (HTML über HTTP) erwiesen sich in vielen Fällen als unzureichend, sodass sich die Idee des Application Hosting nicht auf breiter Basis durchsetzen konnte. An die Stelle der ASP treten vermehrt WSP – Web Service Provider, die ihre Datenbanken und Dienste per Web Service anderen Anwendungen zur Verfügung stellen.

Koalition der neuen Möglichkeiten

Obgleich oftmals als „Featuritis“ verschrien: ein reichhaltiges Angebot an Features ist eines der Kaufargumente für Software. Doch Webanwendungen stehen in Sachen Funktionalität ihren Pendants auf dem Desktop oftmals (noch) nach. Andererseits haben herkömmliche Desktop- Anwendungen einen entscheidenden Nachteil: sie laufen isoliert vom Rest der Welt, sprich vom World Wide Web. Web Services bieten die Möglichkeit, das Web als zusätzliche Funktionalität in bestehende Anwendungen zu integrieren, gemäß dem Motto „The net is the service”.

Für die Einbindung von Web Services bietet Microsoft Office in der Version 2003 bereits eine Vielzahl verschiedener Wege an, unter anderem:

• Research Services (deutschsprachigen Office-Anwendern besser bekannt als die Funktion „Recherchieren“) implementieren eine spezielle WSDL-Schnittstelle und bieten dem Anwender zusätzliche Suchfunktionen an, zum Beispiel die Suche in einer Unternehmensdatenbank.
• Mit dem Web Services Toolkit lassen sich SOAP-basierte Web Services in VBAAnwendungen ansprechen und somit in Form eines Add-ins oder einer Excel-Funktion integrieren.

Research Services sind einfach in der Implementierung und komfortabel in der Anwendung, doch sie erlauben nur die Integration von Suchdiensten. Mit VBAMakros und dem genannten Toolkit lassen sich hingegen flexible Lösungen realisieren. Allerdings sind auch die Möglichkeiten von VBA begrenzt. Beispielsweise lassen sich damit keine so genannten „Smart Tags“ realisieren.

Smarte Hyperlinks

Smart Tags sind ein spezielles Feature von Microsoft Office und mit Hyperlinks vergleichbar. Im Unterschied zu diesen werden Smart Tags jedoch dynamisch an bestimmte Schlüsselwörter oder -phrasen angeheftet (als gepunktete violette Linie zu erkennen) und bieten beim Anklicken ein Menü, aus welchem der Benutzer die jeweils gewünschte Aktion auswählen kann. Smart Tags stellen somit eine optimale Lösung dar, um dem Benutzer kontextsensitive Informationen und Aktionen zur Verfügung zu stellen.

Smart Tags sind für die Office-Anwendungen Excel, PowerPoint und Word ab der Version 10 (Office XP) verfügbar und basieren auf lokalen COM-Klassen, welche die Schnittstellen ISmartTagRecognizer und ISmartTagAction implementieren. Die erst genannte Schnittstelle ist für die Erkennung der Schlüsselwörter zuständig. Dabei überreicht die Office-Anwendung jeweils nur den derzeit sichtbaren Text (in Word beispielsweise den aktuellen Abschnitt) an die jeweilige Recognizer-Klasse. Dies erfolgt jedoch nicht während der Benutzereingabe, sondern nur in den dazwischenliegenden Pausen, sodass die Arbeit des Benutzers hierdurch nicht beeinträchtigt wird. Jedem Wort oder zusammenhängenden Textabschnitt werden ein oder mehrere URNs (Uniform Resource Names) zugewiesen, die den Typ des jeweiligen Smart Tags identifizieren. So stellt Microsoft bereits einige vordefinierte Typen samt der notwendigen Recognizer-Klasse zur Verfügung – etwa für Datums- und Ortsangaben. Die Action-Klassen sind für die Darstellung des Menüs in Abhängigkeit vom jeweiligen Smart-Tag-Typ zuständig sowie für die Durchführung der vom Benutzer gewählten Aktion.

Eine Einbindung von Web Services ist nicht ausdrücklich vorgesehen, doch spricht grundsätzlich nichts dagegen, die Erkennung von Schlüsselwörtern im Freitext an einen öffentlichen oder unternehmensinternen Web Service zu delegieren. Dies ist insbesondere dann von Vorteil, wenn die zugrunde liegende Datenbank sehr groß ist und sich ihr Inhalt häufig ändert.

Aufmacherbild: Illustration of SOA on curl paper and represented with different layer like application, process, messaging layer components and shown with sketch, pencil drawing von Shutterstock / Urheberrecht: Vallepu [ header = Seite 2: Im Dienste der Wissenschaft ]

Im Dienste der Wissenschaft

Ein Beispiel hierfür sind Synonymlisten für Proteine (die Funktionsträger der Gene), für die keine einheitliche und eindeutige Bezeichnung existiert. Zudem verteilen sich die Informationen zu einem bestimmten Protein auf mehrere Online-Datenbanken, die ebenfalls keine einheitlichen Bezeichner (IDs) verwenden. Schließlich werden täglich neue Proteine einer Datenbank hinzugefügt.

Im Rahmen eines Forschungsprojekts an der LMU München (siehe [1]) wurde eine Synonymdatenbank für vier verschiedene Organismen erstellt, wobei sechs verschiedene Online-Datenbanken indiziert wurden. Auf der Basis dieser Synonymdatenbank wurden zwei Web Services implementiert: Ein Protein-Thesaurus (ProThesaurus), der für ein gegebenes Protein alle Synonyme und Datenbankbezeichner sowie die URLs zu den jeweiligen Online-Datenbanken liefert, sowie LiMB (Literature Mine Browser), welcher die bestehende Funktionalität einer gleichnamigen Webanwendung als SOAP-Dienst zur Verfügung stellt. Seine Funktion besteht darin, in Freitext Proteinnamen zu erkennen und eine Liste von Datenbankbezeichnern zurückzuliefern, die mit dem jeweiligen Protein assoziiert sind. Hierfür wurden zwei WSDLSchnittstellen definiert: BiologicalName-Service für Thesauren und BiologicalMarkupService für Textparser. Die LiMB-Implementierung stellt ausschließlich einen Markup-Service zur Verfügung, wohingegen ProThesaurus beide Schnittstellen implementiert und, zusätzlich zu der Thesaurus-Funktion, Datenbankbezeichner in Freitext erkennt. Beide Dienste verwenden dieselbe Datenbank (eine MySQL-Datenbank) und basieren auf Tomcat, Axis und Java.

Die Kombination dieser Software-Pakete ermöglichte eine kostengünstige Implementierung, da hierfür keine Lizenzierungskosten anfielen. Allerdings bereiteten insbesondere die mangelhafte Dokumentation der Axis-Bibliothek und Versionsprobleme zwischen Tomcat, Axis und Java erhebliche Schwierigkeiten. So konnte die eingesetzte Version 1.1 von Axis nicht mit der aktuellen Java-Version 1.5 betrieben werden. Schließlich zeigte sich (siehe hierzu [2]), dass die von Axis aus den vorhandenen Java-Klassen generierten WSDL-Spezifikationen nicht zum WS-I-Standard konform sind, obgleich dies in der Praxis keine Kompatibilitätsprobleme verursachte.

Neue Technologien …

Um die Dienste in Office zu integrieren, wurde eine einfache Clientanwendung namens ProTag (für Protein Tagging) erstellt. ProTag wurde erstmals im Rahmen einer wissenschaftlichen Publikation [3] vorgestellt und steht unter [4] als GPL-lizenziertes Projekt frei zur Verfügung.

ProTag wurde auf Basis des .NET Frameworks 1.1 und mithilfe von Visual Studio .NET entwickelt. Für den Einsatz von .NET sprachen mehrere Gründe: Die umfangreiche Klassenbibliothek samt der zahlreichen GUI-Steuerelemente sowie die hervorragende Unterstützung von SOAP-basierten Web Services. So hatte Visual Studio keine Probleme, die nicht WS-I-konformen Web Services einzubinden, und die Erstellung der Stub-Klassen erfolgte mit nur wenigen Mausklicks. Selbst Änderungen an den WSDL-Dokumenten hatten keine ernsthaften Schwierigkeiten zur Folge. Gegen eine rein COM-basierte Implementierung sprach vor allem die Tatsache, dass Visual Studio 6.0 keine Unterstützung für Web Services bietet. Dies ist nur über ein frei erhältliches Add-on möglich. Abgesehen davon ist die Entwicklung von COM-Komponenten in .NET ebenso problemlos möglich. Dies bietet außerdem den Vorteil, dass die ProTag-Komponenten sowohl unter COM als auch unter .NET verwendet werden können.

… und alte Lasten

Einschränkend muss jedoch erwähnt werden, dass insbesondere die Signierung von .NET-basierten COM-Komponenten
Probleme bereitet. Eine Signierung einer COM-Komponente stellt einerseits die Authentizität der Komponente sicher und identifiziert andererseits den Autor der Komponente. Beides ist notwendig, damit eine Applikation wie Word eine solche COM-Komponente als vertrauenswürdig einstuft und infolgedessen ohne weitere Bestätigung seitens des Benutzers lädt. Im Falle einer .NET-basierten COM-Komponente lädt Word jedoch die Komponente nicht direkt. Stattdessen wird die .NET-Laufzeitumgebung geladen, die ihrerseits die betreffende .NETKlasse lädt. Da sich die .NET-Laufzeitumgebung nicht signieren lässt, ist eine Behelfslösung erforderlich. Diese besteht darin, mithilfe des Shim-Wizards (siehe hierzu [5]) eine signierte COM-Komponente zu erzeugen, die ihrerseits die .NET Laufzeitumgebung samt der eigentlichen .NET-basierten COM-Komponente lädt.

[ header = Seite 3: Gelbe Seiten ]

Gelbe Seiten

Im Falle von ProTag sind dies zwei Komponenten: ProKeyAction und ProKeyRecognizer. Die ProKeyRecognizer-Klasse implementiert die Recognize-Methode der ISmartTagRecognizer-Schnittstelle. Diese Methode leitet den Aufruf an die Markup-Methode der registrierten Biological Markup Services weiter (Abbildung 1). Hierbei wird für jeden Markup-Service eine Instanz der Stub-Klasse Biological- MarkupService erzeugt und mit dem URL des jeweiligen Web Services initialisiert. Die URLs sind in der Windows-Registry hinterlegt und lassen sich mithilfe der WebServices-Klasse aus dem Assembly ProTag.Core.dll auslesen.

Von dieser Klasse abgeleitet ist die Klasse BiologicalNameServiceComposer. Sie verwaltet die Biological Name Services und ermöglicht durch einen einzigen Methodenaufruf, beispielsweise von GetSynonyms, sämtliche Synonyme von allen registrierten Name Services für ein bestimmtes Protein abzufragen. Diese zusätzliche Abstraktionsschicht ermöglicht es anderen Klassen, zum Beispiel der SynonymsVerb– Klasse, die verteilten Name Services als einzelnen Web Service anzusprechen.

Abb. 1: Überblick über die Architektur von ProTag

Erweiterung der Erweiterung

Die SynonymsVerb-Klasse ist eine abstrakte Basisklasse für die Implementierung von Menübefehlen und leitet sich selbst von der abstrakten Klasse ProVerb ab. So wird beim Betätigen des Menübefehls Add Synoynm(s) as Comment zuerst die InvokeVerb-Methode der ProKeyAction-Klasse aufgerufen, die ihrerseits den Aufruf an die Invoke-Methode des jeweiligen ProVerb-Objekts weiterleitet. In diesem Fall ist es die Klasse AddSynonymsAsCommentVerb, welche schließlich von der BiologicalNameServiceComposer-Klasse Gebrauch macht. Die Informationen, welche Menübefehle im jeweiligen Kontext dem Benutzer zur Verfügung stehen, sind ebenfalls in der Windows-Registry hinterlegt. Ein Eintrag für einen Menübefehl besteht aus der Menübeschriftung, dem Namen der von ProVerb abgeleiteten Klasse sowie dem Namen des Assembly, welches die Klasse beinhaltet. Hierdurch können der ProTag-Anwendung zur Laufzeit neue Menübefehle hinzugefügt werden. Folglich erweitert ProTag nicht nur die Office-Anwendungen, sondern ist selbst gleichermaßen erweiterbar. Das dynamische Laden von .NET-Klassen erfordert hierbei nur eine einzige Zeile Code und demonstriert somit eine weitere Stärke des .NET Frameworks:

 

Activator.CreateInstance(Type.GetType(TypeName & “,“ &
AssemblyName))

 

Duales System

Der modulare Aufbau von ProTag ermöglicht einerseits die flexible Erweiterbarkeit, andererseits jedoch auch eine umfangreiche Verwendbarkeit, sodass nur wenige Zeilen Code genügten, um ProTag auch als Standalone-Applikation verfügbar zu machen. Hierbei akzeptiert ProTag Benutzereingaben aus der Zwischenablage, die etwa aus einem PDF-Dokument stammen. Des Weiteren integriert sich ProTag als herkömmliches Office-Addin. Es fügt der Office-Befehlsleiste zusätzliche Menübefehle hinzu, um beispielsweise eine manuelle Suche durchzuführen für den Fall, dass ein Proteinname nicht als solcher erkannt wurde. Schließlich stellt das Assembly ProTag.Functions eine Klasse namens Functions bereit, die die Methoden der BiologicalNameService-Composer-Klasse als COM-Methoden exportiert. Diese Klasse lässt sich unter anderem in VBA-Makros einsetzen. Ihre Methoden können jedoch auch innerhalb von Excel-Formeln als herkömmliche Funktionen eingesetzt werden. Die hierfür notwendige Implementierung wird in einem Online-Artikel unter [5] erläutert.

Fazit

Zwar bereitet die Einbindung von .NETKlassen als COM-Komponenten in die Microsoft-Office-Anwendungen einige Schwierigkeiten, doch dafür punktet das .NET Framework in Sachen Web-Service-Integration. Die zusätzliche Vermittlerschicht zwischen den Web Services und den Office-Anwendungen erlaubt dem Benutzer, bei Bedarf neue Dienste hinzuzufügen, und ermöglicht eine Mehrfachverwendung der verfügbaren Dienste.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -