Find file
Fetching contributors…
Cannot retrieve contributors at this time
12 lines (6 sloc) 6.21 KB
Angenommen ein IT-Unternehmen setzt in seinem Intranet eine Projektverwaltungssoftware ein, in der Mitarbeiter auf die Projekte, an denen sie arbeiten, Zugriff haben. In diesem Intranet werden auch die Aufgaben zu den einzelnen Projekten verwaltet, sowie die zugeordneten Kostenstellen. Die Software bietet auch eine Funktion zur Zeiterfassung an, diese ist aber sehr unkomfortabel und wird von den Mitarbeitern deswegen nicht gerne verwendet. Das Unternehmen entscheidet sich nun, die Online-Zeiterfassung \emph{mite}\footnote{\url{http://mite.yo.lk/}} zur Zeiterfassung einzusetzen. Die Funktionalität von \emph{mite} kann für sich alleinstehend verwendet werden. Hierzu werden über die Website die nötigen Businessdaten von \emph{mite} (Benutzer, Leistungen\footnote{beschreibt eine Tätigkeit, z.B. Programmierung, mit einem Stundensatz}, Projekte, Kunden und Zeiten) angelegt. Diese Daten werden bei \emph{mite} gespeichert. Mit der öffentlichen API von \emph{mite}\footnote{\url{http://mite.yo.lk/api/index.html}} ist es aber auch möglich, alle Businessdaten "`von außen"' zu bearbeiten. \emph{mite} ist ein Beispiel für eine \emph{komplexe Webanwendung} die sich vor allem dadurch auszeichnen, dass sie komplexe Arbeitsabläufe abbilden und deren Arbeitsergebnisse abspeichern --- die Anwendung wird dadurch, im Gegensatz zu klassischen Webservices, \emph{zustandsbehaftet}. Um die Verwendung von \emph{mite} für die eigenen Mitarbeiter so komfortabel wie möglich zu machen, und die erfassten Zeiten automatisch den eigenen Projekten zuordnen zu können, implementiert das Unternehmen in der Intranet-Software ein Mapping zwischen seinen eigenen Businessdaten und denen von \emph{mite}. Mit Hilfe das Mappings können beide Systeme parallel verwendet werden und es ist sichergestellt, dass die Datenbestände beider Seiten synchronisiert sind.
Hier wird das Problem offensichtlich: Die bisherige Vorgehensweise, Webservice individuell an eine Software zu binden ist nicht flexibel. Entscheidet sich das Unternehmen zu einem späteren Zeitpunkt, einen anderen oder weiteren Anbieter zur Zeiterfassung einzusetzen, muss diese Anbindung erneut implementiert werden. Es fehlt eine Beschreibung der Schnittstellen, die derart gestaltet ist, dass die Vermittlung zwischen den verschiedenen Domänenkonzepten, das Mapping, automatisch erfolgen kann.
\label{l:soa}Der Wunsch nach solch einer flexiblen Architektur manifestiert sich in der \ac{SOA}. Die Idee, Informationen und Funktionen von Software mit Hilfe von Webservices zu verwenden, fußt auf dem, durch die Konzepte zur \ac{SOA} eingeleiteten, Paradigmenwechsel zu modularen Systemen mit loser Kopplung. In einer \ac{SOA} werden Anwendungen nicht mehr monolithisch aufgebaut, sondern in kleinere, in sich geschlossene Komponenten unterteilt. Diese kommunizieren miteinander in einem Netzwerk über ihre öffentliche Schnittstellen, der sogenannten API. Diese Kapselung von Diensten hat auch zum Ziel, eine möglichst hohe Kohäsion innerhalb eines Systems zu ermöglichen --- Quellcode soll, wenn möglich, nur einmal geplant, entworfen und geschrieben werden, und im ganzen System zum Einsatz kommen, woraus im Endergebnis weniger Code, eine höhere Standardisierung und damit letztendlich niedrigere Kosten resultieren \cite[S.62]{hn-web20}.
Spätestens mit der Entwicklung des Internets zum \emph{Web 2.0} wurde diese Idee auch auf das Internet übertragen. Inzwischen ist es die Regel, dass webbasierte Anwendungen einen Teil ihrer Daten und Funktionen mit Hilfe von Schnittstellen "`nach außen"' publizieren. Die Kommunikation mit diesen Schnittstellen ist dabei auf Protokollebene standardisiert. Nach Elyacoubi, Belouadha und Roudies in \cite[S.653]{ei-sawsdl} sind etablierte Standards für Webservices der ersten Generation wie \ac{WSDL}, \ac{SOAP} und \ac{UDDI} primär unter dem Aspekt entwickelt worden, einen einfachen Weg zur Verteilung und Wiederverwertung von Services in einer \ac{SOA} zu etablieren. Mithilfe dieser Standards lassen sich zu einem Problem passende Dienste in der \ac{UDDI} finden, die \ac{WSDL} kann dann dazu verwendet werden Quellcode(-Fragmente) zu generieren und mit Hilfe von \ac{SOAP} kann schließlich mit ihnen kommuniziert werden. Es fehlt aber die Möglichkeit, das Auffinden (\emph{discovery}), Veröffentlichen (\emph{publication}), Zusammenstellen (\emph{composition}), und Aufrufen (\emph{invocation}) automatisch vorzunehmen.
\label{l:intro-loosecoupling}Um eine wirklich modulare Architektur zu erzeugen, muss diese in der Lage sein, die zur Erledigung einer Aufgabe nötigen Abläufe aus beliebigen, passenden Diensten zusammensetzen zu können --- erst so wird eine Architektur fehlertolerant und kann auf das Entfallen und Hinzukommen von Diensten schnell reagieren. Voraussetzung hierfür ist, dass die Semantik eines Webservices maschinenlesbar zur Verfügung gestellt wird, damit eine automatische Vermittlung zwischen einer Aufgabe und zur Verfügung stehenden Webservices erfolgen kann.
Im Hinblick auf ökonomische Aspekte kann es sogar von Vorteil sein, die parallele Verwendung mehrere Dienste der gleichen Art zu ermöglichen. Patel beschreibt in \cite[S.29]{pl-depintra}, dass Unternehmensintranets oft zu unspezifisch für die individuellen Bedürfnisse eines einzelnen Mitarbeiters sind. Im anfangs beschriebenen Intranet-Beispiel könnte das Unternehmen seinen Mitarbeitern die Zeiterfassung mit \emph{mite} ermöglichen, aber auch alternativ mit \emph{TimeNote}\footnote{\url{http://www.timenote.de/}}. Auf den ersten Blick erscheint diese Heterogenität kontraproduktiv, das Unternehmen eröffnet seinen Mitarbeitern aber so die Möglichkeit, das Werkzeug für die gegebene Aufgabe "`Zeiterfassung"' zu verwenden, das ihren Vorlieben am besten entspricht, und kann dadurch die Akzeptanz dafür steigern. Neben der Möglichkeit der Wahl, erhält man so auch automatisch Redundanz. Masak hat in \cite[S.236ff]{mkdigioe} diesen Gedanken auf eine größere Ebene übertragen und kommt zu dem Schluss, dass es in einem digitalen Ökosystem, wie das Internet eines ist, notwendig ist, Redundanz auf allen Ebenen einzuführen, und durch ein abstrahiertes Mapping eine ad-hoc Komposition von Services zu ermöglichen, da es durch die schiere Größe unmöglich ist alle Aspekte des Systems systematisch zu erfassen.