Jahrelang zählte die Konzeption und Entwicklung komplexer Web-Services-Standards zum Nonplusultra, um heterogene Anwendungssysteme prozessorientiert zu integrieren. Doch EAI-Projekte sind in der Regel kompliziert, teuer und langwierig. Dass es auch einfacher gehen kann, beweisen Technologien auf Basis von Web 2.0: Mashups, ursprünglich aus der Zusammenführung von Online-Diensten entstanden und immer häufiger in Form von Gadgets auf Privatrechnern im Einsatz, haben das Zeug, sich auch in der Unternehmens-IT zu etablieren.
Was sind Mashups?
Mashups integrieren zwei oder mehrere Web-Dienstleistungen in einer neuen Anwendung (Weblikation). Die Integration kann auf Daten-, Logik- und Darstellungsebene erfolgen. Grundsätzlich können sie als Unterbegriff der Composite Apps verstanden werden. Sie verzichten bewusst auf den komplizierten SOA-Orchestrierungsapparat und lassen sich deshalb als eine Art SOA-Light bezeichnen. Daraus leiten sich auch die bevorzugten Einsatzgebiete ab: Während Composite Apps komplexe Logik und Abhängigkeiten zwischen den Diensten realisieren, zeichnen sich Mashups durch einfache Overlays, Kombinationen und kaum zeitliche oder logische Abhängigkeiten aus.
Die Applikationsintegration lässt sich nach aktuellem Stand auf der Daten-, Logik- oder Darstellungsebene realisieren. Zur vorherrschenden Methode im Business-Intelligence-Umfeld etwa zählt die Datenintegration. Die Informationen aller Applikationen landen hier in einem großen Topf, dem Data Warehouse, über den sich integrierende Auswertungen per BI-Software fahren lassen. Soll die Logik existierender Applikationen verknüpft werden, dann sollen gezielt Funktionen der Applikationen abgerufen und verbunden werden. Diese Form der Integration erfolgt heute typischerweise über ein Methoden-Interface, eine RPC-Schnittstelle oder aber über ein Web-Service-API. Programme auf Darstellungsebene zu verknüpfen gelang erstmals mit den Screenscraping-Techniken in den Anfängen des Web. Jedes Integrationsprinzip ganz gleich, ob auf Daten-, Logik- oder Darstellungsebene - muss zunächst jedoch drei wesentliche Fragen beantworten: Auf welche Art und mit welchem Protokoll soll die Kommunikation erfolgen? Wie wird die Funktionalität des Dienstes angesprochen, und in welchem Format erfolgt die Übertragung der Ergebnisse, also der Daten selbst?
Vermischung der Welten
Mashups (engl. Vermischung, Vermaschung) machen ihrem Namen alle Ehre: Prinzipienfrei mischen sie Web-Applikationen auf allen drei genannten Ebenen und das unter Umständen sogar gleichzeitig. Diese Eigenschaft unterscheidet sie grundlegend von den reinen Vorgehensweisen klassischer Anwendungsintegration. Beginnend mit relativ simplen Methoden wie dem Screen-Scraping der Mutter aller Mashups für das Web 1.0 - lassen sich so einfache Inhalte aus Webseiten mittels XML- oder HTML-Parsern extrahieren. Einen Schritt weiter gehen Integrationskonzepte auf Basis von Browser-Erweiterungen, die bereits geladene Seiten nach Belieben verändern. Dazu zählen etwa das Firefox-Plugin "Greasemonkey", "Turn-about" für den Internet Explorer oder die "Google Toolbar". Als konzeptionelle Erweiterung zum Screen Scraping setzen sie auf das so genannte Active Browsing, mit dem sich extrahierte Web-Seiten-Inhalte zusätzlich aktiv für die eigene Verwendung modifizieren und so um weitere Funktionalität anreichern lassen. Typische Aufgaben dafür sind beispielsweise, Werbung auf Web-Seiten auszublenden, Formulare automatisch auszufüllen oder fehlende Seitenfunktionalität hinzuzufügen.
Zusätzlich zu der Integration auf Darstellungsebene - den Äußerlichkeiten also - geht es nun darum, die inneren Werte der Applikationen anzuzapfen und zu vereinen. Dabei konkurrieren zwei Ansätze: Die Übertragung des alten RPC-Paradigmas der verteilten Verarbeitung in die Web-Welt - via XML-RPC oder Web-Services und Soap sowie der Representational State Transfer (REST) nach Roy Fielding. REST bietet einen durchweg praktikablen Ansatz für die Realisierung eines Integrationsprotokolls. Viele Suchmaschinen, Shops oder Buchungssysteme offerieren ihre Dienste mittlerweile auf Basis des REST-Protokolls. Als zentrale Steuerungsinstrumente für eine Integration auf REST-Basis dienen die grundlegenden HTTP-Befehle GET, PUT, POST oder DELETE, die auf Daten angewendet werden. Eine konsequent nach REST aufgebaute Client-Server-Architektur darf dabei nur Ressourcen wie Seiten, Bilder oder CGI-Skripte kennen, die über URIs (Universal Resource Identifiers) angesprochen werden. Die Besonderheit: Client und Server kommunizieren zustandslos miteinander. Dies bedeutet, dass unter REST der vorherige oder auch zukünftige Verlauf einer Kommunikation keine Rolle spielt. Deshalb müssen alle Informationen folglich im Aufruf einer Ressource enthalten sein. Während also klassische Client-Server-Technik auf Remote Procedure Call (RPC) aufsetzt, werden Zustände und -übergänge innerhalb REST über Ressourcen abgebildet.
RPC und Soap
Demgegenüber wird in der RPC-Welt das Netz als Heimat verschiedener Netzobjekte aufgefasst, die alle etwas anderes können und auch alle eine andere Sprache sprechen. Soap und WSDL (Web Services Description Language) versuchen nun, diesen RPC-Gedanken in das Web zu übertragen. Einem guten Mashup ist es allerdings egal, ob der zu integrierende Dienst den REST-Anforderungen genügt, oder ob er der Web-Service-Fraktion per zustandsbehafteter Kommunikation mit Soap und WSDL angehört. Viele APIs der großen Anbieter bieten beide Protokolle für die Kommunikation an, wobei REST sukzessive die Oberhand zu gewinnen scheint. Die vier am meisten benutzten APIs Google Maps, Flickr, Amazon und YouTube in Mashups bieten REST-basierende Protokolle, unterstützen jedoch auch andere. Auch in puncto Skalierbarkeit hält REST mit Soap mit, wenngleich mit unterschiedlichen Ansätzen: Interaktionen sind in REST quasi autark, weil alle notwendigen Informationen in den Repräsentationen der Ressource enthalten sind. Da alle Interaktionen zustandslos verlaufen, muss bei einem Wechsel von einem Server zu einem anderen kein Status ausgetauscht werden dies wirkt sich wiederum positiv auf die Skalierbarkeit einer Anwendung aus.
Integration auf Datenebene
Während im klassischen Integrationsumfeld die Daten durch einfaches Extrahieren, Transformieren und Zusammenfassen in ein neues Repository integriert werden, lassen sich diese Prozesse im Web-Umfeld separat organisieren und anstoßen. Die derzeit bevorzugte Variante von Servern, die permanent Datenströme anbieten wie etwa Blogs oder News-Sites - leistet dies mittels RSS- oder ATOM-Feeds. Diese Methode ermöglicht es Clients, Datenströme durch regelmäßige Abfrage beim Server zu abonnieren und entweder in unveränderter Form darzustellen oder auch beliebig zu bearbeiten. Neuere Versionen von RSS unterstützen auch Anhänge, so dass sich höher aggregierte Inhalte, wie etwa bei Podcasts oder Vodcasts, leicht verteilen lassen.
Alternative Clients - Gadgets
Neben der Möglichkeit, die Ergebnisse einer Integration im Browser darzustellen, werden zunehmend auch Browser-unabhängige Möglichkeiten unterstützt. Dabei ist allerdings ein relativ großer Wildwuchs entstanden. Bei Gadgets beispielsweise handelt es sich um eine spezielle Variante von Mashups, die auch außerhalb des Browsers laufen und Web-Services auf eigene Art und Weise darstellen. Sämtliche dieser Gadgets setzen auf Web-Services oder anderen APIs - wie etwa Feeds auf und benötigen eine eigene Darstellungs-Engine. Das Problem: Unterschiedliche Gadgets erfordern auch die Einbindung unterschiedlicher Engines. Ein standarisiertes Verfahren zwischen den einzelnen Anbietern von Engines existiert bis dato nicht. Rund 15 Engines tummeln sich neben den bekanntesten von Google, Yahoo und Microsoft momentan im Web. Deshalb gilt es, anhand der verfügbaren Gadgets zu evaluieren, welche tatsächlich im Unternehmen implementiert werden sollen.
Einsatz in Unternehmen
Vorbilder für die Unternehmens-IT sind hier die großen Internet-Dienste, die ihre Daten, Applikationen und zum Teil sogar ihre Infrastruktur "mashbar" gestalten. Dazu zählen etwa Amazon mit elf APIs von Suche über Statistik bis hin zu Affiliate Commerce oder Storage sowie Google mit 20 APIs, Microsoft mit sieben Schnittstellen oder Yahoo mit 23 Interfaces. Generell existiert kaum mehr ein IT-Umfeld, dessen Dienstleistungen nicht bereits als Mashup angeboten werden. Das bedeutet, dass neben Software as a Service via Web orthogonal die Themen Kombinierbarkeit anstehen und damit potenzieren sich die Möglichkeiten des Einsatzes.
Natürlich stellt sich die Frage, welche Anwendungen sich für Mashups eignen. Grundsätzlich lohnt sich eine solche Integration immer dann, wenn sie keine logischen Abhängigkeiten, insbesondere Transaktionsabhängigkeiten, besitzen. Als idealer Anwendungsfall haben sich Situationen erwiesen, in denen ein Dienst als Overlay eines anderen verwendet werden soll. Das ist beispielsweise der Fall, wenn zwei grafische Präsentationen zueinander positioniert werden. Als typisches Exempel gilt Amazon-Light, das APIs von vier großen Playern der Branche verwendet: Google, Ebay, Amazon und Yahoo.
Defizite bei Transaktionen
Kennzeichnend für alle Mashups ist allerdings stets, dass die Funktionalitäten nicht transaktionsbasiert miteinander verbunden sind, sondern sich logisch ergänzen. Schwierigkeiten treten immer dann auf, wenn Mashups versuchen sollen, komplizierte Prozesse zwischen den Diensten darzustellen. Eine Reisebuchung etwa, in der die Hotelreservierung nicht funktioniert, veranlasst den Anwender in der Regel dazu, auch die Flugbuchung rückgängig zu machen. Hier ist man letztlich doch auf eine Orchestrierung der Dienste angewiesen, eine Fähigkeit, die den meisten Mashups derzeit noch nicht gegeben ist.
Unternehmen werden sich den Mashups auf zwei Wegen nähern: durch die Verwendung der offenen APIs (und das Integrieren externer Dienste in eigene Angebote) sowie durch das teilweise Offenlegen eigener E-Commerce- oder E-Communication-Schnittstellen. Häufig sind Interfaces im Unternehmen nämlich bereits Mashup-fähig, jedoch nicht offengelegt. Die Grundlage für ein erfolgreiches Integrationsmodell bildet ein seriöses Ausgangsangebot an Daten, Applikationen und Services. Vor allem im Umfeld des Customer-Rela-tionship-Managements (CRM) lassen sich so Kundenkontakte Mashup-fähig gestalten und in Verbindung mit geografischen Daten und Projekterfolgsrechnungen der letzten Jahre erfolgreich nutzen. Eine Strategie, die auch die öffentlich-rechtlichen Fernsehsender ARD und ZDF wenngleich in anderer Form und nicht auf klassischer Mashup-Basis vorbildlich praktizieren: Beide Stationen nutzen mittlerweile Google Earth als Quelle für die Übertragung zahlreicher Geoinformationen. (ws)