Abbildungsverzeichnis. Tabellenverzeichnis. Quelltextverzeichnis

Transkript

1 Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Aufbau der Arbeit Grundlagen und Technologien Aufgaben Frameworks Representational State Transfer Eindeutige Identifikation von Ressourcen Verknüpfungen/Hypermedia Standardisierte Methoden Unterschiedliche Repräsentationen Statuslose Kommunikation Das Hypertext Transfer Protokoll Jersey Anforderungsanalyse und Entwurf Aufgabenstellung Funktionale Anforderungen Nichtfunktionale Anforderungen Anwendungsfälle Aufgabe erstellen Aufgabenzuweisung ändern Aufgabenbeschreibung aktualisieren Aufgabe löschen Ressourcenzuweisung ändern Aufgabenstatus ändern Aufgabe überwachen Eskalationen ausführen Architektur Implementierung Entwicklungsumgebung Wichtige Begriffe des Frameworks Paketstruktur Technologischer Überblick Der Annotationen Scanner Die TypeHandler Klassen Die Controller-Klassen Die Wrapper Klassen Die REST-Ressourcen Klassen Die Persistenzschicht Objekt- und Repräsentationstransformierung Konfiguration des Frameworks Die Aufgabenklasse Lebenszyklus von Aufgaben Aufgabenbearbeiter Annotationen der Ressourcen Proof of Concept Die Webanwendung Eine Aufgabe anlegen Bearbeiten der Aufgabe Fazit und Ausblick...52

2 Abbildungsverzeichnis Abbildung 1: Beispiel für einheitliches Interface (aus [Tilkov 2008])...8 Abbildung 2: Client/Server Kommunikation...8 Abbildung 3: Client Anforderung mit Vorgabe möglicher Repräsentationen...9 Abbildung 4: Auszug aus den Metadaten der Server Antwort...9 Abbildung 5: Landschaft verteilter Systeme zum Task Management...14 Abbildung 6: Übersicht Anwendungsfälle...17 Abbildung 7: Framework Komponenten Übersicht...25 Abbildung 8: Paketstruktur des Frameworks...27 Abbildung 9: Zusammenspiel des TypeHandlers mit dem Framework...30 Abbildung 10: Öffentliche Schnittstelle am Beispiel der TaskLifecycle Klasse...31 Abbildung 11: Kapselung eines Objekts in einem Wrapper Objekt...33 Abbildung 12: Zusammenspiel der JPA Komponenten...35 Abbildung 13: ER-Diagramm des Frameworks...36 Abbildung 14: Ablauf eines Status Wechsels...42 Abbildung 15: Startbild des CTCFrameworks...46 Abbildung 16: Eingabe der Aufgabendaten...47 Abbildung 17: Anpassen der Tag-Liste...48 Abbildung 18: Eingabe der Aufgabenbearbeiter...48 Abbildung 19: Eingabe von Ressourcen Daten...49 Abbildung 20: Angelegte Aufgabe...50 Abbildung 21: Ergebnis eines GET auf die URI im AV System...51 Abbildung 22: Raten der Zahl...51 Tabellenverzeichnis Tabelle 1: Zusammensetzung einer URI nach RFC Tabelle 2: Anwendungsfall "Aufgabe erstellen"...18 Tabelle 3: Anwendungsfall "Aufgabenzuweisung ändern"...20 Tabelle 4: Anwendungsfall "Aufgabenbeschreibung aktualisieren...21 Tabelle 5: Anwendungsfall "Aufgabe löschen...21 Tabelle 6: Anwendungsfall "Ressourcenzuweisung ändern...22 Tabelle 7: Anwendungsfall "Aufgabenstatus ändern...23 Tabelle 8: Anwendungsfall "Aufgabe überwachen...24 Tabelle 9: Anwendungsfall "Eskalationen ausführen...24 Tabelle 10: Grundbegriffe des Frameworks...27 Tabelle 11: Funktionen der REST Schnittstelle...34 Tabelle 12: Annotation der Aufgabenklassen...39 Tabelle 13: Annotation zum Lebenszyklus...40 Tabelle 14:... Fortsetzung...41 Tabelle 15: Annotationen des Aufgabenbearbeiters...45 Quelltextverzeichnis Quelltext 1: Deklaration der Annotationen-/Klassenindex Struktur...28 Quelltext 2: Signatur der Methode getclassesannotatedwith(...)...29 Quelltext 3: Beispiel für eine Methoden Annotation...32 II

3 Quelltext 4: Signatur der createresource Methode...33 Quelltext 5: Beispiel für eine JPA Annotation...36 Quelltext 6: Signatur einer TaskProducer Methode...37 Quelltext 7: Beispiel für eine TaskState Implementierung

4 1 Einleitung 1 Einleitung Aufgaben und deren Erledigung stellen einen zentralen Aspekt des Geschäfts-, aber auch des Privatlebens dar. Das Konzept der Aufgabe, im Sinne einer Verpflichtung zur Durchführung einer bestimmten Handlung, ist von fundamentaler Bedeutung für eine Vielzahl sozialer Interaktionen von Menschen in den unterschiedlichsten Kontexten. So ist es auch nicht verwunderlich, dass seit dem Beginn des Informationszeitalters diverse Systeme entstanden sind, um dieses Konzept technisch zu unterstützen. 1.1 Motivation Das Konzept der Aufgabe ist in hohem Maße abstrakt. In der Realität können die in einer Aufgabe beschriebenen Anforderungen beliebig variieren, wodurch die Umsetzung des Konzepts in ein Softwaresystem deutlich erschwert wird. So ist es auch nicht weiter verwunderlich, dass die heute existierenden Systeme überwiegend nur eine bestimmte Zielgruppe bzw. einen dedizierten Anwendungsbereich unterstützen. Der Aufgabenträger kann sich eine Aufgabe selbst gestellt oder sie von einem Dritten übertragen bekommen haben. Sehr umfangreiche Aufgaben werden in der Regel nicht von einer einzigen Person, sondern von einer Gruppe bearbeitet. Daraus begründet sich ein Kommunikationsbedarf, der heute oft außerhalb des eigentlichen Systems zur Aufgabenunterstützung, bspw. in Form von s, befriedigt wird. Nicht jede denkbare Aufgabe kann sinnvoll durch den Einsatz geeigneter Software unterstützt werden (bspw. die Zubereitung einer Mahlzeit). Für Aufgaben, deren Bearbeitung sich überwiegend auf materielle Faktoren bezieht, kann eine Software nur wenig Unterstützung bieten. Gerade im Kontext von Unternehmensprozessen geht es aber oft um das Erzeugen von immateriellen Resultaten, nämlich Daten und Informationen. Der Aufgabenträger verwendet dazu i. d. R. Programme, die zu der jeweiligen Problemdomäne spezielle Unterstützung bieten (bspw. Microsoft PowerPoint zum Erstellen von Präsentationen). So wie bspw. ein Hammer als Werkzeug für die Verrichtung der Aufgabe Nagel in die Wand schlagen dient, wird das Programm zum Werkzeug für die Erstellung eines immateriellen Resultats. Trotz dieser logischen Verbindung zwischen Aufgabe und Werkzeug finden sich heute kaum Systeme, die diese beiden Konzepte miteinander verbinden. Dies begründet sich aus der derzeit noch vorherrschenden Nutzung von lokal installierten Anwendungen. Die zunehmende Verbreitung von Webanwendungen könnte eine bessere Kopplung von Aufgabe und Werkzeug ermöglichen. Nicht selten ist hier die verbindliche Nutzung einer bestimmten Software integraler Bestandteil der Aufgabe, weil das Ergebnis bspw. ein bestimmtes Format zur Weiterverarbeitung haben muss. 1

5 1.2 Zielsetzung 1.2 Zielsetzung Im Rahmen des Forschungsprojekts Verteilte Bereitstellung, Ausführung und Verwaltung von Anwenderaufgaben der Fernuniversität in Hagen werden derzeit Ansätze untersucht, die bisher vorherrschende Fokussierung auf einzelne, isolierte Webanwendungen durch eine systemübergreifende, anwenderbezogene Sicht bzgl. der Verwaltung von kollaborativen Aufgaben zu ersetzen. Parallel zu den im Projekt laufenden Entwicklungsarbeiten zu einer die o.g. Kriterien erfüllenden Aufgabenverwaltung in Form von anwenderbezogenen Aufgabenlisten, soll die vorliegende Arbeit die Funktionalität der Aufgabensteuerung beisteuern. Dazu ist ein Framework zu entwickeln, welches den Softwareentwickler in die Lage versetzen soll, ein System zur Aufgabensteuerung zu entwickeln. Das Framework erlaubt dem Entwickler, die kontextspezifischen Eigenschaften der Aufgabe sowie deren Lebenszyklus zu gestalten. Darüber hinaus kann der Entwickler Webapplikationen bzw. Webressourcen wie bspw. Onlinedokumente in die Aufgaben integrieren und diese zeit- oder ereignisgesteuert überwachen. Insbesondere die Integration ausserhalb des Systems betriebener Webanwendungen stellt den Entwickler vor das Problem, sich ggf. mit einer Vielzahl proprietärer Kommunikationsprotokolle befassen zu müssen. Der von Roy Fielding im Rahmen seiner Dissertation beschriebene Architekturstil REST kann die Komplexität einer solchen Anforderung deutlich reduzieren, weshalb immer mehr Webanwendungen eine entsprechende Schnittstelle anbieten. Die mit dem Framework erstellte Anwendung soll daher im Sinne einer systemübergreifenden Kommunikation mit Webanwendungen und -ressourcen konsequent den REST-Architekturstil umsetzen. Der Anwender bzw. ein automatisches System wird mit der aus dem Framework erzeugten Anwendung in die Lage versetzt, kontextbezogene Aufgaben zu erzeugen, zu aktualisieren oder zu löschen. Potentielle zur Bearbeitung erforderliche Webanwendungen oder Dokumente können dabei direkt in die Aufgabe selbst integriert werden. 2

6 1.3 Aufbau der Arbeit 1.3 Aufbau der Arbeit Die vorliegende Arbeit gliedert sich wie folgt. Kapitel 1 Einleitung Das einleitende Kapitel vermittelt grundlegende Informationen zu Problem und Aufgabenstellung. Kapitel 2 Grundlagen und Technologien Einführung wichtiger Begriffe und Technologien aus dem Kontext der Aufgabenstellung. Kapitel 3 Anforderungsanalyse und Entwurf Darstellung der Anforderungen und des daraus resultierenden Entwurfs für das System. Kapitel 4 Implementierung dung des Frameworks Erläuterungen zur Implementierung und Anwen- Kapitel 5 Proof of Concept Anhand eines Fallbeispiels wird gezeigt, wie der Softwareentwickler konkrete Systeme zur Aufgabensteuerung herstellen kann. Kapitel 6 Fazit und Ausblick Abschliessend wird ein Ausblick über mögliche Erweiterungen des Systems gegeben. 3

7 2 Grundlagen und Technologien 2 Grundlagen und Technologien Im vorliegenden Kapitel werden die für diese Arbeit grundlegenden Begriffe und Technologien erläutert. 2.1 Aufgaben Der Begriff der Aufgabe definiert sich in der wissenschaftlichen Literatur teilweise sehr unterschiedlich, was zunächst nicht verwundert, denn schliesslich kann jeder aus seinem persönlichen Erfahrungsschatz heraus bestätigen, dass die Beschreibung einer Aufgabe inhaltlich jede erdenkliche Handlung bzw. Kombinationen aus gewünschten Handlungen, Werkzeugen, Zeitpunkten, etc. beinhalten kann. Dieser Umstand macht es schwierig, Aufgaben auf standardisierte Art und Weise zu definieren. Selbst innerhalb eines abgrenzbaren Kontexts finden sich nur sehr allgemeine Definitionen des Aufgabenbegriffs. Im Kontext der betriebswirtschaftlichen Unternehmung charakterisieren Hentze et al. in [Hentze et al. 2001, S. 32] die Aufgabe als Verpflichtung wie folgt. Die Aufgaben leiten sich aus dem Sachziel der Unternehmung ab und werden durch die Funktionen erfüllt. Eine Aufgabe beinhaltet die Verpflichtung zur Durchführung einer Handlung. Eine eher zielorientierte Definition liefert Hoffmann in [Hoffmann 1980, S. 200] Unter einer Aufgabe wird in der betriebswirtschaftlichen Organisationslehre ein zu erfüllendes Handlungsziel, eine durch physische oder geistige Aktivitäten zu verwirklichende Soll-Leistung verstanden Diese sehr abstrakten Definitionen von Aufgaben machen bereits deutlich, dass die Eigenschaften einer konkreten Aufgabe in Abhängigkeit Ihrer Problemdomäne extrem variieren können. Die Entwicklung einer Software zur Aufgabenverwaltung oder -bearbeitung steht demnach vor der Herausforderung, sowohl möglichst universell also für unterschiedlichste Aufgabenstellungen einsetzbar zu sein als auch der einzelnen konkreten Aufgabe innerhalb einer bestimmten Domäne im Detailgrad der Beschreibung gerecht zu werden. Betrachtet man den Lebenszyklus einer Aufgabe, so besteht der Prozess der Aufgabenerledigung mindestens aus dem Beginn - was inhaltlich besser vorstellbar ist als der Vorgang der Übermittlung - der Bearbeitung selbst und dem Abschluss. Der Lebenszyklus kann aber auch deutlich komplexere Abläufe erfordern, insbesondere, wenn mehr als eine Person mit der Bearbeitung der Aufgabe betraut wurde. So kann es bspw. erforderlich sein, dass der nächste Bearbeitungsschritt in Abhängigkeit einer Bedingung gewählt werden muss oder auf die Übermittlung 4

8 2.1 Aufgaben des Ergebnis einer dritten Person warten muss. Das Austauschen von Ergebnissen im Rahmen der Bearbeitung einer komplexen Aufgabe, bspw. innerhalb eines Teams von Spezialisten, macht außerdem deutlich, dass neben dem rein prozessualen Charakter der Aufgabe auch häufig ein kommunikativer Aspekt existiert [Ferstl et al. 2006]. 2.2 Frameworks Ein Programm wird üblicherweise entwickelt, um einen Endanwender bei der Lösung eines Problems zu unterstützen. Der Programmierer muss dazu i. d. R. über detaillierte Kenntnisse der Problemdomäne verfügen. Er entwirft bspw. Algorithmen oder organisiert die Datenhaltung der Anwendung. Am Ende des Softwareentwicklungsprozesses entsteht ein Programm, welches dem vom Entwickler vorgegebenen Ablauf folgt. Der Grad der Wiederverwendbarkeit von Software kann bedeutend zur Reduzierung der Entwicklungskosten beitragen. Wiederverwendbarkeit im Kontext der Softwareentwicklung beschreibt das Maß, in dem bereits vorhandene Software in die Entwicklung einer neuen Software integriert werden kann [Siedersleben 2003, S. 190ff]. Die sogenannten Klassenbibliotheken stellen die am häufigsten anzutreffende Form der Wiederverwendbarkeit von Software dar. Sie enthalten bereits fertige Lösungsmöglichkeiten zu einer Problemdomäne. Der Entwickler kann solche Bibliotheken meist sehr einfach in sein eigenes Programm einbinden und so deren Funktionalität nutzen. In Abgrenzung zu den Klassenbibliotheken entstehen insbesondere im Rahmen der objektorientierten Entwicklung zunehmend die sogenannten Frameworks (englisch für Rahmenstruktur ). Sie haben i. d. R. ebenfalls einen konkreten Bezug zu einer bestimmten Problemdomäne und bringen genau wie die Klassenbibliothek auch bereits große Teile der erforderlichen Programmlogik mit. Darüber hinaus geben sie aber auch Architektur und Kontrollfluss der zu entwickelnden Anwendung vor [Gamma 2004, S. 37ff]. Frameworks zeichnen sich insbesondere dadurch aus, dass sie den Kontrollfluss einer Anwendung vorgeben. Der Entwickler erweitert das Framework lediglich um die für sein Problem spezifischen Klassen. Die Art, wie diese Klassen in das Framework eingebunden werden, stellt eine Möglichkeit der Kategorisierung von Frameworks dar [Pree 1997]. Der Einsatz von Frameworks kann den Entwicklungsaufwand für eine Software drastisch reduzieren. Im vorliegenden Fall könnte ein Framework zwar nicht den o. g. Widerspruch zwi schen den Anforderungen an ein System zur Aufgabenverwaltung lösen, den Entwickler aber dabei unterstützen, schnell und einfach Anwendungen zur Steuerung, Verwaltung und Bearbeitung von Aufgaben zu erstellen, die den speziellen Eigenschaften der konkreten Aufgabe gerecht werden. 5

9 2.3 Representational State Transfer 2.3 Representational State Transfer Roy T. Fielding, der unter anderem als Chef Architekt an der Entwicklung des HTTP 1.1 Standards beteiligt war, definiert und vergleicht in seiner Dissertation Architectural Styles and the Design of Network-based Software-Architectures [Fielding 2000] unterschiedliche Architekturstile für das Design von verteilten Systemen. Dazu beschreibt er jeden Stil anhand einer Liste von Beschränkungen. Der Architekturstil Representational State Transfer (kurz REST) wird dabei durch die im Folgenden dargestellten fünf Beschränkungen charakterisiert und zeichnet sich durch ein hohes Maß an Effizienz und Einfachheit aus Eindeutige Identifikation von Ressourcen Um einem verteilten System den Zugriff auf entfernte Ressourcen zu ermöglichen, müssen diese über ein einheitliches Namensschema adressierbar sein, um identifiziert werden zu können. Im Internet existiert ein solches Schema in Form der sogenannten Uniform Resource Identifier (kurz URI) bereits. Beispiele für URIs sind oder Im Internet wird auf der Zugriff auf technischer Ebene mit Hilfe des sogenannten Domain Name System (kurz DNS) und dem HTTP Protokoll realisiert. Der so entstehende Namensraum stellt sicher, dass jede mit einer URI beschriebene Ressource innerhalb des Internets eindeutig adressiert werden kann. Die Internet Engineering Taskforce (kurz IETF), eine Organisation, die sich mit der stetigen Weiterentwicklung von Technologien zur Verbesserung, Verwaltung und Nutzung des Internets beschäftigt [IETF01], stellt ihre Ergebnisse in Form von sogenannten RFC Dokumenten der Öffentlichkeit zur Verfügung. In RFC3986 [Berners-Lee et al. 2005] beschreibt die IETF den Aufbau einer minimalen URI als Sequenz von Schema:Authority:Path Im oben verwendeten Beispiel wären demnach http Das Schema Die Autorität products/4187 Der Pfad Tabelle 1: Zusammensetzung einer URI nach RFC3986 6

10 2.3 Representational State Transfer Das Schema wird oft verwendet, um das für den Zugriff erforderliche Protokoll zu spezifizieren. So erkennt bspw. ein Webbrowser, das er mit der angegebenen Ressource über das HTTP Protokoll kommunizieren soll. Die Authority entspricht meist dem DNS Namen einer Ressource und wird mittels eines DNS Service in eine IP Adresse aufgelöst. Dieser Vorgang ist gut vergleichbar mit dem Nachschlagen einer Telefonnummer in einem Telefonbuch. Bereits an dieser Stelle ist eine Kommunikation zwischen dem anfragenden System und dem durch die URI adressierten System möglich. Erst das Zielsystem selbst wertet den Path Anteil der URI aus, welcher die eindeutige Identifizierung der Ressource innerhalb des Zielsystems ermöglicht Verknüpfungen/Hypermedia Der von Fielding beschriebene Hypermedia as the Engine of Application State wird durch die Verwendung von Verknüpfungen realisiert. Am Beispiel des World Wide Web (kurz WWW) sind dies die sogenannten Hyperlinks (kurz Links), mit denen der Anwender einer Website von einer Seite zu einer anderen Seite springen kann. Die Website ist hierbei nichts anderes, als eine Webanwendung, die vom Anwender mit Hilfe der Links gesteuert wird [Tilkov 2009]. Da die Links wiederum in Form von URIs formuliert werden, können sie systemübergreifend andere Ressourcen adressieren und so miteinander verknüpfen Standardisierte Methoden Insbesondere das Konzept der Verknüpfungen führt zu der Frage, wie die Zusammenarbeit vieler Systeme realisiert werden könnte. Hypermedia gibt dem Entwickler zwar ein relativ simples Mittel an die Hand, externe Ressourcen zu adressieren, jedoch sagt dies nichts über die Gestaltung der Schnittstelle des fremden Systems aus. In Systemen, die bspw. SOAP, RPC oder RMI zur Kommunikation einsetzen, ist eine genaue Kenntnis der jeweiligen Schnittstelle erforderlich. Ist eine Anwendung RESTful, d.h. sie setzt alle fünf REST Prinzipien um, dann bietet sie für jede Ressource eine einheitliche Schnittstelle an. 7

11 2.3 Representational State Transfer Abbildung 1: Beispiel für einheitliches Interface (aus [Tilkov 2008]) Die Operationen aus Abb. 1 orientieren sich an denen des HTTP Protokolls. Auch wenn REST häufig mit dem Einsatz von HTTP verknüpft wird, ist dies keinesfalls zwingend. Denkbar wären hier beliebige andere Operationen, so lange sie nur einheitlich für alle definierten Ressourcen sind Unterschiedliche Repräsentationen Fielding erklärt Repräsentationen im REST Kontext in [Fielding 2000, S. 90ff] als Kombination aus Daten und Metadaten, die wahlweise 1. den momentanen Zustand einer Ressource, 2. den gewünschten Zustand einer Ressource oder 3. Werte einer anderen Ressource darstellen können. 8 Abbildung 2: Client/Server Kommunikation

12 2.3 Representational State Transfer Als besonders allgegenwärtiges Bespiel kann der Abruf einer Webseite mit einem Internet Browser von einem Webserver dienen (siehe auch Abb. 2). Der Browser fordert beim Server eine HTML Repräsentation vom Medientyp text/html (siehe auch [Freed et al. 1996]) mittels der GET Methode des HTTP Protokolls ( den gewünschten Zustand einer Ressource ) an. Abbildung 3: Client Anforderung mit Vorgabe möglicher Repräsentationen Der Server akzeptiert die Anforderung und antwortet mit der angeforderten Ressource in einer der möglichen Repräsentationen in diesem Fall text/html. Die Antwort besteht aus Metadaten und Daten hier die eigentliche HTML Seite ( den momentanen Zustand einer Ressource ). Hätte der Server der Anforderung nicht wie vom Client gewünscht nachkommen können, so hätte er optimalerweise eine Fehlerseite geschickt ( Werte einer anderen Ressource ). In den Metadaten sind am Beispiel HTTP noch viele weitere Informationen enthalten, die vom Client ausgewertet werden können, aber nicht zwingend müssen. In Abb. 4 ist bspw. die Länge der übermittelten Daten in Bytes als Parameter Content-Length aufgeführt. Da REST aber nicht zwingend auf HTTP aufbaut, kann dies in anderen Implementierungen vollkommen anders sein. Abbildung 4: Auszug aus den Metadaten der Server Antwort Es kann dabei sehr nützlich sein, einer Ressource mehrere unterschiedliche Repräsentationen zu geben. So kann eine Repräsentation bspw. für einen menschlichen Nutzer geeignet sein, während eine andere für die automatische Verarbeitung durch ein Drittsystem prädestiniert ist [Tilkov 2008] Statuslose Kommunikation In einer Instanz des REST Architekturstils findet die Kommunikation zwischen Client und Server zustandslos statt (siehe auch [Richardson et al. 2007]. Dabei wird der Zustand einer Session niemals vom Server verwaltet. Stattdessen kann entweder der Client den Zustand halten, oder der Server wandelt den Zustand in einen Ressourcenstatus um, worin auch die Bezeichnung Representational State 9

13 2.3 Representational State Transfer Transfer begründet. Die Konsequenz besteht darin, dass in jeder Anfrage alle relevanten Informationen enthalten sein müssen. Als nachteilig ist hierbei sicherlich der Overhead im zu übertragenden Datenvolumen zu sehen. Dafür erkauft man sich jedoch flexible Möglichkeiten zur Lastverteilung oder Ausfallsicherheit. Diese Skalierbarkeit entsteht dadurch, dass der Server keinerlei Informationen zum aktuellen Zustand des Clients vorhalten muss. Selbst logisch aufeinanderfolgende Anfragen können so von unterschiedlichen Servern bearbeitet werden. 2.4 Das Hypertext Transfer Protokoll Das Hypertext Transfer Protokoll (kurz HTTP) ist im weitesten Sinne ein Protokoll zum Datenaustausch im Internet. Seine große Verbreitung begründet sich vor allem durch die Tatsache, dass es überwiegend zur Übertragung von Webseiten genutzt wird. Seine Entwicklung begann 1989 am CERN durch Tim Berners-Lee und Roy Fielding wurde HTTP in der Version 0.9 veröffentlicht ([W3C01]). Die Entwicklung setzte sich fort und mündete 1999 im HTTP/1.1 Standard ([Fielding et at. 1999]), an dem Roy Fielding als Chief Architect beteiligt war. Da HTTP die Anforderungen des REST Architekturstils weitestgehend erfüllt, kann man das Internet in Bezug auf seine Nutzung von HTML und HTTP als eine große RESTful Webanwendung betrachten. HTTP ist zustandslos (siehe Kap ). Da viele Anwendungen im Internet nicht ohne eine Sitzungsverwaltung auskommen, und daher auch oft nicht RESTful sind, wurden diverse Mechanismen entwickelt, um HTTP um entsprechende Funktionen zu erweitern. Dazu gehören bspw. Cookies, bei deren Einsatz der Server kleine Datenpakete auf dem Client speichert, in denen sitzungsspezifische Informationen gespeichert werden. Diese gehören aber nicht zur HTTP Spezifikation und ändern nichts an der Zustandslosigkeit des Protokolls. Das Konzept der (unterschiedlichen) Repräsentationen findet sich, wie bereits in Kap gezeigt, in den MIME-Types wieder. Insbesondere im Rahmen der zunehmenden Verbreitung mobiler Endgeräte, wie bspw. Smartphones, werden häufig unterschiedliche Repräsentationen einer Ressource zur Geräte optimierten Anzeige von Inhalten genutzt. Ressourcen werden analog zu Kap über URIs adressiert. Da HTTP selbst kein Transport Protokoll im Sinne des OSI Schichten Modells ist, benötigt es zwingend ein solches als Unterbau. Hier kommt überwiegend TCP aus der TCP/IP Protokoll Familie zum Einsatz. TCP/IP adressiert Systeme mittels sogenannter IP Adresse. Die Auflösung des Authority Teils der URI (siehe Tabelle 1) in eine IP Adresse wird unter Zuhilfenahme des Domain Name Systems (kurz DNS) durchgeführt. Verknüpfungen sind kein Element von HTTP selbst. Im World Wide Web wird dieses Konstrukt bspw. aus der Hypertext Markup Language (kurz HTML) geliefert, 10

14 2.4 Das Hypertext Transfer Protokoll mit der Webseiten üblicherweise erstellt werden. Aus HTTP Sicht ist der Abruf einer Verknüpfung ein gewöhnlicher Abruf einer Repräsentation einer Ressource. HTTP nutzt einen kleinen Satz von Methoden, die sogenannten Verben, über die alle auf Ressourcen erforderlichen Operationen abbildbar sind (in Anlehnung an [Tilkov 2009]. GET Mit der GET Methode fordert ein System die Repräsentation einer Ressource an. Dabei sind zwei Eigenschaften bedeutend. GET ist safe, also sicher, was in diesem Kontext bedeutet, dass eine GET Anforderung an einer Ressource keine Seiteneffekte auslöst. Das aufgerufene System wird durch den Aufruf logisch1 nicht verändert. Weiterhin ist GET idempotent. Der mehrfache Aufruf der Ressource liefert also stets das gleiche Resultat zurück bzw. überführt den Client stets in den gleichen Status. HEAD Die HEAD Methode entspricht der GET Methode, nur dass anstelle der gesamten Repräsentation einer Ressource lediglich die Metadaten zurückgegeben werden. So kann bspw. das Datenvolumen einer Repräsentation geprüft werden, bevor diese tatsächlich übertragen wird. PUT Im Gegensatz zu GET, aktualisiert PUT unter Angabe der gewünschten URI und des Medientyps den Inhalt einer Ressource bzw. legt sie an, falls sie noch nicht existiert. Wie auch schon GET und HEAD ist PUT idempotent. Ein mehrmaliges identisches PUT führt im ersten Schritt zum Anlegen der Ressource, bei jeder weiteren Wiederholung werden dann aber nicht Dubletten erzeugt, sondern die gerade angelegte Ressource aktualisiert, was bei identischen Aufrufen natürlich zu keiner inhaltlichen Veränderung der Ressource führt 2. POST Genau wie mit PUT können Ressourcen mit POST angelegt werden. Anders als beim PUT gibt der Client hierbei jedoch nicht die URI vor, unter der die Ressource entstehen soll. Stattdessen entscheidet der Server darüber und gibt dem Client als Antwort die URI zurück, unter der die neue Ressource gefunden werden kann [Richardson et al. 2007]. POST ist weder sicher, noch idempotent. 1 Eine physische Veränderung, wie bspw. ein Eintrag in einem Logfile kann nicht ausgeschlossen werden, hat aber keinen Einfluss auf Status oder Konsistenz der Anwendung (siehe auch [Tilkov 2009]). 2 Worauf insbesondere Roy Fielding in diversen Beiträgen immer wieder hinweist, ist der Umstand, dass es hier um rein logische Anforderungen an die adressierte Ressource geht. Was der Server letztlich damit anfängt, also ob es zu einer physischen Veränderung von Server Ressourcen kommt, liegt allein in der Hoheit des Servers selbst. 11

15 2.4 Das Hypertext Transfer Protokoll DELETE Wie der Name bereits vermuten lässt, wird mit der DELETE Methode eine Ressource gelöscht. Auch ein DELETE ist idempotent, was unmittelbar einleuchtet, denn jede Ressource ist eindeutig über die URI identifiziert. Wird DELETE auf eine bereits gelöschte Ressource angewendet, hat dies keine Seiteneffekte. OPTIONS Die OPTIONS Methode erlaubt den Abruf zusätzlicher Möglichkeiten des Servers und ist sowohl idempotent, als auch sicher. Neben den o.g. Verben existieren noch PATCH, TRACE und CONNECT, die jedoch für die vorliegenden Ausführungen keinen Beitrag leisten. Die Darstellung der in HTTP verfügbaren Verben zeigt, dass diese eine gute Basis für eine einheitliche Schnittstelle bieten (siehe Kap ). Analog zu den grundlegenden CRUD Datenbankoperationen (Kurzform für Create, Read, Update und Delete) können auf diesem Interface alle erforderlichen Ressourcenänderungen abgebildet werden. Eine weitere wichtige Eigenschaft, die HTTP als Implementierung der REST Architektur kennzeichnet, ist die Caching Funktionalität. Fielding beschreibt in [Fielding 2000] die Wichtigkeit des Cachings, da es die Effizienz eines Netzwerk Systems bedeutend steigern kann. Der Forderung nach Idempotenz folgend, sorgt Caching dafür, dass die Übertragung der Repräsentation einer Ressource vom Server an den Client nur dann durchgeführt wird, wenn sich ihr Zustand seit dem letzten Abruf geändert hat. 2.5 Jersey Im Sinne der permanenten Weiterentwicklung der Programmiersprache Java wurde der Java Community Process (kurz JCP) eingerichtet. Die Mitglieder des JCP können in diesem Forum neue Vorschläge bzgl. der Anpassung oder Erweiterung der Java Klassenbibliotheken oder der Laufzeitumgebung, der Java Virtual Machine (kurz JVM) einreichen. Wird ein solcher Vorschlag nach Durchlaufen diverser Bewertungen angenommen, wird er als sogenannter Java Specification Request (kurz JSR) Teil eines offiziellen Release von Java. Als ein Framework zur Erstellung von RESTful Webservices wurde der JSR311 unter der Bezeichnung JAX-RS: The JavaTM API for RESTful Web Services vom JCP freigegeben. Jersey ist die quelloffene Referenzimplementierung von JSR311 und steht unter zum Zeitpunkt der Erstellung dieser Arbeit in der Version 1.13 zum Download unter jersey.java.net zur Verfügung. 12

16 3 Anforderungsanalyse und Entwurf 3 Anforderungsanalyse und Entwurf Im Folgenden werden nach dem Top-Down Ansatz zunächst die Aufgabenstellung im Allgemeinen, die daraus resultierenden Anwendungsfälle, welche mit dem zu erstellen Framework realisiert werden sollen sowie die funktionalen Komponenten des Frameworks und der Entwurf der Persistenzschicht erläutert. 3.1 Aufgabenstellung Die mit dem Framework zu erstellende Anwendung gliedert sich in eine Landschaft miteinander agierender Systeme ein, die während des Lebenszyklus einer Aufgabenbearbeitung unterschiedliche Rollen wahrnehmen. Abbildung 5: Landschaft verteilter Systeme zum Task Management Initiierendes System Wahlweise kann ein Anwender mittels einer zur Verfügung gestellten (Web-)Anwendung oder auch ein automatisches System eine Aufgabe im Aufgabensteuerungssystem (kurz AS) erstellen. Falls nach der Erzeugung der Aufgabe inhaltliche Änderungen an der Aufgabe notwendig werden sollten, 14

17 3.1 Aufgabenstellung dann kann der Initiator diese nachträglich aktualisieren oder sogar vollständig aus dem System löschen. Aufgabensteuerung Als zentrale Kommunikationszentrale erfüllt die AS vor Allem die Funktion der Delegation und Überwachung von Aufgaben und ggf. verknüpften Ressourcen. Jegliche Kommunikation der übrigen beteiligten Rollen findet ausschliesslich über die AS statt. Das Bearbeiten einer externen Ressource kann zwar nur in direkter Kommunikation zwischen dem Aufgabenträger selbst und der Ressource stattfinden, aber auch hier fordert die AV des Aufgabenträgers die Verknüpfung zur Ressource bei der AS an. Aufgabenverwaltung Der Aufgabenträger arbeitet mit dem Aufgabenverwaltungssystem (kurz AV). Es stellt dem Anwender alle im zugewiesenen Aufgaben in Form einer Aufgabenliste dar. Die Art der Darstellung kann dabei theoretisch jede beliebige Form annehmen. AS und AV tauschen RESTful lediglich Repräsentationen von Ressourcen aus. Daten-/Anwendungsressource Beinhaltet eine Aufgabe eine verknüpfte Ressource, wie bspw. eine Webanwendung oder ein Onlinedokument, so kann der Aufgabenträger diese mittels einer in die Aufgabe eingebettete Verknüpfung aufrufen und daran arbeiten. Der Status dieser Ressource wird dabei durch die AS überwacht und ggf. an den Aufgabenträger oder den Aufgabeninitiator eskaliert Funktionale Anforderungen Das zu entwickelnde Framework unterstützt den Entwickler bei der Herstellung von Anwendungen zur Aufgabensteuerung. Dabei müssen folgende funktionale Anforderungen erfüllt werden. Lebenszyklus einer Aufgabe Eine Aufgabe durchläuft zwischen ihrer Initiierung und der Fertigstellung möglicherweise weitere Status. Die AS muss demnach eine Logik implementieren, die das Steuern einer Aufgabe durch einen vorgegebenen Lebenszyklus ermöglicht. Hierarchische Aufgaben Analog zu einem Projekt, welches i. d. R. aus mehreren untergeordneten Aktivitäten besteht, kann eine Aufgabe entsprechend auch weitere Unteraufgaben enthalten. Entscheidend dabei ist das logische Zusammenspiel aller Aufgaben gleichen Ursprungs. So sollte sich bspw. der Fortschritt einer Eltern-Aufgabe aus den Fortschrittswerten der Kind-Aufgaben ergeben. Flexible Aufgabendefinition Wie in Kapitel 2.1 beschrieben, steht die Gestaltung der Eigenschaften einer Aufgabe in starker Abhängigkeit zur Problemdomäne. Daher muss der Entwickler die Möglichkeit zur freien Gestaltung der jeweiligen Aufgabendefinition bekommen. Als Basisdefinition soll die Task Management Markup Language (kurz TMML, siehe auch [Schulte 2011]) aus dem Forschungsprojekt Verteilte Bereitstellung, Ausführung und Verwaltung von Anwenderaufgaben des Lehrgebiets Datenverarbeitungstechnik der Fernuniversität in Hagen dienen. 15

18 3.1 Aufgabenstellung Überwachung von Aufgaben und Ressourcen In der Realität ist es regelmäßig erforderlich, dass bspw. bei Erreichen zuvor definierter Zustände oder nach Ablauf einer gewissen Zeitspanne Aktionen zur Eskalation, Benachrichtigung oder sonstiges ausgeführt werden. Das Framework muss eine entsprechende Logik zur Zeit- oder Ereignis gesteuerten Ausführung von Aktionen anbieten. Integration bestehender Webressourcen Im Kontext dieser Arbeit wird davon ausgegangen, dass das Ergebnis einer Aufgabe in Form von Daten vorliegen soll, die mit einer Anwendung erzeugt wurden. So ist es bspw. gängige Praxis in der heutigen Unternehmenswelt, dass Ergebnisse mit Hilfe von Textverarbeitungsprogrammen, Tabellenkalkulationen oder Präsentationsprogrammen erstellt werden. Dabei wird vorausgesetzt, dass der Aufgabenträger eine geeignete Software auf seinem Rechner installiert hat. Muss die Aufgabe darüber hinaus von mehreren Personen zusammen bearbeitet werden, entsteht zusätzlich das Problem des Datenaustauschs, da der überwiegende Teil der heutigen Unternehmenssoftware nicht dafür ausgelegt ist, dass Dokumente konkurrierend bearbeitet werden. Eine mögliche Lösung könnte die Nutzung vom webbasierten Anwendungen und Dokumenten sein. Diese stehen allen Nutzern gleichermaßen und i. d. R. ohne eine erforderliche Installationsprozedur zur Verfügung. Das Framework soll daher die Integration webbasierter Anwendungen und Dokumente in die Aufgabe selbst ermöglichen Nichtfunktionale Anforderungen Neben den funktionalen Anforderungen als Teil der Aufgabe existieren weitere Anforderungen, die ohne Auswirkung in den Anwendungsfällen bleiben. Sicherheit die Entwicklung einer Webanwendung erfordert normalerweise ein belastbares Sicherheitskonzept. Im Rahmen der Aufgabenstellung darf darauf hier verzichtet werden. Programmiersprache Das Framework ist in Java zu erstellen. Es gibt keine zwingende Beschränkung auf die zu verwendende Entwicklungsumgebung. Das Framework wurde mit Netbeans 7.1 entwickelt. 16

19 3.2 Anwendungsfälle 3.2 Anwendungsfälle Die folgenden Abschnitte erklären die in Abbildung 6 dargestellten Anwendungsfälle des Aufgabensteuerungssystems sowie deren Beziehungen zueinander. Abbildung 6: Übersicht Anwendungsfälle Selbstverständlich sind die Aufgabenverwaltung und die Ressource aus Sicht der Aufgabensteuerung nur Akteure, das Schaubild kann so aber die systemübergreifenden Zusammenhänge besser darstellen. 17

20 3.2 Anwendungsfälle Aufgabe erstellen use case Aufgabe erstellen actors Berechtigter, AS, AV precondition keine main flow 1. Ein Berechtigter übermittelt eine Repräsentation der zu erstellenden Aufgabe. 2. Das AS System fordert den Berechtigten zur Eingabe der URIs aller Aufgabenträger auf. 3. Der Berechtigte KANN der Aufgabe eine Ressource hinzufügen (extension Ressourcenzuweisung ändern ). 4. Die Aufgabe wird in der AS angelegt. 5. Die Aufgabe wird an die AV aller Aufgabenträger übermittelt (include Aufgabenzuweisung ändern ). 6. Die AS erhält von den AV aller Aufgabenträger die URI, unter der die Aufgaben in den jeweiligen Aufgabenlisten verwaltet werden. 7. Der Berechtigte erhält als Antwort die URI, unter der die Aufgabe in der AS angelegt wurde. postcondition Die Aufgabe ist in der AS und allen erforderlichen AV System angelegt. Der Berechtigte hat die URI der Aufgabe in der AS erhalten. alternative flow keiner end Aufgabe erstellen Tabelle 2: Anwendungsfall "Aufgabe erstellen" Das Framework stellt hier exemplarisch eine Webseite zur Verfügung, mit der ein Initiator die Aufgabe definieren und an die AS übermitteln kann. In produktiven Umgebungen kann natürlich eine beliebige Anwendung dazu genutzt werden, solange sie den gleichen Medientyp, wie das erstellte System beherrscht. Da die Task Management Markup Language kein originäres Attribut zur Aufnahme einer Ressource anbietet, wird im Rahmen dieser Aufgabe das taskdescription Attribut für diesen Zweck genutzt. Die Implementierung einer Komponente zur Benutzerverwaltung wäre dem Framework sicher dienlich, soll hier aber nicht bearbeitet werden. Daher müssen die entsprechenden URIs vom Initiator kommen und werden nicht über die AS bereitgestellt. 18

21 3.2 Anwendungsfälle Aufgabenzuweisung ändern use case Aufgabenzuweisung ändern actors Berechtigter, AS, AV precondition Die ausgewählte Aufgabe wurde in der AS angelegt. main flow 1. Der Berechtigte ergänzt einen Aufgabenträger (die URI seines AV Systems) in der AS als Bearbeiter der Aufgabe. 2. Die Aufgabe wird an die AV des hinzugefügten Aufgabenträgers übermittelt (extension Aufgabe in AV anlegen ). 3. Die AS erhält von der AV des neuen Aufgabenträgers die URI, unter der die Aufgabe in seiner Aufgabenlisten verwaltet wird. postcondition Die Aufgabe enthält in der AS nun den neuen Aufgabenträger. Die AV des neuen Aufgabenträgers enthält die Aufgabe. alternative flow 1. Der Berechtigte löscht einen Aufgabenträger (die URI seines AV Systems) in der AS als Bearbeiter der Aufgabe. 2. Die Aufgabe wird aus der AV des bisherigen Aufgabenträgers gelöscht (extension Aufgabe in AV löschen ). postcondition Die Aufgabe ist in der AV des bisherigen Bearbeiters nicht mehr vorhanden. Der entfernte Bearbeiter ist in der AS nicht mehr Bearbeiter der Aufgabe. exceptional flow Der zu löschende Aufgabenträger ist der letzte Aufgabenträger der Aufgabe und der Initiator entscheidet, einen neuen Aufgabenträger zuzuweisen. 1. Der Berechtigte durchläuft den main flow 2. Der zu löschende Bearbeiter wird gemäß alternative flow gelöscht. Fortsetzung auf der nächsten Seite 19

22 3.2 Anwendungsfälle postcondition Die Aufgabe ist in der AV des bisherigen Bearbeiters nicht mehr vorhanden. Der entfernte Bearbeiter ist in der AS nicht mehr Bearbeiter der Aufgabe. Die Aufgabe enthält in der AS nun den neuen Aufgabenträger. Die AV des neuen Aufgabenträgers enthält die Aufgabe. exceptional flow Der zu löschende Aufgabenträger ist der letzte Aufgabenträger der Aufgabe und der Initiator entscheidet, die Aufgabe zu löschen. 1. Der zu löschende Bearbeiter wird gemäß alternative flow gelöscht. 2. Die Aufgabe wird aus der AS gelöscht (extension Aufgabe löschen ). postcondition Die Aufgabe ist in der AV des bisherigen Bearbeiters nicht mehr vorhanden. Die Aufgabe ist in der AS nicht mehr vorhanden. end Aufgabenzuweisung ändern Tabelle 3: Anwendungsfall "Aufgabenzuweisung ändern" Eine für diesen Anwendungsfall bedeutsame Forderung der Aufgabensteuerung ist, dass eine Aufgabe niemals ohne einen Bearbeiter sein darf. Dies begründet sich schon aus der Logik einer Aufgabensteuerung heraus damit, dass eine Aufgabe ohne Bearbeiter auch nicht gesteuert werden muss. In diesem Umstand begründen sich die beiden Ausnahme Zweige des Anwendungsfalls. Die Eingabe der Entscheidung bzgl. des weiteren Vorgehens in diesen beiden Zweigen, wie auch die im Anwendungsfall Aufgabenbeschreibung aktualisieren erforderlichen Angaben oder das Löschen einer Aufgabe werden dem Aufgabeninhaber wieder über die bereits o. g. Webseite ermöglicht. 20

23 3.2 Anwendungsfälle Aufgabenbeschreibung aktualisieren use case Aufgabenbeschreibung aktualisieren actors Berechtigter, AS, AV precondition Die ausgewählte Aufgabe wurde in der AS angelegt. main flow 1. Der Berechtigte übermittelt eine Aktualisierung der Aufgabenbeschreibung. 2. Die Aufgabenbeschreibung wird in der AS aktualisiert. 3. Die aktualisierte Aufgabenbeschreibung wird an die AV aller Aufgabenträger übermittelt. postcondition Die Aufgabebeschreibung ist in der AS und allen erforderlichen AV Systemen aktualisiert worden. alternative flow keiner end Aufgabenbeschreibung aktualisieren Tabelle 4: Anwendungsfall "Aufgabenbeschreibung aktualisieren Aufgabe löschen use case Aufgabe löschen actors Berechtigter, AS, AV precondition Die ausgewählte Aufgabe wurde in der AS angelegt. main flow 1. Der Berechtigte löscht die Aufgabe. 2. Die AS löscht die Aufgabe aus allen AV der eingetragenen Aufgabenträger. 3. Die Aufgabe wird aus der AS gelöscht. postcondition Die Aufgabe ist in der AS und allen erforderlichen AV Systemen gelöscht worden. alternative flow keiner end Aufgabe löschen Tabelle 5: Anwendungsfall "Aufgabe löschen 21

24 3.2 Anwendungsfälle Ressourcenzuweisung ändern use case Ressourcenzuweisung ändern actors Berechtigter, AS, AV precondition Die ausgewählte Aufgabe wurde in der AS angelegt. Der Berechtigte verfügt über eine gültige URI der Ressource. main flow 1. Der Berechtigte übermittelt die URI der Ressource an die Aufgabe. 2. Die AS übernimmt die Ressource in die Aufgabe. 3. Die AS aktualisiert die AV Systeme aller eingetragenen Aufgabenträger (include Aufgabenbeschreibung aktualisieren ). postcondition Die Aufgabe ist in der AS und allen betroffenen AV Systemen mit der Ressource verknüpft. alternative flow Der Berechtigte will die vorhandene Verknüpfung zwischen einer Aufgabe und einer Ressource aufheben. 1. Der Berechtigte löscht die URI der Ressource aus der Aufgabe in der AS. 2. Die AS aktualisiert die AV Systeme aller eingetragenen Aufgabenträger (include Aufgabenbeschreibung aktualisieren ). postcondition Die Aufgabe ist in der AS und allen betroffenen AV Systemen nicht mehr mit der Ressource verknüpft. end Ressourcenzuweisung ändern Tabelle 6: Anwendungsfall "Ressourcenzuweisung ändern 22

25 3.2 Anwendungsfälle Aufgabenstatus ändern use case Aufgabenstatus ändern actors AS, AV precondition Die ausgewählte Aufgabe wurde in der AS angelegt. main flow 1. Ein Bearbeiter der Aufgabe führt in seiner AV einen Statuswechsel der Aufgabe durch. 2. Die AV übermittelt den gewünschten Status der Aufgabe an die AS. 3. Die AS prüft, ob die Aufgabe in den gewünschten Status wechseln kann sowie die möglichen Folgestatus. 4. Die AS übermittelt der AV die aktualisierte Aufgabenbeschreibung mit dem aktuellen Status und den möglichen Folgestatus (include Aufgabenbeschreibung aktualisieren ). postcondition Die Aufgabe hat in der AS und allen betroffenen AV Systemen aktuelle Statusinformationen. alternative flow Ein Bearbeiter wechselt den Status der Aufgabe auf den Abschlussstatus. 1. Die AV übermittelt den gewünschten Status der Aufgabe an die AS. 2. Die AS prüft, ob die Aufgabe in den Abschlussstatus wechseln kann. Die Prüfung verläuft POSITIV. 3. Die AS löscht die Aufgabe aus allen betroffenen AV Systemen. 4. Die AS wechselt den Status der Aufgabe in den Abschlussstatus. postcondition Die Aufgabe ist in der AS im Abschlussstatus und in allen zuvor betroffenen AV Systemen nicht mehr vorhanden. end Aufgabenstatus ändern Tabelle 7: Anwendungsfall "Aufgabenstatus ändern 23

26 3.2 Anwendungsfälle Aufgabe überwachen use case Aufgabe überwachen actors AS precondition Die ausgewählte Aufgabe wurde in der AS angelegt. main flow 1. Die AS überprüft, ob in der Aufgabenbeschreibung definierte Zeitwerte erreicht wurden. 2. Die AS überprüft den Status von mit der Aufgabe verknüpften Ressourcen (extension Status der Ressource abfragen ). 3. Die AS überprüft, ob in der AS Eskalationsbedingungen erfüllt werden. hinterlegte postcondition Die AS führt die Eskalationen, zu denen die vorgebenen Bedingungen erfüllt sind, durch (extension Eskalationen ausführen ). end Aufgabe überwachen Tabelle 8: Anwendungsfall "Aufgabe überwachen Eskalationen ausführen use case Eskalationen ausführen actors AS precondition Die ausgewählte Aufgabe wurde in der AS angelegt. main flow 1. Die AS überprüft, ob in der Aufgabenbeschreibung definierte Zeitwerte erreicht wurden. 2. Die AS überprüft den Status von mit der Aufgabe verknüpften Ressourcen. 3. Die AS überprüft, ob in der AS Eskalationsbedingungen erfüllt werden. hinterlegte postcondition Die AS führt die Eskalationen, zu denen die vorgebenen Bedingungen erfüllt sind, durch (extension Eskalationen ausführen ). end Eskalationen ausführen Tabelle 9: Anwendungsfall "Eskalationen ausführen 24

27 3.3 Architektur 3.3 Architektur Im Folgenden wird der strukturelle Aufbau des Collaborative Task Control Frameworks (kurz CTCFramework) erläutert. Zunächst wird ein Überblick über das Gesamtsystem vermittelt, bevor dann die Implementierung aller Komponenten detailliert erklärt wird. Das Framework folgt dem Modell-View-Controller Architekturmuster (kurz MVC) welches die Funktionalitäten Repräsentation, Steuerung des Programmfluss und Datenmodell in separate Schichten kapselt [Gamma et al. 2011, S. 5ff]. Abbildung 7: Framework Komponenten Übersicht In der Präsentationsschicht finden sich die Komponenten zur Kommunikation mit den externen Akteuren. Diese wurden nach ihren Zuständigkeiten für die Beschreibung der Aufgaben (siehe Abb. 7, RESTful Task Schnittstelle), die Aufgabenberechtigten (siehe Abb. 7, RESTful Berechtigten Schnittstelle) und die mit den Aufgaben verknüpften Ressourcen (siehe Abb. 7, RESTful Ressourcen Schnittstelle) 25

28 3.3 Architektur voneinander getrennt angelegt. Die Komponenten dieser Schicht kommunizieren mit den Aufgabenverwaltungssystem der Aufgabenberechtigten sowie mit außerhalb des Frameworks realisierten Webanwendungen. Die Steuerungsschicht stellt die zur Verarbeitung der Anfragen aus der Präsentationsschicht erforderliche Programmlogik bereit. Die Teilung nach den o. g. Zuständigkeiten aus der Präsentationsschicht setzt sich in der Steuerungsschicht fort. Die sogenannte TaskStateEngine Komponente kapselt darüber hinaus noch die Funktionalität zur Steuerung des Task Status und trägt damit wesentlich zur Abbildung des Lebenszyklus der Aufgaben bei. Die Modellschicht stellt für die Komponenten der Steuerungsschicht Methoden zum Persistieren und Ausliefern der zum Betrieb des Frameworks erforderlichen Daten bereit. 4 Implementierung 4.1 Entwicklungsumgebung Die durch das Framework zur Verfügung gestellte Funktionalität wurde nicht vollständig neu entwickelt, sondern setzt auf die Komponenten der Java Enterprise Edition (kurz Java EE) in der aktuellen Version 6 auf. Für Entwicklung und Betrieb von mit dem Framework erstellten Anwendungen ist daher zwingend ein Java EE6 kompatibler Applikationsserver erforderlich. Die im Rahmen dieser Arbeit erstellte Version des Frameworks wurde mit der Entwicklungsumgebung Netbeans 7.2 aus dem Hause Oracle erstellt. Netbeans steht im Internet kostenlos unter [Oracle 2012] zum Download zur Verfügung. Das dort erhältliche JavaEE Bundle enthält bereits den Java EE6 Applikationsserver Glassfish 3.1.2, sowie fast alle erforderlichen Abhängigkeiten. Das vorliegende Netbeans Projekt nutzt Apache Maven als Build Management System. Maven unterstützt den Entwickler bei der Auflösung von Abhängigkeiten und entlastet den Entwickler durch eine weitgehende Automatisierung des Build Prozesses. 4.2 Wichtige Begriffe des Frameworks Die Namensgebung innerhalb des Frameworks folgt einem einfachen Schema, welches zum besseren Verständnis insbesondere der Quelltexte beiträgt. Um innerhalb des Quelltexts eine Vermischung von Deutsch und Englisch zu vermeiden, wurden ausschliesslich englische Begriffe verwendet. 26

29 4.2 Wichtige Begriffe des Frameworks Begriff Bedeutung task Aufgabe task operator Aufgabenträger (operator engl. für Bearbeiter) task operator system bezeichnet das externe Aufgabenverwaltungssystem des Aufgabenträgers task resource eine mit einer Aufgabe verknüpfte Ressource, wie bspw. eine Webanwendung Tabelle 10: Grundbegriffe des Frameworks Auf die in Tabelle 10 genannten Grundbegriffe bauen alle anderen verwendeten Bezeichnungen auf. So bezeichnet eine taskuri den eindeutigen Ressourcen Identifizierer einer Aufgabe, während eine taskresourceuri die gleiche Bedeutung für eine verknüpfte Ressource hat. 4.3 Paketstruktur Die zum Framework gehörenden Klassen liegen entsprechend ihrer Zugehörigkeit zu den oben genannten Komponenten in Paketen (sogenannte packages) unterhalb des Basispakets de.rickert.ctc. Abbildung 8: Paketstruktur des Frameworks Die Pakete aus Abbildung 8 haben teilweise weitere Unterpakete, um bspw. Annotationsklassen zu kapseln, die lediglich zum Markieren von Klassen, Methoden 27

30 4.3 Paketstruktur oder Feldern dienen und keinen funktionalen Programmcode enthalten. 4.4 Technologischer Überblick Um das Verständnis für die Implementierung und Funktionsweise des Frameworks zu erleichtern, sollen zunächst einige grundlegende Klassen eingeführt werden, die für jede Komponente des Frameworks von Bedeutung sind Der Annotationen Scanner Da das Framework allein durch Annotation konfigurierbar ist, müssen Klassen, die über den Klassenpfad der Java Laufzeitumgebung erreichbar sind, nach den CTCFramework spezifischen Annotationen durchsucht werden. Diese Aufgabe übernimmt die AnnotationIndex Klasse. Zwar ist es über die Java Reflection API möglich, die Annotationen von Klassen, Methoden oder Feldern auszulesen, jedoch ist es dafür erforderlich, dass der Klassenname bekannt ist. Um Klassen zu identifizieren, die zum Zeitpunkt der Kompilierung (des Frameworks) noch unbekannt sind, wäre es erforderlich, eine eigene Logik zum Laden der Klassen in die Java Virtual Machine, einen sogenannten Classloader, zu implementieren. Um diesen Aufwand zu vermeiden, wurde auf die Klassenbibliothek Reflections (siehe [Reflections 2012] zurückgegriffen. Das Paket verfügt über Klassen, die zur Laufzeit den gesamten Klassenpfad nach diversen definierbaren Kriterien durchsuchen können, um dann eine Analyse der gefundenen Klassen durchführen zu können. Die AnnotationIndex Klasse verfügt über je eine Liste mit den Framework eigenen Annotationen für Klassen, Methoden und Felder. Der Annotationen Index wird anhand von zwei Suchläufen erzeugt. 1. Im ersten Durchlauf werden ausschliesslich alle Klassen unterhalb der in Abbildung 8 dargestellten Paketstruktur durchsucht. Alle hier gefundenen Elemente dienen dem Framework als Standard Elemente. Wenn ein Entwickler keine anderen Datentypen, als die im Framework ohnehin vorhandenen benötigt, dann werden diese Elemente zur Ausführung der Framework Logik eingebunden. Die Ergebnisse des Suchlaufs werden in einer Schlüssel/Wert Struktur als Paar aus Annotation/Liste aus Elementen (also Klasse, Methode oder Feld) abgelegt. private static HashMap<Class, List<Class>> caindex = new HashMap<Class, List<Class>>(); Quelltext 1: Deklaration der Annotationen-/Klassenindex Struktur 2. Anschliessend durchsucht der Klassenscanner aus dem Reflections Paket alle Teile des Klassenpfads erneut, nun aber aber die Pfade, die nicht innerhalb der Framework Paketstruktur liegen. Findet er hier entsprechende 28

31 4.4 Technologischer Überblick Elemente, dann überschreibt er den jeweiligen Eintrag zu dieser Annotation in der o.g. Struktur. Dieser Ablauf hat natürlich für den Entwickler die Konsequenz, dass es nicht erlaubt sein kann, eigene Klassen im selben Namensraum wie das Framework anzulegen, da dies zur Laufzeit des Frameworks zu schweren Fehlern führen könnte. public static List<Class> getclassesannotatedwith(class annotation); Quelltext 2: Signatur der Methode getclassesannotatedwith(...) Die AnnotationIndex Klasse stellt ihre erzeugten Daten über fünf Methoden zur Verfügung, bei denen jeweils eine Annotationsklasse als Parameter übergeben (siehe Quelltext 2) und dann bspw. eine Liste der damit markierten Klassentypen zurückgeliefert wird Die TypeHandler Klassen Die AnnotationIndex Klasse hält Informationen bzgl. mit Annotationen des Frameworks markierten Klassen, Methoden und Feldern vor, die von den sogenannten TypeHandler Klassen benötigt werden. Ein TypeHandler Objekt hat die Aufgabe, andere Komponenten mit Informationen über Typen und Methoden der mit dem Framework erstellten Anwendung zu versorgen. Dies wird durch vielfachen Einsatz von Dependency Injection und der Nutzung der Java Reflection API erreicht. Unabhängig vom angefragten Element vollzieht sich der Ablauf dabei stets nach folgendem Schema. Im CTCFramework wird Dependency Injection mittels des Contexts and Dependency Injection Frameworks (kurz CDI), das seit der Version 6 fester Bestandteil der Java EE ist, implementiert. CDI nutzt ein typsicheres Verfahren für das Injizieren von Objekten in einen sogenannten InjectionPoint. Die Auflösung des zu injizierenden Objekts geschieht also nach dem Typ (in Abbildung 9 also der Typ Method). Existieren mehrere Objekte, die den Typanforderungen des InjectionPoints entsprechen, wie es bspw. durch abgeleitete Klassen passieren kann, dann wird die injiziert, die mit Annotation markiert wurde. Ist auch auf diesem Weg eine eindeutige Zuordnung nicht möglich, wird ein Laufzeitfehler erzeugt und die Injektion findet nicht statt (zu CDI siehe auch [Ihns et al. 2011, S. 498ff]. 29

32 4.4 Technologischer Überblick Ein Qualifier dient der Selektion einer Komponente für einen InjectionPoint. In der Anwendung muss lediglich die den InjectionPoint Annotation um den gewünschten Qualifier erweitert werden (siehe dazu auch das Beispiel aus Abbildung 9). Dieses Konzept kann unter Zuhilfenahme der sogenannten Producer Methods noch deutlich dynamischer gestaltet werden. Abbildung 9: Zusammenspiel des TypeHandlers mit dem Framework Annotiert man eine Methode, die als Rückgabewert den am InjectionPoint erforderlichen Typ zurück gibt, mit Annotation und einem Qualifier, dann können Objekte sogar zur Laufzeit in dieser Methode unter Berücksichtigung beliebiger Parameter konstruiert werden, um am InjectionPoint injiziert zu werden (siehe [Duggan 2012, S. 332ff]). 30

33 4.4 Technologischer Überblick In der vorliegenden Version des Frameworks existieren derzeit drei TypeHandler für die drei o. g. Basiskonzepte Aufgabenbeschreibung, Aufgabenberechtigte und Aufgabenressource des Frameworks. Funktional sind sie dabei vollkommen identisch, die Aufteilung auf drei Klassen wurde zu Gunsten der Wartbarkeit des Quelltexts vorgenommen Die Controller-Klassen Die drei Controller-Klassen sind die zentralen Komponenten des Frameworks. Sie fungieren in der Mitte zwischen REST-Schnittstelle und Persistenzschicht und enthalten den größten Teil der Anwendungslogik. Ihre öffentlichen Schnittstellen enthalten gerade die Funktionen, welche zur Ausführung der Anwendungsfälle erforderlich sind. Abbildung 10: Öffentliche Schnittstelle am Beispiel der TaskLifecycle Klasse Die TaskLifecycle Controller-Klasse nimmt, wie in Abbildung 10 zu sehen, alle Aufgaben rund um die Aufgabenklassen wahr. Dazu gehören das Anlegen, Ändern, Lesen und Löschen, aber auch die Steuerung des Lebenszyklus der Aufgaben. Alle Controller-Klassen benötigen ein gemeinsames funktionales Fundament. Funktionen, wie das Holen einer Aufgabe aus dem Datenspeicher, benötigen alle Controller-Klassen. Um diese Methoden nicht redundant implementieren zu müssen, wurde ein Design gewählt, in dem die Controller-Klassen von der Superklasse CTCOperationController abgeleitet werden. Diese enthält überwiegend die Logik für den Zugriff auf die Klassen der Persistenzschicht oder zur Kommunikation mit den Aufgabenverwaltungssystemen Die Wrapper Klassen Bei der Entwicklung einer Anwendung auf Basis des CTCFrameworks kann der Entwickler beliebige Klassen modellieren, die innerhalb seiner Anwendung bspw. das Konzept der Aufgabenbeschreibung realisieren. Für das Framework hat dieser Umstand zur Folge, dass die Struktur dieser Klassen dem Framework nicht bekannt ist und diese somit nur stark eingeschränkt genutzt werden könnten. 31

34 4.4 Technologischer Überblick Basierend auf der Tatsache, dass die Klassen zur Abbildung der drei zentralen Konzepte (siehe Kapitel 4.3.2) auf jeden Fall in Form einer definierten Repräsentation über die REST-Schnittstelle übertragbar sein müssen, entstanden die zu den o.g. Basiskonzepten gehörenden Wrapper (engl. für Umschlag, Verpackung) Klassen. Sie bieten dem Framework eine eindeutige, bekannte Schnittstelle und sind in der Lage, Repräsentationen aus Objekten der zugrundeliegenden Konzeptklassen zu erzeugen und umgekehrt. Dieses Vorgehen erspart dem Entwickler bspw. die Notwendigkeit, sich Gedanken zum Datenbankmodel seiner Klassen machen zu müssen, da hier immer nur die Wrapper Klassen genutzt werden. Die im Framework verwendeten Wrapper Klassen TaskWrapper, TaskOperatorWrapper und TaskResourceWrapper haben die Aufgabe, die vom Entwickler erstellten Klassen bzw. deren Instanzen zu kapseln und für das Framework nutzbar zu machen. Gleichzeitig soll der Entwick ler beim Design seiner Anwendung möglichst wenigen Restriktionen unterliegen. Diese Zielsetzung realisiert das Framework durch den Einsatz von Annotationen. Im Beispiel aus Quelltext 3 kennzeichnet die public void addnewoperator( MyOperator myop ) {... } Quelltext 3: Beispiel für eine Methoden Annotation beispielhafte Methode als verantwortlich für das Hinzufügen eines Aufgabenberechtigten zu einer Aufgabe. Wenn das Framework gestartet wird, durchläuft es verschiedene Schritte zur Initialisierung. Diese Sequenz beginnt mit dem Scannen der Annotationen und dem Injizieren der vom Framework benötigten Objekte (siehe Kapitel 4.3.2). Im Anschluss daran werden die Wrapper Klassen über die statische Methode initialize(...) einmalig initialisiert. Die zu übergebenen Parameter variieren je nach Wrapper Klasse. Nun verfügt die Wrapper Klasse über Java Reflection Objekte zum Zugriff auf die für den jeweiligen Kontext relevanten Klassen, Methoden und Felder der vom Entwickler erstellten (und daher dem Framework unbekannten) Klasse. Methodenaufrufe aus dem Framework an die Wrapper Klasse werden nun an die annotierten Methoden der vom Entwickler erstellten Klassen weitergeleitet. Die Wrapper Klassen stellen unter dem Aspekt der Kapselung des eigentlichen Objekts eine Instanz des Proxy Entwurfsmusters dar ([Gamma et al. 2011, S. 254ff]). 32

35 4.4 Technologischer Überblick Abbildung 11: Kapselung eines Objekts in einem Wrapper Objekt Darüber hinaus haben die Wrapper Klassen Zugriff auf die sogenannten Objectbzw. RepresentationProducer Klassen, die das Transformieren einer Repräsentation in ein natives Objekt und umgekehrt leisten. Diese werden benötigt, um eine Änderung des Objekts auch an der Repräsentation desselben nachführen zu können. Ebenso wird ein neues Objekt erzeugt, wenn eine neue Repräsentation übermittelt wurde. Ebenso dienen die Wrapper Klassen als Entitäten zum Persistieren der Daten mittels der Java Persistence API (kurz JPA). Im vorliegenden Projekt wurde die JPA 2.0 Referenzimplementierung EclipseLink verwendet. Da aber nur JPA 2.0 konforme Mechanismen verwendet wurden, steht dem Einsatz alternativer JPA Implementierungen wie bspw. Hibernate nichts im Weg. Details zur Persistenzschicht des Frameworks folgen in Kapitel public <T> URI createresource(taskwrapper taskwrapper, TaskOperatorWrapper taskoperatorwrapper, T data); Quelltext 4: Signatur der createresource Methode Die REST-Ressourcen Klassen Die Webschnittstelle des Frameworks wurde mit dem Jersey Framework erstellt und stellt alle Funktionen seiner Controller-Klassen zur Verfügung. Der Basis Kontext des Frameworks lautet, wie in folgender Tabelle zu sehen, /as, was im derzeitigen Entwicklungsstand des Frameworks auch für den Entwickler nicht änderbar ist. 33

36 4.4 Technologischer Überblick URI HTTP Verb Funktion /as/task GET Gibt eine URI Liste aller Aufgaben aus. /as/task POST Erstellt eine neue Aufgabe. /as/task/{task_id} GET Liefert eine Repräsentation der Aufgabe mit der {task_id}. /as/task/{task_id} PUT Nimmt eine Aktualisierung für die Aufgabe mit der {task_id} entgegen. /as/task/{task_id} DELETE Löscht die Aufgabe mit der {task_id}. /as/task/{task_id}/enterstate/{state} PUT Initiiert den Wechsel der Aufgabe mit der {task_id} in den neuen Status {state}. /as/task/{task_id}/resource GET Gibt eine URI Liste aller Ressourcen der Aufgabe mit der {task_id} aus. /as/task/{task_id}/resource POST Erstellt eine neue Ressource für die Aufgabe mit der {task_id}. /as/task/{task_id}/resource/{res_id} GET Liefert eine Repräsentation der Ressource mit der {res_id} der Aufgabe mit der {task_id}. /as/task/{task_id}/resource/{res_id} PUT Nimmt eine Aktualisierung für die Ressource mit der {res_id} der Aufgabe mit der {task_id} entgegen. /as/task/{task_id}/resource/{res_id} DELETE Löscht die Ressource mit der {res_id} der Aufgabe mit der {task_id} /as/task/{task_id}/operator GET Gibt eine URI Liste aller Bearbeiter der Aufgabe mit der {task_id} aus. /as/task/{task_id}/operator POST Erstellt einen neuen Bearbeiter für die Aufgabe mit der {task_id}. /as/task/{task_id}/operator/{op_id} GET Liefert eine Repräsentation des Bearbeiters mit der {op_id} der Aufgabe mit der {task_id}. /as/task/{task_id}/operator/{op_id} PUT Nimmt eine Aktualisierung für den Bearbeiter mit der {op_id} der Aufgabe mit der {task_id} entgegen. /as/task/{task_id}/operator/{op_id} DELETE Löscht den Bearbeiter mit der {op_id} der Aufgabe mit der {task_id}. Tabelle 11: Funktionen der REST Schnittstelle Die in Tabelle 11 dargestellten Funktionen stehen eingehenden Anfragen zur Verfügung. In manchen Anwendungsfällen kommuniziert das Framework jedoch auch ausgehend (bspw. beim Anlegen einer Aufgabenbearbeitung in der Aufgabenver34

37 4.4 Technologischer Überblick waltung eines Aufgabenbearbeiters). Diese Funktionen konzentrieren sich auf die Klasse OsClientResource Die Persistenzschicht Die für das Framework benötigten Funktionen zur Datenablage beschränken sich auf das Lesen, Speichern, Aktualisieren und Löschen, also die traditionellen CRUD Funktionen (Kurzform für Create, Read, Update und Delete). Die im Rahmen dieser Arbeit entstandene Version des Frameworks realisiert dies auf sehr einfache Art und Weise unter Nutzung der Java Persistence API (kurz JPA). Abbildung 12: Zusammenspiel der JPA Komponenten Die in Abbildung 12 dargestellte Persistence Unit beschreibt eine Datenquelle mit allen für einen Zugriff erforderlichen Parametern. Ihr Name muss dem Framework bekannt sein, ansonsten kann die Anwendung nicht auf die Datenbank zugreifen. Für das CTCFramework ist in der vorliegenden Version der Name CTCFrameworkPU fest vorgegeben, zur Konfiguration unter Netbeans siehe auch Kapitel 5. Das Framework speichert ausschliesslich die o.g. Wrapper Klassen, sowie ggf. in ihnen enthaltene Klassen. Dadurch entsteht ein sehr einfaches Datenbankmodel, wie in Abbildung 13 zu sehen ist. Alle für das Framework erforderlichen Funktionen werden in der Klasse TaskStorage gekapselt. 35

38 4.4 Technologischer Überblick Abbildung 13: ER-Diagramm des Frameworks Die zentrale Entität ist die Tabelle TBL_TASK_REPRESENTATION. Die korrespondierende Klasse enthält drei Collections zur Aufnahme der Aufgabenbearbeiter, Aufgabenressourcen und der möglichen Folgestatus der Aufgabe. Im ER-Diagramm sind diese Relationen als One-To-Many Relation zu sehen. Die JPA Spezifikation gestattet eine Konfiguration des Datenmodells mittels Annotationen. Auf diesem Weg kann bspw. durch annotieren einer Klasse wie in Quelltext 5 zu cascade = CascadeType.ALL) Quelltext 5: Beispiel für eine JPA Annotation bewirkt werden, dass die bereits o.g. One-To-Many Beziehung gilt, so wie dass bei Aktionen auf ein Element der Eltern Entität, die jeweilige Aktion kaskadierend auch auf die Kind-Elemente wirkt Objekt- und Repräsentationstransformierung In der REST Terminologie enthält die Repräsentation eines Objekts alles, was für die Beschreibung seines Zustands erforderlich ist oder sein könnte ([Richardson et al. 2007, S. 112ff]). In der Welt der objektorientierten Programmierung trägt die Klasse bzw. seine Instanz, das Objekt, diese Rolle. Es ist somit erforderlich, ein Konzept zur Verfügung zu stellen, welches Objekte einer Klasse zur Laufzeit des Programms in die erforderlichen Repräsentationen konvertiert und umgekehrt. In einer eher statischen Anwendung, in der die Klassen 36

39 4.4 Technologischer Überblick bereits zum Zeitpunkt der Entwicklung klar definiert und bekannt sind, lassen sich leicht entsprechende Mechanismen finden. Das CTCFramework musste jedoch ein Konzept umsetzen, bei dem die Kernfunktionen, also die in den Anwendungsfällen aus Kapitel 3 geschilderten Vorgänge, auch ohne Kenntnis der Struktur später mit dem Framework entwickelter Anwendungen lauffähig sein würden. Der Lösungsansatz aus der modernen Softwareentwicklung nennt sich XML-Binding. Darunter versteht man das Abbilden von Klassen auf XML Schemata und umgekehrt. Dahinter verbirgt sich letztlich nichts anderes, als das traditionelle Abbilden von Objekten auf die Tabellen relationaler Datenbanken (das sogenannte O/R Mapping), nur dass beim XML-Binding nichts zwingend das Ziel der Datenspeicherung verfolgt wird ([Scholz et al. 2009, S. 92ff]). JAXB (kurz für Java Architecture for XML Binding) ist eine Implementierung des XML-Binding Konzepts und wird auch in namhaften Frameworks wie JAX-WS und JAX-RS genutzt. Aus Sicht des Entwickler gründet sich die Arbeit mit JAXB primär auf das Setzen von Annotationen. Nur in sehr komplexen Szenarien wird es notwendig zusätzliche Klassen zu generieren. Für die Nutzung in eher statischen Anwendungsfällen bringt JAXB sogar einen eigenen Compiler mit (der sogenannte xjc), mit dem sich aus XML Schemata direkt Java Klassen generieren lassen. Im CTCFramework kommt wie oben bereits erwähnt das Jersey Framework zur Implementierung der REST-Schnittstelle zum Einsatz, welches ebenfalls JAXB für die Konvertierung von Objekten in Repräsentation nutzt, jedoch kann hier nur begrenzt Einfluss auf die Konvertierung genommen werden. Außerdem wurde ein Konzept gesucht, welches sich modular in das Framework integriert und auch zum Erzeugen der zu persistierenden Daten geeignet ist. Das unter dieser Motivation entstandene Konzept hat für den Entwickler den Vorteil, dass die Producer Klassen von ihm beliebig ausgetauscht werden können, um vollkommen andere Repräsentationen zu erzeugen. Die Klasse, bzw. eine von den möglicherweise mehreren Klassen, die die Logik zum Erzeugen der gewünschten Repräsentation implementiert, muss lediglich eine Methode annotieren, die als Parameter das zu konvertierende Objekt akzeptiert und einen String zurück public Object createtask(string representation) { } Quelltext 6: Signatur einer TaskProducer Methode Natürlich gibt es auch den umgekehrten Weg, wie beispielhaft in Quelltext 6 zu sehen ist. 37

40 4.5 Konfiguration des Frameworks 4.5 Konfiguration des Frameworks Im Folgenden soll der Entwickler in Lage versetzt werden, eigene Anwendungen mit dem Framework zu erstellen. Dazu ist es zunächst erforderlich, die verschiedenen Mechanismen und natürlich die Annotationen zu kennen. In Kapitel 5 wird dann die Entwicklung einer Anwendung mit dem Framework beispielhaft vollzogen. Die vorliegende Version verfügt derzeit über keinerlei spezielle Unterstützung durch eine IDE bzgl. der Vermeidung von Fehlern bei der Konfiguration und Entwicklung mit dem Framework Die Aufgabenklasse Der Entwickler hat bei der Gestaltung seiner Anwendung viel Spielraum, einige Verpflichtungen müssen jedoch eingehalten werden. So gibt es bei fast jeder der nachfolgend dargestellten Klassen Pflichtfelder, die für den Betrieb des Frameworks grundsätzlich da sein müssen. Das Konzept der Aufgabe realisiert im Framework der TaskWrapper. Dieser kapselt die eigentliche Aufgabenklasse. Wenn der Entwickler eine solche nicht selbst entwickeln möchte, dann nutzt das Framework als Default Aufgabenklasse die TmmlTask Klasse aus dem Paket de.rickert.ctc.tmml. 38

41 4.5 Konfiguration des Frameworks Paket: de.rickert.ctc.annotations.task Annotation Markiert eine Methode zum Setzen der URI der Aufgabe innerhalb der der CTC Domäne. Die Methode muss in der annotierten Klasse liegen. Die Methode muss genau einen Parameter vom Typ java.net.uri Kennzeichnet eine Methode, die aus einer Repräsentation eine Instanz der Task Klasse liefert. Die Methode muss genau einen Parameter vom Typ String entgegennehmen und liefert eine Instanz der Task Klasse Wird zum annotieren einer Klasse verwendet, die eine Aufgabe repräsentiert. Wenn ein ein Producer (siehe auf JAXB Basis funktioniert, dann muss diese Klasse zusätzlich die JAXB typischen Annotationen Analog aber erzeugt aus einer Producer Instanz einer markierten Klasse eine Repräsentation. Die Methode muss eine Instanz der Aufgabenklasse als einzigen Parameter annehmen und ein Objekt vom Typ String Diese Annotation benötigt zwingend noch einen (StorageMethods. Parameter des Enum Typs StorageMethods. CREATE, UPDATE, DELETE, GET, So können Methoden markiert werden, die die vorhandene TaskStorage Klasse ersetzen sollen. Die Signaturen der einzelnen Methoden sollen nicht Gegenstand dieser Arbeit sein und müssen im Quelltext nachgeschlagen werden. Markiert eine Methode, die die URI einer Resource in ein Feld der Task Klasse schreibt. Am Beispiel des TmmlTask ist dies gut nachzuvollziehen, da hier ein entsprechendes Feld noch nicht funktional ist Tabelle 12: Annotation der Aufgabenklassen 39

42 4.5 Konfiguration des Frameworks Lebenszyklus von Aufgaben Paket: de.rickert.ctc.annotations.task.state Annonation Beide Annotationen dürfen nur in Klassen verwendet werden, markiert sind. Sie markieren eine Methode, in der der Entwickler beliebige Logik implementieren darf. die Entry Methode wird immer VOR dem Wechsel in einen neuen Status aufgerufen, die EXIT Methode immer vor dem Verlassen des aktuellen Status. Die Methode MUSS einen Parameter der Klasse java.lang.object entgegennehmen und einen boolean Wert zurückliefern. Das Object ist stets eine Instanz der markierten Klasse um kann vom Entwickler entsprechend gecastet werden. Dabei bedeutet TRUE, dass die Bedingung zum Wechsel erfüllt Markiert eine Methode in einer beliebigen Klasse, die einen parameterlosen Konstruktor hat, zur Prüfung einer frei implementierbaren Eskalationsbedingung. Die Methode nimmt ein Objekt der Klasse java.lang.object entgegen und liefert einen boolean Wert zurück. Die wird TRUE, wenn die Eskalationsbedingung erfüllt wurde. Anmerkung: Diese Logik wurde noch nicht in die Lifecycle Engine übernommen, was bedeutet, dass diese Methode niemals aufgerufen werden Analog (siehe Tabelle 12), nur dass hier eine Repäsentation des Status geschrieben werden kann. Tabelle 13: Annotation zum Lebenszyklus 40

43 4.5 Konfiguration des Frameworks Paket: de.rickert.ctc.annotations.task.state Annonation Markiert eine Klasse, als Status Klasse und benötigt zwei Parameter. String displayname, Class[] followerstates) Der displayname ist der Anzeigename des Status, der auch bei der Konstruktion der URL zum Wechseln des Status verwendet wird (daher muss auf Sonderzeichen, die in einer URL nicht sein dürfen, verzichtet werden) Zusätzlich muss ein Array vom Typ Class übergeben werden, welches die (ebenfalls markiert) Status Klassen enthält, die als Folgestatus zulässig wären. Eine Status Klasse ohne Folgestatus wird als EndZustand interpretiert. Es darf nur eine solche Klasse geben. Eine Status Klasse, die in keiner anderen StatusKlasse als FollowerState auftaucht wird als StartStatus verwendet. Auch diese darf nur einmal vorkommen. Tabelle 14:... Fortsetzung Der Lebenszyklus von Aufgaben wird über Status gesteuert. Diese können sehr flexibel und einfach vom Entwickler erstellt werden und beliebige Logik implementieren Zur Entwicklung einer Lebenszyklus kommen die Annotation aus Tabelle 13 zum Einsatz. Mit dieser überschaubaren Anzahl von Annotationen können sehr mächtige Status-Automaten konstruiert werden. Der Ablauf der gesamten Logik ist dabei wie folgt. 41

44 4.5 Konfiguration des Frameworks Abbildung 14: Ablauf eines Status Wechsels Der Einsatz der in Tabelle 13 genannten Annotationen fällt dabei sehr einfach aus wie das folgende Beispiel displayname = "In_progress", follower = { TmmlTaskStateEnd.class } ) public class TmmlTaskStateInProgress { private TmmlTask public boolean isentryconditionfulfilled(object task) { TmmlTask ttask = (TmmlTask)task; return true; public boolean isexitconditionfulfilled(object task) { this.task = (TmmlTask) task; return true; } } Quelltext 7: Beispiel für eine TaskState Implementierung Annotation definiert hier den Namen des Status, sowie die Klasse TmmlTaskStateEnd als einzigen Folgestatus. Bevor der Status In_progress verlassen werden kann, muss die annotierte Methode ein boolesches true zurückgeben. Ein Statuswechsel würde über die REST Schnittstelle durch ein PUT auf die URI 42

45 4.5 Konfiguration des Frameworks angestossen werden Aufgabenbearbeiter Im Kontext der Aufgabenbearbeiter bzw. Task Operator in der Terminologie des Frameworks dienen Annotationen im Wesentlichen dem gleichen Zweck, wie bei den Aufgaben selbst. Der Fokus liegt hier auf wenigen Pflichtfeldern, die für den Betrieb des Frameworks unerlässlich sind. 43

46 4.5 Konfiguration des Frameworks Paket: de.rickert.ctc.annotations.taskoperator Annotation Markiert ein Feld, welches in der Klasse des Task Operators einen Anzeigenamen darstellt. Das Feld muss vom Typ java.lang.string Wird zum annotieren einer Klasse verwendet, die einen Aufgabebearbeiter repräsentiert. Wenn ein ein Producer auf JAXB Basis funktioniert, dann muss diese Klasse zusätzlich die JAXB typischen Annotationen Kennzeichnet eine Methode, die aus einer Repräsentation eine Instanz der Task Operator Klasse liefert. Die Methode muss genau einen Parameter vom Typ String entgegennehmen und liefert eine Instanz der Task Operator Klasse Analog aber erzeugt aus einer Instanz einer markierten Klasse eine Repräsentation. Die Methode muss eine Instanz der Aufgabenklasse als einzigen Parameter annehmen und ein Objekt vom Typ String Annotiert eine Methode, die im Operator System ( Os ) einen Task anlegt. Die Methode muss einen Parameter vom Typ TaskOperatorWrapper, der das Objekt des TaskOperators enthält, sowie einen String entgegennehmen, der die Repräsentation des Task Annotiert eine Methode, die im Operator System einen Task aktualisiert. Die Methode muss einen Parameter vom Typ TaskOperatorWrapper, der das Objekt des TaskOperators enthält, sowie einen String entgegennehmen, der die neue Repräsentation des Task enthält. 44

47 4.5 Konfiguration des Frameworks Paket: de.rickert.ctc.annotations.taskoperator Annotation Annotiert eine Methode, die im Operator System einen Task löscht. Die Methode muss einen Parameter vom Typ TaskOperatorWrapper, der das Objekt des TaskOperators enthält, Markiert ein Feld vom Typ String, das den Anmeldenamen des Task Operators in seinem Aufgabenverwaltungssystem Markiert ein Feld vom Typ String, welches das Passwort des Task Operators für sein Aufgabenverwaltungssystem Markiert ein Feld vom Typ java.net.uri, welches die URI des Aufgabenverwaltungssystems des Task Operators enthält. Tabelle 15: Annotationen des Aufgabenbearbeiters An dieser Stelle sei auch erwähnt, dass hier Informationen zum Authentifizieren des CTCFrameworks an einem Aufgabenverwaltungssystem erhoben und genutzt werden, das System jedoch derzeit nur die HTTPBasicAuth Methode unterstützt. Komplexere Authentifizierungsverfahren können jedoch einfach vom Entwickler selbst implementiert werden Annotationen der Ressourcen Auch im Bereich der TaskResource Klassen gibt es die schon oben @TaskResourceRepresentationProducer, etc. Auf eine erneute Darstellung soll daher hier verzichtet werden. 45

48 5 Proof of Concept 5 Proof of Concept Nachdem nun die wichtigsten Aspekte des Frameworks dargestellt wurden, soll nun die Anwendung unter praktischen Gesichtspunkten betrachtet werden. Nach dem Öffnen des Netbeans Projekt findet man zunächst die o.g. PaketStruktur unter de.rickert.ctc welche das eigentliche Framework enthält. Zusätzlich ist eine Webapplikation unter de.rickert.webapp zu finden, die die externe Webanwendung repräsentiert. 5.1 Die Webanwendung Bei der externen Ressource handelt es sich um eine Zahlen raten Anwendung, die kollaborativ von allen Bearbeitern einer Aufgabe bearbeitet werden kann. Die Anwendung kommt mit drei Klassen aus. GuessNumber ist die Entitätenklasse, welche über die REST-Schnittstelle kommuniziert werden wird. GuessController steuert die Anwendung, persistiert die Daten und schickt Updates der Repräsentationen an das CTC Framework. GuessNumberResource ist die REST-Schnittstelle der Anwendung und liefert HTML Seiten aus. Im Folgenden wird ein Standard Durchlauf, beginnend mit dem Anlegen der benötigten Ressourcen über eine kleine Webseite, bis hin zum Fertigstellen eines Zahlen-Rate-Spiels gezeigt. 5.2 Eine Aufgabe anlegen Abbildung 15: Startbild des CTCFrameworks Nach dem Starten des Frameworks kann man mit einem Webbrowser aus die URL der Startseite wechseln und erhält folgende Ansicht. 46

49 5.2 Eine Aufgabe anlegen Das Bild zeigt eine leere Aufgabenliste, denn die Datenbank ist noch leer. Durch Drücken des Buttons Add new task kann man eine neue Aufgabe anlegen. Abbildung 16: Eingabe der Aufgabendaten Hier können die bis dato unterstützten Attribute eines TMML Task eingegeben werden. Attribute wie bspw. Modification time sind in der Maske nicht aufgeführt, sondern werden vom Programm mit sinnvollen Werten belegt. Das Formular ist sehr einfach angelegt und validiert keine Eingaben. Das Wissen, dass bspw. das Task detail type Feld ein Pflichtfeld ist, muss der Anwender hier leider mitbringen. An dieser Stelle kann man den Cancel Button drücken, was die Aktion abbricht und zurück zur Aufgabenliste führt, den Add Task Button drücken, was zu einem sofortigen Anlegen des Task führt, ohne die Eingabe weiterer Daten, wie bspw. Aufgabenbearbeiter oder -ressourcen oder den Add tags to task Button drücken, der zum nächsten Bildschirm führt. 47

50 5.2 Eine Aufgabe anlegen Abbildung 17: Anpassen der Tag-Liste Man befindet sich nun auf der Tag-Liste. Man kann einen Tag hinzufügen, indem man ihn in das Textfeld eingibt und anschliessend den Add Tag Button rechts davon drückt. Hat man sich vertippt, kann man bereits gespeicherte Tags mittels des delete Links rechts neben dem Tag wieder von der Liste nehmen. Der Cancel Button bricht immer ab und führt zurück zur Aufgabenliste. Als nächstes wählen wir Assign task operators und gelangen zur Eingabe der Aufgabenbearbeiter. Abbildung 18: Eingabe der Aufgabenbearbeiter Hier können nun die Daten für einen Aufgabenbearbeiter eingegeben werden. Na48

51 5.2 Eine Aufgabe anlegen türlich mutet es merkwürdig an, dass hier ein Aufgabenberechtigter Passworte von fremden System eingibt und in der Praxis sollte es diesen Fall natürlich nicht geben. Unter den hier vorliegenden Laborbedingung ist dieser Umstand kein Problem. Ein Klick auf Assign task resources führt zur Maske für die Eingabe von Ressourcen. Abbildung 19: Eingabe von Ressourcen Daten Wichtig zu beachten ist hierbei, dass die angefragte Resource URI der Link zu den externen Ressource sein muss. Die Tatsache, dass es sich im o.g. Beispiel um die gleiche Maschine handelt, muss nicht zwingend so sein, sondern ist hier lediglich der Testumgebung geschuldet. Bis zu diesem Zeitpunkt sind noch keinerlei Daten im System abgelegt worden. Die Webseiten sind als Java Server Face Seiten implementiert und kommunizieren mit einer sogenannten BackBean im Hintergrund, die auch die temporäre Speicherung der Daten leistet, bis der Anwender durch sein Handeln entscheidet, was damit passieren soll. Drückt man nun den Finish Button, dann passieren mehrere Dinge. Erstellung des Task Objekts Die BackBean führt das Anlegen der Aufgabe genauso durch, wie es ein externes System machen müsste, nämlich mittels der entsprechenden Client Methoden über die REST-Schnittstelle. Das so angelegte Objekt enthält noch weder den Bearbeiter, noch die Ressource. Im Hintergrund wurde bisher lediglich die Status Logik aktiv und hat die Aufgabe in den Start-Status versetzt und dies auch in die entsprechend annotierte Methode geschrieben. 49

52 5.2 Eine Aufgabe anlegen Die BackBean erhält die URI der neuen Aufgabe als Rückgabewert. Anlegen der Bearbeiter in der Aufgabe Unter Anwendung der gleichen Technik wie beim Anlegen der Aufgabe selbst, also mittels eines Webclients und der REST-Schnittstelle, werden nun alle Bearbeiter iteriert und nacheinander der Aufgabe hinzugefügt. Nach jedem Hinzufügen eines Bearbeiters schickt das Framework eine Repräsentation der Aufgabe an das Aufgabenverwaltungssystem des Bearbeiters und speichert die URI unter der es dort angelegt wurde. Anlegen der Ressourcen Zuletzt werden die Ressourcen genau wie die Bearbeiter angelegt. Da auch das Hinzufügen einer Ressource zum TaskWrapper Objekt die Repräsentation des Objekts ändert (obwohl TMML dafür ja gar kein Feld hat, wir den Ressourcen Link ja aber gemeinsam mit dem Status verpacken), wird an alle Bearbeiter Systeme jeweils eine aktualisierte Repräsentation geschickt. Darüber hinaus hat das Framework die annotierte Methode aufgerufen. Der Entwickler hat in dieser Methode eine Logik hinterlegt, die die Ressource selbst per POST Aktion an die URI der Ressource sendet und damit ein neues Spiel im System anlegt, dessen URI als resourceuri wieder im Ressourcen Objekt gespeichert und an das Framework zurückgesendet wird. Hinter diesem Link steckt nun das tatsächliche Spiel, welches ab aufgerufen werden kann. Nun ist alles, was zuvor auf den Formularen eingegeben wurde, verarbeitet und kommuniziert worden. Wir gelangen zurück zur Aufgabenliste und sehen nun unsere eben angelegte Aufgabe. Abbildung 20: Angelegte Aufgabe Anmerkung: Der Edit Link ist noch nicht produktiv zu nutzen, Delete dagegen funktioniert wie erwartet und fragt vor dem Löschen nicht noch einmal nach. Wenn wir uns nun überzeugen wollen, was in den Aufgabenverwaltungssystemen angekommen ist, so können wir dies einfach durch ein GET auf die URI der Aufga50

53 5.2 Eine Aufgabe anlegen be im Aufgabenverwaltungssystem tun. Abbildung 21: Ergebnis eines GET auf die URI im AV System Wir sehen die Links für den Status der Aufgabe, genau wie den der Ressource. 5.3 Bearbeiten der Aufgabe Gehen wir nun mit unserem Browser auf die Ressource URI, dann sehen wir die Webanwendung, die um Eingabe eines Tips wartet. Abbildung 22: Raten der Zahl Ist die geratene Zahl falsch, erhält man eine entsprechende Meldung. 51

54 5.3 Bearbeiten der Aufgabe Im Hintergrund aber, geht das Programm davon aus, dass man sich beim Raten einer Zahl zwischen 0 10 mit jedem Versuch mindestens um 10% seinem Ziel nähert. Daher aktualisiert die Webanwendung nach jedem Versuch das taskprogress Attribut der Aufgabe. Zusätzlich wird der Status von New auf In_progress geändert. Ab dem 9. Versuch bleibt dann allerdings der Fortschritt auf 90%. Es könnte in diesem Zustand auch jeder Bearbeiter der Aufgabe mitraten, die Webanwendung kann die Bearbeiter nicht unterscheiden. Sobald die Zahl erraten wurde setzt die Webanwendung den Fortschritt der Aufgabe auf 100% und den Status auf End. 6 Fazit und Ausblick Der vorliegende Stand des CTCFrameworks zeigt wie basierend auf modernen Frameworks und Klassenbibliotheken ein System zur Steuerung von Aufgaben realisiert werden kann. Im Zentrum dieser Problemdomäne steht dabei die Kommunikation zwischen den Systemen. Die konsequente Anwendung des REST-Architekturstils liefert hier ein gutes Fundament und die heute verfügbaren Tools unterstützen die Arbeit an derartigen System sehr gut. Aber natürlich kann ein Architekturstil allein nicht alle Probleme der konventionellen Maschine-Maschine Kommunikation lösen. So sinnvoll die beliebte Nutzung von HTTP im Zusammenhang mit RESTful Kommunikation auch sein mag, sie standardisiert ausschliesslich den Transport der Daten und nicht deren syntaktisches Format. Dieses wird auch weiterhin exakt zu spezifizieren sein und die Grenze der Kompatibilität der Kommunikation bilden. Der REST Ansatz vermittelt implizit viel Wissen zur Nutzung eines fremden Webservices (der RESTful ist), der Wortschatz des anderen Systems muss trotz allem bekannt sein, damit eine effiziente Datenkommunikation gelingen kann. Die Möglichkeiten der TMML und des darauf basierenden Referenzsystems sind derzeit noch sehr begrenzt. Konzepte wie Eskalationen, hierarchische Aufgaben der auf Statuswechsel basierende Lebenszyklus von Aufgaben oder die Integrati52