Typos und Formulierungen korrigiert.

.gitignore

@@ -6,3 +6,4 @@ fachseminar.bbl
 fachseminar.toc 
 fachseminar.blg
 fachseminar.dvi 
+.project

abkuerzungen.tex

@@ -11,7 +11,6 @@
 \newacro{RDFS}[\emph{RDFS}]{\emph{RDF Vocabulary Description Language: RDF Schema}\footnote{http://www.w3.org/TR/rdf-schema/}}
 \newacro{OWL}[\emph{OWL 2}]{\emph{OWL 2 Web Ontology Language}\footnote{http://www.w3.org/TR/owl2-primer/}}
 \newacro{WSIF}[\emph{WSIF}]{\emph{Web Services Invocation Framework}\footnote{http://ws.apache.org/wsif/}}
-\newacro{REST}[\emph{REST}]{\emph{Representational state transfer}}
 \newacro{W3C}[\emph{W3C}]{\emph{World Wide Web Consortium}\footnote{http://www.w3.org/}}
 \newacro{mite}[\emph{mite}]{Online-Zeiterfassung}
 \newacro{WSMO}{\emph{Web Service Modeling Ontology}}
@@ -20,7 +19,5 @@
 
 % Shorthands für Häufig gebrauchte Kürzel
 
-\newcommand{\ws}{Webservice }
-\newcommand{\wss}{Webservices }
 \newcommand{\restapi}{\emph{RESTful} \ac{API} }
 \newcommand{\restapis}{\emph{RESTful} \ac{API}\emph{s} }

abstract.tex

@@ -1,3 +1,3 @@
 \section*{Abstract}
 
-Die Suche nach Konzepten für die dynamische Bindung von \ws ist die Motivation für diese Fachseminararbeit. Vorraussetzung dafür ist, dass \ws semantisch beschrieben werden, erst so ist eine automatische Dienstvermittlung zur Laufzeit möglich. Wie Dostal und Jeckle aber in \cite[S.55]{xmlspek1} beschreiben, wurden aktuell verbreitete Standards zur Anbindung von \ws wie z.B. die \acs{WSDL} aber im Hinblick auf die Anbindung von \emph{Services} mit einer konkreten \acs{API} entwickelt --- sie beschreiben den syntaktischen Rahmen einer Schnittstelle, das zu Grunde liegende Wissen über das Domänenkonzept, also die \emph{Semantik}, wird nicht festgehalten. Nach einer Einführung in das Thema in Abschnitt~\ref{l:einleitung}, in dem der aktuellen Stand der Entwicklung beschrieben wird und die daraus resultierende Hindernisse bei der dynamischen Bindung von \ws erläutert werden, werden in Abschnitt~\ref{l:sem-web-ser} die theoretischen Aspekte und wie man mit Hilfe von \emph{Ontologien} Domänenkonzepte semantisch beschreibbar machen kann vorgestellt. Mit der \acs{SAWSDL} liefert das \acs{W3C} den Entwurf eines Standards für diese Aufgabe, der in Abschnittes~\ref{l:sawsdl} beschrieben wird. Abschnitt~\ref{l:loesungen} stellt mögliche Lösungsansätze für die Implentierung einer \acs{SOA} vor, deren Dienste zur Laufzeit gebunden werden. Im Fazit in Abschnitt~\ref{l:fazit} werden die aufgezeigten Konzepte auf ihre Anwendbarkeit auf \emph{komplexen Webanwendungen} analysiert.
+Die Motivation für diese Fachseminararbeit ist die Suche nach Konzepten für die dynamische Bindung von Webservices ist. Vorraussetzung dafür ist, dass Webservices semantisch beschrieben werden, erst dann ist eine automatische Dienstvermittlung zur Laufzeit möglich. Wie Dostal und Jeckle aber in \cite[S.55]{xmlspek1} beschreiben, wurden jedoch Standards zur Anbindung von Webservices wie z.B. \acs{WSDL} im Hinblick auf die Anbindung von \emph{Services} mit einer konkreten \acs{API} entwickelt --- sie beschreiben den syntaktischen Rahmen einer Schnittstelle, das zu Grunde liegende Wissen über das Domänenkonzept, also die \emph{Semantik}, wird nicht beschrieben. Nach einer Einführung in das Thema in Abschnitt~\ref{l:einleitung}, in dem der aktuellen Stand der Entwicklung beschrieben wird und die daraus resultierende Hindernisse bei der dynamischen Bindung von Webservice erläutert werden, führt Abschnitt~\ref{l:sem-web-ser} in die theoretischen Aspekte ein und zeigt wie man mit Hilfe von \emph{Ontologien} Domänenkonzepte semantisch beschreibbar machen kann. Mit der \acs{SAWSDL} existiert ein Standards für diese Aufgabe, der in Abschnittes~\ref{l:sawsdl} beschrieben wird. Abschnitt~\ref{l:loesungen} stellt mögliche Lösungsansätze für die Implentierung einer \acs{SOA} vor, deren Dienste zur Laufzeit gebunden werden. Im Fazit in Abschnitt~\ref{l:fazit} werden die aufgezeigten Konzepte auf ihre Anwendbarkeit auf \emph{komplexen Webanwendungen} analysiert.

fachseminar.tex

@@ -78,11 +78,11 @@ \section{Einleitung}
 \label{l:einleitung}
 \input{intro}
 
-\section{Semantische \ws}
+\section{Semantische Webservices}
 \label{l:sem-web-ser}
 \input{semws}
 
-\section{Dynamische Verwendung von semantischen \ws}
+\section{Dynamische Verwendung von semantischen Webservices}
 \label{l:loesungen}
 \input{loesungen}
 

intro.tex

@@ -1,18 +1,17 @@
-In diesem Abschnitt wird das grundlegende Problem bei der Anbindung \emph{webbasierter Anwendungen} erläutert.
+In diesem Abschnitt wird das grundlegende Problem bei der Anbindung \emph{komplexer Webanwendungen} erläutert.
 
 \bigskip
 
-\emph{Webbasierter Anwendungen} zeichnet aus, dass sie komplexe Arbeitsabläufe abbilden --- die Anwendung wird dadurch \emph{zustandsbehaftet}. Als Beispiel für diese Art von webbasierten Diensten werde ich in dieser Seminararbeit eine \ac{mite}\footnote{http://mite.yo.lk/} betrachten. 
+\emph{Webbsierte Anwendungen} zeichnet aus, dass sie komplexe Arbeitsabläufe abbilden --- die Anwendung wird dadurch \emph{zustandsbehaftet}. Als Beispiel für diese Art von webbasierten Diensten werde ich in dieser Seminararbeit die \emph{mite}\footnote{http://mite.yo.lk/} betrachten. 
 
-Angenommen, ein IT-Unternehmen setzt in seinem Intranet eine Projektverwaltungssoftware ein, in der alle Mitarbeiter auf alle 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, \ac{mite} zur Zeiterfassung einzusetzen. Die Funktionalität von \ac{mite} kann für sich alleinstehend verwendet werden. Hierzu werden über die Website die nötigen Businessdaten von \ac{mite} (Benutzer, Leistungen\footnote{beschreibt eine Tätigkeit, z.B. Programmierung, mit einem Stundensatz}, Projekte, Kunden und Zeiten) angelegt. Diese Daten werden bei \ac{mite} gespeichert. Mit der öffentlichen \acs{API}\footnote{http://mite.yo.lk/api/index.html} von \ac{mite} ist es aber auch möglich, alle Businessdaten "`von außen"' zu bearbeiten. Um die Verwendung 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 \ac{mite}. Mit Hilfe das Mappings können beide System parallel verwendet werden und es ist sichergestellt, dass die Datenbestände beider Seiten synchronisiert sind. Entscheidet sich das Unternehmen aber zu einem späteren Zeitpunkt, einen anderen oder weiteren Anbieter zur Zeiterfassung einzusetzen muss diese Anbindung erneut implementiert werden.
+Angenommen ein IT-Unternehmen setzt in seinem Intranet eine Projektverwaltungssoftware ein, in der alle Mitarbeiter auf alle 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, \emph{mite} 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 \ac{API} von \emph{mite}\footnote{http://mite.yo.lk/api/index.html} ist es aber auch möglich, alle Businessdaten "`von außen"' zu bearbeiten. Um die Verwendung 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 System parallel verwendet werden und es ist sichergestellt, dass die Datenbestände beider Seiten synchronisiert sind. Entscheidet sich das Unternehmen aber zu einem späteren Zeitpunkt, einen anderen oder weiteren Anbieter zur Zeiterfassung einzusetzen muss diese Anbindung erneut implementiert werden.
 
-Hier wird das Problem offensichtlich: Die bisherige Vorgehensweise, \ws individuell an eine Software zu binden ist nicht flexibel. Es fehlte eine Beschreibung der Schnittstelle, die derart gestaltet ist, dass die Vermittlung zwischen den verschiedenen Domänenkonzepten, das Mapping, automatisch erfolgen kann.
+Hier wird das Problem offensichtlich: Die bisherige Vorgehensweise, Webservice individuell an eine Software zu binden ist nicht flexibel. Es fehlte eine Beschreibung der Schnittstelle, 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 \ws 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 Intra- oder einem Extranet über ihre öffentliche Schnittstellen, der sogenannten \ac{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 verwendet werden, woraus im Endergebnis weniger Code, eine höhere Standardisierung und damit letztendlich niedrigere Kosten resultieren \cite{hn-web20}. 
-% TODO: Seite fehlt
+\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 Webservice 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 \ac{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 verwendet werden, woraus im Endergebnis weniger Code, eine höhere Standardisierung und damit letztendlich niedrigere Kosten resultieren \cite[S.62]{hn-web20}. 
 
-Spätestens mit der neueren 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{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 \ac{SOAP} kann schließlich mit ihnen kommuniziert werden. Es fehlt ihnen aber die Möglichkeit, das Auffinden \emph{discovery}), Veröffentlichen (\emph{publication}), Zusammenstellen (\emph{composition}), und Aufrufen (\emph{invocation}) automatisch vorzunehmen. \cite[S.653]{ei-sawsdl}
+Spätestens mit der neueren 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 \ac{SOAP} kann schließlich mit ihnen kommuniziert werden. Es fehlt ihnen 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 ein 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 \ws maschinenlesbar zur Verfügung gestellt wird, damit eine automatische Vermittlung zwischen einer Aufgabe und zur Verfügung stehenden \ws erfolgen kann.
+\label{l:intro-loosecoupling}Um ein 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 Webservice maschinenlesbar zur Verfügung gestellt wird, damit eine automatische Vermittlung zwischen einer Aufgabe und zur Verfügung stehenden Webservice 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 z.B. in \cite[S.29]{pl-depintra}, dass Unternehmensintranets oft zu unspezifisch für die individuellen Bedürfnisse eines einzelnen Mitarbeiters sind. Im unserem Intranet-Beispiel könnte das Unternehmen seinen Mitarbeitern die Zeiterfassung mit \ac{mite} ermöglichen, aber auch alternativ mit z.B. \emph{TimeNote}\footnote{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, dass ihren  Vorlieben am ehesten 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 eine 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.
+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 unserem Intranet-Beispiel könnte das Unternehmen seinen Mitarbeitern die Zeiterfassung mit \emph{mite} ermöglichen, aber auch alternativ mit z.B. \emph{TimeNote}\footnote{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, dass ihren  Vorlieben am ehesten 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 eine 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.