ID 5280
Zacharias, Roger: Management- und Web Services- Architekturen: Konzeption und
Realisierung eines Überwachungssystems für Bankperipheriegeräte / Roger Zacharias -
Hamburg: Diplomica GmbH, 2002
Zugl.: Gießen, Fachhochschule, Diplom, 2002
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
III
Vorwort
Technology of a sufficiently advanced level
will be indistinguishable from magic. (Arthur C. Clarke)
Die vorliegende Diplomarbeit entstand im Zeitraum 10/2001 02/2002 an der
Fachhochschule Gießen-Friedberg in Zusammenarbeit mit der Wincor Nixdorf GmbH
& Co. KG unter der Betreuung von Herrn Prof. Dr. Kaufmann und Herrn Prof. Dr.
Scheer. Die Aufgabenstellung ergab sich aus einem Projekt der Wincor Nixdorf
GmbH & Co. KG, in welchem eine umfangreiche Überwachungslösung im
Bankenbereich entwickelt wird. Dazu sollen die zurzeit neu aufkommenden
Architekturen und Paradigmen untersucht und ein möglicher Prototyp erstellt werden
und bei entsprechender Eignung gegebenenfalls in diese Überwachungslösung mit
einfließen.
Die besondere Herausforderung dieser Diplomarbeit lag in der Aktualität der
beschriebenen und verwendeten Architekturen und Technologien, welche einen
Mangel an fundierter Literatur und stabilen Laufzeitumgebungen sowie einen stetigen
Weiterentwicklungs- und Änderungsprozess implizierten. Teilweise musste, um die
volle Funktionalität der Technologien auszunutzen, auf Alpha-Versionen
zurückgegriffen werden, was die Arbeit nicht immer erleichterte, aber natürlich sehr
interessant machte.
Zur Konzeption und Realisierung des Prototyps bediente sich der Autor einer
Kombination aus dem ´Rational Unified Process´ und ausgewählten Elementen des
´Extreme Programming´. Diese Vorgehensweise kann, nach Meinung des
Verfassers, für Projekte in diesem Rahmen sehr empfohlen werden, da sie sich
insbesondere durch schnelle Reaktionsmöglichkeiten bei ständig wechselnden
Anforderungen auszeichnet.
IV
DANKSAGUNGEN
An dieser Stelle möchte ich mich bei meinen Betreuern für die geleistete
Unterstützung bedanken, insbesondere bei Herrn Prof. Dr. Kaufmann, der in einigen
Gesprächen und vielen E-Mails durch zahlreiche Anregungen zum Gelingen dieser
Arbeit beigetragen hat.
Mein Dank geht auch an meine Kollegen, die durch anregende Diskussionen und
konstruktive Kritik sowie aufmunternde Worte einen wichtigen Teil beitrugen,
insbesondere an die, die Angst hatten an dieser Stelle vergessen zu werden, Herrn
Dipl.-Ing. Peter Diel und Herrn Dipl.-Math. Gerhard Schneider.
Für ihre Unterstützung möchte ich mich bei meinen Eltern und Schwiegereltern
bedanken.
Weiterhin bedanke ich mich bei meinen Kommilitonen und Freunden, die mir durch
ihr großes Interesse an dieser Arbeit, durch Fragen und Diskussionen geholfen
haben, dieses Gebiet in seiner Gesamtheit zu begreifen und aus verschiedenen
Blickpunkten zu betrachten.
Für zahlreiche Tipps und Tricks bezüglich Design und Layout bedanke ich mich bei
Sylvia Brandt.
Mein besonderer Dank geht an meine Verlobte Alexandra Georg für Ihr liebevolles
Verständnis, ihre Unterstützung und ihre umfangreiche Hilfe beim Redigieren dieser
Arbeit.
Darüber hinaus danke ich allen weiteren Personen, die auf irgendeine Art zum
Gelingen dieser Arbeit beigetragen haben.
Februar
2002 Roger
Zacharias
VII
Inhaltsverzeichnis
1
EINFÜHRUNG ...10
1.1
E
INLEITUNG
...10
1.2
Z
IELSETZUNG
...11
1.3
V
ORGEHENSWEISE UND
A
UFBAU DER
A
RBEIT
...11
1.4
B
ESCHREIBUNGSMETHODEN
...12
2
ARCHITEKTUREN, TECHNOLOGIEN UND PARADIGMEN...14
2.1
W
EB
S
ERVICE
A
RCHITEKTUREN
...15
2.1.1
Ein neues Paradigma...15
2.1.2
XML (Extensible Markup Language)...29
2.1.3
SOAP (Simple Object Access Protocol)...44
2.1.4
WSDL (Web Services Description Language) ...49
2.1.5
UDDI (Universal Description, Discovery, Integration) ...52
2.1.6
Web Services Frameworks ...55
2.1.7
Auswirkungen auf Geschäftsprozesse und modelle ...66
2.1.8
Zusammenfassung und Ausblick ...67
2.2
M
ANAGEMENT
-A
RCHITEKTUREN
...69
2.2.1
Begriffe, Anforderungen, Historie und Entwicklungen...71
2.2.2
Terminologie und grundlegende Konzepte ...81
2.2.3
OSI-Management / CMIP...87
2.2.4
Internet-Management / SNMP ...96
2.2.5
Vergleich OSI- und Internet-Management ...101
2.2.6
JMX Die Management-Architektur von Morgen? ...103
2.2.7
Integrierte Managementsysteme...114
2.3
T
ECHNOLOGIEN ZUM
Z
UGRIFF AUF
B
ANKPERIPHERIEGERÄTE
/
J/XFS ...117
2.3.1
Historie...117
2.3.2
Technologie, Architektur und Funktionsweise...121
2.3.3
Zusammenfassung ...128
3
EIN ÜBERWACHUNGSSYSTEM FÜR BANKPERIPHERIEGERÄTE...132
3.1
F
ACHLICHER
H
INTERGRUND
...132
3.1.1
Management von und durch Web Services ...133
3.2
A
NFORDERUNGSANALYSE
...137
VIII
3.2.1
Systemspezifikation... 137
3.2.2
Nichtfunktionale Anforderungen ... 138
3.2.3
Funktionale Anforderungen ... 139
3.2.4
Akteure und Anwendungsfälle... 140
3.3
K
ONZEPTIONELLES
M
ODELL
... 150
3.3.1
Statik des Systems... 150
3.3.2
Dynamik des Systems ... 159
3.4
G
ROBENTWURF
(T
OP
L
EVEL
D
ESIGN
)... 161
3.4.1
Benutzerschnittstelle ... 161
3.4.2
Architektur ... 164
3.4.3
Technologien, Produkte und APIs ... 165
3.5
F
EINENTWURF
(D
ETAIL
D
ESIGN
)... 175
3.5.1
Deployment ... 176
3.5.2
Managementdaten ... 179
3.5.3
Informationsfluss ... 180
3.5.4
Detaillierte Statik und Dynamik... 183
3.6
I
MPLEMENTIERUNG
... 184
4
BEWERTUNG ... 186
5
ZUSAMMENFASSUNG ... 192
9
KAPITEL
1
Einführung
One does not discover new lands
without consenting to lose sight
of the shore for a very long time.
(Andrew Gide)
10
1 Einführung
1 Einführung
1.1 Einleitung
Nichts ist beständiger als der Wandel! Diese Erkenntnis trifft momentan genau den
Kern. In allen Bereichen der IT werden bestehende Architekturen, Produkte und
Prozesse hinterfragt. Einhergehend mit dieser Entwicklung ist das Bestreben nach
Standardisierung, Offenheit und die Nutzung bereits vorhandener und bewährter
Implementierungen zu beobachten, ohne aber bereits getätigte Investitionen zu
vernachlässigen. Im Bereich der Softwareentwicklungsprozesse konkurrieren RUP
1
und XP
2
(oder werden sinnvoll gemeinsam eingesetzt), UML
3
hat sich als Standard
durchgesetzt (ist aber mittlerweile für viele schon zu umfangreich geworden), XML
4
ist kein ´Wunderding´ mehr, Begriffe wie ´Web Services´
5
, ´SOAP´
6
und ´EAI´
7
kursieren (und werden überall anders definiert), mächtige Frameworks wie ´J2EE´
8
entstehen, worauf Microsoft mit ´.NET´
9
antwortet und SAP liegt mit ´mySAP.com´
10
voll im Trend. Das Internet ist unersetzbarer Bestandteil unseres Lebens geworden,
der E-Commerce kommt langsam in Fahrt und es wächst der Wunsch der
Unternehmen, Prozesse über das Internet mit anderen Unternehmen zu integrieren.
Viele dieser Entwicklungen sind mit weitreichenden Marketing-Maßnahmen
verbunden, die diesen zunächst den Status des Hype verleihen, sich aber wie XML
später doch als ´ganz brauchbar´ herausstellen. Auch im Bereich der Banken- bzw.
Überwachungs-Software, in dem der praktische Teil dieser Arbeit angesiedelt ist,
gelten diese Regeln. Globalisierung, Vernetzung, anspruchsvollere Konsumenten
und verstärkter Konkurrenzdruck sind die Herausforderungen an die
Finanzwirtschaft, in der, wie in kaum einem anderen Bereich, die IT-Systeme durch
1
Unter dem Rational Unified Process (RUP) versteht man ein objektorientiertes, UML-basiertes Vorgehensmodell, welches
gleichzeitig kommerziell von der Fa. Rational Software vertrieben wird. Weitere Informationen unter http://www.rational.com/rup.
2
Unter Extreme Programming (XP) versteht man einen leichtgewichtigen Entwicklungsprozess für kleine Teams, der aus 12
Richtlinien besteht und hierbei auch bestimmte soziale Aspekte des Software-Engineerings berücksichtigt. Weitere
Informationen unter http://www.extremeprogramming.org.
3
Die Unified Modelling Language (UML) ist eine grafische Notation zur Erstellung objektorientierter Modelle für die Analyse und
den Entwurf objektorientierter Software. Weitere Informationen unter http://www.uml.org.
4
Die Extensible Markup Language (XML) ist eine Metasprache zur Definition von Markup-Sprachen. Eine Einführung in XML
bietet Kapitel 2.1.2 XML (Extensible Markup Language).
5, 6, 7, 8, 9, 10
Auf diese Begriffe wird in Kapitel 2 Architekturen, Technologien und Paradigmen näher eingegangen.
1 Einführung
11
beträchtliche Kosten, enorme Komplexität und hohe Anforderungen an die
Funktionalität gekennzeichnet sind.
Die Lösung sind moderne Architekturen, die leicht in bereits bestehende heterogene
Strukturen integrierbar, beliebig erweiterbar und adaptierbar sind und dabei im
Idealfall auf offenen Standards basieren. Web Services versprechen diese
Anforderungen zu erfüllen und sollen die nächste Generation des Internets - das
´service web´ - ermöglichen. Gleichzeitig steigt der Bedarf an Managementsystemen,
welche in der Lage sind diese komplexen Systeme, welche manuell nicht mehr
beherrschbar sind, zu überwachen und zu administrieren. Auch hier existieren eine
Reihe neuer Technologien und Architekturen, die dies leisten wollen.
1.2 Zielsetzung
Diese Diplomarbeit verfolgt zwei Ziele: Zum einen soll sie in die Gebiete der
Management- und Web Services-Architekturen einführen, deren Vor- und Nachteile,
Einsatzgebiete und Entwicklung diskutieren und sie, sowie entsprechende ´state of
the art´-Lösungen, damit dem Leser näher bringen. Zum anderen soll sie, basierend
auf diesen Erkenntnissen, durch die prototypische Konzeption und Realisierung
eines Überwachungssystem für Bankperipheriegeräte die enormen Möglichkeiten
und Potentiale aufzeigen, wie durch die Kombination von Management- und Web
Services-Architekturen lose-gekoppelte, plattformunabhängige, leicht integrierbare
und adaptierbare Management-Systeme erstellt werden können ein Aspekt, der
nach Wissen des Autors zur Zeit noch nicht in der Literatur zu finden ist. Die
Funktionalität des erstellten Prototyps umfasst nur die absolut notwendigen Aufgaben
von Management-Systemen. Dieser Prototyp kann und wird entsprechend erweitert
werden, um in eine zurzeit bei der Wincor Nixdorf GmbH Co. KG entwickelte
moderne Multichannel-Architektur einzufließen.
1.3 Vorgehensweise und Aufbau der Arbeit
Kapitel 2 Architekturen, Technologien und Paradigmen führt in das Umfeld der
Management- und Web Services-Architekturen sowie in die für die Konzeption und
Realisierung des Überwachungssystems notwendigen Technologien im Banken-
Umfeld ein.
12
1 Einführung
Kapitel 3 Ein Überwachungssystem für Bankperipheriegeräte beschreibt die
Konzeption und Realisierung eines Überwachungssystems für Bankperipheriegeräte
unter Verwendung der im zweiten Kapitel beschriebenen Konzepte.
Kapitel 4 Bewertung beurteilt die Ergebnisse, zu denen der Autor durch seine
wissenschaftliche Auseinandersetzung mit diesen Themen gekommen ist.
Kapitel 5 Zusammenfassung fasst die wichtigsten Punkte dieser Arbeit
zusammen und geht noch einmal auf die enormen Möglichkeiten ein, die sich aus der
Verwendung dieser Architekturen bzw. Technologien ergeben.
1.4 Beschreibungsmethoden
Zur Darstellung der entwickelten Konzepte wird in dieser Arbeit, neben der verbalen
Beschreibung, auch mit der zur Zeit am weitesten verbreiteten grafischen
Notationssprache, der Unified Modelling Language (UML), gearbeitet. Die UML ist
die Vereinigung und Weiterentwicklung verschiedener Analyse- und Design-
Notationen, wurde 1997 von der OMG
1
als Notation für Softwarearchitekturen
standardisiert und liegt zum Zeitpunkt dieser Arbeit in der Version 1.4 vor.
1
Die Object Management Group (OMG) ist eine internationale, nicht profit-orientierte, herstellerübergreifende Organisation, die
von einigen großen IT-Firmen mit dem Ziel gegründet wurde, die Entwicklung von objektorientierter Software und Technologie
zu unterstützen. Dies geschieht hauptsächlich durch die Erstellung von Richtlinien und Standards.
13
KAPITEL
2
Architekturen, Technologien
und Paradigmen
Computers are useless they can only give you answers.
(Pablo Picasso)
14
2 Architekturen, Technologien und Paradigmen
2 Architekturen, Technologien und Paradigmen
Dieses Kapitel soll in die Web Services-, Management- und Bankperipheriezugriffs-
Architekturen und Technologien einführen und damit verknüpfte Paradigmen
aufzeigen. Das Verständnis dieser Punkte ist Voraussetzung für die in Kapitel 3 Ein
Überwachungssystem für Bankperipheriegeräte vorgestellte Konzeption und
Realisierung eines Überwachungssystem-Prototyps. Dieser baut auf diesen
Technologien auf und versucht ihre Vorteile zu nutzen, indem er sie sinnvoll
verknüpft und anwendet. Da sowohl XML als auch SNMP mittlerweile weit
verbreitetet und bekannt sind, können Leser, die in diesen Bereichen entsprechende
Kenntnisse besitzen, Kapitel 2.1.2 XML (Extensible Markup Language) und Kapitel
2.2.4 Internet Management / SNMP ohne Beeinträchtigung auslassen. Die
Aufteilung dieses Kapitels stellt sich folgendermaßen dar:
Web Services Architekturen
Management Architekturen
Architekturen zum Zugriff auf Bankperipheriegeräte
Zu jedem Themengebiet werden zunächst Historie und Notwendigkeit beschrieben,
anschließend Begrifflichkeiten geklärt und tiefer in die Technologie eingestiegen. Am
Ende jedes Themengebiets werden verschiedene Anwendungsbeispiele dargestellt,
wie diese Architekturen heute in der IT verwendet werden. Aufgrund der Komplexität
jeder dieser drei Bereiche soll jeweils nur auf die wichtigsten übergreifenden Punkte
und die für den Prototyp notwendigen Details eingegangen werden. Für denjenigen
Leser, welcher tiefer in die jeweilige Thematik einsteigen möchte, bietet das
Literaturverzeichnis eine Reihe weiterführender Literatur.
2 Architekturen, Technologien und Paradigmen
15
2.1 Web Service Architekturen
Firma X möchte im Internet die Ware W bei Firma Y bestellen, wobei Y diejenige
Firma sein soll, welche W am kostengünstigsten anbietet. Um den günstigsten
Anbieter zu finden, muss ein Mitarbeiter der Firma X mit Hilfe von Suchmaschinen
und Katalogen verschiedene Anbieter auswählen und auf deren Webseiten nach den
Konditionen recherchieren. Günstiger wäre es, die Anforderungsparameter, also
Produkt, Kosten, Lieferbarkeit, Zahlungsbedingungen usw. über eine geeignete
Schnittstelle zu definieren und damit einen Software-Agenten zu veranlassen, alle
Angebote zu durchsuchen um den optimalen Anbieter zu finden. An dieser Stelle
setzt die Vision des dynamischen E-Business unter Nutzung der ´Web Services´
Technologie an. In diesem Kapitel sollen Web Services, ihre Visionen, die zugrunde
liegenden Technologien sowie Auswirkung auf E-Business und Geschäftsmodelle
diskutiert werden.
2.1.1 Ein neues Paradigma
Das Problem ist bekannt: Es existieren Millionen von Web-Servern weltweit, welche
fast das gesamte Wissen der Menschheit jedermann zugänglich machen sollen. Die
übliche Form, in der Informationen geliefert werden, ist HTML, welches von einem
Browser dargestellt den Inhalt dem menschlichen Betrachter präsentiert. Das heißt,
das World Wide Web ist zurzeit fast ausschließlich für die Maschine-Mensch-
Kommunikation vorgesehen (siehe hierzu auch Kapitel 2.1.2.1 Warum XML?). Web
Services sind derzeit eines der am heißesten diskutierten Themen, versprechen sie
doch, die Informationen auch Maschinen (Software) zugänglich zu machen, also
zusätzlich die Möglichkeit der ´program-to-program interaction´ zu eröffnen. Gerade
diese Möglichkeit, das volle Potential des Internets zu nutzen, ist heute für
ausgefeilte B2B-, B2C- oder P2P-Lösungen von zunehmender Bedeutung.
Mit CORBA
1
, RMI
2
, DCOM
3
usw. existieren bereits verschiedene Protokolle für den
Zugriff auf entfernte Dienste. Diese sind aber komplex, teuer und meist nicht
interoperabel. Weiterhin eignen sich diese Protokolle aus dem CORBA-, Java- und
1
Bei der Common Object Request Broker Architecture (CORBA) handelt es sich um die zurzeit bekannteste und ausgereifteste
Middleware-Architektur. Diese Plattform ist sowohl programmiersprachen- als auch plattformunabhängig.
2
RMI (Remote Method Invocation) ist das verteilte Komponentenmodell der Java-Plattform.
3
Die Distributed Components (DCOM) Architektur ist das verteilte Komponentenmodell der Microsoft-Plattform.
16
2 Architekturen, Technologien und Paradigmen
Microsoft-Bereich nicht für das Internet, da sie verbindungsorientiert sind und stabile
Verbindungen erfordern, die das Internet nicht bieten kann. Außerdem sind diese
Protokolle für Aufrufe über das Internet ungeeignet, da sie aufgrund variabler
Portzuordnungen und ähnlichem Probleme mit dem Verbindungsaufbau durch
Firewalls haben. Diese ´tightly coupled systems´ werden durch ´message oriented
middleware´ (MOM) ergänzt, welche die zeitliche Entkoppelung von Systemen durch
asynchrone Nachrichtenverarbeitung ermöglicht, aber im Internet ähnliche Probleme
wie die oben genannten besitzt. Das grundsätzliche Problem besteht darin, dass
Middleware-Technologien und das Internet zwei völlig getrennte Welten darstellen.
Die Idee besteht nun darin, diese beiden Welten zusammenzubringen und das
Internet zu einer Art Middleware zu erweitern. Man setzt für die Kommunikation das
übliche Web-Protokoll HTTP ein und benutzt für den Datentransport XML, welches
selbstbeschreibend und interoperabel ist. Als Messaging-Protokoll wird die im
Internet bereits existierende Messaging-Lösung eingesetzt: E-Mail über SMTP.
Dieses Szenario bzw. diese Vision wird als ´Web Service Technologie´ bezeichnet.
Die Web Service Technologie ist also eher Evolution als Revolution. Bereits
existierende Technologien bilden die Grundlage, auf denen Web Services aufbauen.
Oder um es mit James Harts
1
Worten zu sagen: "Web Services are, in many ways,
the logical conclusion of several threads which have been developing in the IT
industry for twenty years. However, this doesn't mean we should underestimate their
significance. By combining the steam engine and the wheel, George Stephenson was
simply combining the logical conclusions of two established fields of engineering into
their logical conclusion, but the implications of the invention of railroads can still be
felt today. Web Services have something of the feel of that first steam train about
them it's going to be an interesting ride."
2
Folgende Abbildung verdeutlicht die
Entwicklungen, welche die Basis für Web Services legten.
1
James Hart ist einer der Autoren des bekannten Buches ´Professional Java XML´, Wrox Press.
2
Vgl. [JHWS01], S. 2.
2 Architekturen, Technologien und Paradigmen
17
Abbildung 2-1 Entwicklungsgeschichte der Web Services
Hierbei ist jedoch zu beachten, dass Web Services als Ergänzung zu den bereits
existierenden Technologien betrachtet werden müssen. Die Web Service
Technologie dient dazu, Geschäftslogik über das Internet zur Verfügung zu stellen,
wobei Technologien wie J2EE und CORBA der Implementierung dieser
Geschäftslogik dienen.
Da Web Services von allen Global Players der IT, d.h. IBM, Microsoft, Sun, HP,
Oracle usw. propagiert werden, existieren für den Begriff ´Web Service´ eine Reihe
von Definitionen. Eine, nach Ansicht des Autors, geeignete findet sich in [CBDIWS]:
"A web service provides programmable access to a capability that can be used
independently of its implementation via a self-describing interface based on open
internet standards." Ein Web Service stellt eine Fähigkeit (capability) zur Verfügung
dies ist der geleistete Dienst (´service´). Der Zugriff auf diesen Dienst erfolgt via
Internet-Protokollen daher der Begriff ´web´. Bei diesen Protokollen handelt es sich
um ´offene Standards´, d.h. Standards, auf welche sich die Mehrzahl der
Unternehmen geeinigt haben und die vom W3C verwaltet werden. Weiterhin können
Web Services dynamisch gefunden und aufgrund des ´programmierbaren Zugriffs´ in
eigene Applikationen integriert werden.
2.1.1.1 Web Service Perspektiven
Ein Web Service kann aus zwei Perspektiven betrachtet werden: aus der Sicht des
Konsumenten des Dienstes und aus der Sicht des Erbringers (Provider) des
Dienstes. Für den Konsumenten ist nur der erbrachte Dienst entscheidend, d.h. es
interessiert, welche Aufgabe der jeweilige Dienst besitzt, wie er benutzt werden kann
Atomare
Applikationen
Komponenten
MOM
Verteilte
Komponenten
Interaktives
Web
Web Services
18
2 Architekturen, Technologien und Paradigmen
und auffindbar ist. Entscheidend für den Konsumenten ist also nur die
Dienstbeschreibungsschnittstelle, so dass aus dieser Sicht ein Web Service ein
Dienst ist, welcher über eine Schnittstelle im Internet angeboten wird. Für den
Provider ist neben der Schnittstelle die Implementierung des Dienstes bestimmend.
Der Provider entscheidet, welche Funktionalität der Dienst bietet, an welcher Stelle er
sich zur Laufzeit befindet und wo sein Vorhandensein publiziert ist. Aus der Sicht des
Providers handelt es sich also bei einem Web Service sowohl um die offen gelegte
Schnittstelle als auch die Software, welche den Dienst implementiert. Die folgende
Abbildung verdeutlicht dies.
Abbildung 2-2 Web Service Perspektiven
2.1.1.2 Web-Applikations Topologien
Was unterscheidet die Web Service Technologie von anderen Topologien, wie zum
Beispiel ´Application Service Providing´ (ASP) oder ´Software on Demand´ (SOD)?
Application Service Provider stellen meist Komplettlösungen einer Software zur
Verfügung, d.h. die gesamte Applikation im Sinne von Benutzeroberfläche, Workflow,
Geschäfts- und Daten-Komponenten ist in einer Lösung gebunden. Diese
Komplettlösung wird auf den Servern der ASPs gelagert, verwaltet und ausgeführt.
Der Benutzer dieser Software greift meist mittels Browser auf sie zu, um damit zu
arbeiten. Es existieren in den meisten Fällen wenige Möglichkeiten diese Software zu
konfigurieren und sie in die eigenen Geschäftsprozesse einzubinden. Eine
Alternative bietet die Software on Demand Lösung, bei welcher die Software auf
Bedarf (on demand) auf den Rechner des Kunden geladen wird. Diese Software
kann am Ende der Sitzung gelöscht werden oder auf dem Rechner verweilen, bis sie
durch eine neue Version ersetzt wird oder ein bestehender Nutzungsvertrag ausläuft.
Consumer
Perspective
How to publish it
What it does
How to use it
Where to find it
Interface
How to do it
How to build it
Where to host it
Provider
Perspective
Implementation
2 Architekturen, Technologien und Paradigmen
19
Diese Lösung bietet die Möglichkeit der unbeschränkten Konfiguration und
Personalisierung. Web Services bieten eine weit flexiblere Lösung: Der Kern der
Applikation, d.h. Geschäfts- und Datenkomponenten lagern weiterhin auf dem
Server, es kann nun aber programmatisch über ihre Schnittstellen auf sie zugegriffen
werden. So kann der Kunde seine eigenen Geschäftsprozesse und
Benutzeroberflächen erstellen und in diese beliebige Web Services beliebiger
Provider einbinden. Folgende Abbildung verdeutlicht dies.
Abbildung 2-3 ASP, SOD und Web Services (Quelle: [CBDIWS], S.11)
2.1.1.3 Zukunfts-Szenario
Web Services können, wie bereits angesprochen, in allen Bereichen verwendet
werden, wobei ihr größtes Potential sicher in den Bereichen B2B und B2C liegt. Ein
E-Commerce-Szenario der Zukunft, bei welchem die Informationen der
Wertschöpfungskette eines Unternehmens ausschließlich über Web Services
ausgetauscht werden, wird in Abbildung 2-4 E-Commerce Szenario der Zukunft
dargestellt. Die Vorteile stellen sich folgendermaßen dar: Zunächst ist es möglich,
direkt mit der jeweiligen Informationsquelle zu kommunizieren, wodurch jedes Datum
der Wertschöpfungskette immer akkurat und aktuell ist und damit die Notwendigkeit
der regelmäßigen Replikation entfällt. Verlangt der Kunde Informationen zur
Lieferbarkeit eines Produktes, wird diese Anfrage automatisch an den
entsprechenden Lieferanten weitergeleitet und von diesem beantwortet. Auf gleichem
Weg wird das Problem der ungenauen, falschen oder veralteten Daten behoben. So
20
2 Architekturen, Technologien und Paradigmen
ist es sowohl für den Kunden als auch für das Unternehmen möglich, bestimmte Web
Services der Wertschöpfungskette bzw. des Kunden-Frontends unabhängig von
Plattform und Endgerät in die eigene Applikation oder Kette einzubinden.
Abbildung 2-4 E-Commerce Szenario der Zukunft
2.1.1.4 Web Services Modell
Die Web Services Architektur basiert auf Interaktionen zwischen drei Instanzen,
welche jeweils eine bestimmte Rolle einnehmen. Diese Instanzen sind:
Service Provider
Der Service Provider stellt den Web Service zur Verfügung, welcher einen
spezifischen Dienst leistet. Aus der Geschäftsperspektive ist dies der Besitzer des
Dienstes, aus der Architekturperspektive derjenige, welcher den Dienst hostet
und den Zugriff auf diesen ermöglicht.
Service
Requestor
(Consumer)
Der Service Requestor ist der Konsument des Dienstes. Er findet und benutzt den
Dienst, um eine bestimmte Aufgabe zu erfüllen. Aus der Geschäftsperspektive ist
dies das Unternehmen, welches eine bestimmte Funktionalität benötigt, aus der
Architekturperspektive ist dies die Applikation, welche nach einem Dienst sucht
und eine Interaktion mit diesem Dienst anstrebt. Die Rolle des Service
Requestors kann hierbei von einem Browser, welcher auf Benutzereingaben
reagiert, oder einem Programm ohne Benutzerschnittstelle gespielt werden.
Natürlich kann der Service Requestor selbst ein Web Service sein, wodurch
Workflows realisiert werden können.
Produktinfos
abrufen
Über Lieferstatus
informieren
E-Commerce
Unternehmen
Verfügbarkeit
prüfen
Produktinfos
abrufen
Kunden
identifizieren
Produktkatalog
anzeigen
Hersteller
Logistik
Dienstanbieter
usw.
Kunde
Partner-
Unternehmen
Über Angebote
informieren
Bestellung
bearbeiten
Bestellstatus
abfragen
Lieferplan
erstellen
Lieferstatus
abfragen
2 Architekturen, Technologien und Paradigmen
21
Service
Registry
(Broker)
Die Service Registry bietet ein durchsuchbares Verzeichnis für Web Services
Schnittstellen. Service Requestors können in diesem Verzeichnis Dienste
auffinden, um diese zu nutzen.
Um das volle Potential dieser Architektur auszunutzen, müssen drei Interaktionen
stattfinden, welche sowohl einzeln als auch iterativ auftreten können:
publish
Damit auf einen Web Service zugegriffen werden kann und der Service
Requestor diesen finden kann, muss dessen Schnittstelle veröffentlicht werden.
An welcher Stelle die Schnittstelle veröffentlicht wird, hängt von verschiedenen
Faktoren ab. Ist eine dynamische Bindung gewünscht, geschieht dies in der
Service Registry. Andernfalls kann die Schnittstellenbeschreibung auch direkt
zwischen Service Provider und Service Requestor ausgetauscht werden (zum
Beispiel über E-Mail, FTP, Veröffentlichung auf Website usw.).
find
Mit Hilfe dieser Operation erlangt der Service Requestor die
Schnittstellenbeschreibung des gewünschten Dienstes. Dies kann direkt oder
über das Suchen innerhalb der Service Registry geschehen. Weiterhin kann diese
Operation in zwei verschiedenen Lebenszyklusphasen aufgerufen werden: zur
Designzeit, um die Schnittstellenbeschreibung zur Programmentwicklung zu
verwenden und zur Laufzeit, um eine dynamische Nutzung der Architektur zu
ermöglichen.
bind
Durch diese Operation baut der Service Requestor eine Verbindung zum Service
Provider auf und initiiert eine Interaktion. Das Initiieren der Interaktion geschieht
entweder durch einen direkten Aufruf einer Methode des Web Service (RPC) oder
dadurch, dass sich der Service Requestor für asynchrone Ereignisse beim
Service Provider registriert (Messaging).
Wie bereits in Kapitel 2.1.1.1 Web Service Perspektiven angesprochen, hat ein
Web Service zwei grundlegende Bestandteile:
Service
Die Implementierung des Web Service liefert den Service selbst. Dieser Service
ist ein Softwaremodul, welches auf dem Server des Service Providers abgelegt ist
22
2 Architekturen, Technologien und Paradigmen
und per Netzwerk zugreifbar ist. Es interagiert mit dem Service Requestor oder
kann selbst als Service Requestor fungieren, indem es andere Web Services
benutzt.
Service Description
Die Beschreibung eines Web Service beinhaltet die Details der Schnittstelle und
der Implementierung des Dienstes. Dies umfasst Datentypen, Operationen,
Bindungsinformationen und Informationen über den Server, auf welchem sich der
Dienst befindet. Es können weiterhin Metainformationen über den Dienst und
dessen Provider enthalten sein, um den Web Service zu kategorisieren und das
Auffinden durch den Service Requestor zu vereinfachen.
Das typische Szenario sieht folgendermaßen aus: Ein Service Provider stellt
unterschiedliche Dienste, wie zum Beispiel einen Aktienkurs-Informationsdienst, auf
seinem Server zur Verfügung. Desweiteren veröffentlicht er die Web Service
Beschreibung in einer globalen Service Registry, wo diese von jedem aufgefunden
werden kann. Ein Service Requestor sucht in dieser Registry nach für ihn geeigneten
Diensten und findet zum Beispiel diesen Aktienkurs-Informationsdienst. Er erhält als
Antwort auf seine Anfrage an die Registry die Schnittstellenbeschreibung des
Dienstes und ist nun in der Lage auf diesen zuzugreifen, um ihn zum Beispiel in eine
eigene Applikation einzubinden. Das Web Services Modell stellt sich also
folgendermaßen dar:
Abbildung 2-5 Web Services Modell
bind
Service
Description
find
publish
Service
Registry
Service
Requestor
Service
Provider
Service
Description
Service
Service
Description
RPC
message
2 Architekturen, Technologien und Paradigmen
23
2.1.1.5 Warum Web Services?
Es existiert eine Reihe von Vorteilen, welche sich durch die Nutzung von Web
Services ergeben. Einige dieser Vorteile können auch durch andere Ansätze und
bereits existierende Technologien erreicht werden. Nachfolgend verschiedene für die
Web Service Technologie spezifische Vorteile:
Loose technologie coupling zwischen Requestor- und Provider-Plattform
besteht keine Technologieabhängigkeit mehr.
Late binding ermöglicht den Beziehungsaufbau zwischen Systemen zur
Laufzeit.
Dynamic Inspection die Fähigkeiten und Funktionalitäten von Web Services
können auch zur Laufzeit aufgefunden werden.
Programmable Web Services ermöglichen es, dass Systeme Funktionen über
das Internet aufrufen, statt nur Daten auszutauschen und zu präsentieren.
Use of standard protocols es wird eine Reihe standardisierter und allgemein
anerkannter Protokolle verwendet, statt wie bisher viele verschiedene proprietäre
Technologien.
Industry consensus alle Key Player akzeptieren und propagieren die Web
Service Technologie.
Protecting investments Web Services ersetzen keine bestehenden Systeme,
sondern fügen eine Schicht weiterer Funktionalität hinzu. Dadurch sind bereits
getätigte Investionen geschützt.
2.1.1.6 Web Service Standards
Web Services sind in jeder Netzwerk-Umgebung verwendbar, egal ob es sich dabei
um Internet, Extranet oder Intranet handelt. Ihr alleiniger Fokus liegt auf dem
Zusammenspiel der Anwendungskomponenten. Weiterhin spielen weder
Betriebssystem noch Programmiersprache oder Komponentenmodell eine Rolle. Es
liegt nahe, dass eine solche Offenheit der Zusammenarbeit einige Standards
voraussetzt. Diese Standards, welche in den nachfolgenden Kapiteln näher
vorgestellt werden sollen, sind: XML, SOAP, WSDL und UDDI. Es ist jedoch zu
beachten, dass diese vier Standards nur die erste Stufe und damit die Basis der Web
Services Evolution darstellen. Um die vollständige Vision zu verwirklichen, bedarf es
24
2 Architekturen, Technologien und Paradigmen
einer Reihe weiterer Standards, welche sich zum Teil bereits in der Entwicklung
befinden. Der Ansatz, welcher insbesondere von IBM propagiert wird, besteht in
einer modularen Annäherung an die Gesamtvision, d.h. die Evolution verläuft in
Phasen. Dies impliziert, dass jedes Protokoll separat eingeführt wird und Zeit hat sich
selbständig zu entwickeln.
Abbildung 2-6 Web Services Evolution (Quelle: [WSRHRN],S.5)
Eine Erklärung der dargestellten Technologie liefert die folgende Tabelle:
XML
Extensible Markup Language;
Metasprache zur Definition von Markup-Sprachen
SOAP
Simple Object Access Protocol;
XML-Protokoll zum Transport von XML-Daten
WSDL
Web Services Description Language;
XML-Protokoll zur Beschreibung von Web Services
UDDI
Universal Description, Discovery, Integration;
Basis für Web Services Registry
WSIL
Web Services Inspection Language;
Durchsuchen einer Website nach verfügbaren Web Services
WSCM
Web Services Component Model;
Komposition und Präsentation von Web Services
ebXML
Electronic Business Extensible Markup Language;
XML-basierte Infrastruktur für den elektronischen Handel
XML-Signature Beschreiben und Prüfen von digitalen Signaturen auf XML-Basis
2 Architekturen, Technologien und Paradigmen
25
XML-
Encryption
Verschlüsselung von digitalen Inhalten auf XML-Basis
SOAP-DSIG
Simple Object Access Protocol Digital Signatures;
Signieren von SOAP Nachrichten
SAML
Security Assertion Markup Language;
Austausch von Authentifikations- und Autorisierungsinformationen
HTTPR
Hypertext Transfer Protocol Reliable;
Zuverlässiger Datentransport über HTTP
WSFL
Web Services Flow Language;
Workflow auf Web Services Basis
Tabelle 2-1 Web Services Standards
Wir befinden uns zurzeit in der ersten Phase (2001 dynamic business integration,
simple transactions). Die Basisprotokolle (XML, SOAP, WSDL und UDDI) sind
standardisiert oder zumindest de facto Standards. In dieser Phase sind bereits
folgende Szenarien möglich:
Verbesserte Enterprise Application Integration (EAI) Web Services werden
intern zur vereinfachten Anbindung an Legacy-Systeme verwendet.
Business to Business (B2B) Integration zwischen Partnern Web Services
ermöglichen Echtzeit-Kommunikation zwischen ausgewählten Organisationen,
unabhängig von der für die Implementierung verwendeten Technologien.
Erstellung von intelligenten Endpunkten Web Services liefern strukturierte
Informationen zur externen Weiterverarbeitung in fremden Applikationen ohne die
bisherige Abhängigkeit von Benutzerinteraktionen.
Einfache Informationsdienste und Transaktionen sind für eine weitreichendes
Publikum verfügbar.
Obwohl die Web Service Technologie noch in ihren Kinderschuhen steckt, wird sie
von allen Seiten akzeptiert und durch eine Vielzahl von Entwicklungsumgebungen,
Adaptern und Konnektoren unterstützt. "It is difficult to find a previous technology that
the whole industry has been so quick to endorse and adopt without major dissent."
1
1
Vgl. [WSRHRN], S.5.
26
2 Architekturen, Technologien und Paradigmen
Phase zwei (2002-2004 improved infrastructure, more complex transactions) wird
weitere Protokolle einführen, welche eine robustere Infrastruktur und komplexere
Transaktionsszenarios ermöglichen. Eine weitere wichtige Aufgabe dieser Protokolle
ist die Schaffung einer Sicherheitsarchitektur für Web Services.
In Phase drei (2004+ adaptive systems) haben Web Services eine weite
Verbreitung gefunden und Organisationen werden nun nicht nur ihre Systeme,
sondern auch ihre Geschäftsmodelle anpassen, um die Vorteile des dynamischen
Verhaltens der Web Service Technologie zu nutzen. Dazu gehören das dynamische
Auffinden von Geschäftspartnern, die dynamische Nutzung von entfernten Diensten
und die dynamische Anpassung an Änderungen aller Art. Es werden sich selbst
beschreibende und sich selbst heilende Systeme möglich, welche sich permanent
optimieren, um neue Möglichkeiten zu nutzen.
2.1.1.7 Web Services Stack
Um die Operationen publish, find und bind interoperabel auszuführen, wird ein Web
Services Stack benötigt, welcher auf jeder Ebene entsprechende Standards und
Protokolle zur Verfügung stellt. Abbildung 2-7 Web Services Stack zeigt diesen Web
Services Stack. Die jeweils über einer anderen liegende Schicht nutzt die Fähigkeiten
der darunter liegenden Schichten und baut auf diesen auf. Die vertikalen Balken
repräsentieren Anforderungen, welche in jeder Schicht erfüllt sein müssen. Der Text
auf der linken Seite nennt die Standards bzw. aufkommende Standards, die die
jeweilige Schicht adressieren.
Abbildung 2-7 Web Services Stack (Quelle: [WSCA], S.10)
2 Architekturen, Technologien und Paradigmen
27
Die Grundlage des Web Services Stacks bildet das Netzwerk. Web Services müssen
über das Netzwerk zugreifbar sein, um den Informationsaustausch zwischen Service
Requestor und Service Provider zu ermöglichen. Web Services im Internet-Bereich
nutzen weit verbreitete Netzwerkprotokolle wie HTTP, SMTP und FTP, während Web
Services im Intranet Bereich weitere Protokolle wie IIOP
1
oder MQ (Message
Queuing) benutzen können. Die zweite Schicht, das XML-basierte Messaging,
repräsentiert die Benutzung von XML (siehe Kapitel 2.1.2 XML (Extensible Markup
Language)) als Basis für ein Messaging-Protokoll. In diesem Bereich hat sich SOAP
(siehe Kapitel 2.1.3 SOAP (Simple Object Access Protocol)) aus den
verschiedensten Gründen als alleiniger Standard durchgesetzt. Die Service
Description Schicht besteht eigentlich selbst wiederum aus einem Stack von Web
Service Beschreibungs-Dokumenten, wobei WSDL (siehe Kapitel 2.1.4 WSDL (Web
Service Description Language)) der minimale de facto Standard ist, um Web
Services zu beschreiben. Weitere Beschreibungen auf höherer Ebene, wie zum
Beispiel den Unternehmenskontext, Servicegüte oder Dienst-Dienst-Beziehungen
bieten andere Protokolle. Der Unternehmenskontext wird zum Beispiel durch UDDI
(siehe Kapitel 2.1.5 UDDI (Universal Description, Discovery, Integration))
beschrieben, welches in Verbindung mit WSDL eingesetzt wird. Service Komposition
und Workflow werden in einem WSFL Dokument beschrieben. Jede Aktion, welche
ein WSDL Dokument einem Service Requestor zugänglich macht, wird als ´Service
Publication´ bezeichnet. Dabei besteht die einfachste und zugleich am wenigsten
dynamische Möglichkeit darin, das WSDL Dokument direkt an den Service
Requestor zu senden. Alternativ kann der Service Provider das Dokument in einer
öffentlich zugänglichen UDDI-Registry veröffentlichen, wo es für den Service
Requestor auffindbar ist. Das Auffinden des Dokumentes geschieht ebenfalls mit
Hilfe des UDDI Protokolls und wird als ´Service Discovery´ bezeichnet.
Da die Implementierung eines Web Services ein Softwaremodul ist, liegt es nahe,
Web Services durch Komposition anderer Web Services zu erzeugen. Hierbei
existieren eine Reihe von Anwendungsgebieten. So könnten unternehmensinterne
Web Services kollaborieren, um Workflows abzubilden, wobei nach außen hin nur ein
Web Service sichtbar ist, welcher die Workflow-Kette anstößt. Eine weitere wichtige
Anwendung ist die Kollaboration von Web Services verschiedener Unternehmen zum
1
IIOP (Internet Inter ORB Protocol) ist das CORBA-Protokoll für die Kommunikation im Internet.
28
2 Architekturen, Technologien und Paradigmen
Aufbau von Supply Chain Ketten. Einige Anwendungen werden in Kapitel 2.1.7
Auswirkungen auf Geschäftsprozesse und -modelle vorgestellt. Die oberste Schicht,
die Service Flow Schicht, beschreibt Service-Service-Kommunikation, Workflows und
Kollaborationen. Der Standard, welcher sich zurzeit für diesen Bereich etabliert, ist
WSFL.
Web Service Anwendungen, die heutigen E-Business Anforderungen genügen
wollen, verlangen nach einer entsprechenden Infrastruktur, die den Anforderungen
an Sicherheit, Management und Dienstgüte genügen. Diese vertikalen Balken
adressieren jede Schicht und befinden sich zurzeit größtenteils noch in der
Entwicklung.
2 Architekturen, Technologien und Paradigmen
29
2.1.2 XML (Extensible Markup Language)
Dieses Kapitel soll Grundlagen und Konzepte der Metasprache XML vorstellen, wozu
zunächst kurz auf die Geschichte der Technologie eingegangen wird. Anschließend
wird XML in das Umfeld der Meta- und Markup-Sprachen positioniert, die Vorteile
dargestellt und diskutiert, warum XML im Begriff ist, die vorherrschende Sprache für
Datenbeschreibung, Datenspeicherung und Datentransport zu werden.
2.1.2.1 Warum XML?
Die rasante Verbreitung des Internets, welches hauptsächlich auf dem
Transportprotokoll HTTP (Hypertext Transfer Protocol) und der Markup-Sprache
HTML (Hypertext Markup Language) basiert, brachte eine Menge Nachteile und
Unzulänglichkeiten mit sich:
Die Menge an unstrukturierten Informationen ist so gigantisch, dass es sehr
schwer ist, die relevanten Informationen zu finden. Simon Phipps, CTO Sun
Microsystems Inc., meinte zu diesem Problem: "The web could be a much better
business tool if its data was more structured!".
Ein weiteres Problem liegt in der unterschiedlichen Darstellung der Informationen.
Es existiert kein absoluter Standard für die Speicherung von Daten und die
Kommunikation. So durchläuft ein Datum aus der Datenbank viele
unterschiedliche Umformatierungen und Konvertierungen, um zum Beispiel auf
einem WAP-Handy angezeigt zu werden oder in einer PDF-Datei zur Verfügung
zu stehen.
Die Inhalte unterliegen einer hohen Änderungsrate, da die Aktualität ein wichtiges
Kriterium der dargestellten Informationen ist. Diese Aktualität kann aufgrund der
unstrukturierten Informationsmenge nicht oder nur sehr schwer gewährleistet
werden.
Mit Hilfe der Darstellung und des Kontextes kann ein Mensch die Semantik der
Daten erkennen, eine Maschine (Software) ist jedoch nicht in der Lage,
semantische Informationen zu erkennen und zu extrahieren.
Das WWW war ursprünglich für die Mensch-Mensch- bzw. Mensch-Maschine-
Kommunikation konzipiert. Durch die Verwendung dieses Mediums als B2B-
Plattform wird die Maschine-Maschine-Kommunikation immer wichtiger, was
30
2 Architekturen, Technologien und Paradigmen
vollkommen andere Anforderungen an die verwendeten Kommunikations-
sprachen stellt.
XML verfolgt hierbei vier grundlegende Ansätze:
die Strukturierung der zurzeit noch unstrukturierten Informationen im WWW
den plattform- und systemübergreifenden Datenaustausch zwischen
Geschäftspartnern und zwischen Firmenentitäten innerhalb einer Firma
die Beschreibung von Metadaten
die Möglichkeit der maschinellen Verarbeitung der Daten
Mit XML war zunächst ein enormer Hype verbunden, mittlerweile hat sich aber
herausgestellt, dass XML wirklich viele der beschriebenen Probleme lösen kann und
damit seine Daseinsberechtigung in der IT-Welt hat. Die meisten Konzepte, die in
XML verwendet werden, sind nicht neu. Wirklich neu ist die breite Unterstützung
dieses Standards durch die Software-Industrie. Alle Global Player und Rivalen wie
Sun, Microsoft, IBM, Oracle, HP, SAP usw. haben sich in Bezug auf diesen
herstellerunabhängigen, ´freien´ Standard geeinigt. Viele Hersteller haben
mittlerweile ihre proprietären Datenformate aufgegeben und nutzen XML. Die XML
Technologie ist der Hoffnungsträger der IT-Welt: ein plattform- und
applikationsübergreifendes Datenaustausch-, Datenverwaltungs- und
Datendarstellungsformat, welches die divergierenden IT-Infrastrukturen weiter
zusammenbringen und dem WWW zu mehr Struktur und Ordnung verhelfen soll. Mit
Java ist erwiesenermaßen portabler Code möglich (´write once run anywhere´), mit
XML nun auch portable Daten (´write once read anywhere´). Ein weiteres wichtiges
Merkmal ist die strikte Trennung des Inhaltes von dessen Präsentation, d.h. in einem
XML-Dokument werden Aussagen darüber gemacht, um welche Informationen es
sich handelt und wie diese strukturiert sind, aber nicht, wie diese darzustellen sind.
Hierzu existiert der XML Co-Standard XSL, auf welchen in Kapitel 2.1.2.3.7 XSL
Transformation und Darstellung kurz eingegangen werden soll. Weiterhin erlaubt
XML den Anwendern ihre eigene, auf den entsprechenden Anwendungsbereich
abgestimmte, Sprache zu definieren. Wichtig ist hierbei, dass die
Dokumentenstruktur jeder mit XML erzeugten Sprache gleich bleibt und somit
weiterhin unabhängig verarbeitet werden kann. Außerdem ist XML für Computer
einfach zu verarbeiten, auszutauschen und darzustellen. Des Weiteren sind sehr
viele Entwicklungswerkzeuge in diesem Umfeld frei erhältlich und vor allem
2 Architekturen, Technologien und Paradigmen
31
standardkonform. Diese Faktoren führten und führen zu einer weiten Verbreitung
dieser Meta-Sprache.
2.1.2.2 Positionierung
Oft wird XML direkt mit HTML verglichen oder gar als dessen Nachfolger bezeichnet.
Um eine klare Trennung zu erreichen, sollen zunächst die Begriffe der Meta- und
Markup-Sprache, sowie des Dokuments geklärt werden.
Eine Metasprache dient zur Definition der Grammatik und des Vokabulars anderer
Sprachen, d.h. sie enthält Informationen über die in einer Sprache transportierten
Informationen. Mit Meta-Sprachen können also Sprachen, wie zum Beispiel Markup-
Sprachen, definiert werden. Bei XML und dessen Vorgänger SGML (Standard
Generalized Markup Language) handelt es sich um solche Meta-Sprachen zur
Definition von Markup-Sprachen. Markup-Sprachen, auch als
Auszeichnungssprachen bezeichnet, sind Sprachen, welche mittels eingestreuter
Direktiven (Tags) die Struktur und/oder die Präsentation eines Dokumentes
bestimmen. Markup-Sprachen erzeugen Dokumente immer für eine bestimmte
Anwendung und werden meist für eine bestimmte Anwendung (z.B.
Textformatierung) entworfen. Bei HTML handelt es sich um eine solche
Auszeichnungssprache, wobei HTML selbst durch die Meta-Sprache SGML definiert
wurde. Ein Dokument ist wiederum mit Hilfe einer Markup-Sprache definiert und
beinhaltet letztendlich die Daten, ist also der Informationsträger. Ein Dokument
besteht aus:
Struktur (Markup-Elemente mit Attributen)
Inhalt (die eigentlichen Informationen, d.h. Text- und Daten-Elemente)
Präsentation (Definition der Ausgabe des Inhalts)
Als Beispiele sind RTF-Dokumente, Microsoft Word Dokumente, PDF-Dokumente
und natürlich mit HTML definierte WWW-Seiten zu nennen. Der Nachteil von HTML
liegt darin, dass der Inhalt optisch aber nicht semantisch strukturiert wird, d.h. der
Inhalt verschmilzt mit der Präsentation. HTML Tags beschreiben nur, wie der Inhalt
dargestellt werden soll, aber nicht, was er darstellt. So ist es nicht möglich die
dargestellten Daten aus einem HTML-Dokument zu extrahieren, um sie an anderer
Stelle wieder verwenden zu können. Es kommt also zu einem Informationsverlust im
Sinne der Weiterverarbeitung der Daten.
32
2 Architekturen, Technologien und Paradigmen
Die folgende Abbildung verdeutlicht den Zusammenhang zwischen Metasprache,
Markup-Sprache und Dokument.
Abbildung 2-8 Beziehung Meta-Sprache, Markup-Sprache, Dokument
2.1.2.3 XML Technologie
In diesem Kapitel sollen Syntax, Semantik und grundlegende Konzepte der Meta-
Sprache XML anhand eines einfachen Beispiels dargestellt werden.
2.1.2.3.1 Wohlgeformte und gültige XML-Dokumente
Alle XML-Dokumente als konkrete Instanzen einer mit XML definierten Markup-
Sprache haben eine einfache, universelle Grundstruktur, definiert durch die XML-
Syntax. Nach dieser besteht ein XML-Dokument aus:
einem Prolog mit einer ´Startanweisung´, die das Element als XML-Dokument
identifiziert und den verwendeten Zeichensatz festlegt sowie einem optionalen
Verweis auf eine DTD (siehe Kapitel 2.1.2.3.2 - DTD (Document Type Definition))
dem Hauptteil, bestehend aus einem Wurzelelement mit untergeordneten
Elementen in Form einer Baumstruktur, wobei diese Elemente Attribute besitzen
können
einem optionalem Epilog, der Kommentare oder Verarbeitungsanweisungen
enthalten kann
Ein Element enthält eine Anfangsmarke (´Start-Tag´), eine Endmarke (´End-Tag´)
und einen zwischen diesen Marken geklammerten Inhalt. Der Inhalt kann aus
weiteren strukturierten Elementen oder reinem Text bestehen. Elemente können
auch Attribute besitzen, welche in der Anfangsmarke definiert werden. Ein Beispiel
für ein solches Dokument liefert Abbildung 2-9 Einfaches XML-Dokument. In diesem
Beispiel wird ein XML-Dokument dargestellt, wie es (im einfachsten Fall) bei einer
elektronischen Bestellung auftreten könnte. Eine Ähnlichkeit mit HTML ist vorhanden,
allerdings gelten folgende Regeln, die in HTML nicht zwingend sind:
Meta-Sprache
Markup-Sprache
Dokument
definiert
0..*
definiert
0..*
2 Architekturen, Technologien und Paradigmen
33
Elemente dürfen sich nicht überlappen
leere Elemente können in Kurzform benutzt werden
jedes Element muss mit einer Endmarke abgeschlossen werden
Groß- und Kleinschreibung der Element- und Attributnamen ist entscheidend
Attributwerte müssen in Anführungszeichen gesetzt werden
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE Bestellung SYSTEM Bestellung.dtd
Bestellung
Datum14.04.2001/Datum
Kunde
NameRoland
Zack/Name
EMailRoland.Zack@t-online.de/EMail
/Kunde
Artikel Artikelnr=S0019
BeschreibungAMD Athlon 1100/256/30,5 System/Beschreibung
Menge7/Menge
Preis2100 DM/Preis
/Artikel
Artikel Artikelnr=P00123
BeschreibungAgfa-Snapscan 310 Scanner/Beschreibung
Menge17/Menge
Preis 200 DM/Preis
/Artikel
/Bestellung
Abbildung 2-9 Einfaches XML-Dokument
Erfüllt ein Dokument diese Syntaxregeln der XML, wird es, wie das angeführte
Beispiel, als ´wohlgeformt´ (´wellformed´) bezeichnet. Die Prüfung auf
Wohlgeformtheit übernimmt ein ´nicht validierender Parser´. Näheres dazu später in
Kapitel 2.1.2.3.3 - Programmierschnittstellen und Parser.
Die ´Wohlgeformtheit´ gibt an, ob ein Dokument den Syntaxregeln entspricht, nicht
aber, ob die logische Struktur eines Dokumentes stimmt, d.h. ob es die richtigen
Elemente in der richtigen Reihenfolge enthält, ob die Anzahl der Elemente stimmt, ob
keine Elemente fehlen, usw. Hierzu wird die Semantik, d.h. Grammatik und das
Vokabular der Sprache, in Form einer DTD (Document Type Definition) festgelegt.
Stimmt ein Dokument mit dieser vorgegebenen Grammatik überein, wird es als
´gültig´ (´valid´) bezeichnet. Die Prüfung auf Gültigkeit übernimmt ein ´validierender
Parser´. Ein gültiges Dokument ist gleichzeitig immer auch wohlgeformt.
34
2 Architekturen, Technologien und Paradigmen
2.1.2.3.2 DTD (Document Type Definition)
Die DTD beschreibt mit Hilfe der erweiterten Backus-Naur Form (EBNF) die
Grammatik und das Vokabular einer XML-Sprache, d.h. sie ist ein Konstrukt, in dem
sämtliche Element-Deklarationen, Attribut-Deklarationen, Notations-Deklarationen,
Kardinalitäten, usw. zusammengefasst werden. Sie kann somit als Schablone auf
ein XML-Dokument angewendet werden oder, um das Ganze objektorientiert
auszudrücken, die DTD ist die Klasse und das XML-Dokument eine konkrete Instanz
dieser Klasse. Eine solche DTD kann zum Beispiel zur Festlegung einer Corporate
Identity für alle geschäftlichen Dokumente dienen. Mit der passenden Software
(siehe Kapitel 2.1.2.3.3 - Programmierschnittstellen und Parser) können diese
Dokumente ohne Probleme verarbeitet, gespeichert, publiziert und weltweit
ausgetauscht werden. Eine DTD, welche das angeführte Beispiel in ein gültiges
Dokument ´verwandeln´ würde und die entsprechende Markup Sprache definiert,
könnte wie in Abbildung 2-10 Einfache DTD aussehen. In dieser DTD werden für
konkrete Instanzen folgende Vorgaben gemacht:
Das Element ´Bestellung´ besteht aus folgenden Elementen, die in dieser
Reihenfolge aufgeführt werden müssen: ´Datum´, ´Kunde´ und eine nichtleere
Menge von Artikeln.
Das Element ´Datum´ besteht aus einfachem Text.
Das Element ´Kunde´ besteht aus Name und optionaler E-Mail-Adresse, welche
Textelemente sind.
Das Element ´Artikel´ besteht aus einer Beschreibung, einer Menge und einem
Preis, welche jeweils Textelemente sind.
Jeder Artikel hat zwingend ein Attribut ´Artikelnummer´.
?xml version=1.0 encoding=UTF-8 ?
!ELEMENT Bestellung
(Datum, Kunde, Artikel+)
!ELEMENT Datum
(#PCDATA)
!ELEMENT
Kunde
(Name,
EMail?)
!ELEMENT
Name
(#PCDATA)
!ELEMENT EMail
(#PCDATA)
!ELEMENT Artikel
(Beschreibung, Menge, Preis)
!ATTLIST Artikel
Artikelnr ID #REQUIRED
!ELEMENT Beschreibung
(#PCDATA)
!ELEMENT Menge
(#PCDATA)
!ELEMENT Preis
(#PCDATA)
Abbildung 2-10 Einfache DTD
2 Architekturen, Technologien und Paradigmen
35
2.1.2.3.3 Programmierschnittstellen und Parser
XML Parser sind Bestandteile von Anwendungsprogrammen, welche XML-
Dokumente verarbeiten. Das heißt, XML Parser analysieren Dokumente und stellen
der Anwendung die benötigten Informationen über diese zur Verfügung. Mittels
einheitlicher, plattform- und sprachunabhängiger APIs kann der Parser auf die
Dokumente und die darin enthaltenen Daten zugreifen. Hierbei existieren zwei
grundlegende Schnittstellen: Die objektmodell-orientierte DOM-Schnittstelle und die
ereignisorientierte SAX-Schnittstelle. Zur Verdeutlichung dient das folgende
Schaubild:
Abbildung 2-11 Programmierschnittstellen und Parser
Die DOM-Schnittstelle, auch als ´baumorientierte Schnittstelle´ bezeichnet, erlaubt,
wie auch SAX, den standardisierten Zugriff auf beliebige HTML- und XML-
Dokumente. Sie bietet Methoden zum Lesen und zur Manipulation der Baumstruktur
eines Dokumentes. Ein DOM-Parser verarbeitet (parst) zunächst das gesamte
Dokument und erstellt intern einen ´Elementebaum´, der auch als ´Syntaxbaum´ oder
´DOM-Baum´ bezeichnet wird und als Repräsentant des Dokumentes fungiert. Die an
den Parser gekoppelte Anwendung kann nun über einheitliche Schnittstellen diesen
Baum durchwandern und manipulieren, indem sie ihren Zugriff auf einzelne Knoten,
sowie deren Vorgänger und Nachfolger, geschickt nutzt. Das allgemeine Vorgehen
bei der Nutzung der DOM-Schnittstelle ist also die Objektmanipulation auf folgende
Art und Weise:
Gesamtanwendung
Parser-
Schnittstelle
P
A
R
S
E
R
ANWENDUNG
SAX
DOM
XML-
Dokument
36
2 Architekturen, Technologien und Paradigmen
1. Parser instanziieren
2. XML-Dokument vollständig lesen und dabei DOM-Baum aufbauen
3. Resultat-Baum durchwandern, durchsuchen und die Informationen manipulieren
Der Vorteil gegenüber der ereignisorientierten SAX-Schnittstelle liegt in der
Möglichkeit der Navigation und Manipulation des Baumes, d.h. es ist hier möglich die
Baumstruktur vorwärts und rückwärts zu durchwandern. Der große Nachteil dieser
Methode besteht darin, dass das gesamte Dokument geparst werden muss, bevor
auf dessen Inhalt zugegriffen werden kann und dieser Vorgang bei großen
Dokumenten und somit großen Resultat-Bäumen sehr speicherintensiv ist
1
. Um
dieses Problem zu lösen, wurde in der XML-Gemeinde die SAX-Schnittstelle
vorgeschlagen und unter dem Motto "Don´t call the DOM, the parser calls you!"
standardisiert.
Der DOM-Baum des Beispieles im Kapitel 2.1.2.3.1 Wohlgeformte und gültige
XML-Dokumente stellt sich folgendermaßen dar:
Abbildung 2-12 DOM-Baum
Die SAX-Schnittstelle, auch als ´ereignisorientierte Schnittstelle´ bezeichnet, erlaubt,
wie auch DOM, den standardisierten Zugriff auf beliebige XML-Dokumente, wobei
jedoch nicht der DOM-Baum aufgebaut und anschließend bearbeitet wird. Ein SAX-
Parser liest das XML-Dokument sequentiell und ruft bei Ereignissen, wie zum
Beispiel ´Dokumentenanfang´ oder ´End-Tag´ entsprechende Methoden (Event-
Handler-Methoden) auf, deren Rümpfe der Anwendungsprogrammierer seinen
Bedürfnissen entsprechend gestalten kann. Das allgemeine Vorgehen bei der
1
Dieses Problem tritt insbesondere beim Einsatz von XML in Zusammenhang mit Streaming-Technologien auf.
Bestellung
Datum
Kunde
Artikel
Name
Email
Beschreibung
Menge
Preis
2 Architekturen, Technologien und Paradigmen
37
Nutzung der SAX-Schnittstelle ist also die Ereignisbehandlung auf folgende Art und
Weise:
1. Parser instanziieren
2. Event-Handler instanziieren
3. Event-Handler beim Parser registrieren
4. Dokument sequentiell einlesen
5. bei jedem Ereignis den entsprechenden Event-Handler informieren
Der Vorteil gegenüber der baumorientierten DOM-Schnittstelle liegt in der vielfach
höheren Verarbeitungsgeschwindigkeit der SAX-Parser, da kein vollständiger DOM-
Baum aufgebaut werden muss und die an den Parser gekoppelte Anwendung die für
sie unwichtige Teile des Dokumentes ignorieren kann. Weiterhin besteht hierdurch
die Möglichkeit sehr große Dokumente und Streams zu verarbeiten. Allerdings ist die
SAX-Schnittstelle aufgrund der fehlenden Möglichkeit der Baum-Manipulation nicht
für jeden Anwendungsfall geeignet.
2.1.2.3.4 XML Dokumente oder Daten?
Eine konkrete XML-Instanz, welche meist als XML-Dokument bezeichnet wird, fällt
immer in eine der beiden Kategorien:
XML-Dokument (im engeren Sinne)
XML-Daten
XML unterscheidet nicht, ob eine Instanz ein Dokument oder Daten enthält, bei der
Benutzung bestimmter Werkzeuge zur Bearbeitung von XML-Instanzen ist diese
Unterscheidung jedoch wichtig. Meist kann die Kategorie durch bloßes Betrachten
bestimmt werden:
Typische XML-Dokumente werden primär vom Menschen geschrieben und gelesen.
Hierzu zählen zum Beispiel Bücher, Zeitschriften, Webseiten usw. Solche
Dokumente enthalten hauptsächlich Fließtext, einige Überschriften, Tabellen oder
Bilder. Das heißt der Inhalt dieser Elemente wird als reiner Text interpretiert.
Typische XML-Daten sind Rechnungen, Bestellungen, Kataloge, Preislisten und
andere strukturierte Informationen, die primär für die maschinelle Verarbeitung und
den Datenaustausch gedacht sind. Solche Dokumente enthalten oft
´hochstrukturierte´ Daten, die bestimmte Integritätsbedingungen erfüllen und typisiert
sein müssen. (siehe dazu Kapitel 2.1.2.3.6 XML Schema).
38
2 Architekturen, Technologien und Paradigmen
2.1.2.3.5 XML Namensräume
Innerhalb eines XML-Dokumentes muss jeder Element- und Attributname eine
eindeutige Bedeutung besitzen, ansonsten ist das Dokument nicht gültig. Da man
aber sprechende Namen für Elemente und Attribute verwenden sollte, kann dies bei
komplexeren Systemen oft zu Mehrdeutigkeiten und somit zu Namenskollisionen
führen. So kann zum Beispiel ein Tag Titel sowohl für die Anrede als auch für den
Titel einer Veröffentlichung stehen. Zur Auflösung dieser Mehrdeutigkeiten von
Metainformationen, die durch die rasant steigende Anzahl von DTDs und XML
Schemata unausweichlich wird, dienen XML Namespaces.
Dazu qualifiziert man die mehrdeutigen Namen durch Bindung an URIs. Ein
Namensraum ist eine eindeutig identifizierte Sammlung von Namen für Elemente und
Attribute, qualifiziert durch einen URI. Ein Beispiel soll dies verdeutlichen:
?xml version=1.0 encoding=UTF-8 ?
bestellung xmlns:sender="http://www.sender.com"
xmlns:empfänger="http://www.empfänger.de"
sender:artikel
artikelnr="S0019"
beschreibungAMD
Athlon
1100/256/30,5 System/beschreibung
menge7/menge
preis2100
DM/preis
/sender:artikel
empfänger:artikel
beschreibung AMD Athlon 1100/256/30,5 System/beschreibung
menge7/menge
währungDM/währung
preis2100/preis
/empfänger:artikel
/bestellung
Abbildung 2-13 Einfaches Namensraum-Beispiel
Hierbei werden innerhalb des Elementes bestellung zwei Namensräume in der
Form elementname xmlns:namensraumprefix = "uri" deklariert. Die Verwendung
eines Elementes geschieht durch Voranstellen des entsprechenden Präfix und die
Trennung durch einen Doppelpunkt. So ist es, wie in diesem Beispiel beim Element
artikel, möglich, zwei Elemente bzw. Attribute gleichen Namens in
unterschiedlichen Kontexten zu benutzen.
2 Architekturen, Technologien und Paradigmen
39
2.1.2.3.6 XML Schema
Das Konzept der DTD stammt aus der dokumentenorientierten Welt der SGML. XML
wird aber nicht nur zur Dokumentenverwaltung, sondern auch für den
Datenaustausch benutzt (siehe Kapitel 2.1.2.3.4 XML - Dokumente oder Daten?).
In DTDs können dagegen nur Textelemente definiert werden, was für den
Datenaustausch nicht ausreichend ist. XML Schema erweitert die Funktionalität der
DTDs abwärtskompatibel und unterstützt viele gängige Datentypen wie String, Real,
Boolean, Date, Language, sowie selbstdefinierte Typen, Vererbungsmechanismen,
Integritätsbedingungen, Listen, Referenzen usw. Ein weiterer Vorteil der XML
Schema Sprache besteht darin, dass sie selbst in XML formuliert ist und somit im
Gegensatz zur DTD keinen speziellen Parser benötigt. Die Nachteile von XML
Schema gegenüber der DTD sind die mittlerweile sehr große Verbreitung und
Kenntnis von DTDs, die Vielzahl von Werkzeugen und bereits auf Basis von DTDs
definierten Sprachen. Bei Benutzung von XML Schema wird ein Dokument nicht
mehr auf Gültigkeit (siehe Kapitel 2.1.2.3.1 Wohlgeformte und gültige XML-
Dokumente) sondern auf ´Schema-Konformität´ geprüft. Weiterhin existieren im
Gegensatz zu DTDs drei Ebenen der Definition:
Typ-Definition (erfolgt im Schema)
Element- und Attribut-Deklarationen, die diese Typen verwenden (erfolgt
ebenfalls im Schema)
Element-Definitionen, d.h. Element-Instanzen (erfolgt im Dokument)
Das folgende kurze Beispiel soll die Funktionsweise von XML Schema verdeutlichen.
Zuerst wird im Schema ein neuer Typ namens nameT definiert, der sich aus zwei
Strings und einem optionalen Datum zusammensetzt. Im zweiten Schritt werden zwei
Elemente auf Basis dieses Types deklariert, die im dritten Schritt im Dokument
instanziiert werden.
xsd:schema xmlns=http://www.w3.org/2000/08/XMLSchema
!-- Den Typ ´NameT´ definieren --
xsd:complexType name="nameT"
xsd:sequence
xsd:element
name="vorname" type="xds:string"/
xsd:element
name="nachname" type="xds:string"/
/xds:sequence
xsd:attribute name="geburtsdatum" type="xsd:date" use="optional"/
/xsd:complexTyp
40
2 Architekturen, Technologien und Paradigmen
!-- Den neuen Typ in zwei Elementdeklarationen verwenden --
xsd:element name="name" type="nameT"/
xsd:element name="autor " type="nameT"/
/xsd:schema
Abbildung 2-14 Einfaches XML Schema
!-- Elemente vom Typ nameT --
name geburtsdatum="1955-02-02"
vorname Roland /vorname
nachname Zack /nachname
/name
autor
vorname Eva /vorname
nachname Eisen /nachname
/autor
Abbildung 2-15 Benutzung der im Schema deklarierten Elemente
2.1.2.3.7 XSL Transformation und Darstellung
In Kapitel 2.1.2.1 Warum XML? wurde der Vorteil der strikten Trennung zwischen
dem Inhalt und dessen Präsentation hervorgehoben und gezeigt, dass ein XML-
Dokument keinerlei Informationen über die Präsentation der transportierten Daten
beinhaltet. Hierzu dient die selbst in XML definierte Sprache XSL (Extensible
Stylesheet Language), welche als entkoppelte Präsentationsebene fungiert.
XSL ermöglicht es, ein XML-Dokument auf verschiedenen Medien darzustellen, oder
um es anders auszudrücken, durch XSL werden verschiedene Sichten auf ein XML-
Dokument ermöglicht (´Views-Konzept´). So kann zum Beispiel ein XML-Dokument,
welches aktuelle Börsennachrichten enthält, im Internet als HTML-Dokument
publiziert werden, als PDF zur Druckausgabe zur Verfügung gestellt werden, an ein
WAP-Handy in Form eines WML-Dokumentes geschickt werden, in Sprachausgabe
umgewandelt werden oder im reinen Textformat als E-Mail oder SMS versendet
werden. Weitere Anwendungen sind das automatische Generieren einer Antwort aus
einer Anfrage im Online-Shopping Bereich, die Transformation von XML-
Dokumenten in EDI-Nachrichten
1
, die Darstellung eines Dokumentes in
1
EDI steht für ´Electronic Data Interchange´ und es handelt sich hierbei um ein weit verbreitetes Datenaustauschformat für
Geschäftsnachrichten.
2 Architekturen, Technologien und Paradigmen
41
unterschiedlichen Anwendungskontexten (extern, intern, Management, Mitarbeiter),
die Vereinheitlichung von Dokumenten, das Filtern von Informationen usw. XSL
besteht aus zwei Sprachen: aus der Transformationssprache XSLT (Extensible
Stylesheet Language Transformations) und der Formatierungssprache XSL FO
(Extensible Stylesheet Language Formatting Objects).
XSLT ist eine deklarative Sprache, mit der beschrieben wird, wie ein XML-konformes
Dokument in ein anderes, meist auch XML-konformes Dokument, umgewandelt
werden soll. Die Umsetzung kann das alte Vokabular übernehmen, aber auch
verändern oder vollständig ersetzen. Die bekanntesten Anwendungen sind die
Überführung von semantischen XML-Dokumenten in Anzeigestruktur-Dokumente wie
HTML, um diese grafisch aufbereitet in einem Browser zu präsentieren, sowie das
Konvertieren von XML-Dokumenten zwischen verschiedenen Vokabularen, also zum
Beispiel zwischen dem internen Format der Firma A und dem der Firma B. Eine
beispielhafte Anwendung wäre des automatische Generieren eines
´Inhaltsverzeichnis-XML-Dokumentes´ aus den Kapitelüberschriften eines sehr
großem XML-Dokumentes.
Die Transformation eines XML-konformen Dokumentes in ein anderes XML-
konformes Dokument geschieht nach folgendem Prinzip: Ein XSLT-Prozessor liest
das Quell-Dokument sequentiell ein und vergleicht in jedem Knoten, ob dieser einem
in der Stylesheet-Datei angegebenen, Muster entspricht. Trifft dies zu, wird die
entsprechende, auch im Stylesheet angegebene Aktion ausgeführt. Ansonsten wird
das Element kopiert.
Abbildung 2-16 Prinzip der XSLT
XSL Stylesheet (.xsl)
Muster und
Aktionen
XML-konformes Dokument
Quell-Baum
XML-konformes Dokument
Ziel-Baum
XSLT
Prozessor
42
2 Architekturen, Technologien und Paradigmen
Eine XSL Stylesheet-Datei besteht aus einem Satz von Regeln, welche festlegen,
wie das Quelldokument, d.h. der Quellbaum, in das Zieldokument, also den
Zielbaum, konvertiert werden soll. Eine solche Konstruktionsregel gliedert sich in
folgende Teile:
Muster (pattern)
Das Muster gibt an, auf welche Bezeichner innerhalb des XML-Dokumentes sich
die darauf folgende Aktion beziehen soll, das heißt, findet der Parser das
angegebene Muster, wird die entsprechende Aktion ausgeführt.
Aktion (action)
Wurde das angegebene Muster erkannt, wird die darauf folgende Aktion
ausgeführt. Diese Aktion kann aus der entsprechenden Umwandlung des
betroffenen Elementes in die deklarierte Ausgabeform, d.h. das
korrespondierende Element des Zielbaumes (Template, Schablone), oder aus
einer dynamischen Anweisungen, zum Beispiel der Aktivierung eines Skriptes,
bestehen.
XSL FO ist eine Sprache, mit der beschrieben wird, wie ein Formatierer Inhalte auf
dem Ausgabemedium platzieren soll. Dies bedeutet, hier wird ein XML-konformes
Dokument in ein nicht XML-konformes Dokument, wie zum Beispiel ein Format für
Printmedien wie PDF, umgewandelt. Es können hierbei verschiedene Einstellungen
zu den Rändern, Füll-, Hintergrund- und Schrifteigenschaften usw. eingestellt
werden. XSL FO zielt nicht auf die Fähigkeiten eines Programmierers, sondern die
eines Designers oder Layouters ab
1
.
Die Transformation eines XML-konformen Dokumentes in ein nicht XML-konformes
Dokument für Printmedien geschieht nach folgendem Prinzip: Das Quelldokument
wird hierzu zuerst per XSLT in einen FO-Baum umgewandelt und dieser dann mit
einem FO-Prozessor in das nicht XML-konforme Formate übersetzt (PDF, RTF,
Excel, Powerpoint usw.).
1
Mittlerweile existieren eine Reihe von Werkzeugen, welche es erlauben das gewünschte Design zu gestalten und
anschließend die XSL und XSL FO Dokumente automatisch zu erzeugen.
2 Architekturen, Technologien und Paradigmen
43
Abbildung 2-17 Prinzip der XSL FO
XSL Stylesheet (.xsl)
Muster und
Aktionen
XML-konformes Dokument
Quell-Baum
XML-konformes Dokument
FO-Baum
Format für Printmedien
z.B. PDF
XSLT
Prozessor
FO
Prozessor
44
2 Architekturen, Technologien und Paradigmen
2.1.3 SOAP (Simple Object Access Protocol)
Wie bereits in Kapitel 2.1.1.6 - Web Services Standards angeführt, dient das Simple
Object Access Protocol (SOAP) als XML-basiertes Messaging-Protokoll. Es handelt
sich um ein leichtgewichtiges, interoperables Protokoll zum Informationsaustausch in
einer dezentralisierten, verteilten Umgebung, welches sowohl RPCs als auch
asynchrones Messaging ermöglicht.
SOAP ist im Gegensatz zu IIOP
1
, DCOM
2
oder RMI
3
kein verteiltes
Komponentenmodell. Es muss nicht zwingend in Verbindung mit verteilten Objekten
und Methodenaufrufen benutzt werden. Weiterhin besitzt es keinerlei Ansätze in den
Bereichen Object Discovery, Distributed Garbage Collection, Authentifizierung und
Verschlüsselung. Oberste Ziele dieses Protokolls sind Interoperabilität, Einfachheit
und Erweiterbarkeit. Die genannten Punkte können durch entsprechende
Erweiterungen auf SOAP aufgesetzt werden: UDDI dient dem Object Discovery, zur
Verschlüsselung kann HTTPS verwendet werden und Authentifizierungs-
informationen können über den Header mitgeschickt werden. SOAP ist vom
zugrunde liegenden Kommunikationsprotokoll unabhängig, weshalb der Austausch
der XML Daten über beliebige Transportprotokolle erfolgen kann. Für RPCs sind im
Internet-Bereich meist HTTP/HTTPS und für die asynchrone Kommunikation SMTP
vorgesehen. Die SOAP-Spezifikation besteht aus folgenden Teilen:
SOAP Envelope
Dieser Teil definiert ein Framework für die Beschreibung des Inhaltes einer
SOAP-Nachricht, wer diese verarbeiten soll, wie dies geschehen soll und ob die
Verarbeitung obligatorisch oder optional ist.
SOAP Encoding Rules
Die SOAP-Kodierungsregeln dienen der Beschreibung anwendungsspezifischer
Datentypen und ermöglichen damit, Objektinstanzen zu serialisieren und
auszutauschen.
1
IIOP (Internet Inter ORB Protocol) ist das CORBA-Protokoll für die Kommunikation im Internet.
2
Die Distributed Components (DCOM) Architektur ist das verteilte Komponentenmodell der Microsoft-Plattform.
3
RMI (Remote Method Invocation) ist das verteilte Komponentenmodell der Java-Plattform.
Ende der Leseprobe aus 305 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2002, Management- und Web Services-Architekturen, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/220847
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare