Inhaltsverzeichnis

1  Einleitung  1

1.1  Gesch aftsprozesse  1

1.2  Motivation  2

1.3  Anwendungsszenario: verteiltes Sensorennetzwerk  2

1.4  Anwendungsszenario: Startup-Center Diplomarbeit  3

1.5  Ziel der Arbeit  4

1.6  Aufbau der Arbeit  5

2  Grundlagen  7

2.1  WebComposition-Ansatz  7

2.2  XML und deren Erweiterungen  8

2.3  Representational State Transfer  10

2.4  Ressource Description Framework  12

3  Related Work  15

3.1  Workflow Management  15

3.2  Content Management  18

3.3  Zusammenfassung und Bewertung  20

4  Systementwurf  21

4.1  Architektur  21

4.2  WebComposition/extending Services  24

4.2.1  DataGridService  25

4.2.2  ServiceQueue  28

4.2.3  XSDFilter  30

4.2.4  XSLT  31

4.2.5  XPath  32

4.2.6  UI-Adapter index  33

4.3  Zusammenfassung  34

5  Implementierung  35

5.1  Entwicklungsumgebung  35

5.2  WebComposition/extending Services  37

5.2.1  DataGridService  38

5.2.2  ServiceQueue  39

5.2.3  XSDFilter  41

5.2.4  XSLT  42

5.2.5  XPath  43

5.2.6  UI-Adapter index  43

5.3  Zusammenfassung  44

6  Test  45

6.1  Laufzeitumgebung  45

6.2  WebComposition/extending Services  45

6.2.1  DataGrindService  46

6.2.2  ServiceQueue  47

6.2.3  XSDFilter  47

6.2.4  XSLT  48

6.2.5  XPath  48

6.2.6  UI-Adapter index  49

6.3  Beispiel Adressstammdaten  49

6.4  Anwendungsszenario: verteiltes Sensorennetzwerk  54

6.5  Anwendungsszenario: Startup-Center Diplomarbeit  55

6.6  Zusammenfassung  62

7  Fazit und Ausblick  63

8  Anhang  65

8.1  Testszenario DGS  65

8.2  Testszenario XSLT  66

8.3  XSLT - Adressenliste  67

8.4  XSLT - Adressenpflege  69

8.5  XSLT - Adressenneuanlage  72

8.6  XSLT - Adressenformular  74

8.7  Visual Basic Script - Vorlage Word Serienbrief mit Zugriff auf  

WebComposition  /DGS  75

8.8  XSLT - XAML User Interface f ur die Adresssuche  77

8.9  Phidget Sensoren  79

8.10  XSD Phidgets  85

8.11  Phidget URI-Template  86

8.12  Visual Basic Script f ur Excel und Informationspace Phidgets  86

Abbildungsverzeichnis   87

Literaturverzeichnis   91

Abstract

Im Rahmen dieser Arbeit entsteht eine Infrastruktur von Webservices, auf deren Basis die Konzeptionierung und Implementierung von Informationsfl¨ ussen zwischen verteilten Systemen vollst¨ andig durch ein Datenmodell, ein User-Interface-Design (dt. Benutzerschnittstellenentwurf) und der Definition von Business Rules (dt. Gesch¨ aftsregeln) (BR) beschrieben wird.

1 Einleitung

Die Informatik im Sinne einer Ingenieurwissenschaft steht auf den S¨ aulen der Technischen, Praktischen und Theoretischen Informatik und besch¨ aftigt sich mit Forschung, Entwicklung und Produktion von Informationssystemen. Um die Abgrenzung der Informatik als Wissenschaft von der landl¨ aufigen Vorstellung, Informatik beschr¨ anke sich auf Computer und deren Anwendung, zu verdeutlichen, k¨ onnen die trefflich gew¨ ahlten Worte des niederl¨ andischen In-formatikers Edsger Wybe Dijkstra dienen:

In der Informatik geht es genauso wenig um Computer wie in der Astro-

”

nomie um Teleskope.“ [Edsger W. Dijkstra]

Diese Arbeit ist vordergr¨ undig im Bereich der Praktischen Informatik einzugliedern, da der Schwerpunkt auf der Konzeptionierung einer Serviceinfrastruktur liegt. Aspekte der Technischen Informatik wie bspw. unterschiedliche Plattformen oder ¨ Ubertragungstechniken werden aufgezeigt und diskutiert, haben aber dank modernster Technologien auf die grunds¨ atzliche Funktionalit¨ at keinen Einfluss. Der Bereich Theoretische Informatik wird letztlich nur f¨ ur eine einfache Laufzeitbetrachtung tangiert. Ausdr¨ ucklich distanziert wird sich von der Entwicklung neuer Informationssysteme. Vielmehr geht es darum, die Grundlagen einer Informationsinfrastruktur auf Basis moderner Konzepte wie der Enterprise Application Integration (EAI), Serviceorientierter Architektur und Patterns (dt. Muster) zu schaffen.

Im Folgenden wird eine kurze Einf¨ uhrung in das Gebiet der Gesch¨ aftsprozesse (engl. Business Process) gegeben. Anschließend wird die Motivation dieser Arbeit vorgestellt und mit konkreten Zielvorstellungen, in Form von Anwendungsszenarien, charakterisiert. Abschließend bietet dieses Kapitel einiges Vorweg und fasst die Vorgehensweise und damit den Aufbau dieser Arbeit zusammen.

1.1 Gesch¨ aftsprozesse

Ein Gesch¨ aftsprozess ist die Abbildung eines Arbeitsablaufs, der sich aus einzelnen Aktivit¨ aten zusammensetzt. F¨ ur die Erstellung einer solchen Abbildung k¨ onnen verschiedene Formen gew¨ ahlt werden, von einer einfachen Checkliste f¨ ur die Wartung von Industrieanlagen bis hin zu komplexen grafischen Struktogrammen. Das Ziel der Definition von Gesch¨ aftsprozessen besteht darin, die Arbeitsabl¨ aufe zu vereinheitlichen, um eine effiziente Bearbeitung zu gew¨ ahrleisten und jederzeit den aktuellen Stand der Prozesse zu dokumentieren. F¨ ur eine Zertifizierung nach DIN EN ISO 9001 bilden Gesch¨ aftsprozesse ebenfalls eine wesentliche Grundlage

Konkret besteht ein Gesch¨ aftsprozess aus einem definierten Anfang und einem definierten Ende, wobei die einzelnen Aktivit¨ aten zwischen Anfang und Ende einen unterschiedlichen Verlauf nehmen k¨ onnen. Initiiert wird ein Gesch¨ aftsprozess durch ein Ereignis, das durch so genannte Akteure hervorgerufen wird. Akteure wiederum k¨ onnen Personen oder Systeme sein, die am Arbeitsablauf

1

beteiligt sind. Gesch¨ aftsprozesse sind meist das Ergebnis des Business Process Reengineering (BPR), das dazu eingesetzt wird, die einzelnen Prozesse in einem Unternehmen zu identifizieren und zu dokumentieren. Maßgebliche Faktoren f¨ ur einen Gesch¨ aftsprozess sind nach [24] unter anderem die folgenden:

• Komplexit¨ at

Die Komplexit¨ at eines Gesch¨ aftsprozesses ist bestimmt durch die Anzahl der Aktivit¨ aten und deren Abh¨ angigkeiten. Auch die Anordnung der Aktivit¨ aten in Form einer sequentiellen oder parallelen Abarbeitung wirkt sich auf die Komplexit¨ at aus.

• Detaillierungsgrad

Der Detaillierungsgrad beschreibt die M¨ oglichkeit einer Zerlegung des Gesamtprozesses in einzelne Teilprozesse.

• Grad der Arbeitsteilung

Der Grad der Arbeitsteilung repr¨ asentiert die Anzahl der am Prozess beteiligten Akteure und deren Koordinationsbedarf.

1.2 Motivation

Je k¨ urzer und schneller Gesch¨ aftsprozesse sind, desto besser und profitabler ist das Gesch¨ aft. Bernard Favre-Bulle stellt in seinem Buch ” Automatisierung

komplexer Industrieprozesse“[25] fest, dass ein schnelles Reaktionsverm¨ ogen auf ver¨ anderte Ausgangssituationen mit einem flexiblen und innovationsfreudigen Unternehmensmanagement die erfolgreichen Firmen der Gegenwart und vermutlich auch der Zukunft auszeichnet. Gr¨ oße spiele dabei eine weniger entscheidende Rolle, sodass gesagt werden kann: ” ... in Zukunft werden nicht die

großen Fische die kleinen fressen, sondern die schnellen Fische die langsamen.“ Die informationstechnische Abwicklung von Gesch¨ aftsprozessen erfolgt dabei zu einem großen Teil mithilfe von Kommunikation, Datentransfer und Entscheidungsfindung w¨ ahrend der Abarbeitung dieser Gesch¨ aftsprozesse. Um der Vielfalt an m¨ oglichen Gesch¨ aftsprozessen und deren sich ¨ andernden Anforderungen schnell gerecht zu werden, bedarf es einer skalierbaren Servicelandschaft, auf deren Basis die Abbildung der zugrundeliegenden Informationsfl¨ usse durch Komposition einzelner Services erfolgt.

Die Spezifikation von Gesch¨ aftsprozessen selbst soll so abstrahiert werden, dass diese durch ein Datenmodell, dem User-Interface-Design und den Gesch¨ aftsregeln vollst¨ andig beschrieben ist. Insbesondere dem User-Interface-Design wird ein hoher Stellenwert zugeschrieben, da es bei verteilten Systemen unterschiedlichste Charakteristika aufweist und letztlich die Schnittstelle darstellt, die auch eine Integration in bestehende Architekturen erm¨ oglicht.

1.3 Anwendungsszenario: verteiltes Sensorennetzwerk

Ein Anwendungsszenario soll darin bestehen, die Messdaten verschiedener Sen-soren wie bspw. des Temperatursensors einer Central Processing Unit (CPU)

2

oder eines per Universal Serial Bus (USB) angeschlossenen Luftfeuchtesensors zu erfassen, zu speichern und in verschiedenen Formen auszuwerten oder Alarm bei der Tangierung von Grenzwerten auszul¨ osen. Die Architektur eines solchen Systems k¨ onnte wie in Abbildung 1 dargestellt aussehen.

Die zugrundeliegenden Informationen in Form der Messdaten sollen also in verschiedenen Medien dargestellt werden. Eine Realisierung soll lediglich durch Spezifikation des Datenmodells, dem User-Interface (dt. Benutzerschnittstelle) (UI)-Design und der zu verwendenden Gesch¨ aftslogik erfolgen. Die Kommunikation kann auf verschiedenen technischen Realisierungen basieren. Eine Benachrichtigung bei der Tangierung von Grenzwerten kann bspw. per E-Mail, Short Message Service (SMS), Instant Messaging (IM) oder Atom Syndication Format (ATOM) Feed erfolgen. Die Visualisierung der Messwerte kann in Form einer Grafik, eines Reports oder auch durch ein Diagramm in Microsoft Excel dargestellt werden. Den unterschiedlichen Darstellungsformen liegen jedoch stets ein und dieselben Informationen zugrunde, n¨ amlich die Messwerte der verteilten Sensoren.

1.4 Anwendungsszenario: Startup-Center Diplomarbeit

Ein weiteres zu dieser Arbeit passendes Anwendungsszenario ist der Gesch¨ aftsprozess f¨ ur die Bearbeitung einer Diplomarbeit. Ausgehend von der Themenfindung ¨ uber die Literaturrecherche bis hin zu m¨ undlichen Konsultationen, schriftlichen Entw¨ urfen und einzelnen Meilensteinen ist die Diplomarbeit nach erfolgreicher Verteidigung im Idealfall bestanden. Auch hier treten verschiedene Akteure in Szene und tauschen Informationen aus. Gegen¨ uber dem Sen-sorennetzwerk handelt es sich allerdings um einen grundlegend anderen Gesch¨ aftsprozess. Um auch den zeitlichen Verlauf darzustellen, wird zur Veranschaulichung in Abbildung 2 ein Sequenzdiagramm gew¨ ahlt. Die Abbildung eines solchen Gesch¨ aftsprozesses erfordert bereits die Integration bestehender Abl¨ aufe. So wird die Kommunikation mit dem Pr¨ ufungsamt bspw. lediglich durch Verwendung eines Portable-Document-Format (PDF)-Formulars erfolgen. Dieses ist ausgef¨ ullt und unterschrieben beim jeweiligen Sachbearbeiter einzureichen. Nach Genehmigung durch den Pr¨ ufungsausschuss und dem pr¨ ufenden Professor erfolgt eine Best¨ atigung der Aufgabenstellung

3

sowie die Festlegung des endg¨ ultigen Abgabetermins. Die Recherche nach Literatur erfolgt ebenfalls durch ein bereits vorhandenes System der Universit¨ atsbibliothek namens Online Public Access Catalogue (OPAC). Terminvereinbarungen mit dem jeweiligen Betreuer erfolgen in der Regel per E-Mail. All diese M¨ oglichkeiten der Kommunikation sollen hier zu einem zentralen Gesch¨ aftsprozess geb¨ undelt werden. Als Designvorlage wird das Microsoft Startup-Center ¹ verwendet. Die ¨ ubersichtliche Strukturierung des zeitlichen Verlaufs im Header sowie die M¨ oglichkeit der jeweils zul¨ assigen Aktionen im aktuellen Kontext durch das linke Men¨ u garantieren eine intuitive Bedienung.

1.5 Ziel der Arbeit

Wie bereits aus der Motivation dieser Arbeit hervorgeht wird der Informationsfluss zwischen verteilten Systemen auf Basis einer Datenmodellbeschreibung, des UI-Designs und der Definition von Gesch¨ aftsregeln spezifiziert. Ziel ist dabei, dass diese drei Bereiche sowohl von den Anwendern als auch von

¹ https://www.microsoft.com/smallbusiness/startup-toolkit/default.aspx

4

den Entwicklern einfach spezifiziert werden k¨ onnen, ohne dass die Anwender technisches Verst¨ andnis und die Entwickler fachliche Kompetenz einbringen m¨ ussen. Die Kommunikationsl¨ ucke zwischen Entwickler und Anwender soll somit minimiert werden, um den Entwicklungsprozess der informationstechnischen Integration weitestgehend zu automatisieren.

Der Ablauf zur Spezifikation der Informationsfl¨ usse soll stets nach folgendem Schema ablaufen:

• Datenbeschreibung

Welche Daten werden ben¨ otigt und wie sind diese zu logischen Einheiten zu gruppieren? Eine Datenbeschreibung umfasst dabei einen eindeutigen Namen zur Identifikation des Datenspeichers sowie optionale Metadaten zu deren Beschreibung.

• UI-Design

Die einzelnen Ansichten der Daten und deren Interaktionsm¨ oglichkeiten werden spezifiziert. Ansichten k¨ onnen f¨ ur verschiedene UIs in verschiedenen Beschreibungssprachen wie Extensible Markup Language (XML), Hypertext Markup Language (HTML), Extensible Application Markup Language (XAML), aber auch f¨ ur Endanwendungen wie Microsoft Word oder Excel spezifiziert werden.

• Business Rules

Die Definition der Gesch¨ aftsregeln beinhaltet, wie die unterschiedlichen UI-Bestandteile miteinander verkn¨ upft sind und durch welche Ereignisse welche Aktionen im Workflow initiiert werden. Technisch gesprochen wird hier die Orchestrierung der einzelnen Services vorgenommen, um eine Aktion auszuf¨ uhren.

1.6 Aufbau der Arbeit

Die bisherigen Kapitel beinhalteten die Einf¨ uhrung in das Gebiet der Gesch¨ aftsprozesse und die damit einhergehende Motivation sowie die Zielsetzung dieser Arbeit, eine informationstechnische Abbildung so effizient, flexibel und einfach wie m¨ oglich zu gestalten.

Im folgenden Kapitel 2 werden Voraussetzungen und Grundlagen geschaffen, um ein einheitliches Verst¨ andnis der verwendeten Begrifflichkeiten voraussetzen zu k¨ onnen. Dieses Grundlagenkapitel wurde bewusst knapp gehalten, um dem Leser einen ¨ Uberblick der Verwendeten Technologien zu vermitteln und nicht mit deren umfangreiche Spezifikationen zu langweilen. Vor dem eigentlichen Systementwurf erfolgt in Kapitel 3 eine Studie aktuell auf dem Markt befindlicher L¨ osungen und deren Einsatzm¨ oglichkeiten im Rahmen der vorliegenden Anwendungssituationen. Vor- und Nachteile dieser Systeme werden aufgezeigt und diskutiert, um zusammenfassend festzustellen, warum in dieser Arbeit eine eigene L¨ osung favorisiert wird. In Kapitel 4 erfolgt der Systementwurf. Ausgehend von einer Representational-

5

State-Transfer (REST)-Architektur und der diesbez¨ uglich bereits durchgef¨ uhrten ¨ Uberlegungen und Ans¨ atze mit dem WebComposition/Data Grid Service (DGS) wird die grundlegende Architektur schematisiert und erl¨ autert. Darauf aufbauend werden weitere beteiligte Services sukzessive ausgebaut, um Funktionalit¨ at von Workflow-Management-Systemen und Content-Management--Systemen zu kombinieren.

Nach dem Entwurf werden die einzelnen Services im Kapitel 5 implementiert. Im Vorfeld der Implementierung wird kurz auf die verwendete Entwicklungsumgebung eingegangen und gezeigt, dass auch die Wahl dieser frei getroffen werden kann. In welcher Umgebung die verwendeten Services entwickelt werden, spielt grunds¨ atzlich keine Rolle, da ausschließlich Standard- und systemunabh¨ angige Technologien verwendet werden.

Kapitel 6 beinhaltet die Testf¨ alle aller Einzelkomponenten sowie die Komposition dieser Einzelkomponenten zur Realisierung der beiden aufgestellten Anwendungsszenarien und deren Test. Die verwendete Laufzeitumgebung und deren Konfiguration wird am konkreten Beispiel durchgef¨ uhrt, um zu zeigen, dass die Zielsetzung dieser Arbeit erreicht wurde. Abschließend wird in Kapitel 7 eine Zusammenfassung gegeben und ein kurzes Fazit dieser Arbeit gezogen. Visionen zum Einsatz und zur Weiterentwicklung dieser Infrastruktur runden die Arbeit ab und motivieren zu deren Ausbau.

6

2 Grundlagen

Im Rahmen dieser Arbeit werden zahlreiche Technologien eingesetzt, deren grundlegende Funktionsweisen zu Beginn kurz erl¨ autert werden sollen. Somit wird einerseits ein einheitliches Verst¨ andnis ¨ uber deren Einsatz und Funktions-

weise geschaffen. Andererseits wird ein Vokabular eingef¨ uhrt, auf verschiedenen Begriffen einfacher gearbeitet werden kann.

2.1 WebComposition-Ansatz

Der Grundstein des World Wide Web (WWW) wurde 1989 durch Tim Berners-Lee am Kernforschungszentrum (CERN) in Genf entwickelt und am 30. April 1993 weltweit zur Nutzung freigegeben. Seitdem w¨ achst es in rasanter Geschwindigkeit und mit ihm die Vielfalt an Anwendungen innerhalb des WWW. Die damit einhergehende Innovationsgeschwindigkeit bedingt den st¨ andigen Anpassungs- und Erweiterungsbedarf von Web-Anwendungen, wodurch Aspekte des Software-Engineerings auf diese neue Art der Anwendungsentwicklung ubertragen werden. Die neue Disziplin des Web Engineerings entwickelt sich ¨

rasant weiter und verspricht durch ihr systematisches Vorgehen eine effiziente Entwicklung und Wartung von Web-Anwendungen.

Der WebComposition-Ansatzes beschreibt ein Vorgehensmodell, ein Wiederverwendungsmanagement, eine Komponententechnologie und einem Evolutionskonzept [22] f¨ ur Web-Anwendungen. Das Vorgehensmodell beschreibt hierbei in Anlehnung an Entwicklungsmodelle der klassischen Softwareentwicklung nicht die einzelnen Entwicklungsphasen, sondern adaptiert als offenes Vorgehensmodell bereits existierende Softwareentwicklungsmodelle wie bspw. das Wasserfallmodell oder objektorientierte Entwicklungsmodelle. Ausgangspunkt f¨ ur das Wiederverwendungsmanagement ist das sogenannte Komponentendilemma. Es besagt, dass mit steigender Komplexit¨ at zwar die Wahrscheinlichkeit steigt, eine passende Komponente zu besitzen, aber gleichzeitig auch der Aufwand steigt, um die ben¨ otigte Komponente zu finden. Das Problem besteht darin, eine geeignete Repr¨ asentation der Komponente zu finden, um eine Suche in der Menge von Komponenten zu unterst¨ utzen. Die L¨ osung dieses Problems sind Metadaten. Mittels Metadaten k¨ onnen Komponenten in unterschiedlichster Weise beschrieben werden, sodass auch das Auffinden in einer Wiederverwendungssituation gew¨ ahrleistet ist. Die Komponententechnologie beschreibt im Wesentlichen ein Abstraktionsniveau der Sichtweise auf Komponenten und erfolgt mithilfe der WebComposition Markup Language (WCML), einer Anwendung der Extensible Markup Language (XML). Innerhalb von WCML werden Komponenten als einheitliche Modellierungskonzepte beschrieben und durch eine Universally Unique Id (UUID) eindeutig identifiziert. Web-Anwendungen werden innerhalb der WCML durch Komposition einzelner Komponenten beschrieben. Das Evolutionskonzept beschreibt den Umgang mit sich ¨ andernden Systeman-forderungen und der damit verbundenen Anpassung von Anwendungen und Komponenten. Hierbei wird eine leere Web-Anwendung ohne Funktionalit¨ at

7

um einzelne Komponenten erweitert, welche wiederum einzeln ausgetauscht oder erweitert werden k¨ onnen. Die lose Kopplung der Komponenten steht hierbei im Vordergrund.

2.2 XML und deren Erweiterungen

Die Extensible Markup Language ist eine seit 1998 vom World Wide Web Con-sortium (W3C) empfohlene Auszeichnungssprache und stelle eine echte Teilmenge der bereits 1986 von der International Organisation for Standardization (ISO) standardisierten, plattformunabh¨ angigen Auszeichnungssprache Standard Generalized Markup Language (SGML) ² dar. SGML ist weiterhin in der Europ¨ aischen Norm EN 28879:1990 und der DIN EN 28879:1991 beschrieben [32]. Jedes XML-Dokument ist demzufolge stets auch ein SGML-Dokument. Das W3C wurde 1994 am Massachusetts Institute of Technology (MIT) und am europ¨ aischen Kernforschungszentrum (CERN) in Genf gegr¨ undet. Das W3C ist kein offizielles Gremium wie die ISO und kann daher formell auch keine Standards definieren. Aufgrund der breiten Akzeptanz des W3C bei Softwareentwicklern, Forschern und Endbenutzern werden deren Empfehlungen (Recommendations) aber als De-facto-Standard anerkannt [8]. Ein erkl¨ artes Ziel des W3C besteht darin, das World Wide Web maßgeblich durch die Ver¨ offentlichung technischer Dokumente und Empfehlungen zu beeinflussen. XML beschreibt eine Klasse von Datenobjekten, welche als XML-Dokumente bezeichnet werden. Ein XML-Dokument setzt sich wiederum aus sogenannten Entities zusammen, welche die eigentlichen Daten enthalten [9]. Die Entities bestehen aus Daten und dem diese Daten umschließenden Markup. Wichtig ist hierbei, dass es keine fest definierten Markup-Elemente gibt, sondern dass die Entwickler und Autoren ihr eigenes Markup je nach Bedarf spezifizieren. Der dadurch erreichte Freiheitsgrad etablierte XML in den letzten Jahren zum beliebtesten Austauschformat f¨ ur Dokumente und wird heute in verschiedensten Bereichen eingesetzt. ³ Ein einfaches XML-Dokument sieht z.B. wie folgt aus:

v e r s i o n =”1.0” e n c o d i n g=”u t f −8”?> Ralph

Zur Vermeidung von Konflikten bei der Namensgebung von XML-Elementen k¨ onnen sogenannte Namespaces innerhalb eines XML-Dokumentes eingebunden werden. Diese beinhalten eine Sammlung der jeweils zul¨ assigen Element-und Attributnamen und werden auch dazu verwendet, das Vokabular von Erweiterungen wie bspw. der Extensible Stylesheet Language (XSL) bekannt zu machen [13]. Die Einbindung eines Namespaces erfolgt durch das Attribut xmlns wie in folgendem Listing dargestellt:

s l : s t y l e s h e e t v e r s i o n =”1.0” xmlns : x s l =”h ttp : / /www. w3 . or g /1999/XSL/ Transform”>

² ISO Standard: ISO 8879:1986 Information Processing - Text and Office Systems - Standard Generalized Markup Language (SGML)

³ Der Umfang und die M¨ oglichkeiten von und mit XML w¨ urden eine eigene Diplomarbeit f¨ ullen und so sei der interessierte Leser f¨ ur detailliertere Informationen an die Literatur [1] verwiesen.

8

Eine Document Type Definition (DTD) beschreibt das zul¨ assige Markup innerhalb eines XML-Dokumentes. Auch die Verschachtelung von Elementen oder deren H¨ aufigkeitsbeschr¨ ankungen und zul¨ assige Attribute k¨ onnen spezifiziert werden. Die Verarbeitung der durch XML ausgetauschten Daten muss nicht zwingend so flexibel sein wie XML selbst. So kann eine Anwendung bspw. nur XML-Daten verarbeiten, welche einem gewissen Format entsprechen. Um dies sicherzustellen, wird das XML-Dokument gegen die DTD validiert. Erf¨ ullt ein XML-Dokument alle in der DTD angegebenen Regeln, so wird es als g¨ ultig bezeichnet und kann durch die Anwendung verarbeitet werden. XML Schema Definition (XSD) ist eine Empfehlung des W3C und bietet gegen¨ uber der einfachen DTD eine wesentlich m¨ achtigere und ausdrucksst¨ arkere Validierung von XML-Dokumenten [14][15][16]. Wie auch bei der DTD gilt ein XML-Dokument als g¨ ultig, wenn es alle in XML-Schema definierten Vorgaben erf¨ ullt. Im Gegensatz zur DTD bietet XML Schema auch Konstrukte zur Kontrolle von Formaten und Datentypen der XML-Elemente und Attribute. Einfache und komplexe Datentypen sowie Ableitung und Vererbung sind wesentliche Vorteile von XML-Schema. Ein weiterer wichtiger Vorteil besteht auch in dessen Formulierung auf Basis von XML selbst. F¨ ur DTDs waren noch spezielle Editoren n¨ otig und es existierten keine Programmierschnittstellen, wie etwa das Document Object Model (DOM) oder die Simple API for XML (SAX). Eine in XML definierte Schemabeschreibung ist dagegen genauso wie ein XML-Dokument auswertbar.

Die Extensible Stylesheet Language Transformation (XSLT) ist eine auf XML aufsetzende Technologie und beschreibt Regeln f¨ ur die Transformationen eines XML-Dokumentes in ein anderes XML-Dokument [28]. Eine Regel besteht aus einem Muster und einem Template. Der XSLT-Prozessor vergleicht bei der Transformation die Elemente des XML-Eingabe-Dokumentes mit den Mustern der XSLT-Regeln und schreibt bei ¨ Ubereinstimmung das Template dieser Regel in die Baumstruktur des XML-Ausgabe-Dokumentes. Die XML Path Language (XPath) entspricht nicht der XML-Syntax, wird aber f¨ ur die Adressierung von XML-Elementen verwendet. Mithilfe von XPath k¨ onnen Ausdr¨ ucke geschrieben werden, um innerhalb von XML-Dokumenten bspw. alle Elemente mit dem Markup Name zu referenzieren [10]. Die Navigation innerhalb des XML-Dokumentes erfolgt hierbei auf Grundlage einer Baumstruktur und der Angabe eines Pfadausdruckes. Noch m¨ achtigere Werkzeuge f¨ ur die Navigation auch ¨ uber Dokumentengrenzen hinweg erm¨ oglicht die Verwendung von XML Pointer Language (XPointer) oder XML Linking Language (XLink). Diese vereinen das Prinzip der Navigationsm¨ oglichkeiten von XPath-Ausdr¨ ucken und des Referenzierens von XML-Dokumenten durch URIs. Weiterhin finden XPath-Ausdr¨ ucke bei der Definition von Regeln innerhalb der XSL Anwendung [11][12].

9

2.3 Representational State Transfer

Der Begriff REST wurde durch die Dissertation von Roy Thomas Fielding, einem der Hauptautoren des Hypertext-Transfer-Protocol (HTTP) ⁴ , im Jahre 2000 gepr¨ agt und als eine der Schl¨ usseltechnologien f¨ ur das World Wide Web vorgestellt. REST beschreibt eine Softwarearchitektur, die aufbauend auf dem HTTP-Protokoll die Einhaltung folgender Bedingungen propagiert [2]:

• Client-Server

Die Client-Server-Architektur ist eine der am weitesten verbreiteten Softwarearchitekturen f¨ ur verteilte Anwendungen. Hierbei stellen Clienten Anfragen an einen Server, der diese bearbeitet und beantwortet. Diese Vorgehensweise hat zum Ziel, das User-Interface von den Daten zu trennen und deren Interaktion zu koordinieren.

• Zustandslos

Jede Anfrage ist f¨ ur den Server unabh¨ angig von anderen Anfragen. Alle f¨ ur die Bearbeitung n¨ otigen Informationen m¨ ussen in einer Anfrage vorhanden sein. Nachdem eine Anfrage durch den Server bearbeitet und dessen Response an den Client zur¨ uck geschickt wurde k¨ onnen alle Serverressourcen wieder freigegeben werden.

• Cache

Um die Netzwerkslast zu reduzieren, ist die Antwort des Servers als cachable oder nicht zu kennzeichnen. Das bietet den Vorteil, dass als cachable gekennzeichnete Anfragen nicht erneut durch den Server beant-worten werden m¨ ussen, sondern gegebenenfalls bereits durch den Client Cache beantwortet werden k¨ onnen.

• einheitliche Schnittstelle

Wichtigste Bedingung einer REST-Architektur ist eine der Softwareentwicklung entnommene Anforderung der generalisierten Schnittstellen zwischen einzelnen Komponenten. Diese Schnittstelle basiert auf dem HTTP-Protokoll und ist damit haupts¨ achlich f¨ ur die Anwendungsdom¨ ane von Web-Anwendungen interessant. F¨ ur andere Formen der Interaktion ist REST weniger geeignet.

• Schichten

Die einzelnen Komponenten werden in Schichten angeordnet, wobei Komponenten einer Schicht ausschließlich auf Komponenten der unmittelbar darunter liegenden Schicht zugreifen k¨ onnen. Dadurch wird einerseits die Komplexit¨ at reduziert, andererseits entsteht Overhead, wenn Nachrichten durch mehrere Schichten geleitet werden m¨ ussen.

• Code bei Bedarf

REST fordert, dass die Funktionalit¨ at des Clients durch den Download und das Ausf¨ uhren von Applets oder Skripten erweitert werden kann.

⁴ http://www.ietf.org/rfc/rfc1945.txt

10

Dies reduziert die Anforderungen an das Client-System, da keine besonderen Systemvoraussetzungen geschaffen werden m¨ ussen.

Diese Eigenschaften sind keineswegs neu und haben das Web zu dem gemacht, was es heute ist: ein wachsendes Universum von Informationen in einem weltumspannenden System mit unabh¨ angig voneinander interagierenden Systemen. Ziel dieser Architektur ist genau diese Unabh¨ angigkeit der Komponenten und generalisierten Schnittstellen.

HTTP selbst stellt hierbei das Anwendungsprotokoll im TCP/IP-Protokollstapel in Form einer zustandslosen Client-Server-Kommunikation dar. Die Kommunikationseinheiten werden als Nachrichten bezeichnet und gliedern sich in Request (dt. Anfrage) und Response (dt. Antwort), je nach deren Richtung vom Client zum Server und vice versa. Der Aufbau einer Nachricht besteht aus Header und Content. Der Header enth¨ alt Informationen wie Kodierung und Typ des Contents. Das Ziel einer Request wird in Form eines Uniform Resource Identifier (URI) ⁵ adressiert und als Ressource bezeichnet. Allein der Zugriff auf Ressourcen im Web stellt aber noch keine Webanwendung dar und so m¨ ussen neue Ressourcen erstellt oder bestehende Ressourcen manipuliert werden. An diesem Punkt kommt eine entscheidende Schnittstelle ins Spiel, ¨ uber welche die Aktionen an den Ressourcen ausgef¨ uhrt werden, die durch die URI identifiziert wurden. H¨ aufig wurde diese Schnittstelle f¨ ur jede Ressource in Form von Parametern innerhalb der URI kodiert und vom jeweiligen Entwickler je nach Anforderung frei erfunden. Aktuelle Diskussionen mit dem Ziel der Standardisierung dieser Schnittstelle sollen die Orchestrierung von Diensten ¨ uber Plattform-, Anwendungs- und Unternehmensgrenzen hinweg erm¨ oglichen. Herauskristallisiert haben sich bisher zwei Lager: einerseits Vertretern des sogenannten Simple-Object-Access-Protocol (SOAP), andererseits die Anh¨ anger der REST-Architektur [5].

Der Unterschied besteht im Wesentlichen darin, dass SOAP ein eigenes Netzwerkprotokoll darstellt und somit sowohl auf dem Client als auch auf dem Server einen eigenen Stack f¨ ur dessen Nutzung ben¨ otigt. REST hingegen stellt ein einheitliches Interface f¨ ur nicht typisierte Ressourcen zur Verf¨ ugung, welches vorhandene, etablierte und gut verstandene Technologien in maschinenlesbarer Form zur Verf¨ ugung stellt. Andererseits ist der Aktionsvorrat von REST wegen der fest definierten HTTP-Verben auf diese beschr¨ ankt. Demgegen¨ uber k¨ onnen innerhalb von SOAP beliebige Methoden frei definiert werden und bieten somit mehr Flexibilit¨ at, allerdings zu Lasten der Komplexit¨ at. F¨ ur das Vorhaben dieser Arbeit liegen die Vorteile einer REST-Architektur in Bezug auf den in der Einleitung angesprochenen Bereich der technischen Informatik vor allem darin, dass diese Architektur auf dem am weitesten verbreiteten Anwendungsprotokoll HTTP basiert und somit dessen bew¨ ahrte Mechanismen f¨ ur bspw. Caching, Authentisierung sowie Datenschutz und Datensicherheit genutzt werden k¨ onnen. Die HTTP-Unterst¨ utzung ist im Open Systems Interconnection-Reference-Model (OSI) der ISO in der Anwendungsschicht angesiedelt und besitzt damit einen relativ hohen Abstraktionsgrad. Aufgrund

⁵ http://www.ietf.org/rfc/rfc2396.txt

11

der Verbreitung gibt es aber gerade f¨ ur dieses Protokoll handels¨ ubliche Layer 4 bis 7 Switches, um z.B. ein Quality of Service (QoS) zu realisieren. Beispielsweise k¨ onnten bei Google, zu dessen h¨ aufigsten Anfragen GET geh¨ ort, Suchanfragen auf Basis dieser Netzwerktechnik auf andere dedizierte Systeme umgeleitet werden anstatt auf PUT-Anfragen der Google Robots, um neue Seiten in den Index aufzunehmen. Ebenso sind sicherheitstechnische Aspekte mit derartiger Netzwerktechnik leicht zu realisieren, da eine GET-Anfrage nur lesenden Zugriff ben¨ otigt und somit Schreibrechte lediglich f¨ ur PUT, POST und DELETE zur Verf¨ ugung stehen m¨ ussen. Weiterf¨ uhrende Literatur zum Thema Sicherheit im WebComposition-Ansatz ist auf der Homepage ⁶ zum WebComposition/idFS aufgef¨ uhrt.

2.4 Ressource Description Framework

Metadaten, auch Metainformationen genannt, sind im wahrsten Sinne des Wortes Daten, die andere Daten beschreiben. Die Zahl 82,4 allein sagt noch nicht viel aus. Mit der Zusatzinformationen, dass es sich bei der Einheit um Kilogramm handelt, kann sie hingegen schon klassifiziert werden. So einfach auf den Punkt gebracht ist bereits der Kern des Resource Description Framework (RDF) erschlossen. RDF selbst kann durch XML dargestellt werden und beschreibt die Semantik von Daten in einem standardisierten und austauschbaren Format. Die Trennung zwischen Daten und Metadaten werden im RDF-Modell durch Verwendung von Referenzen auf die Daten, nicht aber der Daten selbst realisiert. Anzumerken ist, dass RDF nicht nur ausschließlich in XML dargestellt werden kann, sondern auch hochperformante L¨ osungen unter dem Namen RDF Triple Stores existieren und zumeist auf relationalen Datenbanken basieren. Das RDF-Modell besteht aus den folgenden Elementen [17]:

• Ressourcen

Alles, was durch RDF-Ausdr¨ ucke beschrieben wird, ist eine Ressource. Ressourcen k¨ onnen einfache Webseiten, Teile von Webseiten und andere Onlineressourcen oder auch ganz anders geartete Objekte wie ein Buch oder KFZ sein. Eine Ressource wird immer durch eine URI benannt und referenziert.

• Eigenschaften

Eigenschaften sind Attribute, Beziehungen oder charakteristische Aspekte f¨ ur die Beschreibung von Ressourcen. Jede Eigenschaft hat eine spezielle Bedeutung und definiert deren m¨ ogliche Werte.

• Ausdr¨ ucke

Eine Ressource mit einer benannten Eigenschaften und deren Wert ist ein RDF-Ausdruck. Diese drei Bestandteile werden auch als Subjekt, Pr¨ adikat und Objekt bezeichnet.

Das Potenzial dieser Darstellung von Beziehungen zwischen den unterschiedlichsten Informationen bildet die Grundlage aktueller Diskussionen rund um

⁶ http://webcomposition.net/idfs/

12

das Semantik-Web. Der Umgang mit Subjekt, Pr¨ adikat und Objekt l¨ asst Zusammenh¨ ange ausdr¨ ucken und erkennen, wie diese auch im Sprachgebrauch verwendet werden. Eine Datenverarbeitung, welche bisher nur syntaktische

Regeln ber¨ ucksichtigte, kann nun auch mit dem Wissen ¨ uber Beziehungen

zwischen den Daten ausgestattet werden und somit Informationen ¨ Bedeutung der Daten automatisiert verarbeiten. Am Beispiel dieser Diplomarbeit sieht der RDF-Ausdruck f¨ ur die Beziehung zum Autor wie folgt aus:

Graphisch wird dies wie folgt dargestellt: Die Richtung der Beziehung ist hier-

Abbildung 3: Graphische Darstellung von RDF-Beziehungen.

bei wichtig und geht immer vom Subjekt zum Objekt. Gelesen wird dieser Ausdruck in der Form Diplomarbeit 20081101 hat Autor Ralph Sommermeier oder allgemein Subjekt hat Pr¨ adikat Objekt. Komplexere Strukturen k¨ onnen durch Referenzierung des Objektes auf weitere RDF-Ressourcen gebildet werden und sehen an oben gew¨ ahltem Beispiel wie folgt aus: Die M¨ oglichkeiten

Abbildung 4: Graphische Darstellung komplexer RDF-Beziehungen.

der RDF-Syntax gehen weit ¨ uber diese einfachen Szenarien hinaus, deren Vertiefung ¨ uber 50 Seiten Originalspezifikation erfordern. Zur Abhilfe existieren unterschiedliche auch schon bekannte Formen, welche den Gebrauch von RDF vereinfachen. Im Folgenden werden zwei davon n¨ aher vorgestellt: die zweite wird innerhalb des WebComposition/DGS zur Spezifikation der Beziehung von Ressource, URI-Template und XPath-Ausdruck angewandt.

• Backus-Naur Form (BNF)

Die BNF ist eine Sprache zur Darstellung kontextfreier Grammatiken

13

(Typ-2-Grammatiken in der Chomsky-Hierarchie), die syntaktische Regeln ¨ uber die Zusammensetzung der Literale enth¨ alt. Die Regeln bestehen aus einer linken und rechten Seite, die durch ::= getrennt werden. Auf der linken Seite sind ausschließlich sogenannte Nichtterminalsymbole zul¨ assig. Demgegen¨ uber k¨ onnen auf der rechten Seite Nichtterminalsymbole und Terminalsymbole kombiniert auftreten. Alle Nichtterminalsymbole werden durch umschließende eckige Klammern gekennzeichnet und es existiert eine Regeln, um diese aufzul¨ osen. Eine triviale Beschreibung des Kerns von RDF sieht in der BNF wie folgt aus:

< RDF Statement > ::=< Subjekt >< P r¨ adikat >< Objekt >

• Notation3 - Mime Type text/rdf+n3

RDF-Ausdr¨ ucke bestehen jeweils aus Subjekt, Pr¨ adikat und Objekt. In Notation3 schreibt man diese einzelnen S¨ atze jeweils mit einem Punkt am Ende. Mehrere S¨ atze zum selben Subjekt oder mehrere Objekte zu einem Subjekt k¨ onnen durch das Semikolon bzw. ein Komma getrennt werden. Am Beispiel sieht dies wie folgt aus:

pl omarb ei t > Sommermeier> ;

Unabh¨ angig von der verwendeten Sprache zur Beschreibung von RDF-Ausdr¨ ucken m¨ ussen auch die f¨ ur eine Ressource zul¨ assigen Eigenschaften spezifiziert werden. Innerhalb von RDF werden diese einfach verwendet, aber es wird nicht n¨ aher darauf eingegangen. Diese Spezifikation, ebenfalls auf XML basierend, sind in [27] nachzulesen.

14

3 Related Work

In diesem Kapitel werden die M¨ oglichkeiten evaluiert, auf deren Basis sich die Aufgabenstellung realisieren l¨ asst. Grunds¨ atzlich existieren drei prinzipielle Herangehensweisen zur L¨ osung der Aufgabenstellung mit aktuell auf dem Markt befindlichen Tools und Techniken. Eine sehr weit verbreitete Methode ist nach wie vor der Einsatz oder sogar die Entwicklung individueller, speziell auf die Anwendungsdom¨ ane zugeschnittener Softwarel¨ osungen. Je spezieller bzw. je kleiner der Markt f¨ ur die jeweiligen Anwendungsdom¨ anen ist, desto weniger Anbieter existieren und desto teurer ist in der Regel der Einsatz bzw. die Entwicklung solcher Softwaresysteme. Damit einhergehende Probleme bestehen vorallem darin, dass bei sich ¨ andernden Gesch¨ aftsabl¨ aufen eine aufwendige Anpassung der Software erforderlich wird.

Dieser Nachteil von Individualsoftware wurde erkannt und es entwickelten sich in den letzten Jahren sogenannte Workflow-Management-Systeme (WfMS) teils auch Business-Process-Management-Systeme (BPMS) genannt. Dies sind komplexe Softwaresysteme, welche in der Lage sein sollen, unabh¨ angig von der jeweiligen Anwendungsdom¨ ane Gesch¨ aftsprozesse zu definieren und abzuarbeiten.

Ein weiterer Ansatz ist die Verwendung sogenannter Content-Management-Systeme (CMS). Diese sind im Gegensatz zu den Business-Process-Management (BPM) Systemen nicht f¨ ur die Abarbeitung von Gesch¨ aftsprozessen vorgesehen, sondern lediglich f¨ ur die Visualisierung und Pflege von Inhalten durch strikte Trennung von Content und Layout. Anders ausgedr¨ uckt stellen CMS, Workflows f¨ ur das Management von Inhalten zur Verf¨ ugung. Bekanntheit hat das Stichwort allerdings erst im Zusammenhang mit der Entwicklung von Web2.0 erlangt und wird durch den Begriff Web-Content-Management-Systeme (WCMS) konkretisiert. Ausschlaggebend war hierbei die Notwendigkeit, die Pflege von Inhalten im Web auch Personen zu erm¨ oglichen, die nicht ¨

technisches Hintergrundwissen ¨ uber Hypertext Markup Language (HTML), Cascading Style Sheets (CSS) oder HTTP verf¨ ugen.

3.1 Workflow Management

Nach der Workflow Management Coalition (WfMC) ⁷ ist ein Workflow wie folgt definiert:

The automation of a business process, in whole or part, during which do-

”

cuments, information or tasks are passed from one participant to another for action, according to a set of procedural rules.“

Ein Workflow ist demnach ein fest definierter Gesch¨ aftsprozess, so wie dieser bereits in der Einleitung beschrieben wurde. Daher r¨ uhrt auch die analog verwendete Bezeichnung Business Process. WfMS bzw. BPMS sind folglich die Systeme, welche eine automatisierte Abarbeitung dieser Workflows erm¨ oglichen.

⁷ http://www.wfmc.org

15

Die Darstellung der Architektur von WfMS durch das Workflow Reference Model ⁸ zeigt Abbildung 5. Die wesentlichen Eckpunkte einer automatisierten

Abarbeitung sind unter anderem die folgenden:

• Aktivit¨ aten

Einzelne Schritte des Gesch¨ aftsprozesses werden durch einzelne Aktivit¨ aten im Workflow dargestellt. Der ¨

anderen erfolgt dabei ¨ uber eine fest definierte Schnittstelle. • Informationsfluss

Der Informationsfluss findet zwischen den einzelnen Aktivit¨ aten eines Workflows statt. Den beteiligten Akteuren m¨ ussen zu jedem Zeitpunkt die f¨ ur die Bearbeitung notwendigen Daten zur Verf¨ ugung stehen.

• Rollen

Aktivit¨ aten werden innerhalb eines Workflow den daf¨ ur vorgesehenen Rollen zugewiesen. Dabei sind Rollen Mengen von Akteuren mit bestimmten F¨ ahigkeiten, die zur Bearbeitung einer Aufgabe n¨ otig sind. Es erfolgt somit eine Automatisierung der Ressourcenplanung und Verteilung.

• EAI

Die Anwendungsintegration ist ein wichtiger Bestandteil, um bereits existierende Abl¨ aufe im Workflow zu integrieren. In der Vergangenheit ha-

⁸ http://www.wfmc.org/graphics/processmodellarge.gif

16