Nottelmann-Hennies Bachelorarbeit_TTviaWS_Final

Universität Paderborn
Studienarbeit
zur Erlangung des Grades
Bachelor of Computer Science
für den integrierten Studiengang Informatik
Web-Service-basierte Kommunikation zwischen
einer semistrukturierten Systemumgebung
und einer Projektmanagementanwendung
mit strukturierter Datenspeicherung
Grundlagen und Prototyp am Beispiel von
PAVONE TimeTracking, einer Lotus Notes/Domino-Anwendung,
und Microsoft Enterprise Project Management
Prof. Dr. Ludwig Nastansky
Sommersemester 2004
Betreut von:
Dipl.-Wirt.-Inform. Ingo Erdmann
Björn Reinhold (PAVONE AG)
Vorgelegt von:
Hermann Nottelmann
Informatik
Matrikel-Nr. 6090810
Ferdinandstraße 30
33102 Paderborn
Patrick Hennies
Informatik
Matrikel-Nr. 6079800
Hasenberg 1
33100 Paderborn
I
Inhaltsverzeichnis
1
2
Einleitung ...............................................................................................................1
1.1
Szenario und Zielsetzung ........................................................................................ 1
1.2
Aufbau der Arbeit ................................................................................................... 3
Begriffe und Konzepte ..........................................................................................4
2.1
2.1.1
Client-Server-Modell......................................................................................................... 5
2.1.2
Middleware........................................................................................................................ 6
2.1.3
Nachrichtenbasierte Kommunikation ................................................................................ 8
2.1.4
RPC-basierte Kommunikation........................................................................................... 9
2.2
Datenmodelle.......................................................................................................... 11
2.2.1
Semistrukturiertes Datenmodell ...................................................................................... 11
2.2.2
Relationales Datenmodell................................................................................................ 14
2.3
XML........................................................................................................................ 16
2.3.1
Einordnung von XML ..................................................................................................... 16
2.3.2
Strukturieren von XML-Dokumenten ............................................................................. 17
2.3.3
Verarbeiten von XML-Dokumenten ............................................................................... 18
2.3.4
Transformieren von XML-Dokumenten ......................................................................... 19
2.4
Web Services .......................................................................................................... 21
2.4.1
Architektur ...................................................................................................................... 22
2.4.2
Erkennung (UDDI).......................................................................................................... 25
2.4.3
Beschreibung (WSDL) .................................................................................................... 26
2.4.4
Nachrichtenformat (SOAP) ............................................................................................. 27
2.5
3
Verteilte Systeme ..................................................................................................... 4
Einführung in softwaregestützte Projektverwaltung ......................................... 30
2.5.1
Projekte ........................................................................................................................... 30
2.5.2
Projektmanagement ......................................................................................................... 30
2.5.3
Bedeutung von Zeitphasendaten in Projekten ................................................................. 31
Kommunikation in verteilten Systemen............................................................32
3.1
Integrationsaspekt der Kommunikation ............................................................. 32
3.1.1
Zielsetzung der Geschäftsprozessintegration .................................................................. 32
3.1.2
Heterogene Systemarchitektur als Integrationstreiber..................................................... 33
3.1.3
Konzept der Enterprise Application Integration.............................................................. 35
3.2
3.2.1
Paradigmen der Datenspeicherung...................................................................... 37
Semistrukturierte Datenspeicherung................................................................................ 37
II
3.2.2
Relationale Datenspeicherung ......................................................................................... 40
3.2.3
Koexistenz beider Paradigmen ........................................................................................ 41
3.3
XML als Austauschformat.................................................................................... 41
3.3.1
Konvertierung zwischen XML und semistrukturierten Datenbanken ............................. 43
3.3.2
Konvertierung zwischen XML und relationalen Datenbanken ....................................... 44
3.3.3
Zusammenfassung ........................................................................................................... 47
3.4
Kommunikation..................................................................................................... 48
3.4.1
3.4.1.1
Java RMI................................................................................................................ 49
3.4.1.2
CORBA.................................................................................................................. 50
3.4.1.3
DCOM und .NET Remoting .................................................................................. 51
3.4.1.4
Web Services ......................................................................................................... 52
3.4.2
Kommunikationskonzept................................................................................................. 54
3.4.2.1
Auswahlentscheidung ............................................................................................ 54
3.4.2.2
Modellcharakteristika ............................................................................................ 55
3.5
4
Kommunikationsalternativen .......................................................................................... 48
Limitationen und Entwicklungspotenziale.......................................................... 57
3.5.1
Sicherheit......................................................................................................................... 58
3.5.2
Management und Quality of Service ............................................................................... 60
Prototypische Realisierung des Kommunikationsmodells ..............................61
4.1
Microsoft Project ................................................................................................... 62
4.1.1
Microsoft Project Datenmodell ....................................................................................... 63
4.1.2
.NET Framework............................................................................................................. 66
4.1.2.1
ADO.NET.............................................................................................................. 67
4.1.2.2
ASP.NET ............................................................................................................... 69
4.1.2.3
Visual Studio .NET................................................................................................ 69
4.2
PAVONE TimeTracking....................................................................................... 71
4.2.1
Struktureller Aufbau von TimeSheet-Dokumenten......................................................... 72
4.2.2
Datenaustausch mit Microsoft Project............................................................................. 74
4.2.2.1
Import von Projektstrukturdaten ............................................................................ 75
4.2.2.2
Export von Aufwandsdaten.................................................................................... 81
4.3
Kommunikationselement ...................................................................................... 83
4.3.1
DIME-Attachments ......................................................................................................... 83
4.3.2
Web Service Enhancements ............................................................................................ 85
4.3.3
Microsoft SOAP Toolkit ................................................................................................. 85
4.3.3.1
Verbindungsaufbau und Nachrichtengenerierung.................................................. 87
4.3.3.2
Verarbeitung von Nachrichtenanhängen................................................................ 88
III
4.4
Kommunikationsablauf im Detail ........................................................................ 89
4.5
Einschränkungen und offene Problemstellungen ............................................... 92
4.6
Installationsanweisungen und –besonderheiten.................................................. 94
4.6.1
Installation des Web Service ........................................................................................... 94
4.6.2
Installation des Lotus Notes Clients ................................................................................ 95
5
Zusammenfassung und Ausblick.......................................................................97
6
Literaturverzeichnis............................................................................................99
IV
Abkürzungsverzeichnis
ADO
ActiveX Data Objects
API
Application Programming Interface
ASP
Active Server Pages
B2B
Business-to-Business
B2C
Business-to-Consumer
C#
C-Sharp
CLR
Common Language Runtime
COM
Component Object Model
CORBA
Common Object Request Broker Architecture
CSS
Cascading Stylesheet
DB
Datenbank
DBMS
Database Management System
DCOM
Distributed Component Object Model
DIME
Direct Internet Message Encapsulation
DOM
Document Object Model
DTD
Document Type Definition
EAI
Enterprise Application Integration
ERP
Enterprise Resource Planning
FTP
File Transfer Protocol
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
IDL
Interface Definition Language
V
IETF
Internet Engineering Task Force
IIOP
Internet Inter-ORB Protocol
IIS
Internet Information Server
IP
Internet Protocol
IT
Information Technology
JVM
Java Virtual Machine
MIME
Multipurpose Internet Mail Extensions
MOM
Message Oriented Middleware
NF
Normalform
OASIS
Organization for the Advancement of Structured
Information Standards
ODBC
Open Database Connectivity
OEM
Object Exchange Model
OLE
Object Linking and Embedding
OMG
Object Management Group
ORB
Object Request Broker
RDBMS
Relational Database Management System
RDBS
Relational Database System
RMI
Remote Method Invocation
RPC
Remote Procedure Call
SAX
Simple API for XML
SGML
Standard Generalized Markup Language
SMTP
Simple Message Transfer Protocol
SOAP
Simple Object Access Protocol
VI
SQL
Structured Query Language
TCP
Transfer Control Protocol
UDDI
Universal Description Discovery and Integration
W3C
World Wide Web Consortium
WSDL
Web Service Description Language
WSE
Web Service Enhancements
WWW
World Wide Web
XML
Extended Markup Language
XSL
Extensible Stylesheet Language
XSLT
Extensible Stylesheet Language Transformations
VII
Abbildungsverzeichnis
Abb. 1 Client-Server-Interaktion ...........................................................................6
Abb. 2 Software- und Hardware-Serviceschichten in verteilten Systemen ........6
Abb. 3 Middleware – Broker Architektur .............................................................8
Abb. 4 RPC-Methodenaufruf .................................................................................10
Abb. 5 Graphbasierte Repräsentation semistrukturierter Daten .......................13
Abb. 6 Veranschaulichung eines Relationenschemas und einer Relation ..........14
Abb. 7 XML-Element - Beispiel..............................................................................17
Abb. 8 XML-Schema ...............................................................................................18
Abb. 9 Umwandlung mittels XSLT - Beispiel........................................................21
Abb. 10 Web-Service-Rollenmodell........................................................................23
Abb. 11 Web-Service-Schichtenmodell .................................................................24
Abb. 12 WSDL-Spezifikation .................................................................................26
Abb. 13 Das SOAP-Nachrichtenformat ................................................................28
Abb. 14 RPC-Style und Document-Style SOAP....................................................29
Abb. 15 Applikationstopologie ohne und mit EAI ...............................................35
Abb. 16 Ebenen der Integration .............................................................................36
Abb. 17 Daten- und dokumentenorientiertes XML ..............................................45
Abb. 18 Java RMI-Kommunikationsstruktur ......................................................49
Abb. 19 CORBA – ORB-Architektur ...................................................................51
Abb. 20 .NET Remoting – Übersicht .....................................................................52
Abb. 21 Kommunikationsverlauf in der Übersicht...............................................55
Abb. 22 Web-Service-Kommunikationsmodell .....................................................56
Abb. 23 Erweitertes Web-Service-Schichtenmodell .............................................58
Abb. 24 Web-Service-Kommunikationsmodell (modifiziert) ..............................61
Abb. 25 Technisches Kommunikationsmodell - Teil 1 .........................................62
Abb. 26 Datenmodell Microsoft Project.................................................................65
Abb. 27 Architektur .NET Framework ................................................................66
Abb. 28 ADO.NET-Objektmodell ..........................................................................67
Abb. 29 Connection-Objekt ....................................................................................67
Abb. 30 DataAdapter UpdateCommand ...............................................................68
Abb. 31 DataSet - Beispiel .......................................................................................69
Abb. 32 Technisches Kommunikationsmodell – Teil 2.........................................71
VIII
Abb. 33 Darstellung eines TimeSheet-Dokuments................................................73
Abb. 34 Felderzusammenhänge zwischen TimeSheet u. Microsoft Project .......74
Abb. 35 Projektstrukturdaten aus Microsoft Project – Codebeispiel.................76
Abb. 36 Zugriff auf DOM-Tree-Elemente .............................................................77
Abb. 37 Arbeitsweise XSLT-Prozessor ..................................................................77
Abb. 38 Partielle Datenbankrepräsentation mittels DXL ....................................78
Abb. 39 Pipelining - Codebeispiel ...........................................................................78
Abb. 40 Import – Schritt 1 ......................................................................................79
Abb. 41 Import – Schritt 2 ......................................................................................79
Abb. 42 Import – Schritt 3 ......................................................................................80
Abb. 43 Exportprozess schematisch .......................................................................81
Abb. 44 TimeSheet-Daten für den Export nach MS Project – Codebeispiel......82
Abb. 45 Technisches Kommunikationsmodell - Teil 3 .........................................83
Abb. 46 DIME Attachments - Codebeispiel...........................................................85
Abb. 47 Rolle des Microsoft SOAP Toolkits..........................................................86
Abb. 48 Verbindungsaufbau und Nachrichtengenerierung - Codebeispiel........87
Abb. 49 DIME-Attachments clientseitig - Codebeispiel .......................................88
Abb. 50 Kommunikationsablauf - Schritt 1...........................................................89
Abb. 51 Kommunikationsablauf - Schritt 2...........................................................89
Abb. 52 Kommunikationsablauf - Schritt 3...........................................................90
Abb. 53 Kommunikationsablauf - Schritt 4...........................................................90
Abb. 54 Kommunikationsablauf - Schritt 5...........................................................91
Abb. 55 Kommunikationsablauf - Schritt 6...........................................................91
Abb. 56 Änderungen an der Datenbank PAVONE TimeSheet ...........................96
1
1 Einleitung
[Hermann Nottelmann, Patrick Hennies]
1.1
Szenario und Zielsetzung
In jüngster Zeit hat die Informationstechnik für das betriebliche Umfeld immer
größere Bedeutung gewonnen. Unternehmenserfolg wird maßgeblich durch den
Einsatz und die Nutzung des Internets beeinflusst oder entsteht sogar ausschließlich
daraus. Diese Bedeutungszunahme geht einher mit einer Veränderung der ausgetauschten Daten. Unternehmen sind zunehmend dezentral aufgebaut, was zum einen
aus der steigenden Bedeutung der Projektarbeit, zum anderen aus der Tendenz zur
unternehmensübergreifenden Kooperation resultiert. Mit dieser Entwicklung einher
geht eine zunehmende Heterogenität der Datenspeicherung. Der Integration und
Kommunikation verschiedener Datenbanksysteme kommt daher heutzutage eine
maßgebliche Rolle zu.
Eine funktionierende Kommunikation ist der Grundstein eines jeden Informationsaustauschs. Im Zeitalter der Informationsgesellschaft unterliegen Unternehmen einem
regelrechten Zwang zur Kommunikation, wenn sie als internationaler Akteur
konkurrenz- und damit langfristig überlebensfähig sein wollen.
Voraussetzung einer effizienten Kommunikation sind eine funktionierende
Infrastruktur, ein Kommunikationsmedium und ein Kommunikationsformat. Um die
benötigten Informationen zu erhalten, muss ein geeigneter Kommunikationspartner
gefunden und ein Übertragungsmedium ausgewählt werden. Für den anschließenden
Austausch ist ein geeignetes Format zu wählen, welches die Struktur und Sprache der
übermittelten Informationen festlegt.
In der heutigen Zeit steht mit dem Internet eine moderne, effiziente und global
verfügbare Infrastruktur zur Informationsübermittlung bereit. In der Vergangenheit
war zum Auffinden des betreffenden Informationsanbieters meist ein aufwendiges
Eingreifen des Menschen nötig. Seit einigen Jahren ist jedoch eine fortschreitende
Automatisierung der Informationsextraktion und –verarbeitung zu beobachten. Damit
liegt der Untersuchungsschwerpunkt in zunehmendem Maße auf dem
Kommunikationsformat und der Schnittstellenkomponente an den Endpunkten der
Kommunikation.
Die Aufgabe der Schnittstellen besteht darin, die gewonnenen Informationen in
bestehende Datenstrukturen zu integrieren. Die Datenspeicherung der kommuni-
2
zierenden Anwendungen ist allerdings durch starke Heterogenität gekennzeichnet,
verursacht durch die Verfolgung verschiedener Paradigmen der Datenhaltung.
Einerseits besteht der etablierte Ansatz Daten zentral und in strukturierter Form zu
speichern. Die hierfür eingesetzten Datenbanksysteme sind optimiert für die
Speicherung großer Mengen gleichartiger Daten und werden typischerweise in
Zusammenhang mit monolithischen Anwendungen benutzt.
Andererseits besteht gegenwärtig eine Tendenz zu spezialisierten Applikationen, was
die Modularisierung fördert. Durch diese Entwicklung wird die zentralistische
Datenhaltung um den dezentralen Datenhaltungsansatz ergänzt, bei welchem die
benötigten Informationen bei Bedarf aus heterogenen Datenquellen gewonnen werden.
Es ist somit für die Kommunikation zweckmäßig, von den zugrunde liegenden
Datenquellen durch ein standardisiertes Austauschformat zu abstrahieren. Bei
Einigung auf ein solches Format können Konvertierungsmechanismen in den
Schnittstellen der verschiedenen Datenquellen implementiert werden. Es findet also
eine Verlagerung der Rolle des Kommunikationspartners von den Anwendungen hin
zu Schnittstellen statt.
In diesem Fall ist es sinnvoll, eine Schnittstelle in standardisierter Form zu
dokumentieren, um deren Funktionalität allen potenziellen Kommunikationspartnern
bekannt zu machen. Werden die Forderungen nach Standardisierung der
verschiedenen Komponenten der Kommunikation umgesetzt, führt dies zu einer
Konvergenz von Datenübermittlung, -verarbeitung und -speicherung.
Ziel dieser Arbeit ist es, eine Anwendungskommunikation zu realisieren, die diesen
Anforderungen genügt. Als Vertreter des zentralistischen Ansatzes wird eine
Applikation mit relationaler Datenspeicherung betrachtet. Der dezentrale Ansatz wird
repräsentiert durch eine Anwendung basierend auf Lotus Notes/Domino. Bei
letztgenannten Anwendung handelt es sich um PAVONE TimeTracking, bei der
erstgenannten um Microsoft Enterprise Project Management. Microsoft Enterprise
Project Management dient der Verwaltung und Steuerung von Projekten, während
PAVONE TimeTracking auf die dezentrale Erfassung von Zeitphasendaten in
Projekten fokussiert ist. Für die Kommunikationslösung sollen Projektstrukturdaten in
Microsoft Enterprise Project Management angelegt und bearbeitet werden,
wohingegen die Zeitphasendatenerfassung in PAVONE TimeTracking erfolgt. In
Microsoft Enterprise Project Management erfasste Projektstrukturdaten sollen aus
PAVONE TimeTracking heraus angefordert werden und nach Hinzufügen der
zugehörigen Zeitphasendaten zurücktransferiert werden können.
Die Kommunikation soll mittels eines Web Service implementiert werden, welcher die
Schnittstellenfunktion beider Seiten übernimmt. Wie im Verlauf der Arbeit gezeigt
3
werden wird, ist die Nutzung des Internets als Kommunikationsinfrastruktur und XML
als Austauschformat für diese Architektur zweckmäßig.
1.2
Aufbau der Arbeit
Im folgenden Kapitel wird zunächst auf die verwendeten Technologien und Begriffe
eingegangen. Nach einer Einführung in verteilte Systeme und verschiedene
Datenbanktechnologien erfolgt eine detaillierte Betrachtung der Markup-Sprache
XML und des Web-Service-Konzepts. Geschlossen wird das Kapitel mit einem kurzen
Exkurs zur Bestimmung des Formats und Inhalts von Zeitphasendaten in Projekten.
Im dritten Kapitel erfolgt eine Einordnung der Kommunikationsthematik in den
technologischen und organisatorischen Kontext. Diesem schließt sich ein Vergleich
der Datenspeicherungsparadigmen semistrukturierter und relationaler Datenbanksysteme an. In Kapitel 3.3 wird dann XML in Beziehung zu diesen beiden Datenbanksystemen gesetzt und die Rolle von XML als Austauschformat näher erklärt. Kapitel
3.4 widmet sich schließlich dem Entwurf einer Kommunikationslösung. Dies
geschieht mittels eines Vergleichs gängiger Kommunikationslösungen unter
Einbeziehung des relativ jungen Konzepts der Web Services. Der Vergleich schließt
mit der Auswahlentscheidung zwischen den betrachteten Alternativen. Es folgen der
Entwurf eines daraus resultierenden Kommunikationsmodells sowie die Darstellung
des Kommunikationsverlaufs. Abgerundet wird das Kapitel mit einer Analyse
verschiedener Probleme und Potenziale der gewählten Kommunikationslösung.
Das vierte Kapitel behandelt die Implementierungsdetails des Prototyps. Hierzu wird
das entworfene Kommunikationsmodell in seine Kernelemente unterteilt und
anschließend technisch konkretisiert. Im Anschluss daran erfolgt in Kapitel 4.4 eine
Betrachtung des tatsächlichen Kommunikationsverlaufs. Die fortschreitende
Konkretisierung mündet in der kritischen Leistungsbeurteilung des Prototyps und den
Installationshinweisen.
Im abschließenden 5. Kapitel erfolgen ein Resümee der wichtigsten Aspekte dieser
Arbeit sowie ein Ausblick auf Potenziale und Entwicklungstendenzen.
4
2 Begriffe und Konzepte
Neben der Definition von Begriffen werden in diesem Kapitel grundlegende Konzepte
eingeführt, welche im weiteren Verlauf der Arbeit Verwendung finden.
2.1
Verteilte Systeme
[Hermann Nottelmann]
Aufbauend auf einer begrifflichen Definition werden wesentliche Aspekte verteilter
Systeme herausgestellt, die bei der Kommunikation in einem solchen Umfeld
berücksichtigt werden müssen. Die nachfolgenden Unterkapitel behandeln
grundlegende Konzepte der Kommunikation in verteilten Systemen.
Im Rahmen dieser Arbeit soll die Definition verteilter
(Coulouris/Dollimore/Kindberg 2001, S. 2) benutzt werden:
Systeme
nach
„We define a distributed system as one in which hardware or software
components located at networked computers communicate and coordinate their
actions only by passing messages.”
Diese Definition betont zwei wesentliche Charakteristika eines verteilten Systems: Als
einzige Voraussetzung wird die physikalische Verbindung der beteiligten
Kommunikationspartner genannt; eine Kommunikation ist nur über den Austausch
von Nachrichten möglich.
Die folgenden Aspekte sind bei der Umsetzung verteilter Systeme in besonderer
Weise zu berücksichtigen1:
1
•
Heterogenität: Ein verteiltes System setzt sich zusammen aus einer Vielzahl
verschiedener Netzwerke, Betriebssysteme, Computerhardware und Programmiersprachen.
•
Offenheit: Die Bereitstellung von Schnittstellenbeschreibungen soll die
Integration einzelner Komponenten verschiedener Anwendungen ermöglichen.
•
Sicherheit: Die nachrichtenbasierte Kommunikation stellt bestimmte
Anforderungen an die Sicherheit in verteilten Systemen. Um den
unautorisierten Zugriff auf Ressourcen zu verhindern, muss die Vertraulichkeit
gewährleistet sein. Während des Nachrichtenaustauschs müssen die Integrität
der Daten sowie die Erreichbarkeit des Kommunikationspartners sichergestellt
sein.
Vgl. Coulouris/Dollimore/Kindberg 2001, S. 16-26, sowie Tari/Bukhres 2001, S. 30-32.
5
•
Skalierbarkeit: Ein skalierbares System zeichnet sich dadurch aus, dass es auch
bei einem signifikanten Anstieg der Ressourcen und Benutzer durch hinzufügen zusätzlicher Kapazitäten weiterhin leistungsfähig arbeitet.
•
Fehlerbehandlung: In jedem Prozess, Computer oder Netzwerk können
unabhängig voneinander Fehler auftreten. Somit müssen die einzelnen
Komponenten eines verteilten Systems Fehlerbehandlungsmechanismen für die
abhängigen Komponenten implementieren. Dies umfasst zur Erhöhung der
Fehlerrobustheit neben der Entdeckung auch die Maskierung bzw. Tolerierung
von Fehlern oder die Einführung redundant ausgelegter Komponenten.
•
Nebenläufigkeit: Durch das Vorhandensein von vielen Benutzern besteht die
Möglichkeit simultaner Zugriffe auf dieselbe Ressource. Die Datenkonsistenz
muss auch für dieses Szenario gewährleistet sein.
•
Transparenz: Im Sinne der Komplexitätsreduktion sollen bestimmte Aspekte
der Verteilung dem Anwendungsprogrammierer verborgen bleiben. Das
verteilte System soll nicht als eine Menge isolierter Komponenten, sondern
vielmehr als Ganzheit begriffen werden.
2.1.1 Client-Server-Modell
[Hermann Nottelmann]
Die grundlegende Architektur eines verteilten Systems wird häufig anhand des ClientServer-Modells beschrieben2. Kommunikation in verteilten Systemen kann als
Interaktion zwischen Prozessen mit klar abgegrenzten Zuständigkeiten aufgefasst
werden. Die Prozesse üben zwei verschiedene Rollen aus: Während der Serverprozess
einen Dienst anbietet, wird dieser vom Clientprozess angefragt. Der Server reagiert
auf die Anfrage mit einer Antwort. Die ausgeübte Rolle eines Prozesses beschränkt
sich nicht ausschließlich auf die des Clients bzw. Servers und kann sich im Zeitverlauf
ändern. So kann ein Server wiederum als Client eines anderen Serverprozesses
fungieren (vgl. Abb. 1).
2
Vgl. Tanenbaum/van Steen 2003, S. 62.
6
Client
Anfrage
Server
Anfrage
Antwort
Antwort
Server
Anfrage
Client
Antwort
Prozess:
Computer:
Abb. 1 Client-Server-Interaktion3
2.1.2 Middleware
[Hermann Nottelmann, Patrick Hennies]
Middleware lässt sich allgemein als eine Softwareschicht definieren, deren Aufgabe
die Maskierung von Heterogenität und Bereitstellung eines geeigneten Modells zur
Applikationsprogrammierung in einem solchen Umfeld ist.4
Wichtige Zielsetzungen von Middleware sind die Schaffung von Ortstransparenz und
Unabhängigkeit von Details der Kommunikationsprotokolle, Betriebssysteme oder der
beteiligten Hardware (vgl. Abb. 2).
Hierdurch wird ein Abstraktionsmaß erreicht, welches eine Kommunikation zwischen
Prozessen beteiligter Applikationen weitgehend unabhängig von der unterliegenden
Systemarchitektur ermöglicht.
Applikationen, Dienste
Middleware
Betriebssystem
Computer- und Netzwerkhardware
Abb. 2 Software- und Hardware-Serviceschichten in verteilten Systemen5
3
Aus Coulouris/Dollimore/Kindberg 2001, S. 34.
Vgl. ebenda, S. 32-33.
5
Aus ebenda, S. 32.
4
7
Es existiert eine Reihe von Middleware-Modellen. Mit dem entfernten Prozeduraufruf
(engl. Remote Procedure Call) wird ein frühes Modell in Kapitel 2.1.4 vorgestellt. Im
Zusammenhang mit der Objektorientierung erfolgte eine Erweiterung dieses
Konzeptes um verteilte Objekte. Im Rahmen des Kapitels 3.4.1 werden noch drei
jüngere Modelle betrachtet. Hierbei handelt es sich im Einzelnen um Java RMI,
CORBA und Microsofts Ansätze DCOM bzw. .NET Remoting.
Um die für verteilte Systeme angestrebte Offenheit zu erreichen, bedarf es einer
Schnittstellenbeschreibung. Mittels dieser Beschreibungen sind die einzelnen
Komponenten in der Lage, ihre angebotenen Dienste in Form von Standardregeln
bezogen auf Syntax und ggf. Semantik zu spezifizieren.6 Die Schnittstellenbeschreibung erfolgt typischerweise in einer Schnittstellendefinitionssprache (engl.
Interface Definition Language - IDL). Syntaktisch beschrieben werden etwa die
vorhandenen Funktionen mit den Typen ihrer Parameter bzw. Rückgabewerte sowie
mögliche Ausnahmen zur Fehlerbehandlung.
Die durch die IDL spezifizierte Schnittstelle wird sowohl client- als auch serverseitig
implementiert. Die beiden Instanzen der Schnittstellenbeschreibung werden als Stub
oder auch Proxy bezeichnet. Serverseitig spricht man häufig auch von einem
Skeleton.7 Dieses Modell ermöglicht die transparente Kommunikation zwischen Client
und Server innerhalb verteilter Systeme.
In vielen Fällen wird von der Middlewarelösung auch eine Vermittlungsinstanz
zwischen den Proxies auf Server- und Clientseite bereitgestellt. Eine solche Entität
wird als Broker bezeichnet. Dieser übernimmt entweder die komplette
Nachrichtenzuteilung, in welchem Fall eine indirekte Kommunikation zwischen den
Proxies besteht, oder er stellt nur die initiale Verbindung her und die Proxies
kommunizieren direkt. Oft wird ein Brückenobjekt für die Interaktion zwischen
Brokern eingesetzt (vgl. Abb. 3).
6
7
Vgl. Tanenbaum/van Steen 2003, S. 24-25.
Vgl. ebenda, S. 109.
8
Abb. 3 Middleware – Broker Architektur8
2.1.3 Nachrichtenbasierte Kommunikation
[Patrick Hennies]
Unter nachrichtenbasierter Kommunikation wird im Allgemeinen der Nachrichtenaustausch zwischen Applikationen über ein Netzwerk verstanden.
Man unterscheidet zwischen synchronen und asynchronen Nachrichten. Für die
Übertragung lassen sich entweder Standardprotokolle wie HTTP oder SMTP einsetzen
oder es wird eine spezielle nachrichtenorientierte Middleware (engl. Message Oriented
Middleware - MOM) für das Übertragen der Nachricht verwendet.9 Die
nachrichtenbasierte Kommunikation stellt nur minimale strukturelle Anforderungen
und erfordert als einzige Koordination die Einigung von Server und Client auf ein
gleiches Nachrichtenformat. Client und Server sind daher nur lose gekoppelt und die
Übertragung ist grundsätzlich programmiersprachen- sowie protokollunabhängig
definiert.
8
9
Aus Plášil/Stal 1998, S. 17.
Vgl. Wyke/Rehman/Leupen 2002, S.271-285.
9
Der Einsatz nachrichtenbasierter Kommunikation ist besonders verbreitet, wenn
heterogene Systeme miteinander kommunizieren oder eine engere Systemintegration
nicht möglich oder gewollt ist.
2.1.4 RPC-basierte Kommunikation
[Patrick Hennies]
Der Remote Procedure Call (RPC) ist wie das nachrichtenbasierte Modell ein
Lösungsansatz für die Interaktion in einem verteilten System. Anders als bei der
nachrichtenbasierten Kommunikation arbeitet ein RPC nur mit Low-LevelKommunikationsprotokollen wie TCP/IP. Die Funktionsweise ist der eines lokalen
Prozeduraufrufs sehr ähnlich. Der Client ruft eine Methode auf dem Server auf und
übergibt entsprechende Parameter. Der Server führt die Methode lokal aus und sendet
das Ergebnis als Nachricht zurück. Dieser Routine voraus geht eine so genannte
„Interface Definition“, in welcher die Parameter, Funktionen und Ergebnisformate der
Schnittstellen festgelegt werden. Dies geschieht mittels eines Stub- oder ProxyObjekts aufseiten des Clients und eines Skeleton-Objekts auf Serverseite (vgl. Abb. 4).
Der Stub stellt eine lokale Repräsentation des entfernten Servers dar und kann mit den
definierten Parametern wie eine lokale Präsenz angesprochen werden. Ebenso erhält
das Skeleton-Objekt die Prozedurergebnisse vom Server und behandelt dann den
eigentlichen Transfer. Anders als eine nachrichtenbasierte Interaktion ist ein RPC
somit an eine rigide Einhaltung von Richtlinien gebunden. Bei einer typischen RPCImplementierung wird keine Brokerfunktion benötigt.
10
Abb. 4 RPC-Methodenaufruf 10
10
Aus Tari/Bukhres 2001, S. 18.
11
2.2
Datenmodelle
[Hermann Nottelmann]
Im Rahmen dieses Kapitels werden zwei grundlegend verschiedene Datenmodelle
eingeführt. Dem Datenmodell für semistrukturierte Daten wird das relationale
gegenübergestellt. Bei einem Datenmodell unterscheidet man zwischen der
Beschreibung der Struktur der Datenbank und dem Inhalt in Form von Daten. Unter
diesem Gesichtspunkt soll eine Vorstellung der beiden Datenmodelle erfolgen.
2.2.1 Semistrukturiertes Datenmodell
[Hermann Nottelmann]
Dieses Kapitel beginnt mit einer Motivation für die Notwendigkeit eines
semistrukturierten Datenmodells und mündet in der eigentlichen Begriffsbildung.
Geendet wird mit der Nennung zweier typischer Modellvertreter.
Daten in elektronischer Form entsprechen häufig nicht traditionellen Datenmodellen.
Eine Vielzahl von Anwendungen speichert Daten in proprietären, nicht
standardisierten Formaten. Ein weiteres Beispiel ist die Integration unternehmensexterner heterogener Datenquellen, die sich nicht im Kontrollbereich der jeweiligen
Anwendung befinden. Die zugrunde liegende Struktur derartiger Datenspeicher ist
häufig nur teilweise bekannt und kann sich im Zeitverlauf unbemerkt von der
Anwendung verändern.
Die besondere Herausforderung der Aufstellung eines Datenmodells ist also darin zu
sehen, dass sich die Menge der Datenspeicher sowie deren Inhalt und Semantik
theoretisch ständig verändern können. Dieses Kernproblem bei der Integration
unternehmensübergreifender heterogener Datenquellen wird auch als die Dynamik der
Umgebung11 bezeichnet.
Nur teilweise strukturierte Daten lassen sich häufig nicht durch ein bestimmtes
Schema beschreiben. An die Stelle des Schemas treten selbstbeschreibende Daten.
Semistrukturierte Daten werden daher häufig als schemalos bzw. selbstbeschreibend
charakterisiert. Für traditionelle Datenmodelle werden zuerst die Struktur und die
Datentypen festgelegt; anschließend werden gemäß dieser Festlegung Instanzen
gebildet. Für semistrukturierte Daten wird diese Trennung aufgehoben, da die Daten
direkt beschrieben werden. Diese interne Struktur wechselt häufig und ist nicht streng
typisiert.
11
Vgl. Papakonstantinou/Garcia-Molina/Widom 1995, S. 2.
12
Nach dem intuitiven Gebrauch des Begriffs „semistrukturiert“ im vorhergehenden
Absatz soll nun eine Begriffsbildung anhand charakteristischer Merkmale erfolgen, die
semistrukturierte Daten gänzlich oder teilweise aufweisen12:
•
Es existiert kein an zentraler Stelle gespeichertes Schema für Daten gleichen
Typs; dieses ist vielmehr implizit in jedem Dokument enthalten.
•
Daten besitzen eine wechselnde Struktur. Daten desselben Typs können
abweichende, fehlende oder zusätzliche Attribute haben.
•
Im Zeitverlauf unterliegen die Attribute und die Strukturierung der Dokumente
weiterhin häufigen Veränderungen.
•
Die Trennung zwischen Schema und Daten ist sehr unscharf.
•
Daten wie beispielsweise Volltext unterliegen keiner weiteren durch Attribute
abbildbaren Struktur.
•
Sofern für Attribute Datentypen angegeben sind, ist diese Typisierung nicht als
Integritätsbedingung für die aufzunehmenden Daten zu verstehen.
•
Die Anzahl der potenziellen Attribute und die Vielfalt der internen
Strukturierung sind sehr groß.
Die Repräsentation semistrukturierter Daten erfolgt häufig graphbasiert mittels Knoten
und gerichteter Kanten13 (vgl. Abb. 5). Im Gegensatz zu inneren Knoten sind einzig
den Blättern Daten zugeordnet. Die Kanten tragen Beschriftungen, welche die
Beziehung zwischen den verbundenen Knoten aufzeigen. Die Wurzel gilt als
Einstiegspunkt für alle nachfolgenden Knoten und repräsentiert somit die komplette
Datenbank. Es muss sich nicht um einen Baum handeln.
12
13
Vgl. Heuer 2000, S. 159-160.
Vgl. Garcia-Molina/Ullman/Widom 2002, S. 174-175, oder Abiteboul/Buneman/Suciu 2000, S. 11-13.
13
Projekt
Mitarbeiter
arbeitet an
Name
PAVONE #1
Beginn
Name
Alter
01.12.2003
32
Vorname
Tim
Nachname
Meier
Abb. 5 Graphbasierte Repräsentation semistrukturierter Daten
In (Suciu 1998b) wird ein Überblick der Ansätze für Datenbankensysteme und
Anfragesprachen semistrukturierter Daten gegeben. Im Rahmen dieser Arbeit ist
insbesondere die Verbindung von semistrukturierten Datenmodellen und XML von
Interesse.
Das Object Exchange Model (OEM)14 kann als Urmodell semistrukturierter Daten
angesehen werden. Wie auch andere semistrukturierte Datenmodelle verfolgt es einen
Integrationszweck. So wurde OEM explizit für den Datenaustausch zwischen
heterogenen Systemen konzipiert.15 Dieses schemalose, graphbasierte Datenmodell
wird in Kapitel 3.3 im Rahmen der Diskussion von Datenaustauschformaten noch
einmal näher beschrieben.
Allerdings werden semistrukturierte Daten heutzutage typischerweise in XMLDokumenten abgespeichert16. XML ist ebenfalls graphbasiert, aber durch die
Zeichenorientierung im Gegensatz zum OEM auch für den Menschen lesbar.
Insbesondere die optionale Möglichkeit, die Struktur in einem separaten Schema zu
erfassen, ist gegenüber dem OEM von Vorteil. So wird beispielsweise erst der
Datenaustausch mit relationalen Datenbanken ermöglicht, was im weiteren Verlauf der
14
Vgl. Papakonstantinou/Garcia-Molina/Widom 1995.
Vgl. Abiteboul/Buneman/Suciu 2000, S. 19.
16
Bei XML handelt es sich streng genommen um eine Auszeichnungssprache, der kein Datenmodell
zugrunde liegt. Aufgrund der großen Ähnlichkeit zu Instanzen des semistrukturierten Datenmodells
wird es aber in der Praxis zur Speicherung semistrukturierter Daten eingesetzt. Eine detaillierte
Betrachtung dieses Sachverhalts findet sich in (Suciu 1998a).
15
14
Arbeit aufzuzeigen ist. Eine detaillierte Beschreibung von XML und verwandter
Konzepte erfolgt in Kapitel 2.3.
2.2.2 Relationales Datenmodell
[Hermann Nottelmann]
Das relationale Datenmodell wurde von CODD Anfang der 70er Jahre entwickelt.17
Damit ein Datenbanksystem als vollständig relational bezeichnet werden kann, müssen
drei Architekturmerkmale erfüllt sein18:
•
Berücksichtigung der strukturellen Aspekte des relationalen Modells,
•
Existenz von Regeln zum Einfügen, Verändern und Löschen sowie
•
die Implementierung einer Sprache, die wenigstens so mächtig wie die
Relationenalgebra ist.
Diese Anforderungen sollen nachfolgend näher erläutert werden.
Relationenname
R
A1
…
…
…
…
Attribute
An
Relationenschema
Tupel
Relation
Abb. 6 Veranschaulichung eines Relationenschemas und einer Relation19
Eine relationale Datenbank besteht aus einer endlichen Menge von Relationen. Jede
Relation lässt sich anschaulich als zweidimensionale Tabelle auffassen (vgl. Abb. 6):
Den Kopf der Tabelle mit den einzelnen Spaltenüberschriften bildet das so genannte
Relationenschema. Hierbei handelt es sich um eine Menge von Attributen, denen
Wertebereiche (engl. Domains) zugeordnet sind. In der Praxis sind dies
Standarddatentypen, wie beispielsweise String oder Integer.
Die Zeilen der Tabelle werden als Tupel bezeichnet; sie enthalten die Daten, die in
dieser Relation abgelegt sind. Die Spalteneinträge besitzen den Wertebereich des
jeweiligen Attributs im Tabellenkopf.
17
Vgl. Codd 1970.
Vgl. Codd 1979, S. 398.
19
Aus Heuer 2000, S. 107.
18
15
Die Schemata aller Relationen bilden zusammen das Datenbankschema. Daten werden
auch als Instanz dieses Schemas bezeichnet.20 Die zum jeweiligen Datenbankschema
korrespondierende Relation bezeichnet man genauer als Basisrelation. Als
Architekturmerkmal relationaler Datenbanken kann also die logische Trennung von
Struktur in Form des Datenbankschemas und Inhalt in Form der Basisrelationen
festgehalten werden.
Zur Identifizierung der Tabelleneinträge bzw. Tupel einer Relation werden so
genannte Schlüssel eingeführt. Hierbei handelt es sich um eine minimale Menge von
Attributen zur eindeutigen Tupelkennzeichnung. Der Primärschlüssel identifiziert
eindeutig jedes Tupel einer Relation. Die Menge der Attribute, die in einer anderen
Relation derselben Datenbank als Primärschlüssel fungieren, wird als Fremdschlüssel
bezeichnet.
Mittels Integritätsregeln wird ein konsistenter und konfliktfreier Datenbankzustand
sichergestellt. Die Objektintegrität verlangt, dass der Primärschlüssel zu keinem
Zeitpunkt Nullwerte enthält. Referentielle Integrität sieht die Existenz eines Primärschlüssels zu jedem Fremdschlüssel vor.
Die schrittweise Zerlegung von Relationen in eine redundanzarme Form wird als
Normalisierung bezeichnet. Der Zustand im Normalisierungsprozess wird als n.
Normalform (NF) gekennzeichnet.
Mittels der Relationenalgebra sind im Wesentlichen vier generische Operationen21 auf
den Relationen einer Datenbank möglich, die als Ergebnis wiederum eine Relation
liefern:
•
die Selektion zur Auswahl von Tupeln aus einer Relation,
•
die Projektion zur Auswahl bestimmter Attribute einer Relation,
•
der natürliche Verbund (engl. Join) zur Verknüpfung über gemeinsamen
Attributen zweier Relationen sowie
•
Mengenoperationen wie Vereinigung, Differenz- und Durchschnittsbildung auf
Relationen mit gleichem Schema.
Diese Operationen sind alle in der Abfragesprache SQL (Structured Query Language)
implementiert, die in den meisten relationalen Datenbanksystemen eingesetzt wird.
20
21
Vgl. Garcia-Molina/Ullman/Widom 2002, S. 61.
Vgl. Heuer 2000, S. 114-117.
16
2.3
XML
[Patrick Hennies]
In diesem Kapitel erfolgt eine themenbezogene Betrachtung der Extensible Markup
Language (XML). 22
XML ist eine so genannte Datenbeschreibungssprache (engl. Markup Language); das
bedeutet, sie drückt die Struktur und Form von Daten aus. Die Veränderungen, die
durch die wachsende Bedeutung von XML in fast allen Bereichen des Internets
verursacht wurden, sind umfassend. XML und das World Wide Web sind in ihrer
Entwicklung eng miteinander verbunden und beide haben in vielen Bereichen
wesentlich zum Erfolg des jeweils Anderen beigetragen.
Struktur und Syntax von XML sind heutzutage hinreichend bekannt. Es wird daher
hier nur eine kurze Einführung in diese Bereiche geben. Stattdessen liegt der Fokus
auf den verschiedenen Möglichkeiten XML-Dokumente zu formatieren und zu
bearbeiten.
2.3.1 Einordnung von XML
[Patrick Hennies]
XML entwickelte sich aus der Beschreibungssprache SGML, da versucht wurde, eine
einfachere und damit verständlichere Version der sehr komplexen SGML zu erzeugen.
XML wurde vom W3C-Konsortium entwickelt und 1998 als Standard verabschiedet.
Seitdem hat XML eine kontinuierliche Erfolgsgeschichte hinter sich.
XML ist zusätzlich zu seiner Datenbeschreibungsfunktion auch eine Metasprache.
Also im eigentlichen Sinn eine Sprache um Sprachen zu beschreiben.
Die bekannteste Markup-Sprache ist die Hypertext Markup Language (HTML),
mittels derer Webseiten im Internet beschrieben werden können. Beim Vergleich von
XML und HTML lassen sich jedoch deutliche Unterschiede festhalten.
Der Schwerpunkt von HTML liegt klar auf der Präsentation von Daten und nicht auf
der Strukturierung dieser Daten. XML als Metasprache ist wesentlich abstrakter und
behandelt im Gegensatz dazu genau diese Strukturierungsfunktion, während die
Präsentation nicht berücksichtigt wird. XML unterscheidet sich von HTML auch
darin, dass sich beliebige Sprachstrukturen erzeugen lassen, während bei HTML mit
festen Strukturen gearbeitet werden muss.
22
Vgl. XML - W3C Recommendation, http://www.w3.org/TR/REC-xml/, 2004. Aufgerufen 02.07.2004
17
Daten liegen bei XML in textueller Form vor und werden ausgezeichnet durch XMLElemente, so genannte „Tags“. Es ist möglich, Elemente zu schachteln und somit in
inhaltliche Beziehung zueinander zu setzen. Elemente eines XML-Dokuments können
über Attribute verfügen. Mit Letzteren werden in diesem Fall die Eigenschaften eines
Elements bezeichnet.
Abbildung 7 liefert ein Beispiel für ein XML-Element:
<firma>
<name> PAVONE </name>
<ort land=“Deutschland“> Paderborn </ort>
</firma>
Abb. 7 XML-Element - Beispiel
Als letzter und wesentlichster Unterschied zu HTML kann ein XML-Dokument auch
optional über eine Grammatik- und Datentypenbeschreibung verfügen. Diese dient vor
allem der Strukturierung und Prüfung eines XML-Dokuments. Nachfolgend soll diese
Strukturierungsfunktionalität betrachtet werden.
2.3.2 Strukturieren von XML-Dokumenten
[Patrick Hennies]
Es gibt zwei Typen von Datenbeschreibungen, die gemeinhin als Schema bezeichnet
werden, wobei die ältere (DTD)23 zunehmend durch die neuere und mächtigere
Fassung (XML Schema)24 ersetzt wird. Beide sind in der Lage, eine Struktur in einem
XML-Dokument zu erzeugen und zu überprüfen.
Eine DTD (Document Type Definition) fokussiert im Wesentlichen auf der
Strukturbeschreibung von Daten; die Leistungsfähigkeit zum Erzeugen von
Datentypen als allerdings begrenzt. Eine DTD ist in einer eigenen Sprache und nicht in
XML verfasst, was daraus resultiert, dass DTDs ursprünglich für eine Nutzung
zusammen mit SGML entwickelt wurden. Es können keine spezifischen Datentypen
mittels einer DTD beschrieben werden, da hier nur Texttypen unterstützt werden.
Ein XML-Schema ist hingegen in XML verfasst. Es ist damit in der Lage auch sich
selbst als XML-Dokument zu betrachten und zu validieren. Zusätzlich kann ein XMLSchema durch diese Eigenschaft auch direkt in ein XML-Dokument eingebunden
23
24
Vgl. DTD - Revision 1.2, http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm, 1998.
Aufgerufen 02.07.2004.
Vgl. XML Schema - W3C Recommendation, http://www.w3.org/TR/xmlschema-0/, 2001.
Aufgerufen 02.07.2004.
18
werden und muss nicht mehr als separates Dokument behandelt werden. Ein solches
Schema wird dann als Inlay-Schema bezeichnet.
XML-Schemata sind gut geeignet, um XML-Dokumente zur Aufnahme von
Dateninhalten zu optimieren. Es lassen sich verschiedene Basisdatentypen auswählen
und - durch einen hierarchischen Vererbungsmechanismus - auch beliebige neue
komplexe Typen deklarieren.
Die folgende Abbildung gibt ein Beispiel für ein XML-Schema:
<xs:schema id="NewDataSet" xmlns:xs=http://www.w3.org/2001/XMLSchema>
<xs:element name="NewDataSet”>
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element name="MSP_RESOURCES">
<xs:complexType>
<xs:sequence>
<xs:element name="RES_UID" type="xs:int" minOccurs="0"/>
<xs:element name="RES_TYPE" type="xs:boolean" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
Abb. 8 XML-Schema
Ein XML-Dokument hat den Vorteil auch für den Menschen lesbar und verständlich
zu sein. Es ist aber auch möglich, es für die Maschine-Maschine-Kommunikation
einzusetzen, da mittels eines Schemas die Einhaltung bestimmter struktureller
Vorgaben sichergestellt werden kann. Bei einer automatischen Verarbeitung wird die
Struktur eines XML-Dokuments anhand des beschreibenden Schemas geprüft. Im
Anschluss daran erfolgt die weitere Verarbeitung der Dateninhalte, die im Weiteren
untersucht werden soll.
2.3.3 Verarbeiten von XML-Dokumenten
[Patrick Hennies]
Für das Durchwandern (engl. Parsen) und Verarbeiten von XML-Dokumenten gibt es
zwei Hauptalternativen: zum einen das Document Object Model (DOM)25 und die
Simple API for XML (SAX).26
25
26
Vgl. DOM - W3C Level 3 Core, http://www.w3.org/DOM/, 2004. Aufgerufen 02.07.2004.
Vgl. SAX – Version 2.0, http://www.saxproject.org/, 2002. Aufgerufen 02.07.2004.
19
DOM ist eine standardisierte API (Application Programming Interface) des W3C und
bietet eine plattformunabhängige Möglichkeit auf Dokumente zuzugreifen und deren
Inhalte zu verändern. Man spricht im Fall von DOM auch von einer baumbasierten
API, da Dokumente auf eine interne Baumstruktur abgebildet werden. Diese
Baumstruktur wird dann zugreifenden Applikationen bereitgestellt. DOM lässt sich
auf XML- und HTML-Dokumente anwenden und in beliebigen Programmiersprachen
implementieren.
Aus der Initiative, eine weniger speicherintensive und stärker an Programmiersprachen
orientierte Lösung zu implementieren, entstand ein ereignisbasierter Lösungsansatz,
das SAX-API. Der wichtigste Unterschied zu DOM liegt bei SAX in dem
ereignisorientierten Verarbeitungsansatz. Dateninhalte werden über Ereignisse
abgearbeitet, welche dann in Programmen entsprechende Verarbeitungsmechanismen
auslösen können. In der ursprünglichen Version basierte SAX ausschließlich auf
JAVA. Als Open-Source-Produkt wird es aber ständig weiterentwickelt. Aktuelle
Versionen unterstützen auch weitere Programmiersprachen.
SAX ist einfacher gehalten als DOM und in vielen Fällen auch speichereffizienter. Es
muss aber bei der Ereignisbehandlung ständig der Dokumentenstatus geprüft werden.
Dies ist notwendig, um die aktuelle Position im Dokument nicht zu verlieren. Im
Ergebnis kann dies bei bestimmten Dokumentenarten zu sehr komplexen Programmen
führen.
DOM und SAX sind keine direkten Substitute, sondern haben ein jeweils spezifisches
Einsatzfeld entsprechend der zu verarbeitenden Dateninhalte eines Dokuments.
2.3.4 Transformieren von XML-Dokumenten
[Patrick Hennies]
Zusätzlich zu der Strukturierung und Verarbeitung von XML-Dokumenten ist als
drittes Element bei einer automatischen Nutzung von XML noch die Formatierung
und Präsentation von Dokumenten zu betrachten.
Die Präsentation von Daten in einem XML-Dokument wird durch die unterstützende
Technologie der Cascading Stylesheets (CSS)27 realisiert. CSS haben ähnlich wie
DTDs ihren Ursprung in der SGML-Welt und sind als Technologie bedeutsam, da sie
eine Trennung von Inhalt und Präsentation eines Dokuments ermöglichen.
27
Vgl. CSS – Spezifikation 2.1, http://www.w3.org/TR/CSS21/, 2004. Aufgerufen 02.07.2004.
20
Mittels CSS-Spezifikationen lassen sich Eigenschaften von Elementen wie Farbe,
Schriftart und Textformat eines Dokuments genau bestimmen. CSS lässt sich auf
HTML und XML anwenden und ist als W3C-Standard weit verbreitet.
CSS unterliegt aber insbesondere bei der Darstellung von XML einigen
Beschränkungen. So ist es beispielsweise nicht möglich, Elemente explizit von der
Darstellung auszunehmen. Stylesheets werden üblicherweise durch einen Web
Browser interpretiert und auf Zieldokumente angewendet. Dies ist bei HTML
sicherlich sinnvoll, im Fall eines XML-Dokuments aber potenziell nachteilig, da hier
auch andere Einsatzfelder als Webseiteninhalte bezweckt werden.
Hieraus entstand die W3C-Empfehlung Stylesheetfunktionen für XML-Dokumente
bereitzustellen.28 XSL steht für XML Stylesheet Language. Wenn der Name auch dem
Ursprung gerecht wird, ist die Funktionalität von XSL deutlich umfassender als bei
CSS. Zu der Funktionalität eine Dokumentenpräsentation zu bearbeiten, wie sie für
HTML-Dokumente ausreichte, kam jetzt noch die Fähigkeit zur Transformation eines
Dokuments. Diese erlaubt die Umwandlung eines XML-Dokuments in andere
Dokumententypen wie HTML oder in eine andere XML-Dokumentenstruktur. Diese
Umwandlungsfunktion von XSL wird als XSLT (XSL–Transformations) bezeichnet.
Für die Umwandlung wird ein XSLT-Prozessor eingesetzt, welcher ein XSLDokument auf ein XML-Dokument anwendet und damit ein neues Dokument erzeugt.
Umwandlungen werden umgesetzt durch so genannte „Templates“. Diese Templates
prüfen einen Dokumenteninhalt auf das Erfüllen bestimmter Anforderungen ab. Wird
eine solche Anforderung von einem Element erfüllt, so wird die im Template
festgehaltene Änderung ausgeführt.
Abbildung 9 gibt ein einfaches Beispiel für eine Elementumwandlung mittels eines
Templates. XML-Dokumente lassen sich mittels XSLT fast beliebig umwandeln und
verändern. Sie können so in für verschiedene Applikationen interpretierbare Formate
gebracht werden.
28
Vgl. XSL(T) – Working Draft V.2, http://www.w3.org/TR/xslt20/, 2003. Aufgerufen 02.07.2004.
21
Original Element eines Dokuments:
<Name> PAVONE </Name>
Template:
<xsl:template match=“Name”>
<Firma>
<xsl:value-of/>
</Firma>
</xsl:template>
Output:
<Firma> PAVONE </Firma>
Abb. 9 Umwandlung mittels XSLT - Beispiel
Zusammenfassend ist es also möglich, XML-Dokumente mittels eines Schemas zu
strukturieren, sie durch ein XSL-Stylesheet zu transformieren und anschließend durch
einen XML-Prozessor auszuwerten. XML-Dokumente sind somit eine gute Basis für
die Maschine-Maschine-Kommunikation.
2.4
Web Services
[Hermann Nottelmann, Patrick Hennies]
„Web Services are encapsulated, loosely coupled contracted functions offered
through standard protocols.“ (WebServices.org)
Diese relativ knappe Definition des Web-Service-Konzepts gibt eine gute einleitende
Übersicht über die wesentliche Zielsetzung, die mit der Einführung von Web Services
verfolgt wurde. Es ist aber sinnvoll sie durch eine praktikablere Definition zu ersetzen,
welche auch der entscheidenden Bedeutung verschiedener standardisierter Elemente
Rechnung trägt.
„A Web service is a software system designed to support interoperable
machine-to-machine interaction over a network. It has an interface described
in a machine-processable format (specifically WSDL). Other systems interact
with the Web service in a manner prescribed by its description using SOAP
messages, typically conveyed using HTTP with an XML serialization in
conjunction with other Web-related standards.“ 29
29
Vgl. Definition des W3C – http://www.w3.org/TR/ws-arch/, aufgerufen 02.07.2004.
22
Im Gegensatz zur ersten Definition ist diese deutlich konkreter, aber zugleich auch
wesentlich komplexer. Es ist daher angebracht, die einzelnen Elemente näher zu
erläutern, um zu verdeutlichen, dass der Aussagehalt beider Definitionen praktisch
deckungsgleich ist.
Ein Web Service erreicht eine Kapselung von den einzelnen Elementen der
Kommunikation durch den Einsatz einer in XML verfassten Dienstbeschreibung
(WSDL) für das Kommunikationsinterface. Die lose Kopplung zwischen einem
anfragenden Client und dem Web Service wird realisiert mittels einer
nachrichtenbasierten Interaktion. Diese Nachrichten werden ebenfalls in einem
standardisierten XML-Format (SOAP) ausgetauscht, welches systemunabhängig
verarbeitet werden kann. Zur eigentlichen, physikalischen Datenübertragung werden
nur Standard-Web-Protokolle eingesetzt.
Ein Web Service ist also nicht zwingend auf bestimmte Technologien oder Systeme
festgelegt.
Gemäß dieser Definition lässt sich die Kommunikationsarchitektur eines Web Service
formulieren, welche im Anschluss betrachtet werden soll.
2.4.1 Architektur
[Patrick Hennies]
Die Struktur eines Web Service lässt sich aus zwei Sichten beschreiben.
Das Web-Service-Schichtenmodell trägt vornehmlich dem Kommunikationsablauf aus
Sicht der verwendeten Protokolle Rechnung. Das Web-Service-Rollenmodell hingegen
unterteilt die einzelnen Kommunikationsschritte in Funktionen von drei Aufgabenträgern und betont somit stärker den zeitlichen Ablauf.
Die drei Entitäten des Web-Service-Rollenmodells geben in ihrer Interaktionsbeziehung eine gute Einführung in den strukturellen Aufbau eines Web Service. Die
zugrunde liegenden Technologien werden dann im Anschluss anhand des
Schichtenmodells näher erläutert.
Der Service Requester wird verkörpert durch eine Clientanwendung. Dieser ist der
eigentliche Konsument des Web Services. Er löst den Bearbeitungsprozess aus, indem
er eine Anfrage an den Server formuliert.
Der Service Provider ist der Web-Service-Anbieter. Die Bearbeitungsfunktionalität ist
hier implementiert. Die angebotenen Funktionen des Service Providers sind in einer
Dienstbeschreibung hinterlegt.
23
Der Service Broker ist ein Dienstverzeichnis. Ein Web Service meldet sich hier an und
stellt über eine eingereichte Dienstbeschreibung eine Übersicht der angebotenen
Funktionen bereit. Service Requester können diesen Broker abfragen und so an den
zutreffenden Web Service vermittelt werden. Der Einsatz eines Service Brokers ist
optional.
Die Funktionalität der Dienstbeschreibung, der Brokerabfrage und die Struktur der
Clientanfragen werden in den Folgekapiteln noch weiter detailliert.
Das Web-Service-Rollenmodell fasst die beschriebenen Entitäten und ihren Bezug
zueinander nochmals zusammen:
UDDI
Registry
Service
Broker
WSDL
UDDI
Service
Requester
SOAP
Client
Application
Service
Provider
Service
Implementation
Abb. 10 Web-Service-Rollenmodell
Eine andere Möglichkeit, die Architektur eines Web Service zu untersuchen, ist eine
Betrachtung der verschiedenen Ebenen einer Web-Service-Struktur im Schichtenmodell (vgl. Abb. 11). Letzteres lässt sich in fünf Ebenen unterteilen. Im Einzelnen
handelt es sich hierbei um die Elemente Discovery, Description, Packaging, Transport
und Network, welche die relevanten Aspekte der Struktur eines Web Service
widerspiegeln:
24
Discovery
UDDI
Description
WSDL
Packaging
Transport
Network
SOAP
HTTP
TCP/IP
Abb. 11 Web-Service-Schichtenmodell 30
In allen fünf Ebenen wurde in der Darstellung insbesondere ein spezifisches Protokoll
assoziiert, welches die übliche, aber nicht zwingend zu wählende Umsetzungsart
andeutet. Die Schichten dieses Modells bauen sequenziell aufeinander auf. Web
Services befinden sich aber bezüglich der eingesetzten Technologien in manchen
Bereichen noch innerhalb eines Standardisierungsprozesses, die hier genannten
Protokolle sind damit nicht als endgültige Standards zu sehen.
Die beiden unteren Ebenen adressieren die grundlegenden Aufgaben des Transports
über ein Netzwerk. Die drei höheren Schichten orientieren sich mehr an Leistungen
und Funktionen, die über die Datenübertragung hinausgehen.
Auf der untersten Ebene des Schichtenmodells erfolgt die Übertragung der
Kommunikationsdaten über das zugrunde liegende Netzwerk. Im Modell ist hier
beispielhaft das Transfer Control Protocol/Internet Protocol (TCP/IP) aufgeführt.
Hierbei handelt es sich um das Standardübertragungsprotokoll für die Internetkommunikation. Es wird hier aber nicht näher betrachtet. Vielmehr soll betont werden,
dass sich für die Datenübertragung durchgängig die Basistechnologien und Konzepte
der Internetkommunikation einsetzen lassen. Bei Verwendung eines Web Service sind
auf dieser Ebene der Kommunikation keine Eingriffe oder Veränderungen notwendig.
Auch auf der zweiten Ebene, dem Transport, werden Standardprotokolle eingesetzt.
Die Übertragungsverwaltung setzt auf den Funktionen der Netzwerkebene auf und
kann wahlweise mit HTTP, FTP, SMTP oder neueren Protokollvarianten umgesetzt
werden. Es handelt sich hierbei ebenfalls um standardisierte und weit verbreitete
Internetprotokolle.
30
Aus Tidwell/Snell/Kulchenko 2001, S. 10.
25
Web Services arbeiten also auf den unteren beiden Ebenen des Schichtenmodells mit
bestehenden und bekannten Technologien und verfügen hier über keine spezifischen
Eigenschaften. Auf den oberen drei Schichten können Web Services ebenfalls zumeist
an bestehende Technologien gekoppelt werden. Es wurden auf diesen Ebenen aber
auch speziell angepasste Protokolle und Sprachkonzepte entworfen, die Web-ServiceImplementierungen wesentlich prägen. Daher erfolgt nun eine detaillierte technologiegebundene Betrachtung der oberen drei Modellebenen Discovery, Description und
Packaging.
2.4.2 Erkennung (UDDI)
[Patrick Hennies]
Die Erkennungs- oder Entdeckungsschicht (Discovery) des Web-Service-Modells
wird durch UDDI repräsentiert. UDDI steht für Universal Description Discovery and
Integration und wurde ursprünglich von den Firmen Microsoft, IBM und Ariba
entworfen. Es wickelt, wie der Name andeutet, die Publikation und Entdeckung eines
Web Service ab. Daten, die in UDDI gehalten werden, sind in drei Kategorien, so
genannte Pages, eingeteilt.
•
In den White Pages werden allgemeine Informationen über Firmen abgelegt.
•
Klassifizierende Daten für entweder die Firma oder den bereitgestellten Dienst
sind Teil der Yellow Pages.
•
Inhalt der Green Pages sind technische Details zum Web Service, wie
beispielsweise der Verweis auf die Implementierung.
Das Datenmodell der UDDI-Architektur ist in Form eines XML-Schemas verfasst und
beschreibt die angebotenen Web Services. Es enthält Angaben über Business Entities,
welche die beteiligten Unternehmenseigenschaften repräsentieren. Assoziiert mit
diesen Unternehmen werden dann Business Services. Dies sind die von der BusinessEntität bereitgestellten Dienste und ihre Beschreibungen. Binding Templates, ebenfalls
Inhalt des Datenmodells, verweisen auf Spezifikationen und servicebezogene
Informationen und sind mit den Business-Service-Einträgen verbunden. Viertes und
letztes Element des Datenmodells sind Service Types (oft wird auch der Begriff
tModel verwendet). Diese sind ebenfalls Verweise auf (vornehmlich) technische
Spezifikationen. Diese Verweisart ist meist extern und kann von beliebig vielen
Instanzen referenziert werden, sofern die gleiche Technologie eingesetzt werden soll.
Ergänzend zum Datenmodell wird bei UDDI eine SOAP-basierte API eingesetzt,
welche Funktionen für das Suchen und Veröffentlichen von UDDI-Dateninhalten
anbietet.
26
Erwähnenswert in Bezug auf UDDI sind die Cloud Services. Hierbei handelt es sich
um Umsetzungen der UDDI-Spezifikation. Eine UDDI-Registrierung wird
bereitgestellt, an welcher Web Services angemeldet und gesucht werden können.
Anbieter eines solchen Dienstes sind IBM und Microsoft.
2.4.3 Beschreibung (WSDL)
[Patrick Hennies]
Eine weitere Technologie, die speziell für Web Services entwickelt wurde und eine
deutliche Stärke des Konzepts darstellt, ist die Web Service Description Language
(WSDL).31
Hierbei handelt es sich um eine Spezifikation zur Beschreibung eines Web Service.
Ein WSDL-Dokument ist in XML verfasst und unterliegt einer speziellen Grammatik.
Mittels dieses Dokuments kann ein Client die von einem Web Service angebotenen
Funktionen feststellen und aufrufen. Gemäß dem Web-Service-Rollenmodell ist das
WSDL-Dokument als Interface zwischen Client und Server zu interpretieren.
Die WSDL-Spezifikation unterteilt sich gemäß Abbildung 12 in sechs Kernelemente:
<definitions>
<types>: What Datatypes will be transmitted?
<message>: What Messages will be transmitted?
<portType>: What operations (functions) will be supported?
<binding>: How will the message be transmitted on the wire?
<service>: Where is the service located?
Abb. 12 WSDL-Spezifikation 32
•
31
32
Das definitions-Element ist die Wurzel des XML-basierten WSDL-Dokuments.
Es dient der Namensbezeichnung und enthält alle weiteren Elemente.
Vgl. WSDL – W3C Note 1.1, http://www.w3.org/TR/wsdl, 2001. Aufgerufen 02.07.2004.
Aus Cerami 2002, S. 104.
27
•
Datentypen, die in der Kommunikation verwendet werden können, sind im
types-Element abgelegt, üblicherweise in Anlehnung an die XML-SchemaVorgaben.
•
Nachrichten in eine Richtung werden mittels des message-Elements festgelegt.
Letzteres enthält ein oder mehrere part-Elemente, welche die Nachrichtenparameter festlegen.
•
Nachrichten werden im portType-Element gesammelt; einzelne Nachrichten
lassen sich so zu Operationen gruppieren.
Operationstypen umfassen verschiedene Kommunikationsvarianten wie
beispielsweise Einwegnachrichten (engl. One-way Messages) oder AnfrageAntwort-Nachrichten (engl. Request – Reply). Eine Anfrage-AntwortOperation, ähnlich einem RPC, ist die übliche Implementierung, wenn der
Transport mit dem SOAP-Protokoll realisiert wird.
•
Das binding-Element legt die Transferspezifikationen fest. Übliche
Alternativen für Übertragungsprotokolle sind HTTP POST/GET und SOAP.
•
Adressinformationen, im Wesentlichen die Adresse des Web Service, sind im
service-Element hinterlegt. Optional kann als Teil dieses Elements auch eine
Dokumentation der Bestandteile des WSDL-Dokuments gesetzt werden.
Ein großer Vorteil von WSDL-Dienstbeschreibungen ist, dass sie sich automatisch aus
dem eigentlichen Web Service generieren lassen und nur noch angepasst werden
müssen. Eine WSDL-Dienstbeschreibung ist nur ein optionales Element eines Web
Service, kann aber zu einer deutlichen Erleichterung der Interaktion mit dem Web
Service beitragen.
2.4.4 Nachrichtenformat (SOAP)
[Patrick Hennies]
Im Rahmen der Web-Service-Technologien übernimmt das Simple Object Access
Protocol (SOAP) die Aufgabe des Packaging und damit des Datentransfers über das
Netzwerk. Das SOAP-Protokoll ist ein Standard, der sich aus der XML-RPCSpezifikation der Firma Userland entwickelt hat. Es ist komplett in XML verfasst. Mit
der Verabschiedung des SOAP V1.1-Standards (aktuelle Version 1.2)33 durch das
W3C-Konsortium im Jahr 2000 begann SOAP sich erfolgreich durchzusetzen und
wurde bald von einer Vielzahl von Unternehmen eingesetzt.34 Das originäre Ziel war
33
Vgl. SOAP - W3C Recommendation Version 1.2, http://www.w3.org/TR/soap12-part0/, 2003.
Aufgerufen 02.07.2004.
34
Vgl. Newcomer 2002, S. 86.
28
ein möglichst einfaches Protokoll. SOAP wurde daher wie eine Erweiterung des
HTTP-Protokolls gestaltet. Anstatt aber statische HTML-Seiten abzurufen, werden
XML-Dokumente übertragen. Eine solche Kommunikation, bei der das
Nachrichtenformat in XML vorliegt, wird oft als XML-Messaging bezeichnet. Für die
Verarbeitung an den Kommunikationsendpunkten - im Rahmen von SOAP als SOAP
Nodes bezeichnet - muss ein SOAP-Prozessor das eintreffende XML-Dokument
bearbeiten.
Eine SOAP-Nachricht (vgl. Abb. 13) wird zunächst durch einen SOAP-Umschlag
(Envelope) repräsentiert; darin enthalten sind der Nachrichtenkopf (Header) und der
Nachrichtenkörper (Body).
Jeder Umschlag enthält genau ein Body-Element, in welchem die eigentliche
Nachricht abgelegt ist. Da eine SOAP-Nachricht in XML verfasst ist, sind auch die
Nachrichteninhalte des Body-Elements in XML gespeichert, sie enthalten aber keine
Schema- oder Verarbeitungselemente. Im Nachrichtenkopf sind Verarbeitungsinformationen für die SOAP-Nachricht enthalten. Routinginformationen sind ein
Beispiel für Headerinhalte. Header und Body können je nach Art und Anzahl der
Informationen in mehrere Blöcke eingeteilt sein.
Abb. 13 Das SOAP-Nachrichtenformat 35
SOAP-Nachrichteninhalte können auf zwei verschiedene Weisen strukturiert werden je nachdem, welche Anforderungen an die übertragenen Informationen gestellt
werden. Die beiden Varianten werden als „Document-Style“- und „RPC-Style“-SOAP
bezeichnet und spiegeln die in Kapitel 2.1.3 und 2.1.4 eingeführten Alternativen für
Kommunikationsprotokolle wider. Beim dokumentenorientierten SOAP werden
35
Aus Tidwell/Snell/Kulchenko 2001, S. 17.
29
SOAP-Nachrichteninhalte als komplettes Dokument betrachtet. Beim RPC-Style
SOAP werden über die SOAP-Nachricht Methoden angesprochen und deren
Parameter repräsentiert. Die Unterschiede werden in folgender Abbildung nochmals
beispielhaft betrachtet:
Rpc-style SOAP
<Envelope xmlns=“http://www.w3.org/2001/06/soap-envelope”>
<Header/>
<Body>
<LoadProject>
<ProjectName xsi:type=“string”>TeconeProjekt</ProjectName>
</LoadProject>
</Body>
</Envelope>
Document-Style SOAP
<Envelope xmlns=“http://www.w3.org/2001/06/soap-envelope”>
<Header/>
<Body>
<GetContract>
<from>
<person>Arno Rautmann</person>
<department>Einkauf</department>
</from>
<to>
<person>Arno Rautmann</person>
<department>Einkauf</department>
</to>
<itemtype>Contract</itemtype>
<Contract>Vertriebsleiter</Contract>
</getContract>
</Body>
</Envelope>
Abb. 14 RPC-Style und Document-Style SOAP
Wie deutlich zu erkennen ist, sind RPC-Style-Nachrichten deutlich knapper gehalten
und dienen ausschließlich zum Übertragen von Parametern für Methodenaufrufe. Die
Methode wird als ein XML-Element dargestellt und enthält die Parameter als weitere
Elemente.
Document-Style SOAP enthält Daten in semantischem Zusammenhang. Hiermit
können auch komplexe Strukturen übertragen werden. Wie schon zuvor bemerkt,
sollte hier keine Datentypisierung mittels eines Schemas erfolgen. Obwohl dies
möglich ist, kann dieses zusätzliche Schema die Grenze zwischen SOAP-Nachricht
und Dateninhalt verwischen und eine Verarbeitung der Nachricht erschweren.
30
Das SOAP-Protokoll ist so gehalten, dass es auch im Zusammenhang mit anderen
Kommunikationsprotokollen verwendet werden kann. Gegenwärtig ist aber nur das
HTTP-Protokoll explizit in der Spezifikation vermerkt. Da die SOAP-Spezifikation in
vielen Teilen nur hinweisenden Charakter hat, bestehen verschiedene und teilweise
zueinander inkompatible Implementierungen des SOAP-Protokolls.
Zusammenfassend ist das SOAP-Protokoll in der Lage, die gesamte Bandbreite der
Kommunikation - von einfachen Methodenaufrufen bis hin zum beliebig komplexen
Dokumentenaustausch - zu realisieren, auch wenn gegenwärtig ein einfacher
Methodenaufruf das überwiegende Einsatzfeld ist.36
2.5
Einführung in softwaregestützte Projektverwaltung
In diesem Kapitel erfolgt eine minimale Einführung in Grundlagenbegriffe
softwaregestützter Projektverwaltung, um die Bedeutung und Struktur der von der
Kommunikationslösung zu übertragenden Daten zu erläutern.
2.5.1 Projekte
[Hermann Nottelmann]
Nach DIN 69901 ist ein Projekt folgendermaßen definiert:
„Ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen
in ihrer Gesamtheit gekennzeichnet ist, z. B. Zielvorgabe, zeitliche, finanzielle,
personelle und andere Begrenzungen, Abgrenzung gegenüber anderen
Vorhaben und projektspezifische Organisation.“
2.5.2 Projektmanagement
[Hermann Nottelmann]
Nach DIN 69901 ist „Projektmanagement die Gesamtheit von Führungsaufgaben,
-organisation, -techniken und –mitteln für die Abwicklung eines Projekts.“
Die funktionale Seite des Projektmanagements befasst sich mit den drei Aspekten
Planen, Steuern und Überwachen. Zur Bewältigung dieser Aufgaben wird eine
Vielzahl von Methoden angeboten. Für diese Zwecke eignen sich in besonderer Weise
unterstützend softwarebasierte Werkzeuge.
36
Vgl. Tidwell/Snell/Kulchenko 2001, S. 27.
31
2.5.3 Bedeutung von Zeitphasendaten in Projekten
[Hermann Nottelmann]
Für ein effektives Projektmanagement ist eine vollständige und aktuelle Datenbasis
wichtig. Dies gilt insbesondere für die Aufwandserfassung bezogen auf die beteiligten
Ressourcen. So wird mit den Zeitphasendaten der personelle Aufwand der
Projektteilnehmer ermittelt. Die Erfassung der personellen Aufwände erfolgt
typischerweise dezentral durch den einzelnen Teilnehmer selbst. Wie in der Definition
des Projektbegriffs angedeutet, erfordert ein solches Szenario eine temporäre
projektspezifische Organisation. Diese unterscheidet sich insbesondere von der
regulären Organisation der beteiligten Unternehmen. Es findet eine abteilungs-,
bereichs-, sparten- oder unternehmensübergreifende Zusammenarbeit statt. Weiterhin
arbeitet das Projektteam üblicherweise nicht an einem gemeinsamen Ort, sondern
verteilt an verschiedenen Arbeitsplätzen.
Dieser vorgegebene Rahmen stellt besondere Anforderungen an die softwaregestützte
Zeitphasendatenerfassung. Die Software zur individuellen Aufwandserfassung muss
für jeden Projektteilnehmer zugänglich sein. Da es sich hierbei um eine regelmäßig
wiederkehrende Tätigkeit handelt, sollte auch im Sinne des Kostenmanagements eine
Softwarelösung eingesetzt werden, die auf weit verbreitete Standardsoftware im
unternehmerischen Umfeld aufsetzt. Denkbar sind an dieser Stelle beispielsweise die
Groupwarelösung Lotus Notes/Domino oder aber ein Webinterface.
Die dezentral erfassten Aufwände müssen zeitnah auf der Ebene des Projektmanagers
aggregiert werden und führen ggf. zu einer Revision des Projektplans. Diese
Korrekturen haben dann umgekehrt direkte Konsequenzen für den einzelnen
Projektteilnehmer. So verschieben sich möglicherweise die Vorgangsdauer, die
Abfolge von Vorgängen oder es findet eine Umordnung der zugewiesenen Ressourcen
statt.
Diese wechselseitigen Abhängigkeiten zwischen der Ebene der Projektteilnehmer und
der Steuerungsebene bedingen einen bidirektionalen Kommunikationsfluss. Zum einen
muss die Aggregation der verteilt erfassten Zeitphasendaten gegeben sein, zum
anderen muss in der Gegenrichtung eine Verteilung der aktualisierten Projektstrukturdaten erfolgen.
32
3 Kommunikation in verteilten Systemen
[Hermann Nottelmann]
Kommunikation in verteilten Systemen erfüllt den Zweck der Integration von
heterogenen Anwendungen oder Datenquellen. In diesem Kapitel wird eingangs die
Notwendigkeit zur Integration solcher Anwendungen und Datenquellen motiviert.
Bedingt durch die unterschiedliche Strukturiertheit von Daten wird auf die
Existenzberechtigung zweier verbreiteter Datenbankmodelle eingegangen. Diese
werden auf ihre Kompatibilität mit XML untersucht, da Letzteres als Austauschformat
fungieren soll.
Die Gegenüberstellung verschiedener Kommunikationsalternativen mündet in einem
Web-Service-basierten Kommunikationsmodell.
3.1
Integrationsaspekt der Kommunikation
3.1.1 Zielsetzung der Geschäftsprozessintegration
[Hermann Nottelmann]
Um in der heutigen Zeit in Anbetracht der starken Konkurrenzsituation am Markt
bestehen zu können, müssen Unternehmen ein hohes Maß an Flexibilität aufweisen.
Erfolgreich sind solche Unternehmen, die es verstehen, sich kurzfristig sowohl
produktionstechnisch also auch organisatorisch an geänderte Rahmenbedingungen
anzupassen.
Die Geschwindigkeit, mit der Leistungen am Markt platziert werden können, stellt
einen entscheidenden Wettbewerbsfaktor dar. Ermöglicht wird dies erst durch effizient
gestaltete Geschäftsprozesse, die möglichst einen kontinuierlichen Ablauf der
notwendigen Aktivitäten gewährleisten. In diesem Zusammenhang liegt das
Augenmerk auf den darunter liegenden Softwaresystemen, welche die fachlichen
Funktionen dieser Aktivitäten im Rahmen von Softwareanwendungen realisieren.
Auch die Unternehmensorganisation ist ständigen Veränderungen unterworfen.
Gründe hierfür sind unternehmensinterne Reorganisationsmaßnahmen oder aber
Geschäftsbeziehungen zu externen Partnern. Exemplarisch für erstgenannte
Veränderungen seien Fusionen und Übernahmen, für letztere strategische oder
temporäre Partnerschaften genannt.
Die Unterscheidung zwischen unternehmensinternen einerseits und unternehmensexternen Ressourcen andererseits ist allerdings für die Betrachtung der beteiligten
33
Informationssysteme im Rahmen von unternehmensübergreifenden Geschäftsprozessen nicht mehr zweckmäßig: Hier steht der gemeinsame und einheitliche Zugriff
auf Geschäftslogik und relevante Daten im Vordergrund.
Der geschäftsprozessgetriebenen Integration sowohl unternehmensinterner als auch
unternehmensexterner IT-Systeme wird somit eine besondere Bedeutung beigemessen.
3.1.2 Heterogene Systemarchitektur als Integrationstreiber
[Hermann Nottelmann]
Innerhalb einer Organisation sind Informationen auf eine Vielzahl heterogener
Informationsquellen verteilt. Solche sind z. B. Datenbanken, Dateisysteme, WorkflowSysteme, Enterprise Resource Planning (ERP)-Systeme, Data Warehouses oder
Document-Retrieval-Systeme. Hier hat eine unzureichende Planung der Unternehmensarchitektur zu einer Verbreitung von verschiedenen, häufig nicht kompatiblen
Systemen und Technologien geführt und so die Entwicklung zu Datensilos37
begünstigt.
In großen Unternehmen ist es indes häufig unvermeidbar, dass innerhalb der
Organisation eine Vielzahl unterschiedlicher Systeme zur Datengenerierung und –
haltung zum Einsatz kommt. Hier spielen Faktoren wie z. B. mangelnde Koordination
zwischen den Geschäftsbereichen, unterschiedliche Anpassungsraten bei der Ablösung
von Anwendungssystemen, Fusionen und Übernahmen oder die räumliche Distanz
zwischen in Projekten zusammenarbeitenden Gruppen eine Rolle.38
Bis vor kurzem war im betrieblichen Umfeld der Einsatz von monolithischen und
proprietären Softwaresystemen gebräuchlich. Auswahlentscheidungen für derartige
Anwendungen waren somit strategischer Natur, legte sich die Unternehmung doch
langfristig auf bestimmte vom jeweiligen Hersteller favorisierte Technologien fest und
ging somit ein gewisses Abhängigkeitsverhältnis ein.
Trotz der beschriebenen Nachteile versprach insbesondere das Konzept des Enterprise
Resource Planning (ERP) Abhilfe - zumindest bzgl. der organisationsinternen Datenhaltungsproblematik. Es basiert auf der Idee, dass organisationsweit eine zentrale
Datenbank zuständig für die Datenhaltung und sämtliche Transaktionen ist.39 Doch
auch diese Softwarepakete können nicht alle betrieblich notwendigen Funktionalitäten
bereitstellen, sodass weiterhin eine Vielzahl von ergänzenden Anwendungen zum
Einsatz kommt.
37
Vgl. Sharma/Stearns/Ng 2001, S. 5.
Vgl. Haas/Lin/Roth 2002.
39
Vgl. Kaye 2003, o. S.
38
34
Von Bedeutung ist weiterhin die Rolle von so genannten Legacy-Systemen. Typische
systemimmanente Defizite aus heutiger Sicht werden z. B. in (Dangelmaier et al.
2002, S. 64) beschrieben. Die Autoren führen darüber hinaus zwingende Gründe für
die Beibehaltung von Legacy-Systemen in neuen Integrationsstrukturen auf. So
enthalten solche Systeme erprobte Basisalgorithmen und Funktionalitäten der
Kerngeschäftsprozesse. Sie arbeiten stabil, sicher und weitgehend fehlerfrei.
Durch die hohen Investitionen in bestehende Systeme, vor allem in Legacy- oder ERPSysteme, und bedingt durch aktuell sinkende IT-Investitionen muss die
Interoperabilität zwischen neuen und bereits vorhandenen Systemen sichergestellt
werden. Insbesondere der Integration der bereits vorhandenen Systeme kommt eine
entscheidende Rolle zu:
“It is critical for enterprises to be able to leverage their investments on their
existing enterprise infrastructure and architecture.” 40
Vorangetrieben durch das Web hat indes ein massiver Technologieumbruch begonnen.
Die beschriebenen integrierten Standardanwendungspakete werden durch wesentlich
schlankere Applikationen abgelöst, die klar abgegrenzte Anwendungsfunktionen
übernehmen. Die Fokussierung der Softwareanbieter auf einen klar abgegrenzten
Bereich innerhalb der betriebswirtschaftlichen Unterstützungsfunktionen erlaubt die
Etablierung als Spezialist am Markt. Dieser Trend zur Modularisierung von
Anwendungssystemen in einzelne Bausteine und die damit häufig einhergehende
verteilte Datenhaltung lässt der Integration eine zentrale Rolle zukommen.
Ein weiterer Grund für den Integrationsbedarf ist in der Architektur des Webs zu
sehen: Das Intranet bzw. Internet ist durch die Punkt-zu-Punkt-Kommunikation
charakterisiert; prinzipiell ist es somit allen Knoten möglich untereinander zu
kommunizieren.
Im geschäftlichen Sektor wandelt sich die Funktion des Internets. Wurde das Internet
dort bis vor kurzem noch als Handelsplattform im B2B- bzw. B2C-Bereich begriffen,
dient es Unternehmen in zunehmendem Maße als Basis für verteilte Systeme.
Dem zunehmenden Wettbewerbsdruck versuchen die Unternehmen mit einer
Fokussierung auf Kernkompetenzen zu begegnen. Als Folge dieser Spezialisierung
kommt es zu Outsourcingvorgängen.41 Die relevanten Daten sind zunächst nur
innerhalb des Firmenintranets verfügbar, müssen aber für dieses Szenario auch extern
zugreifbar sein. Somit gewinnt die Integration mit solchen Geschäftspartnern immer
mehr an Bedeutung.
40
41
Vgl. Sharma/Stearns/Ng 2001, S. 13.
Vgl. ebenda, S. 5.
35
3.1.3 Konzept der Enterprise Application Integration
[Hermann Nottelmann]
Die geschäftsprozessgetriebene Integration sowohl unternehmensinterner als auch
unternehmensexterner IT-Systeme ist Aufgabe der Enterprise Application Integration
(EAI). In der Literatur findet sich eine Vielzahl von Definitionen der verschiedenen
Ausprägungen des EAI-Konzepts. Für die Zwecke dieser Arbeit ist indes die
Grundidee ausreichend, wonach es allen Systemen innerhalb und außerhalb der
Organisationsgrenze ermöglicht werden soll, Informationen und Logik miteinander
auszutauschen.42
Eine EAI-Lösung kann somit als Kommunikations- und Konvertierungsplattform43
begriffen werden. In (Dangelmaier et al. 2002) wird zudem das Merkmal der
Prozessorientiertheit betont und die Funktion von EAI mit dem Bild der
„Datendrehscheibe“ beschrieben (vgl. hierzu auch Abb. 15).
E-Commerce
ERP
CRM
E-Commerce
Legacy-Systeme
ERP
CRM
Legacy-Systeme
EAI-Plattform
Kunden-Datenbank
SOP
Produkt-Datenbank Call Center
Kunden-Datenbank
SOP
Produkt-Datenbank Call Center
Abb. 15 Applikationstopologie ohne und mit EAI 44
Der Grad der Integration wird in der Literatur typischerweise mittels eines 3-EbenenModells beschrieben45. Dabei handelt sich im Einzelnen, beginnend mit der
niedrigsten Stufe, um die Integration auf Daten-, Objekt- oder Prozessebene (vgl. Abb.
16). Die Charakterisierung der einzelnen Ebenen erfolgt in Anlehnung an
(Dangelmaier et al. 2002, S. 62 f.).
42
Vgl. Linthicum 1999, S. 6.
Vgl. Kaye 2003, o. S.
44
Aus Knuth et al. 2003, S. 379.
45
Vgl. Ring/Ward-Dutton 1999, o. S.; ähnlich Knuth et al. 2003, S. 383 f.
43
36
Aufgabe der Datenebene ist der Transport der relevanten Datenobjekte wie
beispielsweise Dateien oder Nachrichten von der Datenquelle zur Datensenke. Hier
liegt der Schwerpunkt auf dem sicheren und verlässlichen Transport der Datenobjekte
über unterschiedliche Systemplattformen hinweg.
In der Objektebene findet die Konvertierung der Daten der Quellanwendung in ein
bzgl. der Zielanwendung kompatibles Format unter Beibehaltung der Semantik statt.
Im Gegensatz zu der Punkt-zu-Punkt-Verbindung kann allerdings durch die EAIArchitektur die Anzahl der notwendigen Schnittstellen verringert werden.
Die Prozessebene bildet schließlich die Planungs- und Steuerungslogik der beteiligten
Geschäftsprozesse in der Integrationsplattform ab. Die Geschäftsprozessintegration ist
die am weitesten fortgeschrittene Form der EAI, ist aber aufgrund ihrer Komplexität
auch mit den höchsten Investitionskosten verbunden.
Die Auswahl der adäquaten Integrationsebene ist stark von den Anforderungen des
jeweiligen Unternehmens abhängig; eine Integration auf Daten- oder Objektebene
kann im Einzelfall durchaus ausreichend sein.
Abb. 16 Ebenen der Integration46
Im Rahmen dieser Arbeit wird nur die Integration auf Objektebene angestrebt.
Gleichwohl dient dieses Kapitel dazu, die zu entwickelnde Kommunikationslösung für
heterogene Systeme in den größeren Zusammenhang der Integrationsproblematik zu
stellen und sie als Grundlage für die Geschäftsprozessoptimierung begreifbar zu
machen.
XML und verwandte Technologien sind insbesondere für die Integration auf
Objektebene von großem Nutzen. XML kann zur Repräsentation von Daten wie auch
46
Aus Ring/Ward-Dutton 1999, o. S.
37
als Austauschformat zwischen Datenquellen benutzt werden. Diese beiden Funktionen
von XML werden in den nachfolgenden Kapiteln 3.2 bzw. 3.3 thematisiert. Weiterhin
können XML-Dokumente mittels der in Kapitel 2.3 beschriebenen Technologien
transformiert werden.
3.2
Paradigmen der Datenspeicherung
[Hermann Nottelmann]
Abhängig vom Grad der Strukturiertheit der vorliegenden Daten bieten sich alternative
Datenbankmodelle zu ihrer Speicherung an. Diese Arbeit fokussiert auf den beiden in
Kapitel 2.2 beschriebenen Modellen, dem semistrukturierten einerseits und dem
relationalen Datenmodell andererseits.
Im Rahmen dieses Kapitels soll nun das Verhältnis dieser Datenmodelle zueinander
herausgearbeitet werden. Es gilt insbesondere zu klären, in wieweit es
Überschneidungen oder aber klar abgegrenzte Einsatzfelder für die betrachteten
Datenmodelle gibt. Dies mündet in der Fragestellung, ob im Kontext der
Datenintegration der kombinierte Einsatz beider Datenmodelle sinnvoll ist.
3.2.1 Semistrukturierte Datenspeicherung
[Hermann Nottelmann]
Das semistrukturierte Datenmodell erfüllt zwei Funktionen im Rahmen der
Datenspeicherung47: Es dient als Dokumentenmodell zur gemeinsamen Nutzung von
verteilten Informationen. Es dient weiterhin als Integrationsmodell, indem ähnliche
Daten mit verschiedenen Schemata zweier oder mehrerer Datenbanken beschrieben
werden.
Insbesondere die erstgenannte Funktion macht den Fokus semistrukturierter
Datenspeicherung in Abgrenzung zu relationalen Datenbanken deutlich. Informationen
werden im Kontext von Dokumenten betrachtet. Dabei können zwei inhaltlich
ähnliche Dokumente unterschiedlich strukturiert sein. Bei relationalen Datenbanken
existiert hingegen keine vergleichbare Aggregationsform. Die Daten eines Dokuments
sind hier auf verschiedene Relationen der Datenbank verteilt.
Geschäftsprozesse im Bereich der Büroinformations- und Kommunikationssysteme
sind dokumentenbasiert.48 Semistrukturierte Datenmodelle eignen sich somit in
47
Vgl. Garcia-Molina/Ullman/Widom 2002, S. 173.
48
Vgl. Fischer et al. 2000, S. 288.
38
besondere Weise für den Austausch von Dokumenten unter dem Aspekt der
Geschäftsprozessintegration (vgl. Kapitel 3.1.1).
Eine Speicherung der in Dokumenten gehaltenen Informationen in relationalen
Datenbanken ist oftmals nicht möglich oder zweckmäßig, da der Kontext, in dem die
Informationen stehen, verloren ginge. So wird im zeitlichen Verlauf eines
Geschäftsprozesses auf die Informationen nur insgesamt als Dokument zugegriffen.
Der Umweg über eine relationale Datenbank wäre, wenn überhaupt, nur mit großem
Konvertierungsaufwand möglich.
Nachfolgend soll die Integrationsfunktion des semistrukturierten Datenmodells
betrachtet werden. Eine Vielzahl der in elektronischer Form vorhandenen
Informationen ist gerade nicht in relationalen Datenbanken abgelegt. Hierfür gibt es
hauptsächlich zwei Gründe: Diese sind zum einen modellimmanent, zum anderen
historisch bedingt.
Das relationale Datenmodell ist ungeeignet, Daten mit irregulärer bzw. unbekannter,
sich im Zeitverlauf ggf. verändernder Struktur aufzunehmen. Diese Kennzeichen
gelten aber gerade für die Vielzahl der Web-Dokumente. Die Entwicklung von
semistrukturierten Datenbanken ist daher im Zusammenhang mit der Ausbreitung des
Internets zu sehen.
Große Datenmengen sind nach wie vor in Legacy-Systemen abgespeichert oder liegen
nur in nicht standardisierten und anwendungsspezifischen Formaten vor. Instanzen des
semistrukturierten Datenmodells bieten hier im Gegensatz zu relationalen
Datenbanken durch den Verzicht auf ein singuläres Schema die nötige Flexibilität, um
die beschriebenen strukturell heterogenen Daten einheitlich abzubilden. Sowohl Daten
mit, als auch solche ohne erkennbare Struktur können gleichermaßen und gemischt
modelliert werden.
Die Umsetzung der Integrationsfunktion der semistrukturierten Datenspeicherung
unterscheidet sich grundlegend von der relationaler Datenbanken. Während Letztere
als zentrale, persistente Datenspeicher fungieren, beschränken sich die beiden
verbreiteten Instanzen semistrukturierter Datenmodelle OEM und XML auf eine
Vermittlertätigkeit. Sie ermöglichen den Informationsaustausch zwischen heterogenen
Datenquellen.49
Auch Lotus Notes/Domino lässt sich in den Kontext semistrukturierter Datenspeicherung einordnen, wenngleich es bereits mehrere Jahre vor der eigentlichen
49
Diese Sichtweise der Integration wird im Fall von OEM bereits durch den Namensbestandteil
„Austauschformat“ (engl. Exchange Model) impliziert und findet sich auch in (Papakonstantinou/
Garcia-Molina/Widom 1995) wieder.
39
Begriffs- bzw. Modellbildung produktiv eingesetzt wurde.50 Wichtig erscheint hier der
Hinweis, dass bei Lotus Notes/Domino die Integration der Daten auf einer höheren
Stufe stattfindet. Die semistrukturierten Daten sind auf Dokumente verteilt und in
einer einzigen Datenbankdatei abgespeichert. Als semistrukturiertes Datenbanksystem
bietet Lotus Domino/Notes weiterhin Mechanismen zur Aggregation bzw.
Manipulation der Daten. Ersteres wird hauptsächlich mit dem Ansichtenkonzept (engl.
View), Letzteres mit dem Formularkonzept (engl. Form) ermöglicht.
Daten innerhalb der Dokumente, wie auch alle anderen Elemente der Datenbank (z. B.
die angesprochenen Views und Forms), sind insbesondere selbstbeschreibend
abgelegt, sodass Teile der Datenbank ohne Kontextverlust leicht extrahiert werden
können. Dabei kann eine Konvertierung u. a. in ein XML-Dokument mit Notesspezifischen Auszeichnungen gemäß der so genannten Domino XML (DXL)
stattfinden. Dieser Umstand wird für die Implementierung ausgenutzt und in Kapitel 4
genauer dargestellt.
50
Vgl. Mohan et al. 2000.
40
3.2.2 Relationale Datenspeicherung
[Hermann Nottelmann]
Hauptzweck relationaler Datenbanksysteme ist die dauerhafte Speicherung großer
Datenmengen. Sie fungieren typischerweise als zentrale Datenspeicher innerhalb einer
Unternehmung.
Daten, die in einer relationalen Datenbank abgelegt werden sollen, müssen sich
allerdings durch das bereits vorhandene und für die Zwecke der Unternehmung
etablierte Datenbankschema komplett beschreiben lassen. Es kommt allenfalls eine
Erweiterung der bereits vorhandenen Relationenschemata in Betracht. Insofern sind
die Strukturanforderungen an die zu integrierenden Daten verglichen mit dem
semistrukturierten Datenmodell restriktiver. Diese Einschränkung bringt allerdings
auch eine Reihe von Vorteilen mit sich, wie nachfolgend aufgezeigt wird.
Durch die Strukturvorgabe, der die Daten durch ein externes Schema unterworfen
sind, können effiziente Datenstrukturen für die interne Datenorganisation benutzt
werden. Integritätsregeln stellen bei Änderungsoperationen die Konsistenz des
Datenbestands sicher.
Mittels Normalisierung lässt sich die Datenbank in eine redundanzarme Form bringen.
Die Trennung von Schema und Daten führt zu einer Reduktion der Datenredundanz.
Insgesamt fällt also im Vergleich zur semistrukturierten Datenspeicherung der
Speicherbedarf für die gleiche Menge an Daten erheblich geringer aus.
Die auf der Relationenalgebra beruhende Abfragesprache SQL erlaubt eine effiziente
Suche bzw. Manipulation der gespeicherten Daten. Hierauf aufbauend existieren
mächtige Werkzeuge für Auswertungen und Analysen. So können die in den einzelnen
Tabellen enthaltenen Informationen über die Schlüsselbeziehungen kurzfristig zur
Ableitung von neuen Erkenntnissen verdichtet werden. Diese Möglichkeiten werden
z. B. zur Ermittlung von Vorgangsattributen beim Durchrechnen von Projektplänen
benötigt.
Integrierte Sicherheitskonzepte erlauben einen kontrollierten Datenzugriff abhängig
von den Nutzerrechten. So lässt sich der Datenzugriff mittels so genannter Sichten
(engl. Views) nutzerabhängig auf eine Teilmenge des kompletten Datenbestandes
beschränken.
Relationale Datenbanksysteme ermöglichen typischerweise den parallelen Zugriff
einer großen Benutzerzahl auf den Datenbestand. Durch die Verwendung von Sperrund Transaktionsmechanismen kann die Datenkonsistenz dennoch sichergestellt
werden.
41
3.2.3 Koexistenz beider Paradigmen
[Hermann Nottelmann]
Die beiden diskutierten Paradigmen stellen aufgrund ihrer abweichenden Architektur
unterschiedlich hohe Anforderungen an die strukturelle Beschaffenheit der
aufzunehmenden Daten. Wie gezeigt wurde, adressieren sie in der Regel unterschiedliche Felder des Informationsmanagements. Je nach weiterem Verwendungszweck der
Daten ist die Entscheidung für eine Datenbanklösung entweder auf Basis des
relationalen oder eines semistrukturierten Datenmodells eindeutig vorteilhaft. Die
Datenmodelle ergänzen sich und haben insofern beide ihre Berechtigung.
Bestehende traditionelle Datenmodelle sind für ihre Zwecke oft hervorragend
optimiert. Dies gilt insbesondere für relationale Datenbanken. Das semistrukturierte
Datenmodell soll also nicht zur Ablösung dieser etablierten Datenmodelle benutzt
werden, sondern vielmehr die Integration in Form des Austauschs von Daten aus
heterogenen Datenquellen erleichtern.
Gerade im Kontext von temporären, häufig bereichs- oder unternehmensübergreifenden Organisationsformen bei der Arbeiten in Projekten ist dieser Integrationsansatz vorteilhaft. Da eine derartige projektbezogene Zusammenarbeit zeitlich
beschränkt ist und häufig nur einmaliger Charakter hat, wird typischerweise eine
kurzfristige, flexible Integration der bestehenden Datenquellen angestrebt und nicht
eine Speicherung sämtlicher Daten in nur einer zentralen Datenbank.
3.3
XML als Austauschformat
[Patrick Hennies]
Da beide Datenspeicherungsparadigmen ihre Existenzberechtigung haben, ist es
sinnvoll ein Zwischenformat, welches eine Verbindung zwischen beiden Ansätzen
ermöglicht, einzusetzen. Ein solches Format oder Datenmodell muss in der Lage sein,
semistrukturierte Daten abzubilden und gleichzeitig eine schematische Strukturierung
von gleichartigen Daten zu unterstützen.
Ein Ansatz eines semistrukturierten Datenmodells wird vom Konzept des Object
Exchange Model (OEM) verfolgt. Das wesentliche Merkmal des OEM ist seine
Selbstbeschreibungsfähigkeit. Es wird also keine vorgegebene Struktur und kein festes
Schema angesetzt. Stattdessen hat jedes Objekt sein eigenes Schema.51 Das OEM steht
stellvertretend für den Großteil der Ansätze von Austauschformaten. Der Schwerpunkt
51
Vgl. Papakonstantinou/Garcia-Molina/Widom 1995, S. 4.
42
solcher Ansätze liegt immer auf einer Festlegung von möglichst wenig Regeln, um
eine hohe Anpassungsfähigkeit zu gewährleisten. Ein besonderes Kennzeichen von
OEM ist seine Ausrichtung auf die Integration explizit heterogener Datenquellen.52
Die Umsetzung von OEM ist allerdings nicht standardisiert, was bei einem rechnerinternen Modell von Nachteil ist.53
XML, als ein graphbasiertes Datenmodell, ist in seiner Struktur den wesentlichen
Kennzeichen des OEM sehr ähnlich. Als Beschreibungssprache ist es datenunabhängig
und an keine festen Formate gebunden. XML-Elemente können gut mit den
„Objectnodes“ aus OEM verglichen werden – in beiden Fällen können die Inhalte eine
beliebige Struktur annehmen.54 XML wurde aber explizit definiert, um nicht nur
verschiedenartige Datenquellen zu verbinden, sondern auch standortübergreifend
unterschiedliche Kommunikationspartner zu integrieren.
Ein weiterer wesentlicher Unterschied zum OEM ist darin zu sehen, dass die Struktur
eines XML-Graphen in Textform vorliegt und damit auch für Menschen lesbar ist;
dies ist bei OEM nicht der Fall.
Diese Unterschiede kategorisieren XML damit nicht als rechnerinternes Datenmodell,
sondern als Schnittstelle zwischen Mensch und Maschine oder zwischen nur lose
gekoppelten Systemen. Die Struktur eines XML-Dokuments ist auch ohne explizites
Vorwissen oder genaue Vereinbarungen der Kommunikationspartner durch den
Empfänger les- und verarbeitbar.
Bei XML ist es des Weiteren möglich, komplexe Datentypen mittels Schema explizit
zu definieren. Es lassen sich also auch strukturierte Daten effektiv erfassen.
Aufgrund dieser Eigenschaften ist XML ein geeignetes Austauschformat zwischen
heterogenen Systemen bei internetbasierter Kommunikation.
Im Fall der hier betrachteten Kommunikation zwischen einer semistrukturierten und
einer relationalen Datenbank ist nun noch die Schnittstelle zwischen XMLDokumenten und den beiden Kommunikationsendpunkten zu betrachten.
52
Vgl. Abiteboul/Buneman/Suciu 2000, S. 19.
Vgl. Rahm/Vossen 2003, S.7-9.
54
Vgl. Wyke/Rehman/Leupen 2002, o. S.
53
43
3.3.1 Konvertierung zwischen XML und semistrukturierten Datenbanken
[Patrick Hennies]
“XML unites the worlds of documents and data, and transformation technology
is needed for both worlds: to put data into documents and vice versa and to
transform one document format to another.“ 55
Bei einer Speicherung von XML-Dokumenten in ein dokumentenbasiertes Datenbanksystem wie Lotus Notes ist keine explizite Konvertierung notwendig; die Strukturen
sind in ihren wesentlichen Merkmalen sehr ähnlich. Es ist in diesem Fall vielmehr die
interne Dokumentenrepräsentation anzupassen, damit das Dokument effektiv
verarbeitet werden kann.
Hierzu werden XML-Prozessoren eingesetzt, welche nach vorgegebenen Definitionen
die XML-Dokumente parsen und Informationen auslesen. Die zwei bekanntesten
Umsetzungen sind das Document Object Model (DOM) und die Simple API for XML
(SAX) und wurden bereits in Kapitel 2.3.3 eingeführt. DOM verfolgt einen
baumorientierten Verarbeitungsansatz, wohingegen SAX ein ereignisorientiertes
Interface bietet.
SAX hat den Vorteil durch die Ereignisorientierung bei zielgerichteten Operationen
speichereffizienter zu arbeiten, da durch das Auslösen von Ereignissen vermieden
werden kann, eine komplette Abbildung des geparsten Dokuments zu erzeugen und
das zu lesende Dokument auch nur genau einmal durchlaufen wird.
Beim DOM wird der erzeugte Parserbaum vollständig generiert, bevor weitere
Operationen beginnen. Er kann und muss dann mehrfach durchlaufen werden, was die
Speicherung umfangreicher Datenbestände effektiver verlaufen lässt als bei SAX.
Ein Generieren von XML-Dokumenten aus Lotus Notes heraus ist ähnlich einfach.
Die Struktur der Datenspeicherung einer dokumentenorientierten Datenbank und die
Struktur eines XML-Dokuments sind sehr ähnlich. Es ist hier somit automatisch
möglich aus Datenbankinhalten ein XML-Dokument zu erzeugen. Dieses Dokument
wird bezeichnet als Domino XML (DXL)-Dokument und stellt eine (partielle)
Repräsentation einer Lotus-Notes-Datenbank dar. Auch wenn dieses Dokument eine
recht spezielle XML-Struktur aufweist, ist es vergleichsweise einfach in eine
allgemeine XML-Form zu bringen. Diese Umwandlung wird anhand der
Konvertierungsbetrachtung zwischen XML und einer relationalen Datenbank näher
erläutert.
55
Vgl. Newcomer 2002, S. 59.
44
3.3.2 Konvertierung zwischen XML und relationalen Datenbanken
[Patrick Hennies]
Das Datenmodell eines XML-Dokuments ist in vielen Aspekten andersartig als die
Struktur, die in den meisten Datenbanksystemen verwendet wird. Es ist ein deutlich
aufwendigeres Konvertierungsverfahren notwendig, um XML-Daten aus relationalen
Datenbanken zu extrahieren oder darin zu speichern als bei einer semistrukturierten
Datenbank.
Aufgrund der weiten Verbreitung und Nutzung von XML bieten aber praktisch alle
Datenbanksysteme bereits Automatismen für solche Konvertierungsprozesse. Im
Rahmen dieser automatischen Verfahren werden oft sehr explizite Anforderungen an
das zu importierende XML-Dokument gestellt. Im Fall einer relationalen Datenbank
ist die Hauptanforderung, dass eine explizite Repräsentation der XML-Dokumentenstruktur in Form eines Schemas vorliegen muss. Die Inhalte eines XML-Dokuments
können mittels des Schemas auf das relationale Datenbankschema abgebildet werden.
Dies ist notwendig, da in einer relationalen Datenbank Daten und deren Beschreibung
explizit getrennt gehalten werden. Um die Eignung von XML als Metaformat
zwischen semistrukturierten und relationalen Datenformaten zu unterstreichen, ist es
zuvor sinnvoll, eine Unterteilung von XML-Dokumenten in datenorientiert und
dokumentenorientiert vorzunehmen.
Dokumentenorientierte XML-Dokumente enthalten zumeist unstrukturierte oder nur
teilweise strukturierte Daten. Dokumentenorientierte XML-Dokumente benötigen kein
strukturierendes Schema. Eine DXL-Repräsentation der Daten einer Lotus NotesDatenbank ist ein Beispiel für ein dokumentenorientiertes XML-Dokument. Felder
eines dokumentenorientierten XML-Dokuments können variable Daten enthalten,
ohne dass diese festzulegen sind. Es kann daher im Voraus keine Annahme über den
Dateninhalt getroffen werden. Daten, die aus semistrukturierten Datenbanken
stammen, fallen üblicherweise in diese Kategorie.
Datenorientierte XML-Dokumente sind hingehen klar strukturiert und haben ein stark
spezifiziertes Schema. Sie sind potentiell komplexer als dokumentenorientierte XMLDokumente. Im Gegensatz zu dokumentenorientierten XML-Dokumenten sind hier
feste Vorgaben über Auftreten und Struktur der Dokumenteninhalte festgelegt.
Abbilder von Inhalten einer relationalen Datenbank sind typischerweise datenorientierte XML-Dokumente. Die nachfolgende Abbildung gibt ein Beispiel für
datenorientiertes und dokumentenorientiertes XML.
45
Data oriented
<invoice>
<orderDate>1999-01-21</orderDate>
<shipDate>1999-01-25</shipDate>
<billingAddress>
<name>Ashok Malhotra</name>
<street>123 Microsoft Ave.</street>
<city>Hawthorne</city>
<state>NY</state>
<zip>10532-0000</zip>
</billingAddress>
<voice>555-1234</voice>
<fax>555-4321</fax>
</invoice>
Document oriented
<memo importance='high' date='1999-03-23'>
<from>Paul V. Biron</from>
<to>Ashok Malhotra</to>
<subject>Latest draft</subject>
<body> We need to discuss the latest
draft<emph>immediately</emph>.
Either email me at <email>mailto:[email protected]</email>
or call <phone>555-9876</phone>
</body>
</memo>
Abb. 17 Daten- und dokumentenorientiertes XML56
Wie bereits beschrieben, bieten relationale Datenbanken Funktionen zum Erzeugen
und Importieren von datenorientierten XML-Dokumenten. Eine genauere Betrachtung
dieses Prozesses erfolgt im Rahmen der Implementierung in Kapitel 4.
Konzeptuell ist also bei einer Kommunikation zwischen einer semistrukturierten und
einer relationalen Datenbank die Umwandlung eines dokumentenorientierten in ein
datenorientiertes XML-Dokument notwendig. Der wesentliche Schritt vom
dokumentenorientierten zum datenorientierten XML ist die Schaffung einer klaren
Struktur mittels eines Schemas.
Eine Umwandlung eines XML-Dokuments wird mit der Extensible Stylesheet
Language (XSL) durchgeführt. Eine Komponente der XSL-Sprache ist der XSLTransformer (XSLT), der es erlaubt, unterschiedliche Darstellungen eines Dokuments
zu generieren oder Daten von einem XML-Format in ein anderes umzuwandeln.
XSLT funktioniert sowohl mit DOM als auch mit SAX. Es ist hiermit möglich, einem
56
Darstellung in Anlehnung an das W3C-Konsortium.
46
unstrukturierten Dokument ein strukturierendes Schema anzufügen oder Dateninhalte
umzuformatieren.
Um die Vollständigkeit der Repräsentation des XML-Dokuments im Hinblick auf den
relationalen Datenbankimport sicherzustellen, haben (Kappel, Kapsammer und
Retschitzegger)57 in ihrem Konzeptvergleich zwischen XML und relationalen
Datenbanksystemen sechs Kennzeichen definiert, welche in der Schemaerzeugung
berücksichtigt werden sollten.
57
•
Strukturierung und Typisierung
In einem XML-Schema wird die Struktur des Dokuments mit Hilfe von
Elementtypen und zugeordneten Attributen erzeugt. In relationalen
Datenbanken arbeiten Relationen und zugeordnete Attribute vergleichbar. Im
Wesentlichen lassen sich im XML-Schema durch Vererbung und
Elementenkombinationen deutlich komplexere Typen von Entitäten erzeugen
als für ein relationales Datenbanksystem vorgesehen sind.
•
Einzigartigkeit von Bezeichnern
Relationen dürfen mit gleicher Bezeichnung nicht mehrfach in einem
relationalen Datenbanksystem (RDBS) auftreten. Ebenso wenig erlaubt ein
XML-Schema eine Mehrfachbezeichnung. Es sollte allerdings vermieden
werden, dies im XML-Schema mit Hilfe von Namensräumen oder
Symbolräumen, welche eine gleiche Namensgebung innerhalb jeder Instanz
ermöglichen, zu umgehen.
•
Nullwerte und Defaultwerte
Null- und Defaultwerte sind auch in XML-Dokumenten vorgesehen. In einem
RDBS bezieht sich diese Möglichkeit nur auf Attribute - bei XMLDokumenten wird dies auf Elemente ausgeweitet. Auch Kardinalitäten lassen
sich in XML bestimmen.
•
Identifikation
Identifikation im RDBS funktioniert über Primärschlüssel. Im XML-Schema
sind Schlüssel ebenfalls vorgesehen und können auch eindeutig bestimmt
werden. Sie sind aber im Gegensatz zum relationalen Modell nicht zwingend
erforderlich.
•
Beziehungen
Die Funktionsweise von relationalen Fremdschlüsseln wird in XML mithilfe
des Keyref-Konzepts realisiert, das durch Element- bzw. Attributverweise
ähnlich einer Fremdschlüsselrelation verwendet wird.
Vgl. Kappel/Kapsammer/Retschitzegger 2001.
47
•
Reihenfolge und Ordnung
Es ist zu beachten, dass bei XML-Dokumenten sowohl eine explizite als auch
eine implizite Ordnung bestimmt werden kann. Explizit durch Verwendung des
Elementtyps Sequence und implizit durch die relative Position im Dokument.
Es bestehen Ansätze, solche Anforderungen an ein XML-Schema automatisch zu
prüfen und gegebenenfalls umzusetzen. Augenblicklich ist die Konvertierung
allerdings noch manuell mittels eines XSL-Stylesheets durchzuführen.
3.3.3 Zusammenfassung
[Patrick Hennies]
Es wurde in der vorangegangenen Betrachtung aufgezeigt, auf welche Weise es
möglich ist, Daten aus den jeweiligen Kommunikationsendpunkten einer
semistrukturierten und einer relationalen Datenbank in Form von XML zu extrahieren
oder sie darin zu speichern. Zusätzlich zur großen Ähnlichkeit von semistrukturierten
Datenbankinhalten und XML-Dokumenten wurde festgehalten, dass auch relationale
Datenbanken der Bedeutung von XML durch Kompatibilitätsunterstützung Rechnung
tragen. Das Konzept unterschiedlicher XML-Strukturformate wurde eingeführt und es
wurde im Anschluss daran erläutert, welche Möglichkeiten sich bieten, die beiden
betrachteten Darstellungsformen in die jeweils andere umzuwandeln.
Auch wenn XML der De-facto-Standard in Bereich des Datenaustauschs geworden ist,
sind XML-Dokumente in der Regel nicht gleichartig und es bedarf einer Umwandlung, um eine vollständige Kompatibilität zu anderen Applikationen zu
gewährleisten. Dennoch hat die Verbreitung und Nutzung eines stark standardisierten
Formats wie XML wesentlich zur Erleichterung der Datenkommunikation beigetragen.
48
3.4
Kommunikation
[Patrick Hennies]
Das Ziel dieses Kapitels ist der Vergleich verschiedener Möglichkeiten die eigentliche
Kommunikationslösung zu realisieren. Dieser Vergleich wird geschlossen mit einer
genaueren Analyse des gewählten Implementierungskonzepts.
Das entscheidende Merkmal einer das Internet als Infrastruktur nutzenden
Kommunikation ist, dass es sich hierbei um ein verteiltes System handelt. Gerade bei
der Interaktion innerhalb eines verteilten Systems ist eine organisatorische Steuerung
des miteinander Kommunizierens notwendig. Wie in Kapitel 2.1.2 eingeführt wurde,
ist in diesem Fall der Einsatz einer Middleware sinnvoll. Als Ergänzung der
Kommunikationsinfrastruktur ermöglicht es eine Middleware verteilen Anwendungen,
bekannte und lokale Techniken und Operationen zu nutzen. Die Middleware
übernimmt den Ausgleich der Hard- und Softwareunterschiede und die Kommunikationsverwaltung.
3.4.1 Kommunikationsalternativen
[Patrick Hennies]
Im nachfolgenden Kapitel werden vier Integrationsalternativen für die Umsetzung der
Kommunikation verglichen. Es wird ein Vertreter einer rein nachrichten- bzw.
transaktionsbasierten Middleware betrachtet, die Remote Method Invocation (RMI).
Mit CORBA folgt dann die Untersuchung einer verbreiteten, objektorientierten
Lösung. Microsofts DCOM, die dritte Alternative, ist ebenfalls objektorientiert und
wird vornehmlich als Grundlage für die Weiterentwicklung im Rahmen der .NETEntwicklungsumgebung von Microsoft betrachtet. Als letzte Alternative folgt das hier
favorisierte Konzept der Web Services, welches sich von den vorherigen Alternativen
unter anderem durch seinen stärkeren Abstraktionscharakter unterscheidet.
49
3.4.1.1 Java RMI
[Patrick Hennies]
RMI ist eine Java-basierte RPC-Erweiterung. Ihre Struktur ist im Gegensatz zum
klassischen RPC objektorientiert. Sie ist lauffähig auf einer Java Virtual Machine
(JVM), einer systemunabhängigen Java-Umgebung. Damit ist RMI zwar
systemunabhängig, aber gleichzeitig an eine bestimmte Programmiersprache
gebunden. Zusätzlich zu der Eigenschaft auf einer objektorientierten (Java-) IDL zu
basieren, müssen sich Serverobjekte im Gegensatz zum RPC noch an einer so
genannten RMI-Registry anmelden und dort ihre Dienste veröffentlichen. Die
Interface-Definition sowie die Methodenaufrufe laufen über diese Registry. RMI
verwendet also eine Broker-basierte Architektur und eine Kommunikation wird mittels
einer Interaktion des Clients und lokalen Proxies realisiert. Zusammenfassend lässt
sich RMI im Wesentlichen als objektorientierter Java-RPC bezeichnen. Vor allem
durch die häufige Verwendung von Java-basierten Lösungen hat RMI breitere
Anwendung finden können. Die nachfolgende Abbildung betont nochmals die
Ähnlichkeit der RMI-Kommunikation zum RPC.
Abb. 18 Java RMI-Kommunikationsstruktur 58
58
Aus Tari/Bukhres 2001, S. 21.
50
3.4.1.2 CORBA
[Patrick Hennies]
In CORBA (Common Object Request Broker Architecture) wird der Begriff der
Objektorientierung sehr streng interpretiert. CORBA wurde von der Object
Management Group (OMG) entworfen. In der ursprünglichen Version lag der Schwerpunkt auf der Definition einer Interface Definition Language (IDL), welche die
Systemunabhängigkeit unterstützten sollte. Der Object Request Broker (ORB) ist eine
Entität, die es Objekten ermöglicht, transparent Anfragen und Antworten in einem
verteilten Umfeld zu stellen und zu empfangen.59 Diese Funktionalität wird im
Wesentlichen durch vier Elemente sichergestellt.
•
Common Object Services – Basisdienste wie beispielsweise Ereignisverwaltung.
•
Common Frameworks – Objektgruppen der Common Object Services, sortiert
nach Anwendungsbereich. Ein Beispiel sind Dienste, die sich mit der
Agentenverwaltung befassen.
•
Domain Objects – Geschäftsobjekte, welche domänenspezifische
Modelldefinitionen bereitstellen. Sie nutzen Common Frameworks und
Common Object Services.
•
Application Objects – Anwendungsspezifische Objekte, welche aus allen
vorhergehenden Kategorien zusammengestellt werden können.
Anfragen von Clients an den Server werden in CORBA über eine Objektreferenz auf
das Serverobjekt realisiert. Der Object Request Broker sucht dann die dem Objekt
zugehörige Implementierung und stellt eine Verbindung her. Die CORBA IDL verfügt
mittlerweile auch über Schnittstellen zu vielen gängigen Programmiersprachen.
CORBA ist somit plattformübergreifend einsetzbar, sofern eine ORB-Implementierung von dieser Plattform unterstützt wird (vgl. Abb. 19).
59
Vgl. Myerson 2002, o. S.
51
Abb. 19 CORBA – ORB-Architektur 60
3.4.1.3 DCOM und .NET Remoting
[Patrick Hennies]
Das Component Object Model (COM) ist eine von Microsoft stammende
Entwicklungsumgebung für Windows. Das Grundkonzept im COM-Modell ist das
COM-Objekt, eine Erweiterung von klassischen Objekten zu einer Component. Der
Begriff Component steht hierbei für eine Gruppierung mehrere Objekte und das
Bereitstellen entsprechender Zugriffsinterfaces.
DCOM (Distributed COM) ist die Erweiterung des COM-Modells für verteilte
Umgebungen. DCOM funktioniert auf ähnliche Weise wie CORBA und verwendet
wie alle vorherigen Alternativen eine Broker-Methodik. Anders als bei RMI oder
CORBA werden jedoch explizit temporäre Verbindungen bevorzugt. Anfragen werden
via RPC gestellt und beantwortet, wobei DCOM anders als COM zwingend
objektorientierte RPCs verwendet. Das Interface wird mit der MIDL (Microsoft
Interface Definition Language) beschrieben; hier bestehen ähnliche Wahlmöglichkeiten und Beschränkungen wie bei der CORBA IDL.
COM, und damit auch DCOM, sind trotz ihrer hohen Komplexität aufgrund der
marktbeherrschenden Position der Windows-Plattform weit verbreitet.
.NET Remoting ist die Weiterführung der Entwicklung von DCOM im Rahmen der
Microsoft .NET-Umgebung. Auch wenn noch nicht viele Umsetzungen mit dieser
60
Aus Tari/Bukhres 2001, S. 46.
52
Technik bestehen, ist sie in ihre Funktionsweise weitestgehend deckungsgleich zu
DCOM.
Die COM-Weiterentwicklung COM+ ist ebenfalls Teil des .NET Frameworks. In
beiden Fällen bestehen Schnittstellen für die Migration der älteren auf die neue
Umgebung.
Ein großer Vorteil beim Einsatz von .NET-Remoting im Vergleich zu DCOM ist, dass
hier keine spezielle IDL mehr verwendet wird, sondern diese Funktion vielmehr als
Teil der so genannten .NET Assemblies realisiert wird. Diese Assemblies benötigen
keine weitere Formatierung und können direkt in Anwendungen eingebunden werden.
.NET Remoting ist damit weniger systemabhängig und schwächer gekoppelt als sein
Vorgänger. Die Kommunikationsarchitektur von .NET Remoting unterteilt sich in
Proxyobjekte, Kanalobjekte und Nachrichten. Die Proxyobjekte arbeiten auf die in
Kapitel 2.1.2 beschriebene Weise, wobei das serverseitige Proxyobjekt als
Stackbuilder bezeichnet wird. Die Kanalobjekte dienen der Abstraktion der zugrunde
liegenden Kommunikationsverbindung und verfügen über einen Formatter, um einund ausgehende Nachrichten, je nach Art des gewählten Kommunikationskanals, zu
bearbeiten.
Abb. 20 .NET Remoting – Übersicht 61
Die .NET-Architektur integriert auch das Konzept der Web Services, der vierten
betrachteten Alternative, und wird, da sie auch als Grundlage der Implementierung
gewählt wurde, im 4. Kapitel näher betrachtet.
3.4.1.4 Web Services
[Patrick Hennies]
61
Aus Barnaby 2002, S. 109.
53
Web Services sind eine Weiterentwicklung der bisherigen Alternativen; sie
unterscheiden sich allerdings deutlich in einigen Eigenschaften. Operierend auf einer
höheren Abstraktionsebene als die anderen Middleware-Technologien verwenden
Web Services eine RPC-Emulation und arbeiten mittels asynchronen Nachrichtenaustauschs. Sie sind mehr als Konzept zu verstehen denn als tatsächliche
Implementierung und lassen sich auf bestehende Applikation aufsetzen.
Das Besondere an Web Services ist, dass sie die Technologiegrenzen überwinden
können und nicht von einer bestimmten Programmiersprache oder einem Datenformat
abhängen. Sie arbeiten in einer nur lose gekoppelten Architektur - im Gegensatz zu
CORBA und DCOM, die eine vergleichsweise stärkere Kopplung erfordern. Das
Erzeugen eines ORB ist somit beispielsweise nicht mehr notwendig.62 Dies wird
realisiert mittels einer durchgängigen Verwendung von XML. Web Services gestatten
es auf der Client- und Serverseite unterschiedliche Kommunikationsimplementierungen einzusetzen und miteinander zu verbinden. Trotz ihrer nachrichtenbasierten
und asynchronen Struktur sind Web-Services-Implementierungen aber auch dazu
fähig, eine Anfrage-Antwort-synchrone Kommunikation bereitzustellen. Sie lassen
sich daher auch auf Technologien wie CORBA oder DCOM aufsetzen.63
Besonders im Hinblick auf Applikationsintegration bieten die XML-basierten Web
Services große Vorteile. Es lassen sich Dienste und Anwendungen verschiedenster Art
unter einem Web Service zusammenfassen. Gleichzeitig bietet XML den Standard für
Informationsaustausch und erzwingt durch seine weite Verbreitung auch eine
Unterstützung durch alle wesentlichen Kommunikationsteilnehmer.
Als Kritik an Web Services ist allerdings zu bemerken, dass diese Fähigkeiten
eigentlich nicht neu sind. CORBA und DCOM haben mit der Strategie der verteilten
Objekte schon viel früher ein sehr ähnliches Ziel verfolgt. Hinzu kommt, dass es
gegenwärtig noch mehrere konkurrierende „Standards“ für verschiedene Aspekte der
Web-Service-Architektur gibt. Die Technologie ist jung; es wird wohl auch noch
einige Zeit dauern, bis sich definitive Standards für alle Aspekte durchgesetzt haben.64
Es war nicht primäres Ziel des vergangenen Kapitels eine detaillierte Einführung in
alle existierenden Technologien zu geben. Vielmehr sollten nach einem kurzen
Einstieg vor allem die Ähnlichkeiten der verbreiteten Umsetzungen aufgezeigt
werden. In Relation hierzu wurde dann das neue Konzept der Web Services gesetzt,
was andere, aber bei genauerer Betrachtung nicht immer neue Ansätze in diese
Thematik einbringt.
62
Vgl. Myerson 2002, o. S.
Vgl. Newcomer 2002, S. 8-32.
64
Vgl. Linthicum 2003, o. S.
63
54
3.4.2 Kommunikationskonzept
3.4.2.1 Auswahlentscheidung
[Hermann Nottelmann, Patrick Hennies]
In dem vorangegangenen Kapitel wurden vier verbreitete Möglichkeiten aufgezeigt
eine verteilte Kommunikation zu implementieren. Die Auswahlentscheidung erfolgt
zugunsten von Web Services, da diese eine maximale Unabhängigkeit in Bezug auf
einzusetzende Technologien und Protokolle gewährleisten und damit die flexibelste
Alternative darstellen.
Diese Unabhängigkeit wird erreicht durch eine intensive Nutzung bestehender,
standardisierter und allgemein anerkannter Formate und Protokolle. Es wird auf die
existierende Web-Infrastruktur aufgesetzt, ohne deren Protokollsatz durch zusätzliche
proprietäre Standards auszudehnen. Web Services lassen sich somit als eine das Interund Intranet überbrückende Lösung einsetzen. Eine Kommunikation kann auch
ausschließlich über den HTTP-Port 80 ablaufen und somit sind keine einschneidenden
Änderungen, beispielsweise in unternehmensinternen Sicherheitsroutinen, notwendig.
Ein weiterer De-facto-Standard, den Web Services intensiv nutzen, ist die
Beschreibungssprache XML.
Die durchgängige Verwendung von XML ist einer der zentralen Vorteile von Web
Services. XML wird auf allen Ebenen der Architektur eingesetzt und ist somit Basis
für die Erkennung, Beschreibung, Formatierung und den Austausch von Daten. Der
Kommunikationsfluss zwischen der semistrukturierten und relationalen Datenquelle
kann durchgängig mittels XML-Dokumenten durchgeführt werden (siehe Kapitel 3.3).
Es entfallen zusätzliche Konvertierungen in Zwischen- oder Übertragungsformate.
Durch ihre offene Struktur sind Web Services auch dazu fähig heterogene
Architekturen zu verbinden. Anders als bei eng gekoppelten Systemen können also
Client und Server auf andersartigen Plattformen laufen. Die Erweiterbarkeit wird
hiermit deutlich gestärkt, da neue Kommunikationspartner leicht und ohne wesentliche
Anpassungen mit dem Web Service in Kontakt treten können. Gerade Zeitphasendaten
in Projekten werden oft verteilt erfasst und haben einen zeitlich befristeten,
kurzfristigen Charakter. Ein Web Service ist somit die bestmögliche
Implementierungsalternative.
55
3.4.2.2 Modellcharakteristika
[Hermann Nottelmann, Patrick Hennies]
Ausgangspunkt dieser Arbeit war die Realisierung einer webbasierte Kommunikation
und Integration zwischen Microsoft Enterprise Project Management und PAVONE
TimeTracking. Hierbei handelt es sich allerdings weniger um eine interaktive
Kommunikation, sondern vielmehr um eine reine Informationsübertragung. Auch die
Kommunikationspartner sind nicht die eigentlichen Anwendungen, sondern die
zugrunde liegenden Datenbanksysteme. Es handelt sich also um eine Datenübertragung zwischen Lotus Notes/Domino - einer dokumentenbasierten, semistrukturierten Datenbank - und einer relationalen Datenbank auf einem Microsoft SQL Server.
Der Kommunikationsverlauf hat in der Theorie die folgende Form:
Es wird ein Projekt inklusive aller Vorgänge angelegt und die wesentliche Struktur des
Projekts mit allen relevanten Terminen bestimmt. Diese Eingaben erfolgen in Microsoft Project.
Dieses erstellte Projekt in Form der Projektstrukturdaten wird nach Lotus Notes bzw.
PAVONE TimeTracking übertragen.
Hier werden im Projektverlauf tatsächliche Daten von Projektteilnehmern erfasst und
eingetragen. Zu beliebigen Zeitpunkten erfolgt dann eine Rückübertragung der
erfassten Zeitphasendaten eines Projektteilnehmers zurück nach Microsoft Project.
Zusammenfassend findet also eine bidirektionale Kommunikation statt. Nicht nur in
der Form, dass Parameter für eine Anfrage übertragen werden, sondern dass zwei
unterschiedliche und gegenläufige Informationsflüsse bestehen, die zeitlich
auseinander fallen. Abbildung 21 fasst diesen Ablauf zusammen.
PAVONE
MS-Project
3
Projektdaten
einlesen
2
Projektdaten
übertragen
1
Projekt anlegen
4
Tatsächliche Daten
werden erfasst
5
Erfasste Daten
übertragen
6
Projekt
aktualisieren
…
Abb. 21 Kommunikationsverlauf in der Übersicht
56
Nachdem eine einführende Betrachtung beider Kommunikationsteilnehmer und des
theoretischen Kommunikationsverlaufs erfolgt ist, soll im Folgenden das resultierende
Kommunikationsmodell skizziert werden. Eine detaillierte Betrachtung der
Modellimplementierung erfolgt dann in Kapitel 4.
Sowohl die in der Lotus Notes-Datenbank gehaltenen Aufwandsdaten, also auch die in
der relationalen Datenbank abgelegten Projektstrukturdaten lassen sich mit den in
Kapitel 3.3 beschriebenen Mechanismen in einem XML-Dokument ablegen. Es wurde
dort auch aufgezeigt, dass Inhalte von XML-Dokumenten - sofern sie bestimmte
Strukturanforderungen erfüllen - ebenfalls automatisiert in die jeweilige Datenbank
eingelesen werden können.
Die Übertragung der XML-Dokumente übernimmt ein Web Service. Dieser basiert auf
der Client-Server-Architektur. Der Server stellt Funktionen bereit, welche vom Client
angefragt werden können (siehe Kapitel 2.1.1). Im Detail wurde aufseiten des
Microsoft SQL Servers der Server implementiert, während Lotus Notes-seitig die
Clientanfragen erzeugt werden. Für die Übertragung wird das standardmäßig mit Web
Services assoziierte SOAP-Protokoll verwendet. Auf den Einsatz eines UDDIDienstes wird verzichtet, da eine Entdeckung von Diensten aufgrund gegenseitiger
Kenntnis der Kommunikationspartner hinfällig ist. Die Kommunikation erfolgt direkt.
Die Entscheidung für die Lage des Servers beruht auf einem wesentlichen
Charakteristikum der Zeitdatenerfassung. Aufwände werden mittels Lotus Notes von
den Projektteammitgliedern explizit dezentral erfasst, um dann gebündelt in die
relationale Datenbank transferiert zu werden. Anschließend lassen sich in Microsoft
Project, basierend auf der nun aktualisierten Datenbasis, Projektstrukturanpassungen
vornehmen. Die Aufteilung der Web-Service-Struktur spiegelt diesen Zusammenhang
wider (Abb. 22).
Web Service
XML
Soap
XML
Pavone
Abb. 22 Web-Service-Kommunikationsmodell
Server
NSF
Client
Project
XML
SQL
57
Der Server übernimmt in der Kommunikation die Aufgabe, Daten aus der SQLDatenbank zu erfragen oder sie in dieser zu speichern. Es werden hierzu vom Client
spezifische Methoden aufgerufen und bei Bedarf wird vom Client das entsprechende
XML-Dokument mitgesendet. Bei einer Anfrage nach den Projektstrukturdaten aus
Microsoft Project wird vom Server als Antwort ein strukturiertes XML-Dokument
zurückgeliefert. In der Gegenrichtung speichert der Server die Inhalte des erhaltenen
Dokuments in der Datenbank. Wie in Kapitel 3.2 aufgezeigt, ist für den XML-Import
in eine relationale Datenbank ein durch ein Schema beschriebenes XML-Dokument
notwendig. Das XML-Schema wandelt ein dokumentenorientiertes in ein datenorientiertes XML-Dokument um.
Der Umwandlungsprozess wird allerdings bereits clientseitig durchgeführt. Dies
begründet sich in der Tatsache, dass eine Umwandlung eines XML-Dokuments mittels
XSLT manuell zu erfolgen hat. Da aber eine Vorgabe gewesen ist, möglichst wenige
Strukturannahmen über Client und Server zu treffen, kann der Server nicht von einer
einheitlichen Struktur der vom Client erhaltenen Daten ausgehen. So könnte man sich
zum Beispiel auch eine Zeitdatenerfassung mittels Web-Interface als Alternative zu
der Implementierung PAVONE TimeTracking vorstellen. Dies würde eine
andersartige Datenstruktur zurückliefern, welche der Server dann nicht verarbeiten
könnte. Eine generische Erzeugung von Konvertierungsmechanismen ist mittels
heutiger Konzepte noch nicht möglich. Es müsste also für jede mögliche Alternative
eine Implementierung im Server hinterlegt werden. Dies ist allerdings aufwendiger als
eine clientseitige Umwandlung, da hier bei der Erzeugung der XML-Dokumente
ohnehin bereits ein Konvertierungsprozess abläuft, der nur ergänzt werden muss.
3.5
Limitationen und Entwicklungspotenziale
[Hermann Nottelmann]
Web Services sind eine relativ neue Technologie und unterliegen daher in Teilen
ständigen Veränderungen. Einige Bestandteile befinden sich zum jetzigen Zeitpunkt
noch in einem frühen Entwicklungsstadium und sind in mancher Hinsicht noch nicht
ausgereift. Es bleibt aber festzustellen, dass den beteiligten Standardisierungsgremien
durch die eingesetzten Arbeitsgruppen ein Steuerungsinstrument an die Hand gegeben
wurde, welches die Weiterentwicklung von weithin akzeptierten Technologiebausteinen durch ihre Standardisierungsbestrebungen forciert. Trotz der beschriebenen
Einschränkungen wird allgemein ein großer Erfolg für Web Services vorhergesagt.65
Als grundlegendes Element des Erfolgs ist jedoch die breite Akzeptanz der
verabschiedeten Standards anzusehen.
65
Vgl. Cerami 2002, S.24-26
Description
WSDL
Packaging
Transport
Network
SOAP
HTTP
Quality of Service
UDDI
Management
Discovery
Security
58
TCP/IP
Abb. 23 Erweitertes Web-Service-Schichtenmodell
Das erweiterte Web-Service-Schichtenmodell von Abbildung 23, dessen linke Säule
dem Web-Service-Schichtenmodell aus Kapitel 2.4.1 entspricht, führt drei wesentliche
Aspekte im Zusammenhang mit der nachrichtenbasierten Kommunikation auf, die
somit auch für Web Services relevant sind und die in einer finalen
Implementierungsstufe einer solchen Kommunikationslösung Berücksichtigung finden
sollten. Es handelt sich hierbei im Einzelnen um Sicherheit sowie Management und
Quality of Service. Diese werden in Kapitel 3.5.1 respektive 3.5.2 behandelt.
3.5.1 Sicherheit
[Hermann Nottelmann]
Es empfiehlt sich für die Auseinandersetzung mit der Sicherheit von Web Services,
zunächst von der Implementierungsseite zu abstrahieren und allgemeine Sicherheitscharakteristika nachrichtenbasierter Kommunikation zu betrachten66:
Neben dem Identitätsnachweis der Kommunikationsendpunkte mittels Authentifizierung und Autorisierung basierend auf Rechten spielt die Unleugbarkeit (engl.
Non-Repudiation) eine wichtige Rolle.
Im vorliegenden Fall liegt der Fokus von Web Services auf der Integration von
verteilten Datenquellen; die Unleugbarkeit sichert in Verbindung mit der Revision
(engl. Auditing) die eindeutige Bestimmung des Urhebers von Änderungen am
Datenbestand zu einem beliebigen späteren Zeitpunkt. Hier werden Technologien wie
beispielsweise digitale Signaturen eingesetzt.
Bezüglich der ausgetauschten Nachrichten muss deren Integrität gesichert werden; auf
Empfängerseite muss der Nachrichteneingang in unverfälschter Form gewährleistet
66
Vgl. in Teilen Hartman et al., S. 95-96.
59
sein. Die Vertraulichkeit (engl. Confidentiality) der übermittelten Inhalte wird
typischerweise durch Verschlüsselungstechniken sichergestellt.
Bestehende verbindungsorientierte Sicherheitsimplementierungen sind nur bedingt für
die Anforderungen einer Web-Service-Architektur geeignet. Auf einen Web Service
wird typischerweise über das Internet zugegriffen. Der Weg der Nachrichten ist im
Vorfeld nicht bekannt bzw. kann sich im Kommunikationsverlauf verändern; daraus
erwachsen bestimmte zu adressierende Sicherheitsrisiken. Es handelt sich hier genauer
um die Forderung nach der End-to-End-Sicherheit.67 Dies bedeutet, dass die
verschiedenen Sicherheitsaspekte unabhängig von der gewählten Route vom Sender
bis zum Empfänger gewährleistet sein müssen.
Bezüglich der SOAP-Nachricht ist es deshalb zweckmäßig, Header und Body bei der
Konzeption einer Sicherheitslösung getrennt voneinander zu betrachten. Während der
Header ggf. auch von zwischengeschalteten Einheiten, den so genannten Intermediaries ausgewertet wird, ist der eigentliche Nachrichteninhalt nur für den
Empfänger bestimmt.
Es geht darüber hinaus um die Schaffung eines Sicherheitskontextes, der nicht nur auf
den einmaligen Nachrichtenaustausch beschränkt ist. Dazu müssen sicherheitsrelevante Informationen innerhalb der SOAP-Nachricht mit dem Inhalt verknüpft sein.
Die XML-Prägung der Web-Service-Architektur setzt sich auch in ihrer Erweiterung
um Sicherheitsaspekte vorangetrieben durch Standardisierungsgremien fort. Bislang
existiert mit der Web Services Security68 allerdings nur eine sehr allgemein gehaltene
Spezifikation der OASIS bezüglich der Sicherheit von SOAP-Nachrichten. Diese
überträgt im Wesentlichen die beiden, zuvor für den allgemeinen XML-Kontext
entwickelten, Standards XML Signature69 und XML Encryption70 auf Web Services.
Erstgenannter Standard wurde gemeinschaftlich vom W3C und der IETF entwickelt
und adressiert den Sicherheitsaspekt der Datenintegrität mithilfe digitaler Signaturen.
Beim Letztgenannten geht es um die teilweise Verschlüsselung von XMLDokumenten. Grundlage hierfür bilden die im allgemeinen Sicherheitskontext
verwendeten etablierten Verschlüsselungsprotokolle.
67
Vgl. Web Services Architecture, W3C Working Group Note, 11 Feb 2004. Aufgerufen 02.07.2004.
Vgl. Web Services Security 1.0 (WS-Security 2004), OASIS Standard 200401, March 2004.
Aufgerufen 02.07.2004.
69
Vgl. XML-Signature Syntax and Processing, W3C Recommendation, 12 Feb 2002. Aufgerufen
02.07.2004.
70
Vgl. XML Encryption Syntax and Processing, W3C Recommendation, 10 Dec 2002. Aufgerufen
02.07.2004.
68
60
Der Web-Services-Security-Standard bildet den Ausgangspunkt für eine Reihe
weiterer, noch im Entstehungsprozess befindlicher, herstellerunabhängiger Standards
bzw. Spezifikationen.71
3.5.2 Management und Quality of Service
[Hermann Nottelmann]
Im Kontext verteilter Systeme basierend auf dem Internet als infrastruktureller
Grundlage ist eine Vielzahl von Fehler- bzw. Ausnahmeszenarien denkbar. Um die
Qualität der beteiligten Web Services zu erhöhen, ist es notwendig, zum einen die
Fehlerhäufigkeit zu reduzieren und zum anderen die Qualität der im Fehlerfall
bereitgestellten Informationen zu erhöhen. Quality-of-Service-Eigenschaften sind im
Kontext von Web Services eng mit dem Aspekt der Verlässlichkeit (engl. Reliability)72
verknüpft.
Von zentraler Bedeutung aufgrund der Kommunikationsform von Web Services ist die
verlässliche Nachrichtenübertragung. Die Forderungen an eine solche sind:
•
Garantierte Auslieferung der Nachricht beim Empfänger; andernfalls wird das
Scheitern der Auslieferung dem Sender mitgeteilt.
•
Jede Nachricht wird genau einmal ausgeliefert. Duplikate werden als solche
erkannt und gelöscht.
•
Korrekte Nachrichtenreihenfolge. Die Nachrichten kommen beim Empfänger
in der Reihenfolge an, wie sie vom Sender abgeschickt wurden.
Sichergestellt wird dies typischerweise durch eine Abfolge von Nachrichtenbestätigungen (engl. Acknowledgements) zur Empfangs- bzw. Validitätsbestätigung.
Das Web Services Reliable Messaging Protocol73 und Web Services Reliability74 sind
hier als Ergebnis standardvorbereitender, herstellerspezifischer Bemühungen zu
nennen.
Auf einer höheren Aggregationsstufe wird die Etablierung eines Transaktionsmanagements bezweckt. Web-Service-Management beruht auf der Idee, dass alle Web
Services standardisierte Methoden bereitstellen, über welche diese gemäß vorhandener
Zugriffsrechte kontrolliert und gesteuert werden können.
71
Eine Übersicht findet sich u.a. in (Hartman et al., S. 95-96).
Vgl. Web Services Architecture, W3C Working Group Note, 11 Feb 2004. Aufgerufen 02.07.2004.
73
Vgl. Web Services Reliable Messaging Protocol (WS-ReliableMessaging), March 2004. Aufgerufen
02.07.2004.
74
Vgl. Web Services Reliability (WS-Reliability), Vers. 1, 8 Jan 2003. Aufgerufen 02.07.2004.
72
61
4 Prototypische Realisierung des Kommunikationsmodells
[Patrick Hennies]
Für die Erläuterung der technischen Umsetzung der einzelnen Komponenten der
Kommunikationsstruktur wird nochmals das Modellbild aus Kapitel 3.4.2.2
untersucht.
3
2
1
Kommunikation
PAVONE TimeTracking
Microsoft Project
XML
Soap
XML
Server
NSF
Client
Project
XML
SQL
Pavone
Abb. 24 Web-Service-Kommunikationsmodell (modifiziert)
Dieses Modell lässt sich für eine technische Betrachtung in drei Grundelemente
unterteilen:
1. Microsoft Project, auf dessen Seite der Web-Service-Server implementiert ist,
die SQL-Datenbank liegt und auf welcher ein Web Server die Anbindung an
das Internet ermöglicht.
2. PAVONE TimeTracking, welches aus Lotus Notes heraus operiert und zu
welchem auch der Web-Service-Client zählt.
3. Das Kommunikationselement, welches insbesondere das Format der
übertragenen Nachrichten detailliert und die technische Umsetzung der
Schnittstellen betrachtet.
In diesem Kapitel wird vor allem die technische Umsetzung des gewählten Modells
beschrieben. Hierzu werden zunächst die drei Teilelemente des Kommunikationsmodells in ihren technischen Bausteinen erläutert und ihre Nutzung in der
Implementierung gezeigt. Im Anschluss wird der Kommunikationsverlauf (nochmals)
62
mittels Screenshots detailliert. Geendet wird mit einer Übersicht der getroffenen
Annahmen und gegenwärtigen Beschränkungen der Implementierung sowie
Installations- und Konfigurationshinweisen.
4.1
Microsoft Project
XML
DataSet
Web
Anfragen
Web Service
[Patrick Hennies]
ADO
DataAdapter MS-SQL
MS-Project
Projektdaten
.NET Framework
IIS
Abb. 25 Technisches Kommunikationsmodell - Teil 1
Dies ist eine Detaillierung des rechten Teils des Kommunikationsmodells, also der
Seite, auf welcher die relationale Datenbank und der Web Service liegen.
Zur Implementierung des Web Service ist zunächst ein Web Server einzusetzen.
Dieser ermöglicht die Erreichbarkeit des Web Service aus dem Internet. Da sowohl
Microsoft Project als auch der Microsoft SQL Server auf der Windows-Plattform
basieren, lag es nahe, für die prototypische Entwicklung den Microsoft Internet
Information Server (IIS) - welcher bei Windows XP und 2000 bereits integriert ist - zu
verwenden. Aufsetzend auf dem Web Service wurde das, ebenfalls von Microsoft
entwickelte, .NET Framework als Entwicklungsumgebung ausgewählt. Mittels des
.NET Frameworks wird die Anbindung an die SQL-Datenbank realisiert und die Daten
für den Web Service extrahiert. Microsoft Project wird nicht über den Framework
angesprochen, sondern ist direkt an die Datenbank angebunden. Projektdaten werden
dort in Tabellenform direkt eingespeichert.
63
Das .NET Framework, die Speicherung der Projekttabellen durch Microsoft Project
und die eingesetzten Werkzeuge der Entwicklungsumgebung werden in den
Folgekapiteln 4.1.1 und 4.1.2 näher betrachtet.
4.1.1 Microsoft Project Datenmodell
[Patrick Hennies]
Projektdaten, welche in Microsoft Project erfasst werden, speichert das Programm
üblicherweise in einem eigenen Format. Microsoft Project hat allerdings auch die
Möglichkeit integriert, mittels einer ODBC-Verbindung in Datenbanksysteme, insbesondere SQL-basierte, zu speichern, was für größere Projekte und damit auch
größere Datenmengen sinnvoll ist.
Microsoft Project legt in der SQL-Datenbank bei dieser Speichermethode insgesamt
29 Tabellen an, welche die gesamten Inhalte wiedergeben. Für die abgelegte
Projektstruktur und die Zeitphasendaten sind allerdings nur 5 Tabellen unmittelbar
relevant.
Hierbei handelt es sich um die Tabellen MSP_PROJECTS, MSP_RESOURCES,
MSP_TASKS, MSP_ASSIGNMENTS und MSP_TIMEPHASED_DATA.
•
MSP_PROJECTS
In dieser Tabelle werden Informationen zum angelegten Projekt gespeichert.
Allerdings sind hier keine Informationen zu Projektbeteiligten oder der
Projektstruktur hinterlegt. Für die Implementierung wurden nur zwei Felder
bearbeitet: PROJ_NAME, in welchem der Projektname hinterlegt ist und
PROJ_EXT_EDITED. Dieses Feld muss bei einer externen (also nicht aus
Microsoft Project heraus erfolgten) Änderung an der Datenbank gesetzt
werden, damit Microsoft Project über die Änderungen informiert ist und sie
verarbeiten kann. Fast alle Tabellen, die externe Bearbeitung unterstützen,
besitzen ein solches Feld. Ebenso verfügen alle 5 relevanten Tabellen über ein
UID-Feld. Dies steht für Unique ID und ist der Tabellenprimärschlüssel.
•
MSP_RESOURCES
In der MSP_RESOURCES-Tabelle sind alle Informationen über beteiligte
Ressourcen, also Personal oder Maschinen, hinterlegt. Im vorliegenden Fall
werden nur personelle Ressourcen betrachtet. Wichtig sind hier das
Namensfeld und das Arbeitsleistungsfeld der Ressource sowie der
Fremdschlüsselverweis auf das Projekt, welchem der Mitarbeiter zugeordnet
ist. Die Tabelle wird allerdings nicht bearbeitet; es wird nur der
Primärschlüssel durch einen Namensvergleich ausgelesen.
64
•
MSP_TASKS
Hier sind die Projektvorgänge gespeichert. Informationen wie geplante(r/s)/
tatsächliche(r/s) Start / Ende sind Inhalte dieser Tabelle. Wichtige Felder des
Prototyps waren die TASK_ID, welche die Reihenfolge der Tasks wiedergibt,
der TASK_OUTLINE_LEVEL und das TASK_IS_SUMMARY-Feld, die
zusammen mit der TASK_ID dann die gesamte Vorgangshierarchie inklusive
aller Sammelvorgänge abbilden können. Meilensteine werden über das
TASK_IS_MILESTONE-Feld gekennzeichnet.
•
MSP_ASSIGNMENTS
Diese Tabelle enthält die Assignments, also die Zuweisung einer Ressource zu
einem Vorgang. Sie verweist mittels Fremdschlüsseleinträgen auf die zugehörigen MSP_RESOURCES- und MSP_TASKS-Einträge. Die bereits von
einer Ressource an der Aufgabe geleistete sowie die noch verbleibende Arbeit
sind in dieser Tabelle gespeichert. Sie werden durch die Felder ASSN_WORK
(geplante Arbeit), ASSN_ACT_WORK (geleistete Arbeit), ASSN_REM_
WORK (noch zu erledigende Arbeit) ausgedrückt. Diese Felder werden durch
den Prototyp auch extern angepasst, sollte sich die in PAVONE TimeTracking
erfasste Arbeit über oder unter den geplanten Wert begeben oder sollte ein
Assignment vorzeitig beendet werden.
•
MSP_TIMEPHASED_DATA
Dies ist die Tabelle, in welcher die eigentlichen Zeitphasendaten abgelegt sind.
Zeitphasendaten lassen sich entweder für eine Ressource, einen Vorgang oder
eine Zuweisung erfassen. Daher wird in dieser Tabelle zunächst mittels
TD_CATEGORY die Datenart festgelegt und dann mit TD_REF_UID der
Fremdschlüssel auf die jeweilige Tabelle gesetzt. TD_START und
TD_FINISH bestimmen die Dauer der Zeitphase, während mit TD_UNITS die
zugrunde liegende Einheit gewählt wird. Möglich sind Minuten, Stunden,
Tage, Wochen, Monate oder Jahre. In TD_FIELD_ID wird die Art der
Zeitphasendaten (noch ausstehende Arbeit, tatsächliche Arbeit etc.) festgelegt.
In den Feldern TD_VALUE 1-7 folgen dann die tatsächlichen
Zeitphasen-daten-Werte. Der Großteil der Daten aus PAVONE TimeTracking
wird über neue Einträge in dieser Tabelle transferiert.
Abbildung 26 fasst die verschiedenen Tabellen mit den relevanten Feldern und den
zugehörigen Fremdschlüsselrelationen zusammen.
65
MSP_PROJECTS
MSP_ASSIGNMENTS
PROJ_ID
ASSN_UID
PROJ_NAME
TASK_UID
TASK_UID
PROJ_EXT_EDITED
RES_UID
PROJ_ID
[…]
PROJ_ID
TASK_NAME
EXT_EDIT_REF_DATA
TASK_OUTLINE_LEVEL
ASSN_START_DATE
MSP_RESOURCES
RES_UID
PROJ_ID
ASSN_FINISH_DATE
ASSN_WORK
ASSN_ACT_WORK
RES_NAME
ASSN_REM_WORK
RES_WORK
[…]
[…]
MSP_TIMEPHASED_DATA
TD_UID
PROJ_ID
TD_FIELD_ID
TD_CATEGORY
TD_REF_UID
TD_START
TD_FINISH
TD_UNITS
TD_VALUE1-7
TD_EXT_EDITED
[…]
Abb. 26 Datenmodell Microsoft Project
MSP_TASKS
TASK_IS_MILESTONE
TASK_IS_SUMMARY
TASK_WORK
TASK_ID
[…]
66
4.1.2 .NET Framework
[Patrick Hennies]
Als Grundlage für die Implementierung des Web Service wurde das .NET Framework
von Microsoft ausgewählt. Mit Visual Studio .NET stand hier eine mächtige
Entwicklungsumgebung bereit. Das Framework war als Kernelement der .NETPlattform-Strategie von Microsoft, besonders im Hinblick auf Schnittstellen gut
dokumentiert.
Die Architektur des .NET Frameworks stellt sich wie folgt dar:
.NET Framework Components
Web Services
ASP.NET
ADO.NET
Base Class Library
Common Language Runtime
Abb. 27 Architektur .NET Framework 75
Die Common Language Runtime (CLR) ist eines der zentralen Elemente des .NET
Frameworks und verantwortlich für die Ausführung und Verwaltung des kompilierten
Codes. Aufgaben wie Garbage Collection und das Laden der erforderlichen
Basisklassen sind Funktionen, die typischerweise die CLR übernimmt. Dies ist
vergleichbar mit der Java Virtual Machine bei RMI.
Die Basisklassen (Base Class Libraries) stellen die wichtigsten Grundfunktionalitäten
vorgefertigt bereit. Die Objektorientierung ist elementarer Bestandteil des Frameworks. Neue Klassen erben üblicherweise von der Klasse System.Object. Weitere
wichtige Klassen sind System.Data, welche Funktionen für den Daten(bank-)zugriff
75
Aus Johnson et al. 2002, S. 55.
67
bereitstellt und System.Web, mittels welcher ASP.NET-Seiten generiert werden
können.
4.1.2.1 ADO.NET
[Patrick Hennies]
Der Zugriff auf die Funktionen der Klasse System.Data wird im Framework mittels
ADO.NET durchgeführt. ADO.NET ist eine Weiterentwicklung der ActiveX Data
Objects (ADO), wobei die Namenserweiterung um .NET im Wesentlichen die
Anbindung an Microsofts neue Plattform und eine stärkere Objektorientierung betont.
ADO bildet die Schnittstelle zu Datenbanksystemen und hat bereits alle Funktionen
für Zugriffe auf OLE-DB- und SQL-Datenquellen integriert.
ADO.NET
Data Providers
DataAdapter
Connection
Command
Data Consumers
DataSet
Web Forms
Web Service
DataReader
Abb. 28 ADO.NET-Objektmodell76
Die ADO.NET-Klassen sind unterteilt in Datenprovider (Data Providers), welche die
Verbindung zum Datenbanksystem aufbauen, im vorliegenden Fall also zu der SQLDatenbank, und Datenkonsumenten (Data Consumers), dem Web Service. Innerhalb
des Aufgabenbereichs der Datenprovider wird zunächst ein Connection-Objekt
erzeugt, welches die Verbindung zum Datenbanksystem aufbaut.
baseConnection = new SqlConnection
("server=(local); database=XMLTest; Trusted_Connection=yes");
Abb. 29 Connection-Objekt
76
Aus Riordan 2002, S. 8.
68
Mittels eines DataAdapters werden dann Anfragestrukturen auf die Datenbank
abgebildet. Der DataAdapter ist das komplexeste Element der Datenprovider, da er die
Zusammenführung von Datenbank und DataSet realisiert. Dem DataAdapter werden
Command-Objekte zugewiesen. Diese stellen die typischen Datenbankoperationen dar.
Es gibt Select-, Update-, Delete- und InsertCommands. Diese Befehle können
automatisch erzeugt oder manuell formuliert werden.
Die folgende Abbildung stellt dar, wie in der gegenwärtigen Implementierung eine
einfache Formulierung des Update-Befehls auf einer der betrachteten Datenbanktabellen aussieht.
resourceAdapter0 = new SqlDataAdapter
("SELECT * FROM MSP_PROJECTS", updateConnection);
SqlCommand resourceAdapter0UpdateCmd = new SqlCommand
("Update MSP_PROJECTS set PROJ_EXT_EDITED = @pPROJ_EXT_EDITED,
PROJ_OPT_EXPAND_TIMEPHASED = @pPROJ_OPT_EXPAND_TIMEPHASED
where PROJ_ID = @pPROJ_ID", resourceAdapter0.SelectCommand.Connection);
resourceAdapter0.UpdateCommand = resourceAdapter0UpdateCmd;
Abb. 30 DataAdapter UpdateCommand
Das wichtigste Element der ADO-Architektur ist zweifelsfrei das DataSet. Hierbei
handelt es sich um ein Speicherabbild von Inhalten der Datenbank. Ein DataSet ist
prinzipiell eine vereinfachte Version einer relationalen Datenbank - allerdings
losgelöst von der Datenquelle. Ein DataSet bildet die (gesamte) inhaltliche Struktur
der Datenbank in XML ab. Es enthält Tabellenelemente, Reihenelemente und
(optional) Beschränkungselemente. Datentypen werden über ein Inlayschema
abgebildet. Ein DataSet bildet die ideale Basis für eine XML-basierte
Datenübertragung, da es bereits Funktionen bereitstellt, seine Informationen in einem
XML-Dokument abzuspeichern, und dieses Dokument dann direkt übertragen werden
kann. Für Updateoperationen auf der Datenbank ist die Nutzung eines DataSets
ebenfalls vorteilhaft. Änderungen können zunächst auf einem DataSet durchgeführt
werden, ohne dass bereits direkt die Datenbank geändert wird. Wurden alle Updates
korrekt durchgeführt, können die bearbeiteten Tabellen vollständig und in konsistenter
Form zurückgeschrieben werden.
69
<?xml version="1.0" encoding="utf-8"?>
<DataSet xmlns="http://tempuri.org/">
<xs:schema id="NewDataSet" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:Locale="de-DE">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element name="MSP_RESOURCES">
<xs:complexType>
<xs:sequence>
<xs:element name="RESERVED_DATA" type="xs:string" minOccurs="0" />
<xs:element name="PROJ_ID" type="xs:int" minOccurs="0" />
<xs:element name="RES_UID" type="xs:int" minOccurs="0" />
<xs:element name="RES_TYPE" type="xs:boolean" minOccurs="0" />
<xs:element name="RES_HAS_NOTES" type="xs:boolean" minOccurs="0" />
<xs:element name="RES_CAN_LEVEL" type="xs:boolean" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"
xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
<NewDataSet xmlns="">
#***Actual values would be stored here***#
</NewDataSet>
</diffgr:diffgram>
</DataSet>
Abb. 31 DataSet - Beispiel
4.1.2.2 ASP.NET
[Patrick Hennies]
ASP.NET vereinigt die bisher benannten Elemente des Frameworks. Mittels ASP.NET
werden Web Forms dynamisch erzeugt. Das besondere an ASP.NET ist die so
genannte code behind-Struktur. Code behind steht für eine lokale Trennung der
Programmlogik und des präsentierten Outputs, wobei das Output im Fall von
ASP.NET zumeist eine HTML-Seite ist.
Web Services sind im Rahmen des .NET Frameworks in ASP.NET integriert und
können auf die gleichen Funktionen und Schnittstellen zugreifen. ASP.NET adressiert
aber ein wesentlich weiteres Problemfeld als das hier vorliegende und soll im Rahmen
dieser Arbeit daher nicht betrachtet werden.
4.1.2.3 Visual Studio .NET
[Patrick Hennies]
Visual Studio .NET ist die von Microsoft veröffentlichte Entwicklungsumgebung zum
.NET Framework und wurde zur Erstellung des Web-Service-Prototypen eingesetzt.
70
Es integriert bereits die eigens als Teil des .NET Frameworks entwickelte Sprache C#
(C-Sharp), welche syntaktisch eng mit Java verwandt ist. Es ist natürlich auch möglich
andere Programmiersprachen wie beispielsweise Visual Basic .Net oder C++
einzusetzen. Für diese Arbeit wurde C# ausgewählt. Die nachfolgende Beschreibung
eines Web Service orientiert sich durchgängig an der C#-Syntax.
Einen Web Service zu generieren wird durch Visual Studio erleichtert, da viele
Grundlagenaufgaben übernommen werden. Hierzu legt Visual Studio .NET fünf
unterstützende Programmdateien an.
•
AssemblyInfo.cs
Diese Informationsdatei regelt den Zugriff des Compilers auf so genannte
Assemblies. Eine Assembly ist ein Bibliothekselement und bündelt Typen und
Ressourcen, stellt diese dann der CLR bereit und kann von Anwendungen
referenziert werden.
•
Global.asax
Die Ereignisbehandlung auf Anwendungsebene und Verwaltung übergeordneter Elemente werden in dieser Datei festgehalten.
•
Web.Config
Ein XML-Dokument, welches Konfigurationseinstellungen speichert.
Eventuelle Erweiterungen oder Add-Ins können hier eingesetzt werden. (Siehe
Web Service Enhancements im Kapitel 4.3.2)
•
[WebServiceName].asmx
Über diese Datei, die den Namen des Web Service trägt, wird eine Verbindung
zum Web Service hergestellt. Sie ist mehr als kompilierte und
programmiersprachenabstrakte Schnittstelle zu verstehen und verweist gemäß
der ASP.NET code behind-Struktur auf die Datei in der spezifischen
Programmiersprache.
•
[WebServiceName].asmx.cs
Diese Datei enthält den eigentlichen Programmcode und wird von der asmxDatei referenziert. Das cs weist in diesem Fall auch bereits auf eine
Implementierung in C# hin.
Visual Studio stellt mit dieser Struktur bereits das komplette Grundgerüst für einen
Web Service bereit. Um spezifische Methoden oder Funktionen zu veröffentlichen,
reicht es bereits aus, eine Methode mit dem Attribut <WebMethod> zu versehen. Eine
WSDL-Web-Service-Beschreibung lässt sich ebenfalls automatisch aus der asmxDatei erzeugen und muss dann nur noch angepasst werden. Sie umfasst bereits alle
gekennzeichneten Methoden und deren Parameter.
71
4.2
PAVONE TimeTracking
Webbasierte
Kommunikation
mit Server
Web Service Client
[Hermann Nottelmann]
Konvertierung
XML
XSLTransformer,
TimeSheet
PAVONE
TimeSheet
DOMParser,
DXLImporter etc.
LotusScript
Lotus Notes
Abb. 32 Technisches Kommunikationsmodell – Teil 2
Nachfolgend wird der linke Teil des Kommunikationsmodells im Detail betrachtet. Es
handelt sich also um die Seite, die die Daten in einer Lotus Notes-Datenbank
abspeichert und die mittels des diesseitig implementierten Web-Service-Clients
Anfragen an den Web-Service-Server stellt.
Die Lotus Notes-basierte Anwendung PAVONE TimeTracking fungiert als Frontend
zur dezentralen Aufwandserfassung. Die Aufwände für die Vorgangszuweisungen an
verschiedenen Projekten werden von jedem Projektteilnehmer wochenweise in einem
so genannten TimeSheet gepflegt. Letztere sind in der PAVONE TimeSheetDatenbank unter Lotus Notes abgelegt.
Zwecks Datenaustausch mit der relationalen Datenbank, in welcher Microsoft Project
im vorliegenden Fall sämtliche Projektdaten abspeichert, wurden Konvertierungsmechanismen zwischen einem solchen TimeSheet und einem XML-Dokument gemäß
den Anforderungen der Microsoft-Project-Seite implementiert.
Ausgehend von einer strukturellen Betrachtung eines TimeSheet-Dokuments in
Kapitel 4.2.1 wird in Kapitel 4.2.2 die Realisierung des Datenaustauschs mit Microsoft
Project getrennt nach Datenimport und –export beschrieben.
72
4.2.1 Struktureller Aufbau von TimeSheet-Dokumenten
[Hermann Nottelmann]
Der strukturelle Aufbau beschreibt, wie die Daten intern in den TimeSheetDokumenten abgespeichert sind. Hiervon zu unterscheiden ist die Präsentation der
Daten aus Nutzersicht. Diese wird unter Lotus Notes wie in Kapitel 3.2.1 angedeutet
mittels des Form-Konzepts realisiert.
Die Datenpräsentation weist allerdings einige Besonderheiten mit Einfluss auf den
strukturellen Aufbau der TimeSheet-Dokumente auf. Diese sollen anhand der
Abbildung 33 erläutert werden.
Zentrales Element eines TimeSheets ist eine Tabelle, die von einem Java Applet
aufgrund der vorhandenen Daten erzeugt wird. Jede Zeile weist geordnet nach
Projekten die in der ausgewählten Woche zugeordneten Vorgänge in chronologischer
Reihenfolge aus. Die Tabelle enthält nicht editierbare, vom Java Applet berechnete
Felder. So werden beispielsweise über den tagesgenau erfassten Aufwänden Zeilenund Spaltensummen gebildet oder Restaufwände entsprechend korrigiert. Weiterhin ist
es dem Projektteilnehmer möglich, den nach dieser Woche verbleibenden
Restaufwand zu erhöhen bzw. zu verringern und eine Zuordnung durch Eintragung des
Ist-Ende-Datums abzuschließen.
Standardmäßig können in dieser Tabelle in den drei letzten Spalten auch aufgelaufene
Kosten, Fakturierungsoptionen und Bemerkungen eingetragen werden. Diese
Möglichkeiten finden in der prototypischen Realisierung keine Berücksichtigung.
Bedingt durch den Fokus auf die Unterstützungsfunktion der Projektarbeit wurde die
Aufwandserfassung des Tagesgeschäfts nicht weiter betrachtet.
Für die dokumenteninterne Struktur werden die in der Tabelle aufbereiteten Daten
spaltenweise in Felder geschrieben. So enthält das Feld List_ProjectID eine Liste mit
eindeutigen Projektnamen. Die Anzahl der Listenelemente ist abhängig von der
Anzahl der Zuordnungen und für alle Felder identisch. Die letzten drei Listenelemente
bilden jeweils die Summenzeilen ab und enthalten ggf. Dummy-Werte.
73
Abb. 33 Darstellung eines TimeSheet-Dokuments
Bedingt durch die in Kapitel 3.2 herausgearbeiteten, strukturellen Unterschiede
zwischen semistrukturierter und relationaler Datenspeicherung ist eine gegenseitige
Überführung der gespeicherten Daten mit gewissem Aufwand verbunden.
Als Grundlage für den Datenaustausch empfiehlt es sich, in einem ersten Schritt einen
Zusammenhang zwischen den Feldern des TimeSheet-Dokuments einerseits und den
Attributen der Microsoft Project-Tabellen andererseits herzustellen.
Abbildung 34 stellt diesen Zusammenhang in vereinfachter Form dar. Die erste
Tabellenspalte enthält zusätzlich noch die relevanten Feldnamenbeschriftungen bzw.
Kopfzeileneinträge aus der TimeSheet-Form.
74
Beschreibung
Feldnamen TimeSheet
Attribute Microsoft Project
Person
Username
RES_NAME
Kalenderwoche
CALWEEK, CALYEAR,
CalWeekStartDate, CalWeekEndDate
./.
Projekt
List_ProjectID
PROJ_NAME
Vorgang
List_CategoriesPSP
TASK_NAME
Anfang
List_SchedStartDate
ASSN_START_DATE
Ende
List_SchedDueDate
ASSN_FINISH_DATE
Aufwand
List_SchedEffort
ASSN_WORK
Ist-Anfang
List_ActStartDate
ASSN_ACT_START
Ist-Ende
List_ActDueDate
ASSN_ACT_FINISH
Ist-Aufwand
List_ActEffort
ASSN_ACT_WORK
Ist-Restaufwand
List_ActRemEffort
ASSN_REM_WORK
Mo. – Fr.
List_ActDay1 – List_Actday5
TD_VALUE1 - TD_VALUE5
Abb. 34 Felderzusammenhänge zwischen TimeSheet u. Microsoft Project
Im TimeSheet-Dokument existiert noch eine Reihe von Feldern mit dem
Namenszusatz „Old“. Diese enthalten in der vorliegenden Implementierung die Werte
zu Wochenbeginn und werden zur Aufdeckung der manuellen Restaufwandsänderung
genutzt.
4.2.2 Datenaustausch mit Microsoft Project
[Hermann Nottelmann]
Für den Import der Projektstrukturdaten aus Microsoft Project, genauer aus der
zugehörigen relationalen Datenbank, wurde stark auf die verschiedenen in Lotus Notes
integrierten Möglichkeiten zur XML-Unterstützung zurückgegriffen.
Der Export der Aufwandsdaten nach Microsoft Project hingegen unterscheidet sich
durch den Verzicht auf Letztgenannte deutlich davon. Für diese Richtung wurde aus
Praktizitätsgründen eine zeilenweise Erzeugung einer XML-basierte Repräsentation
der im TimeSheet erfassten Daten gewählt.
Dennoch gibt es einige Gemeinsamkeiten bzgl. der grundsätzlichen Implementierung,
die nachfolgend kurz aufgeführt werden sollen:
75
•
Für beide Richtungen existieren zwei LotusScript-Agenten.77 Ein Agent
implementiert den Web-Service-Client, während der andere die Transformation zwischen TimeSheet-Dokument und XML-Dokument vornimmt.
•
In beiden Fällen ist ein XML-Dokument beteiligt; dieses bildet für den Import
den Ausgangspunkt, für den Export den Endpunkt der Transformation.
•
Zentrale Eigenschaften des Web Service, wie z. B. die IP-Adresse und der
virtuelle Pfad zur WSDL-Datei des Servers, werden in einem gemeinsamen
Konfigurationsdokument namens „WSCommunicationSettings“ gehalten.
•
Für beide Richtungen sind im Wesentlichen drei Arten von Formatänderungen
vorzunehmen: Die Formate von Datum/Uhrzeit-Werten müssen ineinander
überführt werden. Weiterhin weichen noch Aufwandswerte und
Vorgangsnamen voneinander ab. PAVONE TimeTracking speichert die
Vorgangsbezeichnung in hierarchischer Form (vgl. 1. Eintrag in Abb. 33).
4.2.2.1 Import von Projektstrukturdaten
4.2.2.1.1 Struktur und Inhalt des angefragten XML-Dokuments
[Hermann Nottelmann]
Das vom Web-Service-Server angeforderte XML-Dokument enthält drei Arten von
Einträgen (vgl. Abb. 35):
77
•
Eine Liste mit sämtlichen Projekten, für die dem betrachteten Projektteilnehmer Vorgänge in der jeweiligen Woche zugewiesen worden sind.
•
Eine Liste mit den Zuweisungen der Woche. Diese enthält neben den aktuell
geplanten auch die tatsächlichen Start- bzw., soweit vorhanden, Endzeiten.
Weiterhin sind der geplante Aufwand sowie der tatsächliche Aufwand und der
Restaufwand vermerkt.
•
Eine Liste mit allen Vorgängen der beteiligten Projekte, unabhängig von den
betrachteten Zuweisungen. Diese Einträge werden zur Rekonstruktion der
hierarchischen Vorgangsnamen in PAVONE TimeTracking benutzt.
Im Anschluss an die Installationshinweise in Kapitel 4.5 findet sich eine Auflistung sämtlicher Lotus
Notes-seitiger Lösungsbestandteile mit kurzer Funktionserläuterung.
76
<NewDataSet>
<MSP_PROJECTS>
<PROJ_ID>1</PROJ_ID>
<PROJ_NAME>Tecone42</PROJ_NAME>
</MSP_PROJECTS>
<MSP_ASSIGNMENTS>
<PROJ_ID>1</PROJ_ID>
<TASK_UID>2</TASK_UID>
<ASSN_START_DATE>2004-05-20T08:00:00.0000000+02:00</ASSN_START_DATE>
<ASSN_FINISH_DATE>2004-05-28T17:00:00.0000000+02:00</ASSN_FINISH_DATE>
<ASSN_WORK>2880000.000000</ASSN_WORK>
<ASSN_ACT_START>2004-05-20T08:00:00.0000000+02:00</ASSN_ACT_START>
<ASSN_ACT_WORK>1440000.000000</ASSN_ACT_WORK>
<ASSN_REM_WORK>1440000.000000</ASSN_REM_WORK>
</MSP_ASSIGNMENTS>
<MSP_TASKS>
<PROJ_ID>1</PROJ_ID>
<TASK_NAME>V1.1</TASK_NAME>
<TASK_ID>2</TASK_ID>
<TASK_UID>2</TASK_UID>
<TASK_IS_MILESTONE>false</TASK_IS_MILESTONE>
<TASK_IS_SUMMARY>false</TASK_IS_SUMMARY>
<TASK_OUTLINE_LEVEL>2</TASK_OUTLINE_LEVEL>
</MSP_TASKS>
#***Further MSP_TASKS entries to reconstruct hierarchical names***#
</NewDataSet>
Abb. 35 Projektstrukturdaten aus Microsoft Project – Codebeispiel
4.2.2.1.2 XML-Verarbeitung unter Lotus Notes
[Hermann Nottelmann]
Zum besseren Verständnis der im nachfolgenden Kapitel beschriebenen
Transformationsschritte sollen an dieser Stelle vier benutzte Basiskonstrukte im
Zusammenhang mit der Verarbeitung von XML-Dokumenten eingeführt werden.
(1) Erzeugung von und Navigation in einem DOM-Tree
Wie in Kapitel 2.3.3 erläutert, existieren zwei standardisierte Modelle zur
rechnerinternen XML-Verarbeitung. Für diese Implementierung wurde DOM
ausgewählt, das unter LotusScript als NotesDOMParser-Objekt umgesetzt ist und mit
einem XML-Dokument initialisiert wird. Der generierte Baum besteht aus Knoten
unterschiedlichen Typs (vgl. Abb. 36). Die Knoten werden durch ihren Namen
identifiziert. Zum Auslesen der im Baum gespeicherten Daten wird dieser rekursiv
durchlaufen. Mittels der Attributes-Methode kann auf die zugehörigen Attribute
zugegriffen werden. Zu den Nachbarknoten wird mittels der NextSibling-Methode
gewechselt.
77
NodeType
Attributes()
NextSibling()
Attributes
Object node
sibling
Attributes
sibling
sibling
Attributes
Attributes
Abb. 36 Zugriff auf DOM-Tree-Elemente
(2) Stylesheet-basierte Transformationen
Weiterhin kommen zwei XSL-basierte Stylesheets zum Einsatz. Diese werden
allerdings nicht in dem in Kapitel 2.3.4 erläuterten Präsentationskontext benutzt. Sie
werden als Manipulationswerkzeug für strukturelle Änderungen am XML-Dokument
eingesetzt (vgl. Abb. 37). Intern erzeugt das NotesXSLTransformer-Objekt wiederum
DOM-Trees für das Input- und Outputdokument sowie für das Stylesheet.
Letzteres setzt sich, wie in Kap. 2.3.4 beschrieben, aus Templates zusammen. Im
vorliegenden Fall wurden darüber hinaus Variablen und Template-Übergabeparameter
benutzt. Neben der bereits vorgestellten regelbasierten Template-Ausführung können
diese auch ähnlich wie Methoden über ihren Namen aufgerufen werden.
XML
NotesXSLTransformer
Stylesheet
XML
DXL
Abb. 37 Arbeitsweise XSLT-Prozessor
(3) Darstellung von Notes-Dokumenten mit DXL
Als drittes Verarbeitungselement ist DXL (vgl. Kap. 3.2.1) zu nennen. Grundsätzlich
kann eine Lotus Notes-Datenbank ganz oder in Teilen in einem DXL-Dokument
abgebildet werden (vgl. Abb. 38). Hierbei handelt sich um ein entsprechend der
Regeln der Domino-DTD gebildetes XML-Dokument. Für die Implementierung
wurde dieser Sachverhalt für die Gegenrichtung ausgenutzt. Mittels eines NotesDXLImporter-Objekts werden die Daten eines DXL-konformen XML-Dokuments in die
78
Notes-Datenbank importiert, was die Erzeugung eines TimeSheet-Dokuments zur
Konsequenz hat.
DXL
NSF
Database
NoteCollection
DocumentCollection
Document
Abb. 38 Partielle Datenbankrepräsentation mittels DXL
(4) Pipelining
Wie der Name bereits impliziert, kann durch das Pipelining auf die Erzeugung von
zwischengeschaltetem Output in Dateiform verzichtet werden. Stattdessen bildet das
jeweilige Transformationsobjekt den Input der nächsten Stufe.
Im nachstehenden Codebeispiel wird ein XML-Dokument mittels Stylesheet
transformiert. Das erzeugte XML-Dokument wird allerdings nicht zwischengespeichert. Vielmehr kann das NotesXSLTransformer-Objekt direkt als Input für die
DOM-Tree-Erzeugung der nächsten Stufe benutzt werden.
#***Declare used variables;
set inputStream and stylesheet***#
Set transformer = session.CreateXSLTransformer
(inputStream, stylesheet)
Set domParser=session.CreateDOMParser
(transformer)
transformer.Process
Abb. 39 Pipelining - Codebeispiel
4.2.2.1.3 Transformationsschritte zur TimeSheet-Erzeugung
[Hermann Nottelmann]
Der Transformationsprozess, der das XML-Dokument aus Microsoft Project
schrittweise in ein DXL-Dokument umwandelt, um durch den Import des
Letztgenannten ein neues TimeSheet zu erzeugen, lässt sich in drei Teilprozesse
unterteilen.
79
(1) Erzeugung eines DOM-Trees zur Rekonstruktion hierarchischer Vorgangsnamen
Pipeline
Input
XML
MSP
NotesXSLTransformer
NotesDOMParser
DOM Tree
Stylesheet
DOM
Abb. 40 Import – Schritt 1
Ergebnis des ersten Schritts des Transformationsprozesses soll ein DOM-Tree sein,
der im Wesentlichen alle relevanten Informationen über die hierarchische Einordnung
der aktuell zugeordneten Vorgänge enthält.
Dazu wird zunächst ein geeignetes Stylesheet auf das vom Web-Service-Server
erhaltene XML-Dokument angewandt. Auf Basis dieses Zwischendokuments wird
dann besagter DOM-Tree erstellt.
(2) Erzeugung des endgültigen Stylesheets zur Transformation in DXL-Dokument
Project List
DOM Tree
Task List
+
Envir.Variables
Stylesheet
Dynamic
Stylesheet
DXL
+
Settings WS
Stylesheet
Static
Abb. 41 Import – Schritt 2
Ergebnis dieses Schritts soll ein Stylesheet sein, das auf das ursprüngliche XMLDokument angewandt die DXL-Repräsentation eines TimeSheets erzeugt.
Dazu werden die Daten des im vorangegangen Schritt erzeugten DOM-Trees
extrahiert und in zwei Listen abgespeichert. Die erste Liste enthält die Zuordnung von
Projekt-ID und Projektnamen, die zweite bildet die Vorgangs-ID auf den
rekonstruierten hierarchischen Vorgangsnamen ab.
80
Aus den Einträgen dieser Listen, Konfigurationsparametern des Web Service sowie
Umgebungsvariablen, die im Wesentlichen den Ressourcennamen und den
betrachteten Zeitraum enthalten, wird schließlich der „dynamische“ Teil des zu
erzeugenden Stylesheets konstruiert. Zusammen mit dem statischen Teil, der für alle
TimeSheets identisch ist, erhält man abschließend gewünschtes DXL-Stylesheet.
(3) Transformation auf Basis des DXL-Stylesheets und Erzeugung eines TimeSheets
Pipeline
Input
XML
MSP
NotesXSLTransformer
NotesDXLImporter
TimeSheet
Stylesheet
DXL
Abb. 42 Import – Schritt 3
Ergebnis des dritten und letzten Schritts ist die Erzeugung des TimeSheets auf Basis
der Daten aus Microsoft Project.
Die Benutzung einer Pipeline erfolgt analog zum ersten Schritt. Das im letzten Schritt
erzeugte Stylesheet ermöglicht die Transformation des ursprünglichen XMLDokuments in eine DXL-konforme TimeSheet-Repräsentation. Durch den Import
dieses DXL-Dokuments wird der Importvorgang abgeschlossen. Nachfolgend kann
der Projektteilnehmer die Zeitphasendaten für die gewählte Woche erfassen.
81
4.2.2.2 Export von Aufwandsdaten
4.2.2.2.1 Datenextraktion aus TimeSheet-Dokument
[Hermann Nottelmann]
B
TimeSheet
B
A
A‘
C
Extract
C‘
Convert
…
Output
Output
XML
MSP
…
Abb. 43 Exportprozess schematisch
Ergebnis des Exportprozesses soll die Konstruktion eines XML-Dokuments sein, dass
mittels standardisierter Methoden die Überführung der enthaltenen Daten in die
relationale Datenbank von Microsoft Project ermöglicht.
Wie in Kapitel 4.2.1 erläutert, handelt es sich bei den Feldern des TimeSheets in den
meisten Fällen um Listen. Diese werden aus dem Dokument extrahiert und in Arrays
zwischengespeichert. In einigen Fällen müssen mithilfe dafür geschaffener
Konvertierungsmethoden Formatumwandlungen vorgenommen werden, so z. B. zur
Auflösung des hierarchischen Vorgangsnamens. Aus den angepassten Werten kann
nun zeilenweise das gewünschte XML-Dokument erzeugt werden.
4.2.2.2.2 Struktur und Inhalt des zurückgesandten XML-Dokuments
[Hermann Nottelmann]
Neben der von der relationalen Datenbank benötigten Definition eines Inlay-Schemas
(vgl. z. B. Abb. 31) enthält das erzeugte XML-Dokument drei Arten von Einträgen:
•
Eine Liste mit den Namen der tangierten Projekte.
•
Eine Liste mit den Aufwänden von Montag bis Freitag. Durch die
Berücksichtigung eines Konvertierungsfaktors ergibt sich etwa für das Beispiel
aus Abbildung 45, dass an Vorgang „V1.1“ Montag 4h und am Mittwoch 8h
gearbeitet wurden.
•
In bestimmten Fällen wird weiterhin eine Liste mit Korrektureinträgen für
solche Zuordnungen, die vorzeitig abgeschlossen wurden oder deren
Restaufwand im TimeSheet manuell korrigiert wurde, angefügt. Für das
82
betrachtete Beispiel wurde die Zuweisung an Vorgang „V1.1“ bereits
Mittwoch beendet; der ggf. korrigierte Aufwand der Ressource beträgt 48h.
<DataSet xmlns='http://tempuri.org/'>
<xs:schema id='NewDataSet'
#***Further attributes: namespace declarations***# >
<xs:element name='NewDataSet'
msdata:IsDataSet='true' msdata:Locale='de-DE'>
#***Inlay schema for the 3 tables MSP_PROJECTS,
MSP_TIMEPHASED_DATA and MSP_ASSIGNMENTS***#
</xs:schema>
<NewDataSet xmlns=''>
<MSP_PROJECTS>
<PROJ_NAME>Tecone42</PROJ_NAME>
</MSP_PROJECTS>
<MSP_TIMEPHASED_DATA>
<TD_CATEGORY>3</TD_CATEGORY>
<TD_FIELD_ID>2</TD_FIELD_ID>
<TASK_NAME>V1.1</TASK_NAME>
<RES_NAME>Patrick Hennies</RES_NAME>
<PROJ_NAME>Tecone42</PROJ_NAME>
<TD_START>2004-05-17T08:00:00.0000000+01:00</TD_START>
<TD_FINISH>21.05.2004T17:00:00.0000000+01:00</TD_FINISH>
<TD_UNITS>2</TD_UNITS>
<TD_VALUE1>240000</TD_VALUE1>
<TD_VALUE2>0</TD_VALUE2>
<TD_VALUE3>480000</TD_VALUE3>
<TD_VALUE4>0</TD_VALUE4>
<TD_VALUE5>0</TD_VALUE5>
</MSP_TIMEPHASED_DATA>
<MSP_ASSIGNMENTS>
<TASK_NAME>V1.1</TASK_NAME>
<RES_NAME>Patrick Hennies</RES_NAME>
<PROJ_NAME>Tecone42</PROJ_NAME>
<ASSN_WORK>2880000</ASSN_WORK>
<ASSN_REM_WORK>0</ASSN_REM_WORK>
</MSP_ASSIGNMENTS>
</NewDataSet>
</DataSet>
Abb. 44 TimeSheet-Daten für den Export nach MS Project – Codebeispiel
83
4.3
Kommunikationselement
SOAP
XML
.NET Web Service
DIME
Web Service Extensions
MS-SOAP Toolkit
Lotus Notes
[Patrick Hennies]
Abb. 45 Technisches Kommunikationsmodell - Teil 3
Die Kommunikationsseite als drittes und letztes Element des Kommunikationsmodells
führt die Notwendigkeit ein, die zu versendende Nachricht zusätzlich zu SOAP noch
in ein weiteres Format namens DIME zu verpacken. DIME steht für Direct Internet
Message Encapsulation und ist eine Weiterentwicklung des MIME (Multipurpose
Internet Mail Extensions)-Mechanismus, der auch bei Email-Anhängen verwendet
wird. Um DIME nutzen zu können, sind zusätzlich zum .NET Framework noch die
Microsoft Web Service Extensions (WSE) zu installieren. Diese ermöglichen es dann,
den DIME-Kontext einer SOAP-Nachricht abzufragen und zu bearbeiten. Beim
Microsoft SOAP Toolkit ist diese Unterstützung bereits integriert. Die Web Service
Extensions und das Microsoft SOAP Toolkit werden im Anschluss an eine Einführung
in DIME-Attachments noch genauer betrachtet.
4.3.1 DIME-Attachments
[Patrick Hennies]
Mit DIME ist es möglich einer SOAP-Nachricht eine beliebige Anzahl von Anhängen
(Attachments) mitzugeben. Es bestehen bereits verschiedene Ansätze zur Lösung
84
dieses Problems, da innerhalb von SOAP-Nachrichten nur textuelle Inhalte transferiert
werden können. Bei vollständigen und mit einem Schema versehenen XMLDokumenten als Nachrichteninhalt könnte außerdem die Trennung von Elementen der
SOAP-Nachricht und dem eigentlichen Nachrichteninhalt verwischen und die
Verarbeitung erschweren. Die Übertragung wäre zwar möglich, ist aber mittels DIME
deutlich effizienter.
Ein bekannter Lösungsansatz war MIME als Kapselungsmechanismus für Web
Services einzusetzen. Dies wurde in der W3C-Spezifikation „SOAP Messages with
Attachments“78 festgehalten. Der Kapselungsmechanismus, mittels dem auch EmailAnhänge versendet werden, ist allerdings auf einen sehr allgemeinen und flexiblen
Einsatz ausgerichtet und somit nicht effizient. DIME adressiert dieses Problem und ist
deutlich simpler gehalten. Es wurde gemeinsam von Microsoft und IBM entwickelt
und ist ausgerichtet (allerdings nicht begrenzt) auf den Einsatz mit SOAP und XML.
DIME ist somit deutlich effizienter und einfacher als MIME.
Um eine DIME-Nachricht zu versenden, werden ebenso wie bei SOAP StandardInternetprotokolle eingesetzt. Allerdings enthält DIME keine Metadaten mit
Informationen zur Verarbeitung der Nachricht, hierfür wird weiterhin die SOAPNachricht verwendet. Die DIME-Kapselung ist wie ein weiterer Umschlag um die
SOAP-Nachricht aufgebaut, dabei ist sie in verschiedene DIME Records unterteilt.
Der erste Record enthält die eigentliche SOAP-Nachricht; alle (optionalen)
Folgerecords enthalten die Anhänge. Innerhalb der eigentlichen SOAP-Nachricht ist
ein Verweis auf das jeweilige Attachment in einem bestimmten Record enthalten.
In der vorliegenden Implementierung ist eine Einteilung in zwei Records, einen mit
der SOAP-Nachricht und einen mit dem angehängten XML-Dokument, ausreichend.
In den Folgekapiteln 4.3.2 und 4.3.3 wird der Umgang der Kommunikationsendpunkte
mit DIME-Nachrichten am Beispiel erläutert.
78
Vgl. WSE - http://www.w3.org/TR/SOAP-attachments. Aufgerufen 02.07.2004.
85
4.3.2 Web Service Enhancements
[Patrick Hennies]
Web Service Enhancements (WSE) sind eine von Microsoft veröffentlichte
Erweiterung zu .NET und erlauben es „interoperable, secure, and routable Web
Services“79 zu erzeugen. Sie integrieren die Funktionalität der Verarbeitung von
DIME-Nachrichten und ermöglichen auch Sicherheitsverbesserungen wie digitale
Signaturen und Verschlüsselung. Mit WSE ist die Verarbeitung einer DIME-Nachricht
denkbar einfach. Es ist nur notwendig den Kontext einer SOAP-Nachricht abzufragen;
eventuell angehängte Attachments können dann direkt gespeichert werden. Bei einem
Anhängen eines Attachments wird ein Attachment-Objekt eingelesen und dann über
eine Add-Methode dem Nachrichtenkontext hinzugefügt.
***Speichern eines eingehenden Attachments***
SoapContext myContext = HttpSoapContext.RequestContext
SaveFile(path,myContext.Attachments[0].Stream);
***Einfügen eines Attachments in eine SOAP Antwort***
DimeAttachment attachment = new DimeAttachment(“plain/text”; charset= utf-8”,
TypeFormatEnum.MediaType, path)
HttpSoapContext.ResponseContext.Attachments.Add(attachment);
Abb. 46 DIME Attachments - Codebeispiel
4.3.3 Microsoft SOAP Toolkit
[Hermann Nottelmann]
Unter Lotus Notes existiert eine Reihe von Möglichkeiten einen Web-Service-Client
zu implementieren. Diese sind alle dadurch gekennzeichnet, dass sie das vorhandene
Klassen-Framework direkt oder indirekt um weitere Klassen ergänzen. Als
Programmiersprache kann entweder LotusScript oder Java verwendet werden. Im
vorliegenden Fall wurde Lotus Notes-seitig durchgehend in LotusScript programmiert.
Die Anforderung, einerseits SOAP-Nachrichten erzeugen und andererseits Antwortnachrichten im SOAP-Format auslesen zu können, wird von allen Lösungen
unterstützt. Insofern ist die Wahl des von Microsoft angebotenen SOAP Toolkits in
der aktuellen Version 3 nicht unbedingt zwingend und eher auf die grundsätzlich
Microsoft-lastige Gesamtlösung zurückzuführen.
79
Vgl. Microsoft Web Service Enhancements - Release Notes. Aufgerufen 02.07.2004.
86
Die Einbindung der vom Toolkit bereitgestellten Klassen erfolgt indirekt auf Basis
von COM80. Aus Kompatibilitätsgründen zu der in .NET entwickelten Serverseite des
Web-Service wurde die so genannte „Low-Level-API“ des Toolkits eingesetzt. Der
programmiertechnische Mehraufwand wird aber durch eine bessere Kontrolle über die
Erzeugung der SOAP-Nachrichten relativiert. Die Nachrichten sind im RPC-Style
verfasst (vgl. Kap.2.4.4)
Abbildung 47 verdeutlicht noch einmal die Rolle des Microsoft SOAP Toolkits für die
clientseitige Web-Service-Implementierung. Die Erzeugung von Objekten aus vom
Toolkit angebotenen Klassen erfolgt über die SOAP-COM-API. Die Konstruktion der
SOAP-Nachricht erfolgt konform zum existierenden WSDL-Dokument und der
Nachrichtenaustausch wird mittels HTTP-Protokoll realisiert.
WSDL
Notes
LS
Agent
MS
SOAP
Toolkit
Web
Service
SOAP COM API
HTTP
Abb. 47 Rolle des Microsoft SOAP Toolkits
80
Vgl. auch Kapitel 3.4.1.3. Für eine umfassende Behandlung siehe (Rubin/Brain 1999, S. 1-228).
87
4.3.3.1 Verbindungsaufbau und Nachrichtengenerierung
[Hermann Nottelmann]
Nachfolgend soll kurz der Umgang mit SOAP-Nachrichten erläutert werden. Die
Ausführungen beziehen sich auf das Codebeispiel in Abbildung 48.
Für den Verbindungsaufbau zum Web Service wird ein MSSOAP.HttpConnector30Objekt angelegt. Als Eigenschaft der Verbindung wird der Pfad zum beschreibenden
WSDL-Dokument angegeben. Dieser setzt sich zusammen aus der IP-Adresse und
dem virtuellen Pfad des Web Service auf dem IIS. Als zweite Eigenschaft wird die
benutzte Methode unter Berücksichtigung des gültigen Namenraums übergeben. Die
Connect-Methode baut die zuvor definierte Verbindung auf.
Die Konstruktion der eigentlichen SOAP-Nachricht wird durch den Methodenaufruf
BeginMessage gestartet bzw. durch EndMessage beendet.
Auf Basis eines MSSOAP.SoapSerializer30-Objekts wird der Nachrichtenstrom
erzeugt. Auf diesem Objekt existieren Methoden, die die jeweiligen Teile der SOAPNachricht in Form von XML-Tags erzeugen. So wird z. B. durch StartBody bzw.
EndBody der Nachrichtenrumpf ausgezeichnet. Methodennamen und die Namen ihrer
Übergabeparameter werden mit StartElement respektive EndElement in den
Nachrichtenstrom geschrieben. Für die Parameterwerte existieren typabhängige
Methoden.
***Verbindungsaufbau***
EndPointURL = "http://192.168.0.20/Tecone_Project/Tecone.asmx?wsdl"
Set connector = CreateObject("MSSOAP.HttpConnector30")
connector.Property("EndPointURL") = EndPointURL
connector.Property("SoapAction") = "http://tempuri.org/RetrieveProject"
connector.Connect
***Nachrichtengenerierung***
connector.BeginMessage
Set Serializer = CreateObject("MSSOAP.SoapSerializer30")
Serializer.Init connector.InputStream
Serializer.StartEnvelope
Serializer.StartBody
Serializer.StartElement "RetrieveProject", "http://tempuri.org/"
Serializer.StartElement "input_name"
Serializer.WriteString "Müller"
Serializer.EndElement
#***Further input parameters***#
Serializer.EndElement
Serializer.EndBody
Serializer.EndEnvelope
Serializer.Finished
connector.EndMessage
Abb. 48 Verbindungsaufbau und Nachrichtengenerierung – Codebeispiel
88
4.3.3.2 Verarbeitung von Nachrichtenanhängen
[Hermann Nottelmann]
Anders als beim .NET-Framework ist im Microsoft SOAP Toolkit die Unterstützung
von DIME-Nachrichten mit den in Kapitel 4.3.1 beschriebenen Vorteilen bereits
integriert.
Das Codebeispiel von Abbildung 49 verdeutlicht den Umgang mit DIME-Nachrichten
in den für die Implementierung relevanten Formen. Im Unterschied zur Erzeugung
von SOAP-Nachrichten wird das MSSOAP.SoapSerializer30-Objekt mit einem
MSSOAP.DimeComposer30-Objekt initialisiert. Ein Attachment wird ähnlich wie ein
Übergabeparameter in die DIME-Nachricht eingebunden. Auf die in der DIMEAntwortnachricht enthaltenen Attachments kann über ein Array zugegriffen werden.
***DIME-Attachment zusammen mit Request-Message versenden***
Set FileAttach = CreateObject("MSSOAP.FileAttachment30")
FileAttach.FileName = "c:\temp\TimeSheetOutput.xml"
connector.BeginMessage
Set composer = CreateObject("MSSOAP.DimeComposer30")
Set Serializer = CreateObject("MSSOAP.SoapSerializer30")
Serializer.InitWithComposer connector.InputStream, composer
Serializer.StartEnvelope
Serializer.StartBody
Serializer.StartElement "Insert", "http://tempuri.org"
Serializer.EndElement
Serializer.AddAttachment FileAttach
Serializer.EndBody
Serializer.EndEnvelope
Serializer.Finished
connector.EndMessage
***DIME-Attachment aus Response-Message auslesen***
Set Reader = CreateObject("MSSOAP.SoapReader30")
Set Parser = CreateObject("MSSOAP.DimeParser30")
Reader.LoadWithParser connector.OutputStream, Parser
Set FileAttach = Reader.Attachments.Item(0)
FileAttach.SaveToFile "c:\temp\TimeSheetInput.xml"
Abb. 49 DIME-Attachments clientseitig - Codebeispiel
89
4.4
Kommunikationsablauf im Detail
[Hermann Nottelmann, Patrick Hennies]
Abschließend soll der implementierte Kommunikationsablauf noch einmal anhand von
Screenshots aus den beteiligten Anwendungen Microsoft Project (Schritte 1, 5 und 6)
und PAVONE TimeTracking (Schritte 2 bis 4) - wie er sich auch den Projektteilnehmern bzw. dem Projektleiter darstellt - aufgezeigt werden.
Die Abfolge richtet sich nach den in Kapitel 3.4.2.2 herausgearbeiteten Modellcharakteristika.81
1. Projekt anlegen
Abb. 50 Kommunikationsablauf - Schritt 1
Es wurde für dieses Ablaufbeispiel ein Projekt mit 4 Vorgängen angelegt.
Die Vorgänge unterteilten sich in V1, V1.1, V1.2 und V2, wobei V1.1 und V1.2
Untervorgänge des Sammelvorgangs V1 sind. Als Bearbeiter wurde die personelle
Ressource „Patrick Hennies“ ausgewählt und dem Teilvorgang V1.1 zugewiesen.
Es sind bisher 4 Arbeitstage für Vorgang V1.1 geplant und es ist noch keine aktuelle
Arbeit erfasst.
2. Projektdaten übertragen
Abb. 51 Kommunikationsablauf - Schritt 2
81
Eine zusammenfassende Übersicht bietet Abbildung 21.
90
Diese Projektplandaten werden nun aus PAVONE TimeTracking heraus angefragt.
Für die Ressource Patrick Hennies wird für den betreffenden Zeitraum ein neues
TimeSheet angelegt. Der Web Service wird kontaktiert und überträgt die Plandaten,
um das TimeSheet anzulegen.
3. Projektdaten einlesen
Abb. 52 Kommunikationsablauf - Schritt 3
Die Daten wurden transferiert und in das TimeSheet übernommen. Wie zu sehen ist,
wurde der Vorgang V1.1, der einzige relevante Projektvorgang für den betrachteten
Zeitraum, nun in das TimeSheet übernommen. Auch die geplanten Anfangs-, Endeund Aufwandswerte wurden übertragen. In Kalenderwoche 21 wurden bereits 16h an
dem Vorgang gearbeitet.
4. Tatsächliche Daten erfassen
Abb. 53 Kommunikationsablauf - Schritt 4
Es erfolgt nun eine Erfassung von tatsächlichen Aufwänden an verschiedenen Tagen
der Kalenderwoche 22. Die Arbeit an V1.1 wird von Patrick Hennies wie geplant am
25. Mai 2004 beendet, jedoch mit einem um 6h reduzierten Gesamtaufwand.
91
5. Erfasste Daten übertragen
Abb. 54 Kommunikationsablauf - Schritt 5
Die erfassten Daten werden wieder nach Microsoft Project übertragen. Wie zu sehen
ist, sind nun die geplanten Arbeitseinträge auch durch aktuelle Arbeitsleistungen
ergänzt.
6. Projektplan aktualisieren
Abb. 55 Kommunikationsablauf - Schritt 6
In der Projektplanungsübersicht wird der Vorgang V1.1 somit nun als abgeschlossen
angezeigt, die geplante Arbeit wurde durch die tatsächlichen Arbeitsleistungen
ergänzt. Es kann nun also eine weitere Planung des Projektverlaufs durchgeführt
werden.
92
4.5
Einschränkungen und offene Problemstellungen
[Hermann Nottelmann, Patrick Hennies]
Im Bezug auf die Implementierung des Prototyps wurden insbesondere folgende
Annahmen getroffen und Einschränkungen festgestellt, die bei einer finalen Version
noch zu beheben oder verbessern wären:
•
Projekterfassungs- und Kommunikationsverlauf
Es wird angenommen, dass es keine Unterbrechung oder Veränderung des
entwickelten Kommunikationsverlaufs gibt. Dies bedeutet, dass insbesondere
keine Zeitphasendaten in Microsoft Project und keine Projektstrukturänderungen in PAVONE TimeTracking erfasst werden. Sollte dies dennoch
geschehen, werden diese Änderungen mit großer Wahrscheinlichkeit nicht in
den jeweiligen Kommunikationspartner übernommen.
•
Umlaute
Die Verwendung von Umlauten bei Namensbezeichnern führt für den
Importfall der Projektstrukturdaten aus Microsoft Project zu Problemen bei der
Konvertierung. Dies ist nur durch die durchgängige Verwendung der
alternativen Kodierung „ISO-8859-1“ zu lösen.
•
Beschränkung der Anzahl an Mitarbeitern und Projekten
Die Anwendung wurde explizit nur für ein Projekt und einen beteiligten
Mitarbeiter getestet. Die Implementierung berücksichtigt zwar theoretisch
mehrere Beteiligte und auch mehrere Projekte, aber hierfür liegt keine
Testgewährleistung vor.
•
Namensgleichheit
Es wurde explizit eine hundertprozentige Namensgleichheit der Projekte,
Vorgänge, Personen und Zuweisungen in PAVONE TimeTracking und
Microsoft Project angenommen. Dies steht aber in Übereinstimmung mit der
Annahme zum Projekterfassungsverlauf.
•
Namenseindeutigkeit
Es sollte keine gleichen Namen bei verschiedenen Projekten oder Mitarbeitern
geben. Vorgänge müssen innerhalb eines Projekts einen eindeutigen Namen
haben.
Folgende Leistungsmängel sind Teil des entwickelten Prototyps:
•
Anlegen von TimeSheet-Dokumenten
TimeSheet-Dokumente werden unabhängig von bereits Vorliegenden in der
letzten Stufe aus einem DXL-Dokument erzeugt. Sollte der Projektteilnehmer
93
bereits ein TimeSheet für den gleichen Zeitraum erzeugt haben, besteht durch
die Verwechslungsgefahr die Möglichkeit von Inkonsistenzen.
•
Festschreibung von alten Aufwänden
Die Festschreibung von alten (bereits gesendeten) Aufwänden ist nicht
garantiert und wird nicht erzwungen. Es ist also möglich, erfasste
Zeitphasendaten nach Microsoft Project zu übertragen und das TimeSheetDokument anschließend noch einmal zu ändern und abzuspeichern, was eine
Dateninkonsistenz verursacht.
•
Ende-Start-Beziehung
Es erfolgt nur eine begrenzte Berücksichtigung strenger Ende/StartBeziehungen. Zeitdaten aus einem Vorgang können somit bereits erfasste
Daten eines anderen, in Beziehung stehenden, Vorgangs ändern. Wenngleich
dies oft sinnvoll ist, sind die Änderungen allerdings nicht sofort ersichtlich.
•
Zeitzonen-Konflikt
In manchen Fällen kann es zu einem Zeitzonenkonflikt zwischen der LotusNotes-Seite und der Microsoft-Project-Seite kommen. Befindet sich einer der
beiden beteiligten in einer anderen Zeitzone oder es ist eine der involvierten
Softwarekomponenten auf eine abweichende Zeitzone eingestellt, so führt dies
zu falschen Tagesarbeitszeiten. Die übliche Tagesarbeit ist von 08:00-17:00h
eingestellt. Durch eine Zeitzonenverschiebung kann diese Arbeitszeit jetzt
unter Umständen verschoben werden, was dann potenziell zu einer
Umverteilung der geleisteten Stunden auf Folgetage führen kann. Die
eigentlichen Summenwerte werden hierbei nicht beeinflusst.
94
4.6
Installationsanweisungen und –besonderheiten
4.6.1 Installation des Web Service
[Patrick Hennies]
Folgende Software sollte auf dem Zielrechner installiert sein:
(Die Installationsreihenfolge ist wichtig, daher sollten die Komponenten in der hier
verwendeten Reihenfolge installiert werden.)
Als Betriebsystemgrundlage dient Microsoft Windows XP - SP1.
•
Microsoft Internet Information Server (IIS) Version 5.1
Das IIS-Lockdown-Tool sollte nicht ausgeführt werden.
•
Microsoft SQL Server 2000 Gold (ohne Service Pack 3)
•
Microsoft .NET Framework in der Version 1.1.4322; höhere Versionen sind
wahrscheinlich kompatibel, wurden aber nicht getestet, da keine zur
Entwicklungszeit vorlag.
•
Microsoft Web Service Enhancements in der Version 1.0
•
Microsoft Project Professional 2002
•
(Optional) Visual Studio .NET 2003
Folgende Konfigurationseinstellungen müssen nach der Installation durchgeführt
werden:
•
Die zu benutzende Datenbank (Bezeichnung: XMLTest) muss im SQLEnterprise-Manager-Tool angelegt und von Microsoft Project aus referenziert
werden. Der Name kann auch abweichend gewählt werden, dies muss dann
aber im Programmcode angepasst werden. Die Datenbank wird bei Microsoft
Project unter Datei/Speichern_unter/ODBC/Computerdatenquelle/Neu... angelegt. Es muss in den Folgedialogen nur der SQL-Server ausgewählt werden.
Alle Tabellen legt Microsoft Project nach Auswahl der Datenbank
selbstständig an.
•
Für den Zugriff des Web Service auf die SQL-Datenbank muss das ASP.NETBenutzerkonto als db_owner in der Datenbank eingetragen werden.
•
Falls Visual Studio .NET verwendet werden soll, muss der Benutzer den
Gruppen Administratoren, Debuggerbenutzer und VS Developers angehören.
95
•
Das Gast-Konto des Computers darf deaktiviert sein, die Konten
IUSR_Benutzername,
IWAM_Benutzername,
SQLDebugger,
ASPNET
allerdings nicht.
Anschließend kann die auf der CD hinterlegte Installationsroutine ausgeführt werden.
Sie prüft unter anderem auch das Vorhandensein des IIS und .NET Frameworks ab.
Sollte die Installationsroutine für den Web Service nicht starten oder trotz korrekter
Installation aller Komponenten nicht funktionieren, ist das Visual Studio .NET-Projekt
auch direkt auf der CD hinterlegt. (In diesem Fall muss allerdings der Tecone_ProjektOrdner in das IIS-root-Verzeichnis kopiert werden. (Typischerweise unter
C:\Inetpub\wwwroot)
Zusätzlich müssen in manchen Fällen auch die Web Service Enhancements noch als
Add-In unter Visual Studio .NET referenziert werden. Die Installationsroutine sollte
allerdings im Normalfall die Assembly-Dateien mitintegrieren.
4.6.2 Installation des Lotus Notes Clients
[Hermann Nottelmann]
Nachstehende Software muss auf den Clientrechnern installiert sein:
Als Betriebssystems kann Microsoft Windows ab Version 9x eingesetzt werden.
•
Lotus Notes Release 6.0
•
PAVONE TimeTracking 6
•
Microsoft SOAP Toolkit 3.0
•
(Optional) Lotus Domino Designer Release 6.0
Die notwendigen Änderungen an der Datenbank PAVONE TimeSheet (vgl. Abb. 56)
können vorgenommen werden, indem die Datenbankdatei gp_ts_d.nsf durch die
gleichnamige Version auf der beigefügten CD-ROM ersetzt wird.
Für den Import der Projektstrukturdaten aus Microsoft Project müssen die IP-Adresse
des Web-Service-Servers, das zugehörige virtuelle Verzeichnis sowie die Dateipfade
der ausgetauschten XML-Dokumente im Web-Service-Konfigurationsdokument in der
PAVONE TimeSheet-Datenbank eingetragen werden. Dies geschieht bei Neuanlage
eines TimeSheets über die Schaltfläche „Konfiguration WebService“.
96
Forms
Neues TimeSheet MSP
Actions:
neu
Auswahl Person
Auswahl eines Lotus Notes-konformen Ressourcennamens
TimeSheet anlegen
Aufruf von InvokeWebServiceSendTimeSheet, ImportDataFromXML
u. DeleteNewTS
Konfiguration WebService
Öffnen von WSCommunicationSettings
WSCommunicationSettings
Actions:
neu
Speichern und Schließen
Änderungen speichern u. Fenster schließen
Bearbeiten
Dokument editieren
TimeSheet
modifiziert
Actions:
Speichern
Änderungen im TimeSheet-Dokument speichern
Export nach MS Project
Aufruf von ExportDataToXML u. InvokeWebServiceSendTimeSheet
View
1.1 TimeSheets nach Person
Action:
TimeSheet erstellen
modifiziert
Neues Dokument in der Form „Neues TimeSheet MSP“ anzeigen
Agents
InvokeWebServiceGetData
Übergibt Resourcenname u. Woche; erhält XML-Dokument
mit Projektstrukturdaten als Attachment
ImportDataFromXML
Transformiert XML-Dokument in TimeSheet
ExportDataToXML
Schreibt Aufwandsdaten aus aktuellem TimeSheet in XML-Dokument
InvokeWebServiceSendTimeSheet
Übergibt XML-Dokument an Web-Service-Server als Attachment
DeleteNewTS
Löscht aktuelles Dokument
Abb. 56 Änderungen an der Datenbank PAVONE TimeSheet
97
5 Zusammenfassung und Ausblick
[Hermann Nottelmann, Patrick Hennies]
Ziel der vorliegenden Arbeit war der Entwurf einer Kommunikationslösung zwischen
PAVONE TimeTracking, einer Lotus Notes/Domino-Anwendung und Microsoft
Enterprise Project Management, mit der Datenspeicherung auf relationaler Basis.
Es wurde versucht, eine möglichst offene und erweiterbare Lösung zu implementieren.
Insbesondere war keine enge Kopplung oder Integration der beiden Applikationen das
Ziel, sondern vielmehr eine Interaktion auf der Datenebene - oder genauer eine
Kommunikation zwischen einem semistrukturierten und einem relationalen Datenbanksystem. Dazu wurden im Wesentlichen zwei Technologien eingesetzt: XML und
Web Services.
Es wurde aufgezeigt, dass XML durch den starken Abstraktionslevel und die
durchgängige Verbreitung das geeignete Datenaustauschformat ist. XML und
verwandte Technologien bieten Schnittstellen und Automatismen, um alle
notwendigen Umwandlungsprozesse effizient durchzuführen und gestatten außerdem
eine leichte Erweiterbarkeit für die Kommunikation mit Drittanwendungen.
Web Services wurden als eine sehr neue und in mancher Hinsicht im
Entwicklungsprozess befindliche Technologie vorgestellt. Ihre aktuelle Verbreitung ist
begrenzt, weshalb auch nur wenige Erfahrungsberichte über ihren Einsatz vorliegen.
Allerdings lassen Web Services die Integration von Altanwendungen und
insbesondere auch von Legacy-Systemen mit gegenwärtigen wie auch zukünftigen
Applikationen zu. Dies ermöglicht eine Vereinheitlichung der Kommunikationsstruktur, ohne eine von Grund auf neue Architektur schaffen zu müssen. Ferner wurde
untersucht, in welchem Kontext Web Services zu bisherigen Implementierungen
stehen, wo Stärken liegen und wo noch Verbesserungen notwendig sind.
Nach Einführung dieser beider Technologien wurden sie zu den Kommunikationsendpunkten ins Verhältnis gesetzt. Anschließend wurde das Kommunikationsmodell entworfen und eine kleinschrittige Betrachtung des Kommunikationsverlaufs unternommen. Anhand dieser wurden dann nochmals die verschiedenen
Methoden und Prozesse zur Konvertierung und Bearbeitung der Daten während des
Kommunikationsablaufs untersucht.
Abgerundet wurde diese Analyse durch den Entwurf eines Kommunikationsprototyps,
welcher die zuvor untersuchten Technologien inkorporiert und eine Kommunikationsmöglichkeit aufzeigt.
98
Im Fall der beiden eingesetzten Technologien gibt es zahlreiche Entwicklungspotenziale. Dass XML in seiner Bedeutung noch steigen wird, ist zweifelsfrei. Die
Überlegung von Microsoft, die nächste Generation ihres Dateisystems in XML zu
entwerfen, ist hierfür nur ein Beispiel von vielen.
Auch dem Konzept der Web Services wird von vielen ein großer Siegeszug
vorhergesagt, nicht zuletzt dank der durchgängigen Nutzung von XML. Sollten sich
schließlich klare Strukturen in Form von Standards und Sicherheitsrichtlinien
herausgebildet haben, sind Web Services eine mächtige Technologie und werden mit
großer Wahrscheinlichkeit ein wichtiges Element vieler Kommunikationslösungen
sein.
So prognostiziert unter anderem die IDC eine Verzehnfachung der Investitionen in
Web Services vom Jahr 2003 auf 2008.82 Die Ursache für dieses Wachstum wird
zumeist in steigendem Vertrauen auch kleinerer Firmen gesehen. Initial wurden Web
Services zwar von den Marktführern unterstützt, waren aber eine riskante und
potenziell kostspielige Technologie. Dies wird sich voraussichtlich in naher Zukunft
ändern, da Web Services gerade durch ihren komplementären und nicht substituierenden Ansatz eine zukunftsträchtige Positionierung aufweisen.
Der implementierte Prototyp macht sich bereits diese Entwicklungspotenziale zunutze
und ist somit insbesondere leicht integrier- und erweiterbar. So wäre es denkbar, die
Zeitaufwände auch über ein Web-Interface zu erfassen.
Eine Weiterentwicklung des Prototyps sollte einerseits das Fähigkeitsspektrum des
Prototyps weiter ausbauen. Möglich wäre beispielsweise zusätzlich zur
Zeitphasendatenübertragung auch die erfassten Kosten zu transferieren. Auch die
Schwächen des Prototyps im Hinblick auf Konsistenzprüfung und Fehlerrobustheit
sollten adressiert werden.
Andererseits sollte eine Weiterentwicklung auch im Hinblick auf die Grenzen der
Web-Service-Technologie erfolgen. Sicherheitsaspekte sind wegen des unternehmensübergreifenden Einsatzes von zentraler Bedeutung und werden bislang von WebService-Standards nicht zufrieden stellend gelöst. Die Dynamik der gegenwärtigen
Standardisierungsbestrebungen lässt jedoch Positives für die zukünftige Entwicklung
im diesem Bereich erwarten.
82
Vgl. Rogers, S.: Worldwide Web Services Software 2004-2008 Forecast: Cautious Adoption
Continues, IDC Market Analysis, Document No. 31079, Apr 2004.
99
6 Literaturverzeichnis
Abiteboul/Buneman/Suciu 2000:
Abiteboul, S.; Buneman, P.; Suciu, D.: Data on the Web: From Relations to
Semistructured Data and XML, Morgan Kaufmann, San Francisco 2000.
Barnaby 2002:
Barnaby, T.: Distributed .NET Programming in C#, Apress, 2002.
Cerami 2002:
Cerami, E.: Web Service Essentials, O`Reilly, 2002.
Codd 1970:
Codd, E. F.: A Relational Model for Large Shared Data Banks, In: Communication
of the ACM, Vol. 13, No. 6., June 1970, S. 377-378.
Codd 1979:
Codd, E. F.: Extending the Database Relational Model to Capture More Meaning,
In: ACM Transactions on Database Systems, Vol. 4, No. 4, Dec. 1979, S. 397-434.
Coulouris/Dollimore/Kindberg 2001:
Coulouris, G.; Dollimore, J.; Kindberg, T.: Distributed Systems: Concepts and
Design, Third Edition, Addison-Wesley, 2001.
Dangelmaier et al. 2002:
Dangelmaier et al.: Klassifikation von EAI-Systemen, In: HMD - Praxis der
Wirtschaftsinformatik, Vol. 39, Heft 225, 2002, S. 61-71.
Fischer et al. 2000:
Fischer, J. et al.: Bausteine der Wirtschaftsinformatik: Grundlagen, Anwendungen,
PC-Praxis, 2. Aufl., Erich Schmidt Verlag, Berlin 2000.
Garcia-Molina/Ullman/Widom 2002:
Garcia-Molina, H.; Ullman, J. D.; Widom, J.: Database Systems: The Complete
Book, Prentice Hall, New Jersey 2002.
100
Haas/Lin/Roth 2002:
Haas, L. M.; Lin, E. T.; Roth, M. A.: Data Integration through Database Federation,
IBM Systems Journal, Vol. 41, No. 4, 2002.
Hartman et al. 2003:
Hartman, B.; Flinn, D. J.; Beznosov, K.; Kawamoto, S.: Mastering Web Services
Security, Wiley, Indianapolis 2003.
Heuer 2000:
Heuer, A.: Datenbanken: Konzepte und Sprachen, 2. Aufl., mitp-Verlag, Bonn
2000.
Johnson et al. 2002:
Johnson, D. et al.: Developing .NET Web Services with XML, Syngress
Publishing, 2002.
Kappel/Kapsammer/Retschitzegger 2001:
Kappel, G.; Kapsammer, E.; Retschitzegger, W: XML and Relational Databases –
A Comparison of Concepts, In: Proceedings of the International Conference on
Internet Computing (IC'01), Las Vegas, Nevada, USA, June 25-28, 2001.
Kaye 2003:
Kaye, D: Loosely Coupled: The Missing Pieces of Web Services, RDS Press, o. O.
2003.
Knuth et al. 2003:
Knuth, M. et al.: Web Services. Einführung und Übersicht, Software & Support
Verlag GmbH, Frankfurt 2003.
Linthicum 1999:
Linthicum, D. S.: Enterprise Application Integration, Addison-Wesley, 1999.
Linthicum 2003:
Linthicum, D. S.: Next Generation Application Integration – From Simple
Information to Web Services, Addision Wesley, 2003
101
Mohan et al. 2000:
Mohan, C. et al.: Evolution of Groupware for Business Applications: A Database
Perspective on Lotus Domino/Notes, In: Proceedings of the 26th VLDB
Conference, Cairo, Egypt, Sept. 2000.
Myerson 2002:
Myerson, J. M.: The Complete Book of Middleware, Auerbach Publications,
London 2002.
Newcomer 2002:
Newcomer, E.: Understanding Web Services: XML, WSDL, SOAP and UDDI,
Addison-Wesley, 2002.
Papakonstantinou/Garcia-Molina/Widom 1995:
Papakonstantinou, Y.; Garcia-Molina, H.; Widom, J.: Object Exchange Across
Heterogeneous Information Sources, In: Proceedings of the IEEE International
Conference on Data Engineering (ICDE’95), Taipei, Taiwan, March 1995.
Plášil/Stal 1998:
Plášil, F.; Stal, M.: An Architectural View of Distributed Objects and Components
in CORBA, Java RMI, and COM/DCOM, In: Software - Concepts & Tools, Vol.
19, No. 1, Springer-Verlag, Heidelberg 1998, S. 14-28.
Rahm/Vossen 2003:
Rahm, E.; Vossen, G.: Web & Datenbanken: Konzepte, Architekturen,
Anwendungen, dpunkt-Verlag, Heidelberg 2003.
Ring/Ward-Dutton 1999:
Ring, K.; Ward-Dutton, N.: Enterprise Application Integration: Making the Right
Connections, Ovum Ltd., London 1999.
Riordan 2002:
Riordan, R. M.: Microsoft ADO.NET Step-by-Step, Microsoft Press, 2002.
Rubin/Brain 1999:
Rubin, W.; Brain, M.: Understanding DCOM, Prentice Hall, 1999.
102
Sharma/Stearns/Ng 2001:
Sharma, R.; Stearns, B.; Ng, T.: J2EE Connector Architecture and Enterprise
Application Integration, Addison-Wesley, 2001.
Suciu 1998a:
Suciu, D.: Semistructured Data and XML, In: Proceedings of the International
Conference on the Foundations of Data Organization (FODO’98), Kobe, Japan,
Nov. 1998.
Suciu 1998b:
Suciu, D.: An Overview of Semistructured Data, In: ACM SIGACT News, Vol. 29,
No. 4, Dec. 1998, S. 28-38.
Tanenbaum/van Steen 2003:
Tanenbaum, A.; van Steen, M.: Verteilte Systeme: Grundlagen und Paradigmen,
Pearson Studium, München 2003.
Tari/Bukhres 2001:
Tari, Z.; Bukhres, O.: Fundamentals of Distributed Object Systems: The CORBA
Perspective, Wiley, 2001.
Tidwell/Snell/Kulchenko 2001:
Tidwell, D.; Snell, J.; Kulchenko, P.: Programming Web Services with SOAP,
O`Reilly, 2001.
Wyke/Rehman/Leupen 2002:
Wyke, A.; Rehman, S.; Leupen, B.: XML Programming (Core Reference),
Microsoft Press, Redmond 2002.
103
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides Statt, dass ich die namentlich kenntlich gemachten Teile
der vorliegenden Arbeit selbständig und nur unter Verwendung der angegebenen
Hilfsmittel angefertigt habe; die aus fremden Quellen direkt oder indirekt
übernommenen Gedanken sind als solche kenntlich gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch
nicht veröffentlicht.
Paderborn, den 08.07.2004
Hermann Nottelmann
Ich erkläre hiermit an Eides Statt, dass ich die namentlich kenntlich gemachten Teile
der vorliegenden Arbeit selbständig und nur unter Verwendung der angegebenen
Hilfsmittel angefertigt habe; die aus fremden Quellen direkt oder indirekt
übernommenen Gedanken sind als solche kenntlich gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch
nicht veröffentlicht.
Paderborn, den 08.07.2004
Patrick Hennies