Konzeption einer Serviceinfrastruktur für den Informationsfluss zwischen verteilten Systemen

Inhaltsverzeichnis

1 Einleitung
1.1 Geschäftsprozesse
1.2 Motivation
1.3 Anwendungsszenario: verteiltes Sensorennetzwerk
1.4 Anwendungsszenario: Startup-Center Diplomarbeit
1.5 Ziel der Arbeit
1.6 Aufbau der Arbeit

2 Grundlagen
2.1 WebComposition-Ansatz
2.2 XML und deren Erweiterungen
2.3 Representational State Transfer
2.4 Ressource Description Framework .

3 Related Work
3.1 Workflow Management
3.2 Content Management
3.3 Zusammenfassung und Bewertung

4 Systementwurf
4.1 Architektur
4.2 WebComposition/extending Services
4.2.1 DataGridService
4.2.2 ServiceQueue
4.2.3 XSDFilter
4.2.4 XSLT
4.2.5 XPath
4.2.6 UI-Adapter index
4.3 Zusammenfassung

5 Implementierung
5.1 Entwicklungsumgebung
5.2 WebComposition/extending Services
5.2.1 DataGridService
5.2.2 ServiceQueue
5.2.3 XSDFilter
5.2.4 XSLT
5.2.5 XPath
5.2.6 UI-Adapter index
5.3 Zusammenfassung

6 Test
6.1 Laufzeitumgebung
6.2 WebComposition/extending Services
6.2.1 DataGrindService
6.2.2 ServiceQueue
6.2.3 XSDFilter
6.2.4 XSLT
6.2.5 XPath
6.2.6 UI-Adapter index
6.3 Beispiel Adressstammdaten
6.4 Anwendungsszenario: verteiltes Sensorennetzwerk
6.5 Anwendungsszenario: Startup-Center Diplomarbeit
6.6 Zusammenfassung

7 Fazit und Ausblick

8 Anhang
8.1 Testszenario DGS
8.2 Testszenario XSLT
8.3 XSLT - Adressenliste
8.4 XSLT - Adressenpflege
8.5 XSLT - Adressenneuanlage
8.6 XSLT - Adressenformular
8.7 Visual Basic Script - Vorlage Word Serienbrief mit Zugriff auf WebComposition/DGS
8.8 XSLT - XAML User Interface für die Adresssuche
8.9 Phidget Sensoren
8.10 XSD Phidgets
8.11 Phidget URI-Template
8.12 Visual Basic Script für Excel und Informationspace Phidgets

Abbildungsverzeichnis

Literaturverzeichnis

Abstract

Im Rahmen dieser Arbeit entsteht eine Infrastruktur von Webservices, auf deren Basis die Konzeptionierung und Implementierung von Informationsflüssen zwischen verteilten Systemen vollständig durch ein Datenmodell, ein UserInterface-Design (dt. Benutzerschnittstellenentwurf) und der Definition von Business Rules (dt. Geschäftsregeln) (BR) beschrieben wird.

1 Einleitung

Die Informatik im Sinne einer Ingenieurwissenschaft steht auf den Säulen der Technischen, Praktischen und Theoretischen Informatik und beschäftigt sich mit Forschung, Entwicklung und Produktion von Informationssystemen. Um die Abgrenzung der Informatik als Wissenschaft von der landläufigen Vorstellung, Informatik beschränke sich auf Computer und deren Anwendung, zu verdeutlichen, können die trefflich gewählten Worte des niederländischen Informatikers Edsger Wybe Dijkstra dienen:

”InderInformatikgehtesgenausowenigumComputerwieinderAstro- nomie um Teleskope.“ [Edsger W. Dijkstra]

Diese Arbeit ist vordergründig im Bereich der Praktischen Informatik ein- zugliedern, da der Schwerpunkt auf der Konzeptionierung einer Serviceinfra- struktur liegt. Aspekte der Technischen Informatik wie bspw. unterschiedliche Plattformen oder Übertragungstechniken werden aufgezeigt und diskutiert, ha- ben aber dank modernster Technologien auf die grundsätzliche Funktionalität keinen Einfluss. Der Bereich Theoretische Informatik wird letztlich nur für ei- ne einfache Laufzeitbetrachtung tangiert. Ausdrücklich 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ührung in das Gebiet der Geschäftsprozesse (engl. Business Process) gegeben. Anschließend wird die Motivation dieser Ar- beit vorgestellt und mit konkreten Zielvorstellungen, in Form von Anwendungs- szenarien, charakterisiert. Abschließend bietet dieses Kapitel einiges Vorweg und fasst die Vorgehensweise und damit den Aufbau dieser Arbeit zusammen.

1.1 Geschäftsprozesse

Ein Geschäftsprozess ist die Abbildung eines Arbeitsablaufs, der sich aus ein- zelnen Aktivitäten zusammensetzt. Für die Erstellung einer solchen Abbildung können verschiedene Formen gewählt werden, von einer einfachen Checkliste für die Wartung von Industrieanlagen bis hin zu komplexen grafischen Struk- togrammen. Das Ziel der Definition von Geschäftsprozessen besteht darin, die Arbeitsabläufe zu vereinheitlichen, um eine effiziente Bearbeitung zu gewähr- leisten und jederzeit den aktuellen Stand der Prozesse zu dokumentieren. Für eine Zertifizierung nach DIN EN ISO 9001 bilden Geschäftsprozesse ebenfalls eine wesentliche Grundlage Konkret besteht ein Geschäftsprozess aus einem definierten Anfang und einem definierten Ende, wobei die einzelnen Aktivitäten zwischen Anfang und Ende einen unterschiedlichen Verlauf nehmen können. Initiiert wird ein Geschäfts- prozess durch ein Ereignis, das durch so genannte Akteure hervorgerufen wird. Akteure wiederum können Personen oder Systeme sein, die am Arbeitsablauf beteiligt sind. Geschäftsprozesse 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ür einen Geschäftsprozess sind nach [24] unter anderem die folgenden:

- Komplexität Die Komplexität eines Geschäftsprozesses ist bestimmt durch die Anzahl der Aktivitäten und deren Abhängigkeiten. Auch die Anordnung der Aktivitäten in Form einer sequentiellen oder parallelen Abarbeitung wirkt sich auf die Komplexität aus.
- Detaillierungsgrad Der Detaillierungsgrad beschreibt die Möglichkeit einer Zerlegung des Gesamtprozesses in einzelne Teilprozesse.
- Grad der Arbeitsteilung Der Grad der Arbeitsteilung repräsentiert die Anzahl der am Prozess beteiligten Akteure und deren Koordinationsbedarf.

1.2 Motivation

Je kürzer und schneller Geschäftsprozesse sind, desto besser und profitabler ist das Geschäft. Bernard Favre-Bulle stellt in seinem Buch ”Automatisierung komplexer Industrieprozesse“^[25] fest, dass ein schnelles Reaktionsvermögen auf veränderte Ausgangssituationen mit einem flexiblen und innovationsfreu- digen Unternehmensmanagement die erfolgreichen Firmen der Gegenwart und vermutlich auch der Zukunft auszeichnet. Größe spiele dabei eine weniger ent- scheidende Rolle, sodass gesagt werden kann: ”...inZukunftwerdennichtdie großen Fische die kleinen fressen, sondern die schnellen Fische die langsamen.“ Die informationstechnische Abwicklung von Geschäftsprozessen erfolgt dabei zu einem großen Teil mithilfe von Kommunikation, Datentransfer und Entscheidungsfindung während der Abarbeitung dieser Geschäftsprozesse. Um der Vielfalt an möglichen Geschäftsprozessen und deren sich ändernden Anforderungen schnell gerecht zu werden, bedarf es einer skalierbaren Servicelandschaft, auf deren Basis die Abbildung der zugrundeliegenden Informationsflüsse durch Komposition einzelner Services erfolgt.

Die Spezifikation von Geschäftsprozessen selbst soll so abstrahiert werden, dass diese durch ein Datenmodell, dem User-Interface-Design und den Geschäftsregeln vollständig 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öglicht.

1.3 Anwendungsszenario: verteiltes Sensorennetzwerk

Ein Anwendungsszenario soll darin bestehen, die Messdaten verschiedener Sen- soren wie bspw. des Temperatursensors einer Central Processing Unit (CPU) 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ösen. Die Architektur eines solchen Systems könnte wie in Abbildung 1 dargestellt aussehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Sensorennetzwerk.

Die zugrundeliegenden Informationen in Form der Messdaten sollen also in ver- schiedenen Medien dargestellt werden. Eine Realisierung soll lediglich durch Spezifikation des Datenmodells, dem User-Interface (dt. Benutzerschnittstelle) (UI)-Design und der zu verwendenden Geschäftslogik erfolgen. Die Kommuni- kation kann auf verschiedenen technischen Realisierungen basieren. Eine Be- nachrichtigung bei der Tangierung von Grenzwerten kann bspw. per E-Mail, Short Message Service (SMS), Instant Messaging (IM) oder Atom Syndicati- on 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 je- doch stets ein und dieselben Informationen zugrunde, nämlich die Messwerte der verteilten Sensoren.

1.4 Anwendungsszenario: Startup-Center Diplomarbeit

Ein weiteres zu dieser Arbeit passendes Anwendungsszenario ist der Geschäfts- prozess für die Bearbeitung einer Diplomarbeit. Ausgehend von der Themen- findung über die Literaturrecherche bis hin zu mündlichen Konsultationen, schriftlichen Entwürfen und einzelnen Meilensteinen ist die Diplomarbeit nach erfolgreicher Verteidigung im Idealfall bestanden. Auch hier treten verschie- dene Akteure in Szene und tauschen Informationen aus. Gegenüber dem Sen- sorennetzwerk handelt es sich allerdings um einen grundlegend anderen Ge- schäftsprozess. Um auch den zeitlichen Verlauf darzustellen, wird zur Veran- schaulichung in Abbildung 2 ein Sequenzdiagramm gewählt.

Die Abbildung eines solchen Geschäftsprozesses erfordert bereits die Integra- tion bestehender Abläufe. So wird die Kommunikation mit dem Prüfungsamt bspw. lediglich durch Verwendung eines Portable-Document-Format (PDF)- Formulars erfolgen. Dieses ist ausgefüllt und unterschrieben beim jeweiligen Sachbearbeiter einzureichen. Nach Genehmigung durch den Prüfungsausschuss und dem prüfenden Professor erfolgt eine Bestätigung der Aufgabenstellung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Sequenz - Diplomarbeit.

sowie die Festlegung des endgültigen Abgabetermins. Die Recherche nach Lite- ratur erfolgt ebenfalls durch ein bereits vorhandenes System der Universitäts- bibliothek namens Online Public Access Catalogue (OPAC). Terminvereinba- rungen mit dem jeweiligen Betreuer erfolgen in der Regel per E-Mail. All diese Möglichkeiten der Kommunikation sollen hier zu einem zentralen Geschäfts- prozess gebündelt werden. Als Designvorlage wird das Microsoft Startup-Center1 verwendet. Die übersichtliche Strukturierung des zeitlichen Verlaufs im Hea- der sowie die Möglichkeit der jeweils zulässigen Aktionen im aktuellen Kontext durch das linke Menü garantieren eine intuitive Bedienung.

1.5 Ziel der Arbeit

Wie bereits aus der Motivation dieser Arbeit hervorgeht wird der Informa- tionsfluss zwischen verteilten Systemen auf Basis einer Datenmodellbeschrei- bung, des UI-Designs und der Definition von Geschäftsregeln spezifiziert. Ziel ist dabei, dass diese drei Bereiche sowohl von den Anwendern als auch von den Entwicklern einfach spezifiziert werden können, ohne dass die Anwender technisches Verständnis und die Entwickler fachliche Kompetenz einbringen müssen. Die Kommunikationslücke zwischen Entwickler und Anwender soll somit minimiert werden, um den Entwicklungsprozess der informationstechnischen Integration weitestgehend zu automatisieren.

Der Ablauf zur Spezifikation der Informationsflüsse soll stets nach folgendem Schema ablaufen:

- Datenbeschreibung Welche Daten werden benötigt 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öglichkeiten werden spezifiziert. Ansichten können für verschiedene UIs in verschiedenen Beschreibungssprachen wie Extensible Markup Language (XML), Hypertext Markup Language (HTML), Extensible Application Markup Language (XAML), aber auch für Endanwendungen wie Microsoft Word oder Excel spezifiziert werden.
- Business Rules Die Definition der Geschäftsregeln beinhaltet, wie die unterschiedlichen UI-Bestandteile miteinander verknüpft 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ühren.

1.6 Aufbau der Arbeit

Die bisherigen Kapitel beinhalteten die Einführung in das Gebiet der Geschäftsprozesse und die damit einhergehende Motivation sowie die Zielsetzung dieser Arbeit, eine informationstechnische Abbildung so effizient, flexibel und einfach wie möglich zu gestalten.

Im folgenden Kapitel 2 werden Voraussetzungen und Grundlagen geschaffen, um ein einheitliches Verständnis der verwendeten Begrifflichkeiten voraussetzen zu können. Dieses Grundlagenkapitel wurde bewusst knapp gehalten, um dem Leser einen Überblick 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ösungen und deren Einsatzmöglichkeiten im Rahmen der vorliegenden Anwendungssituationen. Vor- und Nachteile dieser Systeme werden aufgezeigt und diskutiert, um zusammenfassend festzustellen, warum in dieser Arbeit eine eigene Lösung favorisiert wird.

In Kapitel 4 erfolgt der Systementwurf. Ausgehend von einer Representational- State-Transfer (REST)-Architektur und der diesbezüglich bereits durchgeführ- ten Überlegungen und Ansätze mit dem WebComposition/Data Grid Service (DGS) wird die grundlegende Architektur schematisiert und erläutert. Darauf aufbauend werden weitere beteiligte Services sukzessive ausgebaut, um Funk- tionalität 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ätzlich keine Rolle, da ausschließlich Standard- und systemunabhängige Technologien verwendet werden.

Kapitel 6 beinhaltet die Testfälle 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ührt, 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.

2 Grundlagen

Im Rahmen dieser Arbeit werden zahlreiche Technologien eingesetzt, deren grundlegende Funktionsweisen zu Beginn kurz erläutert werden sollen. Somit wird einerseits ein einheitliches Verständnis über deren Einsatz und Funktionsweise geschaffen. Andererseits wird ein Vokabular eingeführt, 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ächst es in rasanter Ge- schwindigkeit und mit ihm die Vielfalt an Anwendungen innerhalb des WWW. Die damit einhergehende Innovationsgeschwindigkeit bedingt den ständigen Anpassungs- und Erweiterungsbedarf von Web-Anwendungen, wodurch Aspekte des Software-Engineerings auf diese neue Art der Anwendungsentwicklung übertragen 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 Wieder- verwendungsmanagement, eine Komponententechnologie und einem Evoluti- onskonzept ^[22] für Web-Anwendungen. Das Vorgehensmodell beschreibt hier- bei in Anlehnung an Entwicklungsmodelle der klassischen Softwareentwicklung nicht die einzelnen Entwicklungsphasen, sondern adaptiert als offenes Vorge- hensmodell bereits existierende Softwareentwicklungsmodelle wie bspw. das Wasserfallmodell oder objektorientierte Entwicklungsmodelle.

Ausgangspunkt für das Wiederverwendungsmanagement ist das sogenannte Komponentendilemma. Es besagt, dass mit steigender Komplexität zwar die Wahrscheinlichkeit steigt, eine passende Komponente zu besitzen, aber gleich- zeitig auch der Aufwand steigt, um die benötigte Komponente zu finden. Das Problem besteht darin, eine geeignete Repräsentation der Komponente zu fin- den, um eine Suche in der Menge von Komponenten zu unterstützen. Die Lösung dieses Problems sind Metadaten. Mittels Metadaten können Kompo- nenten in unterschiedlichster Weise beschrieben werden, sodass auch das Auf- finden in einer Wiederverwendungssituation gewährleistet ist.

Die Komponententechnologie beschreibt im Wesentlichen ein Abstraktionsni- veau der Sichtweise auf Komponenten und erfolgt mithilfe der WebCompo- sition Markup Language (WCML), einer Anwendung der Extensible Markup Language (XML). Innerhalb von WCML werden Komponenten als einheit- liche 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 ändernden Systeman- forderungen und der damit verbundenen Anpassung von Anwendungen und Komponenten. Hierbei wird eine leere Web-Anwendung ohne Funktionalität um einzelne Komponenten erweitert, welche wiederum einzeln ausgetauscht oder erweitert werden können. 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 Teil- menge der bereits 1986 von der International Organisation for Standardization (ISO) standardisierten, plattformunabhängigen Auszeichnungssprache Stan- dard Generalized Markup Language (SGML)2 dar. SGML ist weiterhin in der Europäischen 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äischen Kernforschungszentrum (CERN) in Genf gegründet. Das W3C ist kein offizielles Gremium wie die ISO und kann daher formell auch keine Standards definieren. Aufgrund der breiten Akzeptanz des W3C bei Softwa- reentwicklern, Forschern und Endbenutzern werden deren Empfehlungen (Re- commendations) aber als De-facto-Standard anerkannt ^[8]. Ein erklärtes Ziel des W3C besteht darin, das World Wide Web maßgeblich durch die Veröffent- lichung 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 be- liebtesten Austauschformat für Dokumente und wird heute in verschiedensten Bereichen eingesetzt.3 Ein einfaches XML-Dokument sieht z.B. wie folgt aus:

Abbildung in dieser Leseprobe nicht enthalten

Zur Vermeidung von Konflikten bei der Namensgebung von XML-Elementen können sogenannte Namespaces innerhalb eines XML-Dokumentes eingebunden werden. Diese beinhalten eine Sammlung der jeweils zulässigen Elementund 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:

Eine Document Type Definition (DTD) beschreibt das zulässige Markup inner- halb eines XML-Dokumentes. Auch die Verschachtelung von Elementen oder deren Häufigkeitsbeschränkungen und zulässige Attribute können 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üllt ein XML-Dokument alle in der DTD angegebenen Regeln, so wird es als gültig bezeichnet und kann durch die Anwendung verarbeitet werden.

XML Schema Definition (XSD) ist eine Empfehlung des W3C und bietet ge- genüber der einfachen DTD eine wesentlich mächtigere und ausdrucksstärkere Validierung von XML-Dokumenten ^{[14] [15] [16]}. Wie auch bei der DTD gilt ein XML-Dokument als gültig, wenn es alle in XML-Schema definierten Vor- gaben erfüllt. Im Gegensatz zur DTD bietet XML Schema auch Konstrukte zur Kontrolle von Formaten und Datentypen der XML-Elemente und Attribu- te. 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ür DTDs waren noch spezielle Editoren nötig 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ür 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 Übereinstimmung das Template dieser Regel in die Baumstruktur des XML-Ausgabe-Dokumentes.

Die XML Path Language (XPath) entspricht nicht der XML-Syntax, wird aber für die Adressierung von XML-Elementen verwendet. Mithilfe von XPath können Ausdrücke geschrieben werden, um innerhalb von XML-Dokumenten bspw. alle Elemente mit dem Markup 〈Name〉 zu referenzieren [10]. Die Na- vigation innerhalb des XML-Dokumentes erfolgt hierbei auf Grundlage einer Baumstruktur und der Angabe eines Pfadausdruckes. Noch mächtigere Werk- zeuge für die Navigation auch über Dokumentengrenzen hinweg ermöglicht die Verwendung von XML Pointer Language (XPointer) oder XML Linking Language (XLink). Diese vereinen das Prinzip der Navigationsmöglichkeiten von XPath-Ausdrücken und des Referenzierens von XML-Dokumenten durch URIs. Weiterhin finden XPath-Ausdrücke bei der Definition von Regeln inner- halb der XSL Anwendung ^{[11] [12]}.

2.3 Representational State Transfer

Der Begriff REST wurde durch die Dissertation von Roy Thomas Fielding, einem der Hauptautoren des Hypertext-Transfer-Protocol (HTTP)4, im Jahre 2000 geprägt und als eine der Schlüsseltechnologien für 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ür 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ür den Server unabhängig von anderen Anfragen. Alle für die Bearbeitung nötigen Informationen müssen in einer Anfrage vorhanden sein. Nachdem eine Anfrage durch den Server bearbeitet und dessen Response an den Client zurück geschickt wurde können 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 beantworten werden müssen, sondern gegebenenfalls bereits durch den Client Cache beantwortet werden können.
- einheitliche Schnittstelle Wichtigste Bedingung einer REST-Architektur ist eine der Software- entwicklung entnommene Anforderung der generalisierten Schnittstellen zwischen einzelnen Komponenten. Diese Schnittstelle basiert auf dem HTTP-Protokoll und ist damit hauptsächlich für die Anwendungsdomäne von Web-Anwendungen interessant. Für 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önnen. Dadurch wird einerseits die Komplexität reduziert, andererseits entsteht Overhead, wenn Nachrichten durch mehrere Schichten geleitet werden müssen.
REST fordert, dass die Funktionalität des Clients durch den Download und das Ausführen von Applets oder Skripten erweitert werden kann. Dies reduziert die Anforderungen an das Client-System, da keine besonderen Systemvoraussetzungen geschaffen werden müssen.

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ängig voneinander interagierenden Systemen. Ziel dieser Architektur ist genau diese Unabhängigkeit der Komponenten und generalisierten Schnittstellen.

HTTP selbst stellt hierbei das Anwendungsprotokoll im TCP/IP-Protokoll- stapel in Form einer zustandslosen Client-Server-Kommunikation dar. Die Kom- munikationseinheiten 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ält Informationen wie Kodierung und Typ des Contents. Das Ziel einer Request wird in Form eines Uniform Resource Identifier (URI)5 adressiert und als Ressource bezeichnet.

Allein der Zugriff auf Ressourcen im Web stellt aber noch keine Webanwen- dung dar und so müssen neue Ressourcen erstellt oder bestehende Ressourcen manipuliert werden. An diesem Punkt kommt eine entscheidende Schnittstelle ins Spiel, über welche die Aktionen an den Ressourcen ausgeführt werden, die durch die URI identifiziert wurden. Häufig wurde diese Schnittstelle für jede Ressource in Form von Parametern innerhalb der URI kodiert und vom jewei- ligen Entwickler je nach Anforderung frei erfunden. Aktuelle Diskussionen mit dem Ziel der Standardisierung dieser Schnittstelle sollen die Orchestrierung von Diensten über Plattform-, Anwendungs- und Unternehmensgrenzen hin- weg ermöglichen. Herauskristallisiert haben sich bisher zwei Lager: einerseits Vertretern des sogenannten Simple-Object-Access-Protocol (SOAP), anderer- seits die Anhänger der REST-Architektur ^[5].

Der Unterschied besteht im Wesentlichen darin, dass SOAP ein eigenes Netz- werkprotokoll darstellt und somit sowohl auf dem Client als auch auf dem Ser- ver einen eigenen Stack für dessen Nutzung benötigt. REST hingegen stellt ein einheitliches Interface für nicht typisierte Ressourcen zur Verfügung, welches vorhandene, etablierte und gut verstandene Technologien in maschinenlesba- rer Form zur Verfügung stellt. Andererseits ist der Aktionsvorrat von REST wegen der fest definierten HTTP-Verben auf diese beschränkt. Demgegenüber können innerhalb von SOAP beliebige Methoden frei definiert werden und bie- ten somit mehr Flexibilität, allerdings zu Lasten der Komplexität.

Für das Vorhaben dieser Arbeit liegen die Vorteile einer REST-Architektur in Bezug auf den in der Einleitung angesprochenen Bereich der technischen Infor- matik vor allem darin, dass diese Architektur auf dem am weitesten verbreite- ten Anwendungsprotokoll HTTP basiert und somit dessen bewährte Mechanis- men für bspw. Caching, Authentisierung sowie Datenschutz und Datensicher- heit genutzt werden können. Die HTTP-Unterstützung ist im Open Systems Interconnection-Reference-Model (OSI) der ISO in der Anwendungsschicht an- gesiedelt und besitzt damit einen relativ hohen Abstraktionsgrad. Aufgrund der Verbreitung gibt es aber gerade für dieses Protokoll handelsübliche Layer 4 bis 7 Switches, um z.B. ein Quality of Service (QoS) zu realisieren. Bei- spielsweise könnten bei Google, zu dessen häufigsten Anfragen GET gehört, Suchanfragen auf Basis dieser Netzwerktechnik auf andere dedizierte Systeme umgeleitet werden anstatt auf PUT-Anfragen der Google Robots, um neue Sei- ten in den Index aufzunehmen. Ebenso sind sicherheitstechnische Aspekte mit derartiger Netzwerktechnik leicht zu realisieren, da eine GET-Anfrage nur le- senden Zugriff benötigt und somit Schreibrechte lediglich für PUT, POST und DELETE zur Verfügung stehen müssen. Weiterführende Literatur zum Thema Sicherheit im WebComposition-Ansatz ist auf der Homepage6 zum WebCom- position/idFS aufgeführt.

2.4 Ressource Description Framework

Metadaten, auch Metainformationen genannt, sind im wahrsten Sinne des Wor- tes 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 Kilo- gramm 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 be- schreibt 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 darge- stellt werden kann, sondern auch hochperformante Lösungen unter dem Namen RDF Triple Stores existieren und zumeist auf relationalen Datenbanken basie- ren. Das RDF-Modell besteht aus den folgenden Elementen ^[17]:

- Ressourcen Alles, was durch RDF-Ausdrücke beschrieben wird, ist eine Ressource. Ressourcen können 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ür die Beschreibung von Ressourcen. Jede Eigenschaft hat eine spezielle Bedeutung und definiert deren mögliche Werte.
- Ausdrücke Eine Ressource mit einer benannten Eigenschaften und deren Wert ist ein RDF-Ausdruck. Diese drei Bestandteile werden auch als Subjekt, Prädikat und Objekt bezeichnet.

Das Potenzial dieser Darstellung von Beziehungen zwischen den unterschied- lichsten Informationen bildet die Grundlage aktueller Diskussionen rund um das Semantik-Web. Der Umgang mit Subjekt, Prädikat und Objekt lässt Zu- sammenhänge ausdrücken und erkennen, wie diese auch im Sprachgebrauch verwendet werden. Eine Datenverarbeitung, welche bisher nur syntaktische Regeln berücksichtigte, kann nun auch mit dem Wissen über Beziehungen zwischen den Daten ausgestattet werden und somit Informationen über die Bedeutung der Daten automatisiert verarbeiten. Am Beispiel dieser Diplom- arbeit sieht der RDF-Ausdruck für die Beziehung zum Autor wie folgt aus:

Subjekt = http : //www.diplomarbeiten.de/20081101

Prädikat = Autor

Objekt = RalphSommermeier

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

Abbildung in dieser Leseprobe nicht enthalten

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ädikat Objekt. Komplexere Strukturen können durch Referenzierung des Objektes auf weitere RDF-Ressourcen gebildet wer- den und sehen an oben gewähltem Beispiel wie folgt aus: Die Möglichkeiten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Graphische Darstellung komplexer RDF-Beziehungen.

der RDF-Syntax gehen weit über diese einfachen Szenarien hinaus, deren Ver- tiefung über 50 Seiten Originalspezifikation erfordern. Zur Abhilfe existieren unterschiedliche auch schon bekannte Formen, welche den Gebrauch von RDF vereinfachen. Im Folgenden werden zwei davon näher vorgestellt: die zwei- te 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

(Typ-2-Grammatiken in der Chomsky-Hierarchie), die syntaktische Re- geln über die Zusammensetzung der Literale enthält. Die Regeln beste- hen aus einer linken und rechten Seite, die durch ::= getrennt werden. Auf der linken Seite sind ausschließlich sogenannte Nichtterminalsymbole zulässig. Demgegenüber können auf der rechten Seite Nichtterminalsym- bole und Terminalsymbole kombiniert auftreten. Alle Nichtterminalsym- bole werden durch umschließende eckige Klammern gekennzeichnet und es existiert eine Regeln, um diese aufzulösen. Eine triviale Beschreibung des Kerns von RDF sieht in der BNF wie folgt aus:

Abbildung in dieser Leseprobe nicht enthalten

- Notation3 - Mime Type text/rdf+n3

RDF-Ausdrücke bestehen jeweils aus Subjekt, Prädikat und Objekt. In Notation3 schreibt man diese einzelnen Sätze jeweils mit einem Punkt am Ende. Mehrere Sätze zum selben Subjekt oder mehrere Objekte zu einem Subjekt können durch das Semikolon bzw. ein Komma getrennt werden. Am Beispiel sieht dies wie folgt aus:

Abbildung in dieser Leseprobe nicht enthalten

Unabhängig von der verwendeten Sprache zur Beschreibung von RDF-Aus- drücken müssen auch die für eine Ressource zulässigen Eigenschaften spezifiziert werden. Innerhalb von RDF werden diese einfach verwendet, aber es wird nicht näher darauf eingegangen. Diese Spezifikation, ebenfalls auf XML basierend, sind in ^[27] nachzulesen.

3 Related Work

In diesem Kapitel werden die Möglichkeiten evaluiert, auf deren Basis sich die Aufgabenstellung realisieren lässt. Grundsätzlich existieren drei prinzipi- elle Herangehensweisen zur Lösung 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, spezi- ell auf die Anwendungsdomäne zugeschnittener Softwarelösungen. Je spezieller bzw. je kleiner der Markt für die jeweiligen Anwendungsdomänen ist, desto we- niger Anbieter existieren und desto teurer ist in der Regel der Einsatz bzw. die Entwicklung solcher Softwaresysteme. Damit einhergehende Probleme beste- hen vorallem darin, dass bei sich ändernden Geschäftsabläufen 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ängig von der jeweiligen Anwendungsdomäne Geschäftsprozesse zu definieren und abzuarbei- ten.

Ein weiterer Ansatz ist die Verwendung sogenannter Content-Management- Systeme (CMS). Diese sind im Gegensatz zu den Business-Process-Management (BPM) Systemen nicht für die Abarbeitung von Geschäftsprozessen vorgese- hen, sondern lediglich für die Visualisierung und Pflege von Inhalten durch strikte Trennung von Content und Layout. Anders ausgedrückt stellen CMS, Workflows für das Management von Inhalten zur Verfügung. 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öglichen, die nicht über technisches Hintergrundwissen über Hypertext Markup Language (HTML), Cascading Style Sheets (CSS) oder HTTP verfügen.

3.1 Workflow Management

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

”Theautomationofabusinessprocess,inwholeorpart,duringwhichdo- 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äftsprozess, so wie dieser bereits in der Einleitung beschrieben wurde. Daher rührt auch die analog ver- wendete Bezeichnung Business Process. WfMS bzw. BPMS sind folglich die Sy- steme, welche eine automatisierte Abarbeitung dieser Workflows ermöglichen.

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

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Workflow Reference Model.

Abarbeitung sind unter anderem die folgenden:

- Aktivitäten Einzelne Schritte des Geschäftsprozesses werden durch einzelne Aktivitäten im Workflow dargestellt. Der Übergang von einer Aktivität zur anderen erfolgt dabei über eine fest definierte Schnittstelle.
- Informationsfluss Der Informationsfluss findet zwischen den einzelnen Aktivitäten eines Workflows statt. Den beteiligten Akteuren müssen zu jedem Zeitpunkt die für die Bearbeitung notwendigen Daten zur Verfügung stehen.
- Rollen Aktivitäten werden innerhalb eines Workflow den dafür vorgesehenen Rollen zugewiesen. Dabei sind Rollen Mengen von Akteuren mit be- stimmten Fähigkeiten, die zur Bearbeitung einer Aufgabe nötig sind. Es erfolgt somit eine Automatisierung der Ressourcenplanung und Ver- teilung.
- EAI Die Anwendungsintegration ist ein wichtiger Bestandteil, um bereits exi- stierende Abläufe im Workflow zu integrieren. In der Vergangenheit ha- ben sich bereits unterschiedliche Applikationen und Datenbanken in Un- ternehmen etabliert und müssen in den Workflows integriert werden, um einen durchgängigen Datenaustausch zu ermöglichen. Es werden die Formen Application to Application (AtoA), Business to Business (BtoB) und Business to Consumer (BtoC) unterschieden, entsprechend der in- teragierenden Akteure.

Eine Klassifikation von Workflows nach Joachim Müller ^[24] untergliedert diese in den allgemeinen Workflow, den fallbezogenen Workflow und den Ad-Hoc- Workflow. Die Modellierbarkeit bzw. die Automatisierbarkeit nimmt in der gegebenen Reihenfolge ab. Ein Ad-Hoc-Workflow ist demnach nicht zu modellieren, weil die einzelnen Schritte nicht vorhersagbar sind und situationsabhängig entschieden werden müssen.

Zusammenfassend kann man WfMS oder auch BPMS als eine Sammlung ver- schiedener Tools und Techniken für die Prozessmodellierung, die Servicekom- position (auch Orchestrierung genannt), die EAI und einer Process Enginge für die Abarbeitung der Workflows mit Controlling-Mechanismen, auffassen. Eine von der Nomina GmbH veröffentlichte Liste umfasst laut Stand 2006 über 120 Anbieter von BPM-Systemen allein für den deutschsprachigen Raum ^[3]. Erhebungen zufolge, die die IIR Deutschland GmbH auf dem am 09./10. Oktober 2007 durchgeführten 6. IIR Forum veröffentlichte, erstreckt sich das Interesse für BPM-Lösungen über die in Abbildung 6 aufgeführten Branchen ^[4].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Interessentenstruktur 6. IIR Forum.

Daraus wird ersichtlich, dass der Markt an BPM-Lösungen so breit gefächert und unstrukturiert ist, dass es schwer ist, diesen zu überblicken. Hinzu kommt, dass die verwendeten Schlagworte der einzelnen Hersteller zugunsten individu- eller Werbestrategien uneinheitlich sind, wodurch es zu Missverständnissen bei den Kunden kommen kann, was wiederum verunsichernd oder gar ab- schreckend wirken kann. Business Process Execution Language (BPEL), Busi- ness Process Modelling Language (BPML), Business Process Modelling No- tation (BPMN), XML Process Definition Language (XPDL) oder Workflow XML (WfXML), um nur einige zu nennen, sind Modelle und Sprachen, die in diesem Zusammenhang häufig genannt werden. Global Player dieses Mark- tes sind IBM, Microsoft, Oracle und SAP welche laut Gartner aktuell massiv an Marktanteilen gewinnen und diesen von 20 Prozent Anfang 2007 auf über 60 Prozent Ende 2007 durch Zukäufe ausgebaut haben [29]. Als Ursache für deren zunehmend marktbeherrschenden Stellung kann die Tatsache gesehen werden, dass kleinere BPMS-Anbieter meist nur einzelne Tools anstelle kompletter BPM-Suiten vertreiben. Auch die Integration gängiger Anwendersoftware wird durch die in diesem Umfeld ebenfalls gut positionierten Hersteller mit der eigenen Software verwoben.

Folglich sind derartige Systeme meist ”oversized“undkönnennurdurchfach- kundiges Personal integriert und erweitert werden. Das verursacht wiederum Kosten, welche ein angemessenes Return on Investment (ROI) nur für finanziell entsprechend ausgestattete Unternehmen gestatten.

3.2 Content Management

Die wörtliche Übersetzung von Content Management lautet ”Verwaltungvon Inhalten“ und beschreibt genau dessen Einsatzgebiet, jedoch hat sich im Fach- vokabular der englische Begriff etabliert. Content-Management unterstützende Softwaresysteme werden als CMS bezeichnet. CMS stellen eine Untergruppe der Autorensysteme dar. Autorensysteme sind ganz allgemein auf das Zusam- mensetzen multimedialer Informationseinheiten spezialisiert. Eine Definition des Begriffes Content Management wird aus ^[23] übernommen:

”UnterContent-Managementverstehtmandiesystematischeundstrukturier- te Beschaffung, Erzeugung, Aufbereitung, Verwaltung, Präsentation, Verarbei- tung, Publikation und Wiederverwendung von Inhalten.“

Demnach stellen CMS Anwendungen dar, auf deren Basis Content Manage- ment mithilfe der Informationstechnik betrieben werden kann. Eine einheit- liche Architektur dieser Systeme ist nicht vorhanden. Dennoch sind einzelne Bestandteile in allen CMS wiederzufinden. So ist z.B. der Content Life Cy- cle ein elementarer Bestandteil aller CMS und stellt sozusagen den Business Process für die Erstellung von Content dar. Ausgehend von der Recherche über die Erstellung, Kontrolle, Freigabe, Publikation und Archivierung von Inhalten sind in den einzelnen Stadien unterschiedliche Akteure beteiligt. Ein weiteres grundlegendes Architekturmerkmal besteht in der strikten Trennung zwischen Content und Layout. Diese Voraussetzung sorgt für die Wiederver- wendung von Content auch in unterschiedlichen Medien. Als Beispiel seien hier die Print-, Audio- oder visuellen Medien genannt. WCMS hingegen sind speziell für den Einsatz von Medien im Internet entwickelt und verfügen meist nur über diesen einen Publikationskanal. Auch in diesen spezialisierten Systemen sind Elemente des Workflow Managements enthalten. Verschiedene Inund Exportschnittstellen sorgen für die automatisierte Datenbeschaffung bzw. Datenbereitstellung. Auch Aspekte der Personalisierung entsprechend eines Rollenkonzeptes für die Verwaltung sensibler Daten finden Berücksichtigung. Ein weiterer Aspekt ist die Art und Weise, wie Content zur Verfügung gestellt wird. Dabei spielt die Dynamik der Inhalte eine entscheidende Rolle. Eine Klassifikation wird in ^[30] wie folgt vorgenommen:

- Dynamische Systeme Bei Anfragen an das Content-Management-System werden deren Ant- worten immer neu erstellt. Diese Verfahrensweise ist für sich ständig ändernde Inhalte vorgesehen und geht zulasten der Serverressourcen. Ty- pische Einsatzgebiete sind bspw. die Publikation von Wetterinformatio- nen oder Börsenkursen.
- Statische Systeme Bei den statischen Content-Management-Systemen liegen für alle Anfra- gen fest definierte Inhalte vor. Diese werden gelesen und ohne weitere Bearbeitung an den Client gesendet. Diese Systeme haben den Vorteil, viele Zugriffe zu bewältigen, sind aber dem gegenüber nicht zu persona- lisieren.
- Hybride Systeme Diese Systeme stellen die Kombination von dynamischen und statischen Systemen dar. Die Vorteile beider Verfahren werden vereint und so können dynamische Inhalte zur Laufzeit erstellt und mit den vorliegenden stati- schen Inhalten ergänzt werden. Somit wird ein Optimum an Performance erreicht.

Der Markt für Web Content Management bietet ebenfalls zahlreiche Lösun- gen. Die Vielfalt an freien und kommerziellen WCMS sowie einfachen und komplexen Lösungen machen die Wahl eines konkreten Systems nicht gerade einfach. In ^[31] wird eine weitere sinnvolle Klassifikation in Small, Midsize und Enterprise WCMS verwendet. Der Klassifikator hierbei ist der Umfang des zu verwaltenden Inhalts und die Anzahl der beteiligten Redakteure. Bei En- terprise WCMS kommen zudem noch Import- und Export-Schnittstellen zum Einsatz, um Inhalte auch für externe Applikationen zur Verfügung zu stellen. Folgende Tabelle beinhaltet eine kleine Auswahl bekannter Content-Manage- ment-Systeme.

[...]

---

¹ Elliotte Rusty Harold, W. Scott Means: XML in a Ntushell O’Reilly, 2005.

² Roy Thomas Fielding: Architectural Styles and the Design of Network-based Software Architectures UNIVERSITY OF CALIFORNIA, 2000.

³ Kersteb Bassow: ISIS Business Integration Special: Edition 1-2006 Nomina GmbH, 2006.

⁴ IIR Deutschland GmbH: 6. IIR Forum Business Process Ma- nagement http://www.bpm-events.com/de/sales tn-struktur.htm, 23.05.2007.

⁵ Software und Support Verlag GmbH: Entwickler Magazin Ausgabe 5.07, 2007.

⁶ Karl Eilebrecht, Dr. Gernot Starke: Patterns kompakt Spektrum Akademischer Verlag, 2004.

⁷ E. Gamma, R. Helm, R. Johnson, J. Vlissides: Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software AddisonWesley, 1995.

⁸ Rainer Eckstein, Silke Eckstein: XML und Datenmodellierung dpunkt.verlag GmbH, 2004.

⁹ Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler: Extensible Markup Language (XML) 1.0 W3C Recommendation http://www.w3.org/TR/2000/REC-xml-20001006, 06.10.2000.

¹⁰ James Clark, Steve DeRose: XML Path Language (XPath) Version 1.0 W3C Recommendation http://www.w3.org/TR/1999/REC- xpath-19991116, 16.11.1999.

¹¹ Paul Grosso, Eve Maler, Jonathan Marsh, Norman Walsh: XPointer Framework W3C Recommendation http://www.w3.org/TR/2003/REC-xptr-framework-20030325, 25.03.2003.

¹² Steve DeRose, Eve Maler, David Orchard: XML Lin- king Language (XLink) Version 1.0 W3C Recommendation http://www.w3.org/TR/2001/REC-xlink-20010627/, 27.06.2001.

¹³ Tim Bray, Dave Hollander, Andrew Layman: Namespaces in XML W3C Recommendation http://www.w3.org/TR/1999/REC-xml- names-19990114/, 14.01.1999.

¹⁴ David C. Fallsid: XML Schema Part 0: Primer W3C Recommenda- tion http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/, 02.05.2001.

¹⁵ Henry S. Thompson, David Beech, Murray Maloney, Noah Men- delsohn: XML Schema Part 1: Structures W3C Recommenda- tion http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/, 02.05.2001.

¹⁶ Paul V. Biron, Ashok Malhotra: XML Schema Part 2: Data- types W3C Recommendation http://www.w3.org/TR/2001/REC- xmlschema-2-20010502/, 02.05.2001.

¹⁷ Ora Lassila, Ralph R. Swick: Resource Description Frame- work: (RDF) Model and Syntax Specification W3C Recommen- dation http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/, 22.02.1999.

¹⁸ Michael K. Smith, Chris Welty, Deborah McGuinness: OWL Web Ontology Language: Guide W3C Working Draft http://www.w3.org/TR/2003/WD-owl-guide-20030331/, 31.03.2003.

¹⁹ Deborah L. McGuinness, Frank van Harmelen: OWL Web Ontology Language: Overview W3C Working Draft http://www.w3.org/TR/2003/WD-owl-features-20030331/, 31.03.2003.

²⁰ Frank van Harmelen, Jim Hendler, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, Lynn Andrea Stein: OWL Web Ontology Language: Reference W3C Working Draft http://www.w3.org/TR/2003/WD-owl-ref-20030331/, 31.03.2003.

²¹ Jeff Heflin: Web Ontology Language (OWL) Use Cases and Requi- rements W3C Working Draft http://www.w3.org/TR/2003/WD- webont-req-20030331/, 31.03.2003.

²² Martin Gaedke, Guntram Gräf: WebComposition Process Model: Ein Vorgehensmodell zur Entwicklung und Evolution von Web- Anwendungen Telecooperation Office (TecO), Universität Karlsru- he, 1999.

²³ Stefan Jablonski, Christian Meiler: Web-Content- Managementsysteme Informatik Spektrum, Band 25, Heft 2, 18.04.2002.

²⁴ Joachim Müller: Workflow-based Integration: Grundlagen, Techno- logien, Management Springer Verlag, 2005.

²⁵ Bernard Favre-Bulle: Automatisierung komplexer Industrieprozes- se: Systeme, Verfahren und Informationsmanagement Springer Verlag, 2004.

²⁶ Marco Skulschus, Marcus Wiederstein: XSLT 2.0: Fortgeschrittene

Anwednungen mitp-Verlag, 2005.

²⁷ Dan Brickley, R.V. Guha: RDF Vocabulary Descripti- on Language 1.0: RDF Schema W3C Recommendation http://www.w3.org/TR/2004/REC-rdf-schema-20040210/, 10.02.2004.

²⁸ James Clark: XSL Transformations (XSLT) Version 1.0 W3C Re- commendation http://www.w3.org/TR/xslt, 16.11.1999.

²⁹ James Clark: Market Share: Business Intelligence Platform Softwa- re, Worldwide, 2007 http://www.gartner.com/DisplayDocument?- ref=g search&id=697207&subref=simplesearch, 22.09.2007.

³⁰ Henning Behme: iX Magazin für Professionelle Informationstech- nik Heise Zeitschriften Verlag, 12/2007.

³¹ Oliver Zschau, Dennis Traub, Rik Zahradka: Web Content Mana- gement. Websites professionell planen und betreiben. Galileo Press, 2001.

^[32] Deutsches Institut f¨ur Normung e.V.: Textverarbeitung und Kommunikation. Genormte Verallgemeinerte Auszeichnungssprache (SGML). Beuth, 1991.