Anatol Zund smarter living

5Sep/07Off

Junit 4.1

Das Referat über JUnit habe ich in Zusammenarbeit mit Mircea Dumitru geschrieben.
Referat als PDF: JUnit_4_1.pdf

JUnit in einem Satz

JUnit ist ein Java-Framework für die Erstellung von Unit Tests

Definition von JUnit

JUnit ist ein Framework zum Testen von Java-Programmen, das besonders für automatisierte Unit-Tests einzelner Units (meist Klassen oder Methoden) geeignet ist. Es basiert auf Konzepten, die ursprünglich unter dem Namen SUnit für Smalltalk entwickelt wurden.

Einleitung

Warum Testen?

In der heutigen Zeit, wo Softwareprodukte immer komplexer werden, ist vor allem die Qualität einer Software sehr wichtig. Da aber komplexe Software in begrenzter Zeit nur unvollständig erfassbar und realisierbar ist enthält jede Software Fehler.
Um diese Fehler zu aufzudecken werden Tests notwendig, die eine teilweise hohe Softwarequlität sicherstellen können.
Ziel eines Tests ist somit eine Software mit der Absicht zu prüfen, Fehler zu finden.
Ein Test sollte:

  • Fehler so früh wie möglich finden
  • unabhängig erfolgen
  • mehr bringen als kosten
  • automatisiert wiederholbar sein
  • möglichst zeitnah zur Programmierung sein
  • Spaß machen

Ein Test sollte nicht:

  • keine Fehler finden

Somit kann ein Test nicht die Korrektheit eines Software beweisen, sondern nur die Anwesenheit von Fehlern.

Softwaretestarten

Tests können bzgl. eines Testobjekts in verschiedene Testarten klassifiziert werden:

  • Unit –bzw. Modul Tests
  • Integrationstests
  • Performance Tests
  • Funktionale –und Akzeptanz Tests

Unit –bzw. Modul Tests

Unit –bzw. Modul Tests dienen zur Verifikation der Korrektheit der einzelnen Softwarebausteine (Module; je nach Programmiersprache z. B. Klassen). Durch Ablauf aller Testfälle soll nach Programmfehlern gesucht werden. Hierzu wird ein ausführbarer Code erzeugt der die einzelnen Testfälle durchspielt und die Ergebnisse mit den erwarteten Werten vergleicht. Dabei prüft jeder Testfall immer nur ein mögliches Verhalten des Moduls ab, um hinterher genau feststellen zu können, wodurch ein Fehler erzeugt wurde.
Unit Tests sollten zeitnah zur Programmierung erstellt und nach jeder Programmmodifikation ausgeführt werden.

Integrationtests

Integrationstests prüfen die kortrekte Interaktion voneinander abhängiger Komponenten in einem komplexen System. Dazu müssen die zu prüfenden Komponenten den Unit-Test erfolgreich abgeschlossen´haben um zu zeigen, dass sie isoliert fehlerfrei funktionieren.

Performance Tests

Performance Tests dienen dazu das Verhalten einzelner Module oder Systeme bezüglich einer definiterten Hardwareumgebung zu Testen. Im Mittelpunkt steht dabei, ob das System die vom Kunden gewünschte Reaktionszeit einhält und auch unter hoher Auslastung keine Fehler produziert.

Funktionale Tests

Funktionale Tests dienen dazu, die vom Kunden gewünschte Funktionalität des Systems unter Real-Bedingungen zu prüfen. Dabei wird getestet ob das entwickelte System den Anforderungen des Auftraggebers oder späteren Benutzers entspricht.

Unit Testarten

Die weitere Klassifizierung von Unit Tests basiert auf drei verschiedene Unit Testarten:

  • Logischer Unit Test
  • Integrations Unit Test
  • Funktionaler Unit Test

Logischer Unit Test

Der Logische Unit Test überprüft nur einzelne Methoden bestimmter Klassen eines Softwaresystems.

Integrations Unit Test

Der Integrations Unit-Test überprüft das Zusammenspiel zwischen den einzelnen Komponenten eines Softwaresystems.

Funtionaler Unit Test

Der Funtionaler Unit-Test erweitert die Grenzen des Logischen Unit Tests und Integrations Unit Test so, dass Arbeitsabläufe getestet werden können. Die einzelnen Arten von Unit Tests können als White-Box-Test oder als Black-Box-Test durchgeführt werden.
White-Box-Test
Der White-Box-Test wird von den gleichen Programmieren entwickelt und durchgeführt wie das zu testende System selbst. Dabei besteht eine Kenntnis über die innere Struktur des Testobjektes.
Black-Box-Test
Der Black-Box-Test wird von speziellen Testabteilungen entwickdet und durchgeführt. Dabei besteht keine Kenntnis über den inneren Aufbau des zu testenden Objektes.

Herleitung der Testfälle

Die wichtigsten Bausteine, um erfolgreich zu Testen, sind die richtigen Testfälle. Es nutzt wenig, wenn man 20 Tests durchführt die im Endeffekt das Selbe Verhalten abprüfen, man dafür jedoch ein anderes Verhalten komplett übersieht. Für die Herleitung der Testfälle gibt es verschiedene Methoden, die wir hier auszugsweise aufzeigen wollen.

Äquivalenzklassenmethode

Bei der Äquivalenzklassenmethode werden Eingabeparameter eines Moduls oder einer Methode, die das gleiche Verhalten haben, in Klassen eingeteilt. Dazu wird die Spezifikation des Moduls oder der Methode analysiert.
Beispiel:
Man betrachtet ein Modul, dass nur Geldbeträge zwischen 0,01€ und maximal 500€ verarbeiten soll. Nun kann man alle Werte zwischen 0,01 und 500 zu einer Klasse zusammenfassen. Man wählt aus diesem Bereich dann einen Wert zum Testen aus. Ist der Test mit diesem Wert erfolgreich kann man davon ausgehen, dass er auch für alle anderen Werte der Klasse erfolgreich verläuft.
In diesem Beispiel kann man 3 Äquivalenzklassen bilden:

  • 0,01 <=x <= 500
  • x<=0
  • x>500

Prüft man aus diesen Bereichen jeweils einen Wert ab, kann man das Verhalten des Moduls testen.

Grenzwertanalyse

Die Grenzwertanalyse ist eine Erweiterung der Äquivalenzklassenmethode. Zusätzlich wird hier besonderes Augenmerk auf die Grenzen der Spezifikationen gelegt, da die Fehler sich in diesem Berech häufen.
In unserem Beispiel würde man die 3 Testfälle für die Äquivalenzklassen um folgende Testfälle erweitern:

  • -0,01
  • 0,00
  • 0,01
  • 500,00
  • 500,01

Vorgehensmethoden zur Softwareentwicklung

Testgetriebene Entwicklung

Von testgetriebener Entwicklung spricht man, wenn bei der Softwareentwicklung der Testplan vor der eigentlichen Implementierung erstellt wird. Während bei der klassischen Vorgehensweise der Test erst nach Fertigstellung des Moduls/Systems erstellt wird.
Nachteile wie mangelnde Testbarkeit, Zeitmangel, unzureichende Tests werden bei dieser Methode vermieden.
Testgetriebene Entwicklung arbeitet mit Tests auf zwei Ebenen.

Testen im Kleinen

Diese Tests beziehen sich auf die einzelnen Module des Systems. Hierbei wird der Testplan während der Entwicklung mit entwickelt. Man teilt die Implementierung in kleine Portionen auf z.B. in einzelne Methoden. Vor jeder Implementierung einer Methode werden die dazu gehörenden Testfälle erstellt. Dann wird (noch vor der Implementierung der Methode) ein Testlauf durchgeführt, der fehlschlägt. Nun wir die Methode implementiert und anschließend wieder getestet. Dies wiederholt sich so lange, bis alle Testfälle positiv beendet werden. Danach räumt man den Sourcecode auf und kümmert sich um die Kommentare. Ein abschließender Testlauf stellt sicher, dass man dabei keine Änderungen an der Funktion der Methode vorgenommen hat.

Testen im Großen

Diese Tests beziehen sich auf das gesamte System. Die Testfälle lassen sich aus den Spezifikationen ableiten und werden schon vor der Systemimplementierung aufgestellt.
Mit Hilfe dieser Tests kann geprüft werden, ob das System den Anforderungen des Kunden genügt.
Vorteile
Die Vorteile der testgetriebenen Entwicklung liegen in der verringerten Fehleranzahl (besonders bei Änderungen) und einer besseren Messbarkeit der Anforderungen. Da nur korrekte Module gespeichert werden, kann jeder Programmierer meistens auf „korrekte“ Module zugreifen um mit ihnen zu arbeiten. Des Weiteren fördert diese Vorgehensweise das „Think first – code later“-Prinzip, da man sich vor der Implementierung schon Gedanken über die Testfälle und damit auch über mögliche Probleme macht.

Weiterführende Tests

Dieses Kapitel widmet sich weiterführenden Tests, die auch über den Rahmen von JUnit hinausgehen.

Integrationstest (Cactus)

Cactus erlaubt es einem Integrationstests von Servlets und JSPs durchzuführen. Dabei wird das zu testende System auf dem Zielsystem ausgeführt um sein Verhalten in der Laufzeitumgebung zu prüfen. Es erweitert JUnit und verwendet im Moment noch JUnit 3.8.1.
Die Testfälle sind gleich aufgebaut wie bei JUnit selbst. Man kann die Tests sowohl manuell über die Komandozeile, als Plugin in einer IDE, oder im Webbrowser ausführen. Als Ergebnis bekommt man eine Zusammenfassung als XML-Datei die fehlgeschlagene Tests aufzeigt, oder aber eine Erfolgsmeldung zurückgibt.

Funktionale Tests (HTTPUnit)

HttpUnit ist eine Erweiterung für JUnit um automatisierte Website-Tests durchzuführen. Es ermöglicht die zurückgegebene Seite zu analysieren und z.B. dort enthaltenen Links zu folgen. Somit kann das Surf-Verhalten von Usern simuliert werden. Zusätzlich kann man auch Formulare oder JavaScript ausführen.

Load/Performance Testing (JMeter)

Bei JMeter handelt es sich um ein umfangreiches Testtool um Systeme unter großer Last zu testen. Hierzu erzeugt das Tool je nach Vorgabe eine große Anzahl von Threads, die alle auf das gleiche System zugreifen und misst dabei z.B. die Latenzzeit oder den Datendurchsatz. Dabei unterstützt es unter Anderem folgende Tests:

  • http, ftp
  • Datenbanken über JDBC
  • Java
  • JUnit
  • Webservices
  • LDAP

Da dieses Tool die Möglichkeit hat die Tests über mehrere Rechner zu verteilen kann damit auch ein Lasttest gegen größere Maschinen durchgeführt werden.

Load Testing (JUnitPerf)

Mit JUnitePerf kann man erweitert man JUnit um die Funktion Performance-Parameter abtesten zu können. So kann man vorgegebene Reaktionszeiten messen und testen. Zusammen mit einem Lastentest mit JMeter kann das System unter realen bzw. extremen Bedingungen getestet und somit verifiziert werden.

2Sep/07Off

Seminararbeit – Mashups

Autoren: Andreas Richter, Anatol Zund Präsentation:

  • mashup.ppt
  • Videos (in das gleiche Verzeichins wie die Präsentation entpacken)

Die Seminararbeit wurde in das iwiki der FH-Würzburg eingestellt. Die aktuelle Version findet sich unter www.iwiki.de/wiki/index.php/Mashup

aus Iwiki, der freien Wissensdatenbank

Der Begriff Mashup hat seinen Ursprung in der Musik. Ähnlich wie in der Musik, wo zwei oder mehrere Songs zusammengemischt zu einem neuen Song als Mashup bezeichnet werden, ist auch Mashup in der IT definiert. Die Begriff Mashup entstand parallel mit dem Begriff Web 2.0 und bezeichnet Webseiten, welche aus mindestens zwei Services zusammen gemischt wurden. Die APIs der einzelnen Services stellen für das neue Mashup Daten und Services, wie z.B. Karten, Videos, Suchfunktionen, Bezahlsysteme und vieles mehr zur Verfügung.

Grundlagen

Weitere Definitionen von Mashups stammen von Wikipedia und IBM:
"A mashup is a website or web application that seamlessly combines content from more than one source into an integrated experience." (Quelle: Wikipedia)
"Mashups are an exciting genre of interactive Web applications that draw upon content retrieved from external data sources to create entirely new and innovative services." (Quelle: IBM)

Abgrenzung

Die Abgrenzung von Mashups zu "normalen" Seiten ist fließend. Allen Definitionen zu Grunde liegt die Tatsache, dass, durch das Zusammenspiel mehrerer Datenquellen oder Services etwas Neues, möglichst innovatives, erzeugt werden soll. Die Frage ist wie man dies genau sieht. Für manche reicht es Daten aus mehreren Quellen auf einer Seite anzuzeigen. Diese Art der Verwendung fremder Inhalte ist nicht neu. In den 90er Jahren war kaum eine private Homepage zu finden, die nicht einen Newsticker, Wetterberichte oder einen externen Webcounter einsetzte. Eine andere Herangehensweise wäre zu sagen, dass die Mashup-Seite mit den externen Daten eine Transformation durchführen muss. Dies würde aber dazu führen, dass eine Seite die externen Daten nur mit einem anderen Layout anzeigt auch als Mashup gilt. Bei einer Abgrenzung durch die Verwendeten Techniken kommt man ein Stück weiter. Während auf "normalen Seiten" externe Daten meist durch das Darstellen von Bildern, Java-Applets oder einfache Javascript-Aufrufen angezeigt werden, greift man bei Mashups auf externe oder interne APIs zurück. Die drunter liegenden Techniken sind auch schon früher verwendet worden (JavaScript), jedoch hatte der Anwender nur sehr begrenzte Möglichkeiten. Der größte Punkt den ein Mashup ausmacht ist die Vermischung der Daten. Auf einer "normalen" Seite würde man z.B. ein Bild von einer Karte finden (das durchaus von einem externen Anbieter kommen kann) und eine Liste mit Adressen. Aus diesen beiden getrennten Datenbereichen würde bei einem Mashup ein einziger Bereich werden. Eine Karte auf der die Einzelnen Adressen durch Marker angezeigt werden über die der User interaktiv zu weiteren Informationen geführt wird.

History

Je nach Definition gibt es Mashups schon eine ganze Weile. Auch für die strengeren Definitionen gibt es Beispiele aus älteren Web-Tagen. Eine der ersten Webapplikationen die als Mashup bezeichnet wurde ist housingmaps.com. Die Seite wurde im April 2005 von Paul Rademacher entwickelt. Rademacher ärgerte sich über die Tatsache, dass er die Immobilien, die in der CraigRentals-Liste aufgeführt waren, selbst auf einer Karte suchen musste. Auf seiner Suche nach einer Lösung für diese Situation kam ihm der im Februar 2005 vorgestellte Kartendienst Google Maps gelegen. Er schrieb ein Mashup, das die Daten der CraigRentals-Liste auf einer Karte von Google Maps anzeigt; ein schönes Beispiel wie zwei Datenquellen bzw. Dienste miteinander verknüpft werden. Seitdem ist die Anzahl der Mashups stark gestiegen. Viele davon verknüpfen keine externen Daten miteinander sondern leben von einer Community, die Daten im Mashup einstellen. Beispielsweise Fahrrad-Routen auf einer Karte.

Technik

Die technische Realisierung kann in drei Bereiche aufgeteilt werden:

  • API / content provider
  • Die Mashup Seite
  • Der Client des User

API (content provider)

Der API- / content-provider: stellt seine Informationen mit Hilfe von Web-Protokollen, RSS/Atom oder eigenen Schnittstellen zur Verfügung. Informationen können aber auch durch Screen scraping beschafft werden.

Web- Protokolle

Sowohl SOAP als auch REST sind plattformneutrale Protokolle, die zur Kommunikation mit remote services eingesetzt werden.
SOAP
SOAP (Services-Oriented Access Protocol) besteht aus zwei Hauptkomponenten. Zum einen der Gebrauch des XML Formats zur plattformunabhängigen Kodierung und zum anderen der Nachrichtenstruktur, die aus header und body besteht. Der Header wird verwendet um textabhängige Informationen auszutauschen und mit dem Body werden die anwendungsspezifischen Daten übermittelt. Die SOAP Nachrichten werden üblicherweise mit dem http-Protokoll übertragen.
REST
REST (Representational State Transfer) ist eine Technik zur web-basierenden Kommunikation, die nur HTML und XML verwendet. REST ist sehr einfach und unterstützt nur die Operationen Post, Get, Put, Delete, welche für alle Arten von Informationen angewendet werden. Den Schwerpunkt bei REST bildet die Information selbst.

RSS und ATOM

RSS ist ein XML basiertes Format, das entwickelt wurde um Informationen die häufig aktualisiert werden auszutauschen. Der Content Provider stellt seine Information in einem RSS Dokument zur Verfügung. Auf der Mashup-Seite wird dieses externe Dokument eingebunden, so dass bei jedem Seitenaufruf immer die aktuelle Version verwendet wird. Atom ist ein neueres, aber ähnliches Protokoll. Es versucht die Vorzüge der unterschiedlichen RSS Formate zusammenzufassen und zu erweitern Diese beiden Protokolle können hervorragend bei Mashups verwendet werden die Neuigkeiten oder Termine verknüpfen.

Screen scraping

Screen scraping wird eingesetzt, wenn der Content Provider keine API zur Verfügung stellt. Durch den Einsatz von Tools wird der relevante Inhalt von Webseiten extrahiert und später in das eigene Mashup eingebunden. Der Hauptnachteil dieser Technik ist, dass die meisten Webseiten regelmäßig im Design verändert werden und das Tool nach so einem Vorgang manuell wieder auf die Webseite angepasst werden muss um den Inhalt korrekt herauszufiltern.

Semantisches Web und RDF

Das semantische Web ist eine Theorie, Informationen, die für den Menschen geschaffen wurden so zu beschreiben, dass diese auch von Maschinen verstanden und weiterverarbeitet werden können. Webseiten sind bisher für Menschen optimiert. Die Informationen werden mit einer Fülle an Formatierungs-Befehlen angereichert, so dass die Datenstruktur und Zusammenhang nicht aus dem über das Web übertragenen Quelltext ermittelt, sondern nur vom Menschen interpretiert werden kann. Durch Screen scraping kann ein Teil dieser Struktur wieder hergestellt werden (natürlich nur durch die Tatsache, dass ein Mensch den Quelltext analysiert hat und den einzelnen Blöcken eine Funktion zugewiesen hat)
RDF ist ein syntaktischer Ansatz zum Beschreiben von Daten. Neben dem Beschreiben von einzelnen Datenobjekten, in einem Datenmodell, können auch die Beziehungen der Objekte untereinander beschrieben werden. Durch das Beschreiben können Dokumente und weitere mit ähnlichem Inhalt vereinfacht und auch domainübergreifend gesucht werden.

Mashup Anbieter

Grundlegend benötigt ein Mashup Anbieter Webspace wo er die HTML-Seiten ablegen kann. Je nach Umfang des Mashups kommen dann noch serverseiteige und clientseitige Module zum Einsatz.

Serverseitig

Serverseitigen stehen dem Mashup Anbieter Programmiersprachen wie Java servlets, Perl, PHP, Python oder Ruby zur Verfügung.

Clientseitig

Mashups können clientseitig mit Hilfe von Javascript, Java-Applets oder Flash realisiert werden. Durch das benutzen von Javascript-APIs, wie z.B. bei Google Maps, wird der eigene Server entlastet. Die eingebundene Anwendung wird direkt vom Server des Content Provider geladen. Dadurch ist die Erstellung einer Webanwendung möglich, welche programmiertechnisch unabhängig vom sich ständig ändernden Inhalt ist. Meist verwendete Technik ist hier heutzutage AJAX

Gemischt

Gerne wird bei Mashups auch die Kombination aus einer server- und clientseitigen Anwendung verwendet.

Client des Users

Auf der Clientseite des Users wird ein Browser mit Javascript-Unterstützung benötigt.

Kategorien

Die Mashups lassen sich an Hand ihres Hauptzweckes in mehrere Kategorien einteilen. Hier werden die wichtigsten kurz erläutert.

Mapping

Mapping Mashups stellen Örtlichkeiten, Aufnahmen von Photos oder Wege und Routen auf virtuellen Karten dar.
Namhafte API Provider:

Interessante Mashups

  • housingmaps.com Bildet Häuser in den USA ab, welche zum Kauf oder zum Mieten angeboten werden.
  • About airport parking Auf mehreren Kartenausschnitten werden die Parkmöglichkeiten rund um ausgewählte Flughäfen in den USA angezeigt. Zudem wird die Entfernung zum Flughafen und die Parkgebühren angegeben.

Photo/Video

Die meisten Video und Photo Mashups bieten eine Lösung zum verwalten der eigenen Photos/ Video um ein einfaches Tauschen mit anderen Community-Mitgliedern zu ermöglichen.
Namhafte API Provider:

Interessantes Mashup

  • Pixagogo.com Auf dieser Seite werden Photos zu einem bestimmten Thema angezeigt und zudem noch extra auf einer Karte gemapped.

Handel

Bei Commerce Mashups stellen existierende Onlineshops oder Auktionshäuser, die Funktionalität ihrer Shops zur Verfügung. Zudem können dann auch im selbst entwickelten Mashup weitere Daten und Sicherheits- oder Bezahlfunktionen von anderen Anbietern eingebunden werden.
Namhafte API Provider

Interessante Mashups

  • Scan by shopper Dies ist eine Anwendung für Handys. Während dem Einkaufen ist ein Vergleich mit online Angeboten, durch Eingabe oder Fotografieren des Barcodes der Produkte, möglich.
  • qwertycars Diese britische Webseite verwendet die Autoangebote von Ebay und zeigt den Standort an dem das Auto abgeholt werden kann auf einer Karte an.

Suche

Search Mashups gehören mit zu den ältesten und weit verbreitesten Mashups. Ein Suchdienst stellt seinen Suchschlitz zum Einbinden in andere Webseiten zur Verfügung.
Namhafte API Provider

Interessantes Mashup

Mashup entwickeln / APIs

Um ein eigenes Mashup zu entwickeln hat es sich als vorteilhaft erwiesen sich an folgenden Ablauf halten:

  1. Idee finden
  2. Datenquellen suchen (APIs, screen-scraping, community)
  3. eigene Programmierkenntnisse analysieren
  4. Bei APIs registrieren
  5. Programmieren

 

Google Maps

Google Maps führt 30% Anteil die API-Rangliste souverän an und es ist daher sinnvoll hier einen kurzen Überblick über die API zu geben. Google Maps basiert momentan ausschließlich auf einer JavaScript Bibliothek.

Bereitgestellte Klassen

GMap2
Die GMap2 Klasse stellt die zentrale Karten-Klasse dar. Sie sorgt für die Anzeige der Karteninhalte und kümmert sich um die internen Event-Verwaltung (z.B. verschieben der Karte). Alle weiteren Anzeigefunktionen von Google Maps benötigen das Map-Objekt
Controls
Mit Hilfe der Controls können der Karte Steuerelemente hinzugefügt werden. So gibt es Kontrollen für den Zoom-Level und die Art der Karteansicht. Event-Verwaltung wird intern verarbeitet.
Events
Mit Hilfe der Event-Verwaltung kann man der Karte Funktionen für die Interaktivität mit dem Benutzer hinzufügen. So kann man das Klicken der Maustaste abfragen und in diesem Fall einen Marker setzen. Natürlich stehen neben Klick auch die gängigen Events zur Verfügung
Overlays
Overlays sind eine Art Folie die man auf die Karte legt. Auf diesen Folien kann man Markierungen in Form von Icons, „Sprechblasen“ oder Linien speichern. Man kann inzwischen auch eigene Overlay-Klassen erstellen die die ursprüngliche Klasse erweitern.
XML und RPC
Die API stellet Methoden zur Verfügung um Daten aus anderen Quellen zu laden. Dabei wird entweder ein XMLHttpRequest-Objekt verwendet oder ein einfacher http-GET Request abgesetzt. Des Weiteren stehen grundlegende XML-Parse Funktionen zur Verfügung um per XML-übertragene Daten zu verarbeiten.
Geocoding
Mit Hilfe des Geocoding ist man in der Lage Adressen in Länge- und Breiten-Koordinaten zu übersetzen. Mit diesen Koordinaten kann man dann z.B. einen Marker auf dem Overlay setzen.

Voraussetzungen

Um Google Maps auf der eigenen Seite zu verwenden benötigt man eine Registrierung. Dabei bekommt man den API-Key. Dieser Key kann nur auf der dazugehörigen Domain benutzt werden.

Chancen/Risiken/Ausblick

Risiken

API-Anbieter
Das Risiko der API-Anbieter beschränkt sich zum größten Teil auf die Finanzierung des API-Services. Es entstehen Kosten für die IT-Infrastruktur, die eine größere Anzahl von Anfragen verarbeiten muss. Sollte die Popularität einer API sprunghaft ansteigen, oder falsch geplant worden sein, kann es hier zu Engpässen kommen. Der API-Anbieter hält jedoch alle Fäden in der Hand. Zumindest die AGBs der kostenlosen APIs schließen ein Recht auf die Benutzung des Services aus. Der Service kann jederzeit eingestellt oder geändert werden.

Mashup-Betreiber
Das finanzielle Risiko eines Mashup-Betreibers ist für „einfache“ Mashups begrenzt. Es wird lediglich Webspace benötigt. Ein Großteil des Datenvolumens wird über die API-Anbieter abgewickelt. So können zumindest in der Probephase die Kosten gering gehalten werden. Diese Tatsache ermöglicht es auch, dass Privatleute ohne größeres Risiko Mashups anbieten können. Wächst der Service, muss auch etwas mehr in die IT investiert werden. Spätestens hier muss ein Finanzierungsmodell erarbeitet werden Weitere Gefahr droht dem Mashup-Anbieter von Nachahmern. Hat man ein erfolgreiches Konzept, dauert es nicht mehr lange bis ähnliche Services auftauchen. In manchen Fällen übernehmen auch die API-Anbieter die Idee. So geschehen bei Flicker wo, nachdem es mehrere Mashups gab die die Fotos mit Google Maps verknüpften, auch an so einem Dienst gearbeitet wird.

Chancen

API-Anbieter
Wenn man von einigen Idealisten absieht stehen hinter angebotenen APIs natürlich wirtschaftliche Interessen. Hierzu werden verschiedene Ansätze verwendet. So werden einige APIs nur gegen Bezahlung oder mit zusätzlichen Premiumdiensten angeboten. Google Maps darf man nur auf öffentlich zugänglichen Seiten kostenlos verwenden. Für Intranet-Dienste, oder Seiten die mehr als 50000 Aufrufe pro Tag erzeugen fangen die Kosten bei 10000€ pro Jahr an. Ein weiteres Herangehen ist das Revenue-Model. Hierbei stellt der API-Anbieter Produktdaten und in den meisten Fällen auch die Verkaufsabwicklung zur Verfügung. Der API-Anwender verwendet diese Daten auf seiner Seite. Bei einem Kauf über die Mashup-Seite bekommt der API-Anwender einen gewissen Betrag als Provision. Diese Maßnahme ist dafür gedacht, den Umsatz des API-Anbieters zu steigern. (vgl. Amazon, Ebay, Google AdSense) Als letzte Einnahmequelle der API-Anbieter ist die Platzierung von Werbung zu sehen. Neben den APIs die nur dies als Ziel haben behält sich z.B. Google Maps vor auf den Karten Werbung einzublenden (Google Maps Pro wird dabei ausgenommen). Allerdings wurde bis jetzt noch keine Werbung auf Google Maps angezeigt, da dieser Bereich momentan noch sehr umstritten ist.
Mashup-Anbieter
Die Finanzierungsmöglichkeiten der API-Anbieter sind begrenzter. Bezahl-Dienste setzen sich auf Grund umständlicher Zahlungsmethoden und der „Internet is free“-Mentalität nicht durch. Neben der Einblendung von Werbung, was bei niedrigen Besucherzahlen nicht zum Erfolg führen wird, bleibt die Verwendung von Revenue-Modellen. Es wird fieberhaft an weiteren Geschäftsmodellen gearbeitet, ohne jedoch einen wirklichen Durchbruch vermelden zu können. Einige Dienste bieten, wie die APIs auch, Premiumdienste an. Die Grundfunktionen bleiben kostenlos, einige Zusatzfunktionen werden Kostenpflichtig. Bei einigen Seiten kann man sich auch einen Eintrag kaufen (z.B. auf Kartendiensten). Es wird auch darüber nachgedacht, von der Community erarbeitete Daten (z.B. auf Karten erstelle Routen) zu verkaufen. Dies stößt aber nur bei wenigen Mitgliedern auf Zustimmung, die ja ihre Arbeit kostenlos der Seite zur Verfügung stellen.

Ausblick

Die meisten Mashups entstehen zurzeit in den USA. In Europa sind Mashups erst im Kommen und werden meist noch gar nicht wahrgenommen, was höchstwahrscheinlich an der Anzahl und Qualität der APIs liegt. In den USA gibt es viele API Provider, welche Daten von örtlichen Gegebenheiten wie z. B. die Kriminalitätsrate von Chicago oder freistehende Wohnungen in großen Städten, aufbereiten. Dadurch ist es möglich informativ hochwertige Mashups zu erzeugen, welche aber nur ein begrenztes Publikum ansprechen. In Deutschland sind diese spezifischen APIs nicht vorhanden, deswegen basieren hier die meisten Mashups auf mapping APIs oder auf nicht regionalgebundenen APIs. Bei den Mashups ohne den regionalen Bezug bekommt der User meist schnell den Eindruck, dass es sich bei der Anwendung um eine Spielerei und nicht um einen informativen Service handelt. Damit Mashups in Deutschland eine Zukunft haben müssten informative APIs mit regionalem Bezug entstehen um daraus hochwertige Mashups erzeugen zu können. Ansonsten werden nicht mehr als eine Spielerei bleiben.
Im Gartner Group Hype Cycle befinden sich die Mashups gerade am Höhepunkt. Die Zahl der Mashups nimmt stetig zu. In den laufenden Monaten wird diese Zunahme abnehmen und eine gewisse Ernüchterung eintreten, wenn sich die finanziellen Erfolge nicht einstellen. Vor allem Mashups ohne größeren Nutzen und keinen finanziellen Modellen werden von der Bildfläche verschwinden.

Weblinks

veröffentlicht unter: abgeschlossene Projekte keine Kommentare