DPArchiv.0136
Werbung
Diplomarbeit
Ein generisches Framework zur grafischen
Anbindung von Web-Services
Steffen Apfel
Dezember 2004
Betreuer: Prof. Dr. Paul Müller
Dipl. Inform. Markus Hillenbrand
Fachbereich Informatik
AG Integrierte Kommunikationssysteme
Universität Kaiserslautern Postfach 3049 67653 Kaiserslautern
Ich versichere, dass ich die vorliegende Diplomarbeit selbstständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel verwendet habe.
Kaiserslautern, den 28.12.2004
(Steffen Apfel)
Abstract
Web-Services interagieren miteinander, um in Service-orientierten, verteilten Umgebungen gemeinschaftlich Aufgaben zu bearbeiten. Web-Services
bauen auf vorhandenen XML-basierten Technologien wie u. a. WSDL,
SOAP und UDDI auf und verwenden diese, um unabhängig von verwendeter
Plattform, Programmiersprache und Transport-Protokoll miteinander zu
kommunizieren. Die Web Service Description Language (WSDL) beschreibt
die Schnittstelle eines Web-Service und spielt somit eine herausragende Rolle in der Web-Service-Architektur. WSDL kann automatisch maschinell zur
Ansprache des transparent dahinter liegenden Web-Service verwendet werden. In dieser Diplomarbeit wird untersucht werden, inwieweit aus WSDL
generisch eine grafische Oberfläche (GUI) zur Ansprache von Web-Services
erzeugt werden kann. Ausgangsdokument ist lediglich das WSDL-Dokument,
aus dem alle relevanten Informationen zum GUI-Aufbau extrahiert werden.
Neben einer Analyse von WSDL werden ein Modell und ein Prototyp entwickelt, die die Möglichkeiten und Grenzen der GUI-Generierung aus WSDL
herausstellen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Inhaltsverzeichnis
Kapitel 1:
Einleitung ............................................................................................................ 9
1.1
Motivation .............................................................................................................. 10
1.2
Ziele ........................................................................................................................ 12
1.3
Struktur ................................................................................................................... 13
Kapitel 2:
Technologien ..................................................................................................... 15
2.1
Web-Services ......................................................................................................... 15
2.1.1
Service-orientierte Architektur ...........................................................................................18
2.2
Grundlagentechnologie: XML ............................................................................... 19
2.3
Datenschema: XSD ................................................................................................ 20
2.4
Web Service Description Language 1.1 (WSDL) .................................................. 21
2.4.1
Aufbau eines WSDL-Dokumentes .....................................................................................22
2.4.2
Modularisierung durch Importieren ...................................................................................32
2.4.3
Vergleich WSDL 1.1 und WSDL 2.0.................................................................................34
2.5
Universal Description, Discovery and Integration (UDDI) ................................... 37
2.6
SOAP...................................................................................................................... 39
2.7
Zusätzliche Technologien ...................................................................................... 41
2.8
Zusammenfassung .................................................................................................. 42
Kapitel 3:
Einordnung der Arbeit..................................................................................... 44
3.1
Apache Axis und WSDL2Java............................................................................... 44
3.1.1
Vergleich von WSDL2Java mit wscompile von Sun Microsystems ..................................50
3.2
Binding des Clients ................................................................................................ 53
3.3
Related Work: WSRP von OASIS ......................................................................... 57
3.4
Zusammenfassung .................................................................................................. 60
Kapitel 4:
Modellbildung ................................................................................................... 61
4.1
Beschreibung des Frameworks............................................................................... 61
4.1.1
Anwendungsfälle................................................................................................................62
4.1.2
Grafische Komponenten .....................................................................................................65
4.2
Anforderungskatalog .............................................................................................. 67
4.3
Aufbau der GUI ...................................................................................................... 71
4.3.1
WSDL-Komponenten.........................................................................................................73
4.3.2
Datentypen in XSD ............................................................................................................74
7
Inhaltsverzeichnis
4.4
Einbettung semantischer Informationen ................................................................ 90
4.5
Zusammenfassung ................................................................................................. 93
Kapitel 5:
Realisierung ...................................................................................................... 95
5.1
Architektur des Frameworks.................................................................................. 96
5.2
Aufbau der grafischen Komponenten .................................................................... 99
5.3
Anordnung der grafischen Komponenten ............................................................ 101
5.4
Realisierung des Bindings ................................................................................... 103
5.5
Zusammenfassung ............................................................................................... 104
Kapitel 6:
Implementierung ............................................................................................ 105
6.1
Gestaltung der grafischen Oberfläche ................................................................. 105
6.2
Abbildung der Datentypen auf Java .................................................................... 109
6.3
Anzeigen von Dokumentationen ......................................................................... 117
6.4
Zusätzliche Implementierungsaspekte ................................................................. 122
Kapitel 7:
Zusammenfassung und Ausblick .................................................................. 127
Kapitel 8:
Anhang ............................................................................................................ 129
8.1
Vordefinierte, primitive Datentypen und ihre Fassetten...................................... 129
8.2
Abgeleitete Datentypen und ihre Fassetten ......................................................... 130
8.3
Übersicht: XSD-Datentypen, Java-Datentypen und Swing-Komponenten ......... 131
8.4
Modulares WSDL-Dokument durch Importieren ................................................ 133
8.5
Java-Klasse des XSD-Datentyps float ................................................................. 140
Literaturverzeichnis............................................................................................................. 144
Abbildungsverzeichnis ......................................................................................................... 149
Glossar
.......................................................................................................................... 151
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
9
Kapitel 1: Einleitung
Web-Services haben heutzutage eine fundamentale Bedeutung in der Verwendung des Internets, der
Weiterentwicklung verteilter Systeme und bei der Softwareentwicklung eingenommen. Vor einigen
Jahren waren die Softwarehersteller stets bemüht, Programme mit größtmöglicher Funktionalität zu
entwickeln. Web-Services bieten nun eine völlig neue Perspektive der Programmentwicklung. Innerhalb eines Web-Service kann modular eine überschaubare Funktionalität implementiert werden. WebServices können zur Bewältigung komplexer Aufgaben orchestriert werden, diese gemeinsam erledigen, und danach in neuer Konstellation weitere Aufgaben erfüllen. Durch diese lose Kopplung je nach
Problemstellung, bieten Web-Services ein mächtiges Konstrukt zum problemorientierten Bearbeiten
von Aufgaben.
Web-Services stellen primär keine neuartigen Dienste zur Verfügung, sondern stellen vielmehr Technologien zur unabhängigen Orchestrierung vorhandener Dienste bereit. Somit können bisher isoliert
arbeitende Dienste zur Lösung vorhandener Probleme in einem größeren Wirkungsumfeld zusammengestellt werden. Bislang bestand das Hauptproblem beim Zusammenfügen von verteilten Diensten
über Netzwerkgrenzen hinweg in der Inkompatibilität. In den 90iger Jahren fand eine Ausbreitung der
Local Area Networks (LAN) statt. Anwendungen konnten nun über Rechnergrenzen hinweg miteinander kommunizieren und Aufgaben bearbeiten. Durch die Vernetzung der Computer gewannen
verteilte Anwendungen immer mehr an Bedeutung. Microsoft entwickelte aus dem Component Object
Modell (COM) das Distributed COM (DCOM). Bei COM wird die Funktionalität der verwendeten
Objekte über Schnittstellenbeschreibungen definiert. Innerhalb einer DCOM-Architektur können Objekte auf Windows-Plattformen verteilt vorliegen und angesprochen werden [CHY+97]. Parallel dazu
entwickelte die Object Management Group (OMG) die Common Object Request Broker Architecture
(CORBA). CORBA-Programme können unabhängig von Plattform und Programmiersprache miteinander kommunizieren und Objekte austauschen, wobei beide Teilnehmer eine CORBAImplementierung und Bibliotheken benötigen [OMG04]. Zusätzlich brachte Sun Microsystems Remote Method Invocation (RMI) heraus. RMI ist eine Java-API zur Kommunikation zwischen entfernten,
verteilten Java-Objekten in heterogenen Systemen [RMI03].
Allerdings wiesen diese drei Innovationen eine große Schwäche auf: Sie waren nicht miteinander
kompatibel. Beim Ansatz von DCOM ist man auf die Windows-Plattform beschränkt. Bei RMI von
Sun Microsystems besteht die Abhängigkeit zur Programmiersprache Java und bei CORBA von OMG
war man auf der anderen Seite auf die zugrunde liegende Netzwerk-Technologie und Middleware
beschränkt, die bei allen Kommunikationsteilnehmern vorhanden sein musste. Somit ist bei diesen drei
Lösungen kein Einsatz in einer heterogenen Systemlandschaft gegeben. Web-Services überwinden
diese drei Schwächen der Programmiersprachen-, Plattform- und Technologie-Abhängigkeit. Bei
Web-Services basieren sämtliche verwendete Technologien auf der Extensible Markup Language
10
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
(XML) [BPS+04]. XML wird von jeder Plattform und Sprache unterstützt und schafft somit Interoperabilität. In XML können sämtliche Übertragungsdaten serialisiert werden. Diese werden dann über
ein vorhandenes Transport-Protokoll gesendet, hauptsächlich HTTP. Der Empfänger kann die empfangenen Daten in ein für sein Programm verständliches Format deserialisieren. Dadurch können
unterschiedliche Programme miteinander kommunizieren und Tätigkeiten zusammen ausführen.
Selbst Legacy-Systeme, die wegen der Inkompatibilität mit neueren Standards oft nicht mehr zur
Verwendung kamen, können nun in bestehende Systeme integriert werden. Jeder Service arbeitet völlig transparent mit seinen jeweiligen Partnern zusammen. Lediglich die Schnittstelle des Service wird
veröffentlicht, um Informationen über Datenformate, Bindungsinformationen und verwendete Nachrichten zu publizieren. Von der dahinter liegenden Service-Realisierung wird abstrahiert.
In diesem einleitenden Kapitel soll zunächst die Motivation zur Erstellung dieser Diplomarbeit angeführt werden. Im nächsten Unterkapitel wird das Ziel der Arbeit festgesetzt und dessen Erreichung
beschrieben. Abschließend werden die nachfolgenden Kapitel dieser Publikation vorgestellt.
1.1 Motivation
In dem Buch „XML, Web Services, and the Data Revolution“ bezeichnet der Autor F. Coyle WebServices als ein Phänomen [Coy02]. Einerseits hat der Autor sicherlich Recht, dass Web-Services die
Benutzung des Internets erweitern und durch die neuartige Benutzung des Internets als ein Phänomen
betrachtet werden können. Allerdings ist meiner Meinung nach der Begriff „Phänomen“ falsch verwendet. Web-Services stellen keine revolutionäre, neue Technologie dar, sondern Web-Services beruhen auf bewährten, etablierten Technologien. Diese führen sie in einer neuen Art der Verwendung
zusammen.
Web-Services schaffen durch ihre Interoperabilität einen wichtigen Schritt zur Integration verschiedener Plattformen wie Java, DCOM und CORBA und abstrahieren von Entwicklungsdetails. Da WebServices auf offenen, XML-basierten Standards aufsetzen, die von jeder Plattform unterstützt werden,
kann man sich einzig und allein auf die Funktionalität von Services konzentrieren. Beim Anbinden
eines Services ist lediglich dessen Funktionalität von Interesse und die verwendete Programmiersprache oder Entwicklungsplattform sind transparent. In dieser Eigenschaft liegt ein riesiges Potenzial für
die Weiterentwicklung und Verbreitung von Web-Services. Softwareentwickler sind nicht darauf angewiesen, sich beim Entwickeln eigener Software auf eine Programmiersprache oder Plattform mit
Kunden oder Geschäftspartnern zu einigen. Stattdessen können sie unabhängig von herrschenden
Standards eigene Programme entwickeln und durch Web-Services ihren Kunden zur Verfügung stellen. In der Verwendung und Weiterentwicklung von Web-Services liegt also ein großes Potenzial für
die weitere Entwicklung des Internets und die Softwareentwicklung. Zudem können durch WebServices kostspielige Standards wie z.B.: Electronic Document Interchange (EDI) im Business-toBusiness Bereich zur Bestell-, Dokument- und Rechnungsabwicklung umgangen oder gar ersetzt wer-
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
11
den [EDI04]. Web-Services bieten also ein großes Reservoir für zukünftige Softwareerstellung. Im
Bereich der verwendeten Technologien arbeiten seit geraumer Zeit große Unternehmen wie Microsoft
und IBM oder aber auch Standardisierungsunternehmen wie das von Tim Berners-Lee geleitete World
Wide Web Consortium (W3C) und der Organization for the Advancement of Structured Information
Standards (OASIS) zusammen und entwickeln ständig neue Versionen der bestehenden Technologien.
Web-Services sollen so aufgebaut werden, dass Systeme andere Web-Services selbstständig finden,
deren Funktionalität integrieren und zusammen anliegende Aufgaben erledigen. Der automatisierte
Datenaustausch ohne menschliche Interaktion und Hilfestellung zwischen Systemen steht dabei im
Vordergrund der Weiterentwicklungen.
Eine Fragestellung hat allerdings bisher kaum Beachtung bekommen:
Wie kann ein Anwender einen Web-Service benutzen?
Gibt es eine grafische Oberfläche zum Erstellen der Anfragen an einen Web-Service?
Werden einem Anwender Hilfestellungen zum Editieren der erforderlichen Parameter und Benutzung eines Dienstes gegeben?
Wie kann eine Oberfläche generisch und somit für alle existierenden Web-Services erzeugt
werden?
Reichen vorhandene Standards aus oder müssen diese erweitert, bzw. neue Standards entwickelt werden?
Nach einschlägiger Literatur- und Netzrecherche wurden nur wenige Ansatzpunkte zur Lösung dieses
Problems gefunden. OASIS entwickelt den Standard Web Service for Remote Portlets (WSRP). Durch
diesen Standard sollen Web-Service-Anbieter (Provider) zusätzlich zu ihrem Web-Service eine eigene
Graphical User Interface (GUI) mit parametrisierten Markup-Fragmenten erstellen. Die MarkupFragmente werden dann innerhalb eines Portals an das passende Endgerät angepasst und anschließend
eine GUI erzeugt. Diese Lösung ist zurzeit auf Portale beschränkt und ein weiterer Nachteil bei dieser
Lösung ist allerdings, dass ein Web-Service-Anbieter zusätzlich zu seinem Web-Service die MarkupFragmente entwickeln muss. Alte, bestehende Web-Services müssten um diese Markup-Fragmente
erweitert werden. Ein erheblicher Programmieraufwand würde entstehen, um alle bereits existierenden
Web-Services mit diesem neuen Standard konform zu halten. Daher sollte eine Lösung gefunden werden, die auf den bestehenden Standards aufbaut und diese zur Generierung einer GUI verwendet.
In der vorliegenden Diplomarbeit wird deshalb untersucht, inwieweit der bestehende Standard zur
Schnittstellenbeschreibung eines Web-Service, die Web Service Description Language (WSDL), als
Grundlage zur Erzeugung einer grafischen Oberfläche verwendet werden kann. Ein WSDL-Dokument
beschreibt die Schnittstelle des Web-Service, legt das Übertragungsprotokoll fest, spezifiziert alle
verfügbaren Operationen, definiert alle zu übertragenen Daten und definiert mit der XML Schema
Definition Language (XSD) sämtliche verwendete Datentypen [BM04b]. Somit sind alle relevanten
Informationen zum Erstellen einer Anfrage an den Web-Service in einem WSDL-Dokument integriert.
Aus diesem Grund sollte es möglich sein aus einem WSDL-Dokument generisch eine GUI zu erzeu-
12
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
gen, mit deren Hilfe ein Anwender alle Eingaben durchführen kann. Dies ist der zentrale Ansatzpunkt
dieser Diplomarbeit. Es wird untersucht, ob die Extraktion der Informationen des WSDL-Dokumentes
zur Erzeugung der GUI ausreichen. In diesem Falle wäre die Entwicklung eines neuen Standards, wie
z.B. WSRP, in Frage zu stellen. Vielmehr könnte man den Standard WSDL erweitern und vorhandene
Schwachstellen neu spezifizieren.
1.2 Ziele
Zur Erläuterung des Ziels dieser Diplomarbeit, soll zunächst der Titel der Arbeit näher betrachtet werden: „Ein generisches Framework zur grafischen Anbindung von Web-Services“.
Das Hauptziel der Diplomarbeit ist die Entwicklung eines Modells und Prototypen eines Frameworks
zum Ansprechen von Web-Services. Die grafische Oberfläche soll generisch erzeugt werden und für
sämtliche Web-Services eine einheitliche GUI erstellen. Diese GUI soll den Anwender intuitiv leiten
und Hilfestellung beim Benutzen von Web-Services bieten. Die Benutzung schließt zum einen die
Erstellung der Anfrage und zum anderen das Anzeigen der Antwort und evtl. übertragenener Anhänge
(Attachments) mit ein. Als Ausgangsdokument zur Generierung der GUI soll ausschließlich die
Schnittstellenbeschreibung eines Web-Service, das WSDL-Dokument, dienen. Das WSDL-Dokument
enthält vielfältige Informationen, die an dieser Stelle kurz angesprochen werden. WSDL liefert
Informationen zum Verbindungsaufbau, Netzwerkadresse, Name des Web-Service und sämtliche
Operationen, die ausgeführt werden können. Mit diesen Informationen kann die Verbindung zum
Web-Service aufgebaut werden. Des weiteren spezifiziert das WSDL-Dokument alle ausgetauschten
Daten und deren Formate, die als XML-Schema angegeben werden. Diese Daten können nun zur
Generierung einer Eingabemaske innerhalb der GUI verwendet werden. Für sämtliche Datentypen
wird eine spezifische Eingabekomponente generiert, aus denen sich die GUI je nach vorliegendem
WSDL-Dokument
sukzessive
aufbaut.
Zusätzlich
können
die
Datentypdefinitionen
zu
Vailidierungszwecken verwendet werden. Zur Erreichung dieses Ziels der Diplomarbeit, wird ein
Schwerpunkt auf die Analyse von WSDL-Dokumenten und darin enthaltene XSD-Datentypen gelegt.
In Kapitel zwei und drei werden zunächst die theoretischen Grundlagen aufbereitet. Kapitel vier
erklärt das entwickelte Modell zur Realisierung des Projektes und Kapitel fünf geht auf die
Realisierung des Frameworks ein. In Kapitel sechs werden einige Implementierungsaspekte bei der
Realisierung des Modells vorgestellt.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
13
1.3 Struktur
Zur Demonstration einiger Technologien, Verarbeitungsschritte und letztendlich Entwicklung der GUI
wurden zwei Anwendungsbeispiele ausgewählt. Im ersten theoretischen Teil der Ausarbeitung veranschaulicht ein Taschenrechner-Web-Service den Aufbau eines WSDL-Dokumentes. Dieser WebService bietet zwei Operationen an. Eine Addition addiert zwei Ganzzahlwerte -einfache Datentypenund liefert als Ergebnis die Summe beider Werte. Die Subtraktion nimmt einen komplexen Datentyp,
der aus zwei Gleitkommazahlen aufgebaut ist, entgegen und liefert die Differenz beider Werte. Anhand dieses überschaubaren Beispiels kann u. a. der Aufbau eines WSDL-Dokumentes illustriert, das
Anbinden des Clients, sowie auf die unterschiedliche Behandlung von komplexen und einfachen Datentypen eingegangen werden. Dieses einfach aufgebaute Demonstrationsbeispiel soll vor allem zum
Einstieg in die Beschreibungssprache WSDL dienen. Nachdem das theoretische Grundwissen von
WSDL erklärt wurde, soll im zweiten praktischen Teil ein weiterer, komplexerer Web-Service als
Anschauungsbeispiel dienen. Ein Bibliotheks-Web-Service bietet zum einen das Speichern neuer Bücher und Publikationen an und zum anderen das Suchen von Büchern oder Autoren. Durch dieses Beispiel soll der Aufbau der GUI erläutert werden, das Senden von Daten oder weitere komplexe Datentypen wie Felder und Aufzählungen beschrieben werden. Insbesondere bietet der entwickelte Prototyp
die Möglichkeit bereits verwendete Eingaben erneut zu laden und wiederum einzubinden.
Diese Diplomarbeit ist in die fünf Hauptkapitel Technologien, Einordnung der Arbeit, Modellbildung,
Realisierung und Implementierung untergliedert. Im zweiten Kapitel werden Web-Services definiert
und die wichtigsten Technologien vorgestellt. XML und die XML Schema Definition Language
(XSD) werden als Basistechnologien vorgestellt. Im Mittelpunkt dieses Kapitels steht die Betrachtung
der Web Service Description Language (WSDL), die als Ausgangspunkt zur Generierung der GUI
dient. Neben WSDL werden schließlich die beiden anderen wichtigen Technologien im Zusammenhang mit Web-Services erklärt: Universal Description, Discovery and Integration (UDDI) und SOAP.
Nachdem im zweiten Kapitel die theoretischen Grundlagen für diese Arbeit gelegt wurden, beschäftigt
sich Kapitel drei mit der Einordnung der Arbeit. Zunächst wird das Projekt Axis der Apache Foundation vorgestellt und dessen Architektur erläutert. Weiterhin wird das Werkzeug WSDL2Java von
Apache Axis vorgestellt. Mit Hilfe dieses Werkzeugs werden aus einem WSDL-Dokument JavaKlassen erzeugt, die zur weiteren Verwendung innerhalb des zu erstellenden Prototypen bereitgestellt
werden. Da Sun Microsystems auch ein Werkzeug zur Verfügung stellt, findet danach ein Vergleich
von WSDL2Java der Apache Foundation und wscompile von Sun Microsystems statt. Unter vorgegebenen Kriterien werden beide Werkzeuge getestet und abschließend bewertet. Nachkommend wird das
verwandte Thema WSRP von OASIS vorgestellt, dessen Vorgehensweise geschildert und mit den
Ergebnissen dieser Arbeit verglichen und abgegrenzt.
Kapitel vier zeigt das entwickelte Modell zur Realisierung dieser Arbeit. Zunächst wird die Architektur des Frameworks erläutert. In diesem Zusammenhang wird auf die Problematik der Komplexität des
WSDL-Dokumentes eingegangen. Anschließend werden die verwendeten XSD-Datentypen erklärt
14
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
und deren spätere grafische Präsentation festgelegt. Zusätzlich wird eine Möglichkeit zum Einbinden
von semantischen Informationen in der GUI modelliert.
In Kapitel fünf wird der praktische Teil der Arbeit vorgestellt. Zunächst wird die Architektur des Prototypen durch zwei statische UML-Diagramme beschrieben. Nachfolgend wird der Aufbau der grafischen Oberfläche aus den Informationen des WSDL- und XSD-Dokumentes vorgestellt. Anschließend
wird die Realisierung der Anbindung des Clients diskutiert, bevor ausführlich auf die Realisierung des
Frameworks Bezug genommen wird. In Kapitel sechs werden diverse Implementierungsaspekte näher
vorgestellt. Es werden die Abbildungsvorschriften der XSD-Datentypen auf Java aufgelistet und in
diesem Zusammenhang entstehende Namenskollisionen erläutert. Darüber wird gezeigt, wie durch
gezieltes Einbinden von Dokumentationen semantisch eindeutige Eingabemasken zur Anfrage an einen Web-Service generiert werden. Nach diesen fünf Hauptkapiteln folgt in Kapitel sieben eine Zusammenfassung der Diplomarbeit und Ausblick auf weitere Entwicklungen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
15
Kapitel 2: Technologien
In diesem Kapitel wird zunächst eine Definition für Web-Services angegeben und erklärt wie WebServices auf dem Prinzip der Service-orientierten Architekturen (SOA) beruhen. Danach werden die
wichtigsten Technologien im Zusammenhang mit Web-Services vorgestellt. Zuerst wird im Unterkapitel 2.2 die Rolle von XML im Bezug auf Web-Services und deren Technologien erläutert. XML
dient als Basis für die darauf aufbauenden anderen Technologien. Im Zusammenhang mit XML wird
anschließend die XML Schema Definition Language (XSD) vorgestellt, die zur Beschreibung der Datentypen innerhalb der anderen Technologien verwendet wird. XSD wird im vierten Kapitel nochmals
aufgegriffen, wenn die grafische Darstellung einzelner Datentypen diskutiert wird. Nach der Beschreibung dieser beiden Basistechnologien werden die drei Haupttechnologien von Web-Services erklärt.
Unterkapitel 2.4 beschreibt die WSDL ausführlich und erläutert den Modularisierungs-Mechanismus
des Importierens. Da WSDL in unterschiedlichen Versionen vorliegt, Werkzeuge zur automatischen
Codegenerierung allerdings nur mit der älteren kompatibel sind, wird ein Vergleich der Versionen
vorgenommen. WSDL stellt das Ausgangsdokument zur Erstellung der grafischen Oberfläche dar.
Dementsprechend wird der Schwerpunkt in diesem Kapitel auf WSDL gelegt. Unterkapitel 2.5 stellt
Universal Description, Discovery and Integration (UDDI) vor. Diese Technologie wird zum Beschreiben und Finden von Web-Services verwendet. Danach wird in Kapitel 2.6 SOAP, ein Protokoll zum
strukturierten Datenaustausch, vorgestellt. Kapitel 2.7 erwähnt weitere Technologien, die im Zusammenhang mit Web-Services eine Rolle spielen. Die abschließende Zusammenfassung wiederholt die
wichtigsten Aspekte dieses Kapitels.
2.1 Web-Services
Das World Wide Web Consortium (W3C) definiert allgemein einen Web-Service wie folgt:
„A Web service is a software system identified by a URI [RFC2396] 1, whose public interfaces and
bindings are defined and described using XML. Its definition can be discovered by other software
systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages by Internet protocols.” [ABFG04]
In dieser Definition wird herausgestellt, dass ein Web-Service auf dem Prinzip einer Serviceorientierten Architektur (SOA) basiert. Ein Web-Service kann demnach durch andere Softwaresysteme über eine URI gefunden werden und besitzt eine XML-basierte Schnittstellenbeschreibung. Andere
Systeme kommunizieren mit dem Web-Service in der Schnittstellenbeschreibung definierten Art. Diese Definition wird im nächsten Unterkapitel nochmals herangezogen, wenn ein Web-Service im Zu-
1
RFC: Request for Comments (öffentliches Diskussionsdokument, siehe Glossar)
16
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
sammenhang mit der SOA erklärt wird. In einer weiteren Definition des W3C wird bei der Beschreibung eines Web-Service näher auf die verwendeten Technologien eingegangen:
„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.” [BHM+04]
In dieser technischen Definition des W3C wird zum einen darauf hingewiesen, dass Web-Services in
automatisierbarer Weise Daten über ein Netzwerk senden. Eine menschliche Interaktion ist nicht
zwingend erforderlich und Softwaresysteme können eigenständig miteinander kommunizieren und die
Daten austauschen. Zum anderen werden zwei XML-basierte Standards erwähnt: WSDL zum Beschreiben der Schnittstellen eines Web-Service und SOAP als Nachrichtenformat zum Austausch der
Daten. Durch die Darstellung und Übertragung der Daten in XML ist ein Web-Service sowohl unabhängig vom Betriebssystem, der Programmiersprache sowie vom Transport-Protokoll. Eine XMLbasierte Datenübertragung über HTTP kann somit über Netzwerk- und Firewallgrenzen hinweg vonstatten gehen. Darin liegt u. a. der fundamentale Vorteil gegenüber beispielsweise CORBA (Transport-Protokoll-abhängig: ORB), RMI (Sprachen-abhängig: Java) und DCOM (Plattform-abhängig:
Windows). Die nachfolgende Abbildung 1 zeigt den Protokoll-Stack eines Web-Service und zeigt die
vier unterschiedlichen Schichten mit den jeweils eingesetzten Technologien.
Service-Discovery & Publishing
(UDDI)
Service-Beschreibung
(WSDL)
XML-Messaging
(SOAP, XML-RPC)
Transport
(HTTP,SMTP,FTP,BEEP)
Abbildung 1: Übersicht des Protokoll-Stacks eines Web-Service nach [Cer02]
Transport-Schicht:
Diese Schicht ist für den Transport der Nachrichten über ein Netzwerk verantwortlich. Der darüber
liegende Web-Service abstrahiert von dieser Schicht. Somit können in dieser Schicht unterschiedliche
Protokolle zum Einsatz kommen, wie z.B. das Hyper Text Transport Protokoll (HTTP) [RFC2616],
das Simple Mail Transport Protokoll (SMTP) [RFC821], das File Transfer Protokoll (FTP) [RFC959],
oder auch neuere Protokolle, wie das Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Die
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
17
Web-Service-Architektur beschreibt in den drei anderen, oberen Schichten die Funktionalität des
Web-Service und ordnet in dieser vierten Schicht ein Transport-Protokoll zu.
XML-Messaging-Schicht:
Diese Schicht kodiert (verpackt) die Nachrichten in ein gängiges XML-Format, welches von allen
Teilnehmern verstanden wird. Es findet eine Serialisierung der Daten in ein XML-basiertes Format
statt (in der Literatur auch oft Marshalling genannt bei XML Remote Procedure Call-Aufrufen). Die
Nachrichten können mit XML Remote Procedure Call (XML-RPC) und SOAP übertragen werden.
SOAP wird in Kapitel 2.7 vorgestellt und RPC im Rahmen des Projekts Axis in Kapitel 3.1.
Service-Beschreibung:
In dieser Schicht wird mit Hilfe von einer Beschreibungssprache der Web-Service und dessen Schnittstelle (Interface) beschrieben, somit kann von der darunter liegenden Implementierung abstrahiert
werden. Die Web Service Description Language (WSDL) bildet den De-facto-Standard zur Beschreibung von Web-Services. Die Autoren des Buches „Webservice-Programmierung mit SOAP“ [STK02]
benennen als weitere Beschreibungssprachen Ressource Description Framework (RDF) [BG04] und
DARPA Agent Markup Language (DAML) [HHP+01]. Allerdings ist das primäre Einsatzgebiet von
RDF der Austausch und das Verwenden von Metadaten im Internet und von DAML das Beschreiben
von Objekten und deren Relationen zueinander. Diese beiden Beschreibungssprachen sind daher eher
ergänzend als substituierend für WSDL anzusehen.
Service Discovery und Publishing:
Service-Anbieter (Provider) können mit Hilfe von UDDI ihren Service beschreiben und in einem öffentlichen Verzeichnis publizieren. Anwender benutzen dieses Verzeichnis, um vorhandene WebServices zu suchen und danach in ihre Verarbeitung und Systeme einzubinden. Im Zusammenhang mit
UDDI wird oft die Analogie zu den gelben Telefonbuchseiten gewählt, da beide eine ähnliche Suchfunktion bieten. WS-Inspection ist ein weiterer Mechanismus zum Finden von Web-Services
[BEG+03].
Einige Autoren listen auch manchmal fünf Schichten innerhalb des Protokoll-Stacks auf, wie z.B.
Kuschke und Wölfel in ihrem Buch „Web Service kompakt“ [KW02] oder Snell et al. in dem Buch
„Webservice-Programmierung mit SOAP“ [STK02]. Diese Autoren fügen unterhalb der TransportSchicht eine Netzwerk-Schicht ein und als Vertreter dieser Schicht das TCP/IP-Protokoll. Allerdings
ist diese Beschreibung einer untersten Schicht überflüssig, da Web-Services letztendlich auf höherer
Schicht beschrieben werden und von den darunter liegenden abstrahieren. Eine Haupteigenschaft von
Web-Services ist gerade die Unabhängigkeit von Transport-Protokollen. Ein Web-Service kann abstrakt beschrieben werden, indem seine Funktionalität ohne konkrete Angaben über das TransportProtokoll definiert wird. Einem Web-Service wird letztendlich ein Transport-Protokoll über eine Bindung zugeordnet. Also ist für die eigentliche funktionale Beschreibung des Web-Service die Trans-
18
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
port-Schicht erst später bei der konkreten Bindung wichtig. Eine weitere Schicht unterhalb der Transport-Schicht ist zur Beschreibung eines Web-Service somit nicht nötig.
Web-Services können prinzipiell bei jeder verteilten, Netz-basierten Orchestrierung von Softwaresystemen eingesetzt werden. Einige Beispiele für Web-Services sind u. a. Reservierungsdienste, B2BAnwendungen, Kostenabrechnungen, E-Commerce-Anwendungen, Sprachübersetzer, Meldedienste
(Wetter, Verkehr, Börseninformationen), verteilte Geschäftsprozesse und Rechnungssysteme 1.
Nach der Definition von Web-Services und deren Einordnung in den zugrunde liegenden ProtokollStack, folgt nun die Einordnung eines Web-Service in die Service-orientierte Architektur.
2.1.1
Service-orientierte Architektur
In diesem Unterkapitel wird zunächst erklärt, was eine Service-orientierte Architektur (SOA) ist, und
wie sie definiert wird. Danach wird ein Zusammenhang zu Web-Services hergestellt, da diese eine
spezielle Ausprägung und Realisierung der SOA darstellen. SOA basieren auf einem verteilten System, in dem diverse Service-Anbieter Dienste zur gegenseitigen Benutzung zur Verfügung stellen, um
eine gemeinsame Aufgabe zu erledigen. Ein Service-Anbieter stellt den anderen Service-Nutzern eine
Schnittstelle bereit, um den dahinter stehenden Dienst zu benutzen. Ein Service-Anbieter stellt seine
Dienste durch eine Applikation, ein Legacy-System, ein Ausgabegerät oder eine Computereinheit zur
Erbringung eines Dienstes bereit. Bei der Bereitstellung eines Dienstes ist lediglich das Interface zur
Benutzung für andere Teilnehmer von Interesse, die darunter liegende Implementierung ist transparent
gehalten.
Somit kann diese beliebig verändert oder gänzlich ausgetauscht werden, solange sich
dadurch die Schnittstelle für den Dienst nicht verändert. Die Schnittstelle definiert dabei die Funktionsweise des Dienstes und legt das Format der Nachrichten fest. Sämtliche Anbieter und Nutzer
kommunizieren dabei durch Nachrichtenaustausch über Transport-Protokolle miteinander, um die
vorliegende Aufgabe zu bearbeiten. In diesem verteilten System entsteht somit eine dynamische Orchestrierung unterschiedlicher Systeme. Je nach vorliegendem Aufgabenproblem arbeiten verschiedene einzelne Services zusammen, die nach Erledigung der Aufgabe wieder in neuer Konstellation zusammen arbeiten können.
Aus dieser Definition von SOA wird deutlich, dass ein Web-Service auf dem Prinzip der SOA beruht
und diese Architektur erweitert. Bei Web-Services erfolgt der Nachrichtenaustausch in XML-basierten
Formaten und daher unabhängig von der jeweils benutzten Plattform und Programmiersprache.
Abbildung 2 schematisiert die Zusammenarbeit von Anbietern, Nutzern und Registrierung und stellt
die Service-orientierte Architektur übersichtlich dar. In dieses allgemeine Schaubild der SOA wird der
Einsatz der Web-Service-Technologien WSDL, UDDI und SOAP eingebettet und somit der Zusammenhang zwischen SOA und Web-Services nochmals verdeutlicht.
1
Internetadresse mit einigen Web-Service-Beispielen: www.xmethods.net
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
19
Service
Registry
UDDI,
WSDL
UDDI
find
Service
publish
bind
Requestor
Service
Provider
SOAP
Abbildung 2: Service-orientierte Architektur mit Web-Service-Technologien
Der Dienst-Anbieter („Service Provider“ in Abb.2) publiziert („publish“ in Abb.2) mittels UDDI eine
Schnittstellen- und eine Dienstbeschreibung im Service-Verzeichnis („Service Registry“ in Abb.2).
Der Dienst-Anbieter ist verantwortlich für die Implementierung, Inbetriebnahme und Wartung des
angebotenen Dienstes. Ein Dienst-Nutzer (in der Literatur oft als Client bezeichnet, „Service Requestor “in Abb.2) kann innerhalb des Service-Verzeichnisses nach Diensten und Dienst-Anbietern suchen. Die Suche kann über eine API oder Suchmaske von UDDI erfolgen. Das Service-Verzeichnis,
auch Dienst-Makler (Service Broker) genannt, bietet eine Verwaltung und Speicherung der Dienstbeschreibungen für Web-Services an. Findet („find“ in Abb.2) ein Dienst-Nutzer einen Dienst, so erhält
er in Form eines WSDL-Dokumentes eine Schnittstellenbeschreibung des vorliegenden Service. Der
Dienst-Nutzer kann den Service des Dienst-Anbieters direkt in seine Applikationen integrieren und
nutzen („bind“ in Abb.2). Zum Senden der Nachrichten wird ein Protokoll der XML-MessagingSchicht verwendet, in der vorliegenden Arbeit wird sich dabei auf SOAP beschränkt.
Die Mächtigkeit dieser Architektur besteht darin, dass Aufgaben gemeinschaftlich durch verschiedene
Dienst-Anbieter Plattform-unabhängig und über Organisationsgrenzen hinweg verteilt gelöst werden
[Bur04].
2.2 Grundlagentechnologie: XML
Die Extensible Markup Language (XML) ist seit 1998 eine W3C-Empfehlung (Recommendation)
[BPS+04]. XML ist eine einfache, strukturierte Datenbeschreibungssprache, die von der Standard
Generalized Markup Language (SGML) abgeleitet wurde. XML ist eine Markupsprache zur strukturierten, wohlgeformten Darstellung von Daten und dabei unabhängig von Hersteller und Programmiersprachen. An dieser Stelle wird nicht auf die XML-Spezifikation eingegangen, sondern es soll die
Bedeutung von XML für die Benutzung von Web-Services herausgestellt werden. Der offene Standard
XML ist mehr als nur eine technische Spezifikation, denn XML hat die Entwicklung der vernetzten
Welt beeinflusst. Die Entwicklung neuer Technologien (z.B.: WSDL, UDDI und SOAP) bauen dabei
20
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
auf der Basistechnologie XML auf. Zusätzlich ist XML als Schüsseltechnologie zum Datenaustauschformat zwischen Programmen in verteilten Systemen avanciert. Frank P. Coyle geht in dem Buch
„XML, Web Services, and the Data Revolution“ sogar soweit, dass er von drei Revolutionen ausgeht,
die XML in den letzten Jahren auslöste [Coy02]:
Früher waren Daten stark an das Format einer Applikation gebunden, quasi jedes Programm benutzte
sein eigenes Datenformat. XML löste diese spezifischen Datenformate in einer Datenrevolution ab, da
XML unabhängig von Programmiersprachen und Betriebssystemen ist. Ferner ist XML unabhängig
von Transport-Protokollen und somit müssen Daten nicht an Formate von bestehenden Technologien
wie CORBA, RMI und DCOM angepasst werden. Diese Objekt-basierten Systeme sind nicht kompatibel zueinander und erschweren einen Datenaustausch über die Systemgrenzen hinweg. XML ermöglichte also eine Architekturrevolution, da XML als Netzwerk-Protokoll TCP/IP verwenden kann und
somit mit jedem verteilten System kommunizieren vermag. Schließlich bewirkte der Einsatz von XML
und Web-Services eine Softwarerevolution. Einfache Prozesse, Services, Geschäftsprozesse und sogar
Legacy-Systeme können nun kombiniert werden, um zusammen Aufgaben zu bearbeiten. Durch die
neue Möglichkeit der Interoperabilität stehen den Entwicklern von Programmen neue Wege offen.
XML legte den Grundstein für die Entwicklung neuer Technologien und letztendlich auch zum Etablieren von Web-Services.
2.3 Datenschema: XSD
Die XML Schema Definition Language (XSD) ist in der Version 1.0 seit dem 02.05.2001 eine Empfehlung (Recommendation) des W3C [FW04]. Diese Datenbeschreibungssprache wird im Rahmen
dieser Diplomarbeit zum Spezifizieren von Datentypen in WSDL verwendet und daher näher untersucht. In Kapitel 4.3 werden Aufbau und Struktur von XSD vertieft, wenn die Konvertierung von Datentypen in grafische Konstrukte und Validierungskomponenten erklärt wird. Innerhalb der Modellbildung stellt XSD einen zentralen Punkt dieser Diplomarbeit dar. Zum einen wird die GUI anhand der
vorliegenden Datentypen dynamisch generiert. Ein Zahlenwert wird z. B. anders grafisch dargestellt
als ein selbstdefinierter, komplexer Datentyp. Zum anderen findet eine Validierung der Daten statt,
falls Restriktionen für einen Datentypen in XSD durch Fassetten angegeben werden. XSD bietet ein
Vokabular um Struktur und Inhalte von Datentypen innerhalb eines WSDL-Dokumentes zu definieren
und ist selbst ein XML-Dokument. XSD definiert einerseits eine Reihe von Basisdatentypen (siehe
Übersicht der Datentyp-Hierarchie in XSD im Kapitel 4.3) und erlaubt die Definition eigener Datentypen und explizite Behandlung von Namensräumen. Diese neuen Datentypen können aus Basisdatentypen aufgebaut und durch eigene Restriktionen erweitert werden. Somit hat der Entwickler von WebServices ein mächtiges Instrumentarium zur Verfügung zum Entwickeln Problem-bezogener Datenstrukturen. XML-Daten könnte man auch mit der Document Type Definition (DTD) beschreiben.
DTD überprüft genauso wie XSD die Korrektheit und Wohlgeformtheit der XML-Daten. DTD weist
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
21
allerdings erhebliche Nachteile im Vergleich mit XSD auf und ist für den Einsatz innerhalb eines
WSDL-Dokumentes nicht geeignet. DTD´s werden in der Extended Backus Naur Form (EBNF) und
nicht in XML-konformer Syntax verfasst. Somit müsste man ein DTD in ein XML-Tag einbetten, um
es zusammen mit dem WSDL-Dokument zu versenden. Zusätzlich unterstützt DTD keine Namensräume, somit entstehen durch den Import-Mechanismus Namenskollisionen. Des Weiteren werden
keine Deklarationen von eigenen Datentypen unterstützt und DTD definiert selbst nur 10 Datentypen.
XSD unterstützt im Gegensatz dazu 44 Datentypen und erlaubt die Bildung von eigenen Datentypen.
Aus diesen Gründen ist die Verwendung von DTD sehr ungeeignet. Zur Erstellung des Modells und
zur Implementierung des Prototypen wurde deshalb ausschließlich XSD verwendet.
2.4 Web Service Description Language 1.1 (WSDL)
Die Web Services Description Language (WSDL) ist eine XML-basierte SchnittstellenBeschreibungssprache, mit deren Hilfe man Web-Services als eine Menge von Endpunkten beschreiben kann, die untereinander Nachrichten austauschen. Der Austausch und die gesendeten Nachrichten
selbst werden abstrakt beschrieben. Danach werden sie an ein konkretes Transport-Protokoll und
Nachrichtenformat gebunden, um so einen Endpunkt genau zu definieren. Von Microsoft, IBM und
Ariba wurde WSDL entwickelt und das W3C brachte zunächst am 15.März 2001 Version 1.1
[CCMW01] als W3C Note1 zur Diskussion heraus, bevor am 11.Juni 2003 Version 1.2 [CGMW04] als
W3C Working Draft2 herausgebracht wurde. Zurzeit liegt die Version 2.0 [CGM+04] seit dem
26.März 2004 als W3C Working Draft vor. Zur Diskussionsgrundlage wird in der vorliegenden Arbeit
Version 1.1 herangezogen und am Ende des Unterkapitels ein Vergleich mit Version 2.0 durchgeführt.
Werkzeuge, die WSDL parsen und Java-Code generieren, unterstützen zurzeit lediglich Version 1.1.
Durch den Vergleich von WSDL 1.1 und WSDL 2.0 wird deutlich, dass der Kern der Sprache erhalten
bleibt und lediglich an den genannten Stellen erweitert wird. Ein Update von Version 1.1 auf 2.0 würde keine großen Erweiterungen für die prototypische Implementierung des Modells verursachen und
die Ergebnisse dieser Diplomarbeit nicht revidieren bzw. beeinflussen.
Das W3C definiert WSDL folgendermaßen:
“The Web Services Description Language WSDL Version (WSDL) defines an XML grammar for
describing network services as collections of communication endpoints capable of exchanging
messages. WSDL service definitions provide documentation for distributed systems and serve as a
recipe for automating the details involved in applications communication.”
1
W3C Note: Das vom W3C veröffentlichte Dokument hat einen formellen Zustimmungsprozess durchlaufen
und wird veröffentlicht. Von Seiten des W3C gibt es keine Garantie der Weiterbearbeitung
2
W3C Working Draft: Ein vom W3C veröffentlichtes Dokument zur Einsicht und Diskussion durch die Öffent-
lichkeit, Veränderungen werden vorbehalten.
22
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Durch diese Definition wird ein weiterer wichtiger Aspekt von WSDL verdeutlicht, nämlich die automatische Integration durch Applikationen. WSDL ist nicht nur von Benutzern lesbar, sondern auch
direkt von Applikationen. Dadurch sind Applikationen in der Lage nach dem Parsen des WSDLDokumentes den beschriebenen Service just in time in die eigene Verarbeitung einzubinden und zu
nutzen. Dies ist auch der zentrale Ansatzpunkt dieser Diplomarbeit. Der zu entwickelnde Prototyp
nimmt ein WSDL-Dokument entgegen und generiert dynamisch daraus die GUI, die der Benutzer zum
Editieren der Anfrage und Anzeigen der Antwort verwendet.
Bevor im nächsten Unterkapitel der allgemeine Aufbau von WSDL erörtert wird, soll zunächst eine
Abgrenzung zwischen WSDL und der Interface Definition Language (IDL) aus der CORBA-Welt
herausgestellt werden. IDL, sowie auch WSDL, beschreiben beide die Schnittstelle für einen entfernten Service und dessen Datentypen. Die einzelnen Komponenten der beiden Beschreibungssprachen
sind sich sehr ähnlich: IDL-Types entsprechen WSDL-Types, IDL-Methoden korrespondieren zu
WSDL-Operationen, IDL-Interfaces zu WSDL-Porttypes und IDL-CORBA-Objekte korrespondieren
zu WSDL-Services.
IDL ist eine Textdatei, die einen Service mit dessen Methoden und Parametern beschreibt. Diese Beschreibung erfolgt Programmiersprachen-unabhängig. Der Object Request Broker (ORB) nimmt lokale Aufrufe entfernter Objekte entgegen und leitet diese an den Service weiter. Die XML-basierte
WSDL bietet ebenfalls eine Datenunabhängigkeit von verwendeten Programmiersprachen, allerdings
auch Unabhängigkeit von verwendeter Middleware und Transport-Protokoll, was bei IDL und
CORBA nicht gegeben ist. WSDL kann ebenfalls erweitert werden, somit können Nachrichten unabhängig von Protokoll und Format beschrieben werden.
2.4.1
Aufbau eines WSDL-Dokumentes
Der Aufbau eines WSDL-Dokumentes wird nun näher erläutert und die einzelnen Elemente spezifiziert. Sämtliche Informationen sind aus der W3C Note WSDL 1.1 vom 15.März 2001 entnommen
[CCMW01]. Zunächst sollen alle Elemente kurz andiskutiert und in Relation zueinander gestellt werden, bevor danach jedes Element im Detail erklärt wird. Ein WSDL-Dokument ist hierarchisch aufgebaut wobei das Definitions-Element (<definitions>) das Wurzelelement bildet und als Container
für die anderen Elemente dient.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
23
Die allgemeine Struktur eines WSDL-Dokumentes1:
<definitions targetNamespace="xs:anyURI" >
<documentation />?
[ <import /> ]*
<types />?
[ <message /> | <porttype /> | <binding /> | <service /> ]*
</definitions>
Das Definitions-Element beinhaltet als Attribute alle Namensraumdeklarationen des WSDLDokumentes. Hier werden neben dem Zielnamensraum (targetNamespace) der Elemente auch
weitere
Namensräume deklariert (u. a. Namensräume der verwendeten XSD-, SOAP-, WSDL-
Version und eigene Namensräume) und jeweils einem Präfix zugeordnet. Das nachfolgende Beispiel
zeigt die Verwendung von Präfixen und Namensräumen innerhalb des Definitions-Elementes.
<wsdl:definitions …
xmlns:myNamespace1="http://www.icsy.de/company/Myschema1"
xmlns:myNamespace2="http://www.icsy.de/private/Myschema2"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
</wsdl:definitions>
In dem obigen Beispiel wird dem Präfix myNamespace1, myNamespace2 und xsd jeweils ein
separater Namensraum zugeordnet. Der Präfix xsd steht nun als Stellvertreter innerhalb dieses Dokumentes für den Namensraum des XML-Schemas und myNamespace1 repräsentiert einen selbst
festgelegten Namensraum, myNamespace2 analog dazu. Durch Zuordnung von Namensräumen zu
einzelnen Elementen wird deren eindeutige Identität gewahrt. Lokale Namen von Elementen können
mehrfach vergeben werden. Eine Unterscheidung findet dann über den unterschiedlichen Namensraum
statt. Elemente werden aus diesem Grund durch einen qualifizierten Namen (QName) angesprochen.
Ein qualifizierter Name stellt einen XML-qualifizierten Namen dar, der eindeutig durch einen Namensraum und einen lokalen Namen spezifiziert ist. Das nächste Beispiel zeigt die Verwendung von
qualifizierten Namen zur eindeutigen Ansprache von Elementen.
<wsdl:complexType …>
<xsd:element name="company_address" type="myNamespace1:Address"/>
<xsd:element name="private_address" type="myNamespace2:Address"/>
</wsdl:complexType …>
Innerhalb eines nicht weiter spezifizierten komplexen Datentyps werden zwei weitere komplexe Datentypen referenziert, die beide den gleichen lokalen Namen Address aufweisen. Ohne Verwendung
eines qualifizierten Namens wäre eine Unterscheidung der zwei unterschiedlichen Datentypen nicht
möglich. Die Eindeutigkeit wird durch die Zuordnung des Namensraumes in Form des Präfixes bewahrt.
1
Informale Syntax:
"?" (0 oder 1), "*" (0 oder mehr), "+" (1 oder mehr)
24
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Weiterhin können optional Dokumentationen für den Anwender zum besseren Verständnis des
WSDL-Dokumentes im Dokumentations-Element (<documentation>) angeführt werden (siehe
Kapitel 4.5) und weitere Dokumente durch das Import-Element (<import>) eingebunden werden
(nächstes Unterkapitel). Das Datentyp-Element (<types>) wird zum Festlegen komplexer Datentypen verwendet und in Kapitel 4.4 untersucht. Zunächst sollen aber die vier Hauptelemente und deren
Kindelemente eines WSDL-Dokumentes näher betrachtet werden. Abbildung 3 zeigt dazu eine schematische Übersicht über diese Elemente und deren Relationen zueinander.
WSDL-Dokument
Service
…
Port
Binding
…
Port
Binding
Binding
Porttype
Operation
Message
Porttype
…
Operation
Message
Message
konkretes
Level
abstraktes
Level
…
Message
Abbildung 3: vereinfachter Aufbau eines WSDL-Dokumentes
Ein WSDL-Dokument beinhaltet ein Service-Element (<service>). Dieses Element gruppiert alle
verwendeten Port-Elemente (<port>) und beinhaltet somit eine Kollektion von einem oder mehreren
Ports. Jeder Port wird wiederum durch ein Anbindungs-Element (<binding>) an ein konkretes
Transport-Protokoll und Nachrichtenformat gebunden. Neben der Bindung wird jeder Port zusätzlich
durch einen Porttyp detailliert beschrieben. Das Porttyp-Element (<porttype>) beinhaltet mehrere
Operationen, ohne Angaben über den Transport-Mechanismus anzugeben. Jedes Operations-Element
(<operation>) ist letztendlich eine Kollektion von ein- und ausgehenden Nachrichten und legt
deren Sequenz und Kardinalität fest. Ein Nachrichten-Element (<message>) stellt die BasisKommunikationseinheit dar und beinhaltet die gesendeten Daten.
Die einzelnen Elemente können zur besseren Übersicht in zwei Levels unterteilt werden. Im konkreten
Level werden das Service-Element (mit dem Port-Element als Kindelement) und das AnbindungsElement gruppiert. Diese drei Elemente beschreiben wie der Web-Service an ein Transport-Protokoll
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
25
gebunden wird und unter welcher Adresse er zu kontaktieren ist. Der Web-Service wird also auf konkreter Ebene beschrieben. Im abstrakten Level (Porttyp- und Nachrichten-Element) wird von der konkreten Realisierung abstrahiert und lediglich die Daten zum Nachrichtenaustausch festgelegt. Zum
abstrakten Level werden ebenfalls die optionalen Datentyp-Elemente (<types>) gezählt, die die Parameter der Nachrichten spezifizieren. Datentyp-Elemente werden allerdings nur bei Verwendung von
selbst definierten, komplexen Datentypen verwendet und daher in dieser allgemeinen Übersicht nicht
berücksichtigt. Während das konkrete Level die Frage „Wie wird der Web-Service angesprochen?“
beantwortet, beschäftigt sich das abstrakte Level nur um das „Was der Web-Service leistet?“.
Anhand des in der Einleitung bereits erwähnten Beispiels des Taschenrechner-Web-Service sollen die
einzelnen Elemente nochmals anschaulich beschrieben werden. Bei diesem Beispiel in Abbildung 4
wird nicht auf die interne Darstellung der einzelnen Elemente eingegangen, sondern ein Gesamtüberblick dargestellt und von einigen Details abstrahiert. Innerhalb der einzelnen Elemente mussten zur
besseren Übersicht Interna weggelassen werden. Im Anhang 8.4 befindet sich das komplette WSDLDokument.
26
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
<wsdl:definitions targetNamespace="http://www.icsy.de/da/Cal"
xmlns:calNS="http://www.icsy.de/da/apfel/wsdl/Cal">
<wsdl:message name="addRequest">
<wsdl:part name="addend1" type="xsd:int"/>
<wsdl:part name="addend2" type="xsd:int"/>
</wsdl:message>
<wsdl:portType name="Calculator">
<wsdl:operation name="add" parameterOrder="addend1 addend2">
<wsdl:input message="calNS:addRequest" name="addRequest"/>
<wsdl:output message="calNS:addResponse" name="addResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="CalSoapBinding" type="calNS:Calculator">
<wsdlsoap:binding style="rpc" transport="http://…/soap/http"/>
<wsdl:operation name="add">
<wsdl:input name="addRequest"></wsdl:input>
<wsdl:output name="addResponse"></wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="prototype_Service">
<wsdl:port binding="calNS:CalSoapBinding" name="Calculator">
<wsdlsoap:address location="http://www.icsy.de/CalService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Abbildung 4: WSDL-Dokument des Taschenrechner-Web-Service
Das Port-Element repräsentiert den Taschenrechner-Web-Service. Dieser Port kann nun mit mehreren
anderen Ports in einem Service-Element spezifiziert werden. Das Service-Element würde somit unterschiedliche Web-Services beinhalten und eine Gruppierung dieser vornehmen. Durch das Anbindungs-Element wird dem Taschenrechner-Web-Service das Transport-Protokoll SOAP zugeordnet.
Im Porttyp-Element werden die einzelnen erlaubten Operationen des Services festgelegt. In diesem
Beispiel besteht der Web-Service aus den beiden Operationen Addition und Subtraktion. Für die Operation Addition wird dann im Operations-Element die ein- und ausgehenden Nachrichten festgelegt.
Diese Operation besteht lediglich aus einer eingehenden Nachricht (beide Summanden als Parameter)
und einer ausgehenden (Summe als Parameter). Für beide Nachrichten wird schließlich im Nachrichten-Element die Datentypen der Parameter festgelegt. Für die ausgehende Nachricht wären das zwei
Ganzzahlwerte (int).
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
27
Nachfolgend werden die wichtigsten Elemente eines WSDL-Dokumentes aufgelistet und detailliert
erläutert. Durch das Präfix wsdl wird verdeutlicht, dass es sich um ein WSDL-Element handelt. Die
Elemente von Datentyp-Deklarationen in XSD verwenden als Präfix xsd und können somit von
WSDL-Elementen unterschieden werden. Sämtliche Elemente können durch ein DokumentationsElement direkt im WSDL-Dokument näher beschrieben und erläutert werden.
<wsdl:documentation>
Die Dokumentation erläutert das umschließende Element.
</wsdl:documentation>
Innerhalb des Tags <documentation> kann eine Erläuterung zum dem Vaterelement angegeben
werden.
<types>
Dieses Element beinhaltet Datentyp-Definitionen zum Spezifizieren der Datentypen innerhalb einer
Nachricht. Um Plattformunabhängigkeit zu gewährleisten und eine Standardisierung festzulegen, wird
die XML Schema Definition Language zur Definition der Datentypen verwendet. Alternativ könnte
man auch andere Datenschemata nehmen, wie z.B. Document Type Definition (DTD), Relax NG1,
Abstract Syntax Notation (ASN.1)2 oder falls man ausschließlich mit CORBA-Objekten kommuniziert
das CORBA-Typsystem. Diese Datenschemata spielen allerdings in der Praxis im Bezug auf WebServices eher eine untergeordnete Rolle.
Die Struktur dieses Elementes:
<wsdl:types>
<xsd:schema .... />*
</wsdl:types>
Die Verwendung des Datentyp-Elementes ist optional, je nach der Komplexität der verwendeten Datentypen bei einem Web-Service. Benötigt man lediglich einfache Datentypen (z. B. einen Zahlenwert
ohne besondere Restriktionen als Parameter), so muss man diesen einfachen Datentyp nicht extra definieren. Einfache Datentypen werden implizit durch den Namensraum von XSD festgelegt. Wird allerdings als Parameter ein komplexerer Datentyp (z. B. eine Adresse bestehend aus Name und Anschrift)
verwendet, so muss dieser Datentyp in einem Datentyp-Element näher spezifiziert werden. Diese einfachen und komplexen Datentyp-Definitionen können zum Teil sehr umfangreich werden, da alle
sprachlichen Mittel von XSD zur Verfügung stehen. Aus diesem Grund werden die DatentypDefinitionen im Kapitel 4.3 separat behandelt.
1
weitere Informationen zu Relax NG findet man unter http://www.relaxng.org/ns/structure/1.0
2
ITU-T Recommendation X.680, weitere Informationen findet man unter http://www.itu.int/home/index.html
28
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Beispiel:
<wsdl:types>
<xsd:complexType name="SubType">
<xsd:element name="Minuend" type="xsd:float"/>
<xsd:element name="Subtrahend" type="xsd:float"/>
</xsd:complexType>
</wsdl:types>
Beim Taschenrechner-Web-Service werden bei der Addition zwei einfache Datentypen (Ganzzahlwerte) verwendet. Für diese beiden Parameter benötigt man keine extra Deklaration in einem DatentypElement. Bei der Subtraktion hingegen wird ein komplexer Datentyp (SubType) verwendet. Dieser
Datentyp ist benutzerdefiniert und muss somit deklariert werden, damit Sender und Empfänger des
Web-Service ein identisches Verständnis dieses Datentyps haben. In diesem Beispiel ist der komplexe
Datentyp aus zwei einfachen Datentypen (Gleitkommazahlen, float) aufgebaut.
<message>
Eine Nachricht (Message) ist eine Basis-Kommunikationseinheit zwischen einem Web-Service und
einer Anwender-Applikation und beinhaltet die gesendeten Daten innerhalb einer Nachricht zwischen
beiden Teilnehmern. Das Nachrichten-Element listet alle Parameter auf, die innerhalb dieser Nachricht
verwendet werden, und besitzt einen eindeutigen Namen innerhalb des Dokumentes. Besitzen mehrere
Elemente einen identischen Namen, so muss die Identität durch Zusatz eines Namensraumes erreicht
werden (qualifizierter Name).
Die Struktur dieses Elementes:
<wsdl:message name="nmtoken"> *
<wsdl:part name="nmtoken" element="qname"? type="qname"?/> *
</wsdl:message>
Ein Nachrichten-Element besteht aus logischen Part-Elementen (<part>). Diese sind wiederum
durch einen eindeutigen Namen innerhalb dieses Nachrichten-Elementes identifiziert. In den PartElementen werden die übertragenen Parameter benannt und der Datentyp festgelegt. Das Attribut
element innerhalb von <part> referenziert ein XSD-Element durch einen qualifizierten Namen.
Das Attribut type referenziert einen einfachen oder komplexen XSD-Datentyp.
Beispiel:
<wsdl:message name="addRequest">
<wsdl:part name="addend1" type="xsd:int"/>
<wsdl:part name="addend2" type="xsd:int"/>
</wsdl:message>
In dieser Nachricht namens addRequest werden in den beiden Part-Elementen die Parameter
addend1 und addend2 als Parameter festgelegt. Zusätzlich werden die Datentypen beider Parameter fixiert, in dem Beispiel zwei Ganzzahlwerte (int).
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
29
<porttype>
Ein Porttyp-Element besteht aus einer Menge von Operationen, die wiederum die zuvor definierten
Nachrichten-Elemente gruppieren. Das Porttyp-Element gehört wie die voran gegangenen Elemente
zum abstrakten Level, somit werden keine Angaben über das Transport-Protokoll angegeben. Das
Porttyp-Element bestimmt zwar Transmissions-Primitiven, legt aber nicht fest wie diese realisiert
werden. Weiterhin legt das Porttyp-Element alle Operationen fest, die auf einem Port ausführbar sind.
Somit wird der funktionale Rahmen des Web-Service festgelegt.
Die Struktur dieses Elementes:
<wsdl:portType name="nmtoken">
<wsdl:operation name="nmtoken" .... /> *
</wsdl:portType>
Ein Porttyp-Element besitzt einen eindeutigen Namen unter allen vorhanden Porttyps innerhalb des
Dokumentes. Das Operations-Element ist ein Kindelement des Porttyp-Elementes und besitzt folgende
Struktur:
<wsdl:operation name="nmtoken" parameterOrder="nmtokens"*>
<wsdl:input name="nmtoken"? message="qname"/>*
<wsdl:output name="nmtoken"? message="qname"/>*
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
Mit dem Attribut parameterOrder können Angaben über die Parameterreihenfolge angegeben
werden. Der Name muss nicht eindeutig sein, im Gegensatz zu den anderen Elementen von WSDL.
Dadurch können einzelne Operationen überladen werden und lediglich durch die Anzahl der Nachrichten oder unterschiedliche Datentypen innerhalb einer Nachricht unterschieden werden. Das Überladen
von Operationen kann man sich analog zum Überladen von Methoden bei einer Objekt-orientierten
Sprache vorstellen. Zusätzlich wird spezifiziert, ob es sich bei den Nachrichten um Eingehende oder
Ausgehende handelt. Ferner kann man in einer Fehlernachricht eine Ausgabe spezifiziert werden, die
im Fehlerfall übermittelt wird. Die Elemente <input> und <output> beziehen sich dabei auf den
Web-Service. <input> bedeutet dabei, dass der Web-Service eine Nachricht empfängt, der Anwender diese also sendet. <output> besagt, dass der Anwender eine Nachricht empfängt und der WebService sendet. WSDL unterstützt dabei vier Transmissions-Primitiven für Operationen, die festlegen
wie ein Web-Service und eine Anwender-Applikation untereinander kommunizieren und welche
Kombinationen von Nachrichten erlaubt sind:
One-way:
Der Service empfängt eine Nachricht vom Anwender und sendet keine Antwort
zurück.
<wsdl:input name="nmtoken"? message="qname"/>
Anwendungsszenario: Hochladen einer Datei
30
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Request-Response: Der Service empfängt eine Nachricht und sendet eine Antwort zum Anwender.
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
Anwendungsszenario: Anfrage nach dem Börsenkurs einer Aktie und aktueller
Kursstand als Antwort.
Solicit-Response: Der Service sendet eine Nachricht und empfängt eine Antwort vom Anwender.
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
Anwendungsszenario: Benachrichtigung, dass persönliche Daten überprüft
werden sollen, als Antwort Bestätigung der Einsicht der Daten und evtl. Änderungen.
Notifikation:
Der Service sendet eine Nachricht zum Anwender.
<wsdl:output name="nmtoken"? message="qname"/>
Anwendungsszenario: Service sendet eine Nachricht, dass sich das Nutzungsangebot eines Dienstes erweitert hat.
Beispiel einer Request-Response Operation:
<wsdl:portType name="Calculator">
<wsdl:operation name="add" parameterOrder=" addend1 addend2">
<wsdl:input message="addRequest" name="addRequest"/>
<wsdl:output message="addResponse" name="addResponse"/>
</wsdl:operation>
</wsdl:portType>
In diesem Beispiel, das aus Abbildung 4 entnommen wurde, wird eine komplette Addition mit Anfrage und Antwort beschrieben. Die Anfrage (<input>) und die Antwort (<output>) werden jeweils in dem zuvor beschriebenen Nachrichten-Element näher erläutert. Hier findet lediglich eine
Komposition der enthaltenen Nachrichten innerhalb dieser Operation statt. Zusätzlich werden die Eingabeparameter von addRequest chronologisch festgelegt im Attribut parameterOrder. In
diesem Beispiel wäre eine Vertauschung der Reihenfolge der Parameter ohne Auswirkungen auf das
Ergebnis, da die Addition kommutativ ist. Bei der Subtraktion würde allerdings das Ergebnis falsch
ausgewertet werden bei Nichteinhaltung der korrekten Parameterreihenfolge.
<binding>
Durch das Anbindungs-Element wird ein Nachrichtenformat definiert und dem abstrakten Porttyp ein
konkretes Transport-Protokoll (z.B.: SOAP, HTTP Get/Post oder MIME) zugeordnet. Prinzipiell kann
jedes Transport-Protokoll verwendet werden das XML-Daten transportieren kann.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
31
Die Struktur dieses Elementes:
<wsdl:binding name="nmtoken" type="qname"> *
<-- extensibility element (1) --> *
<wsdl:operation name="nmtoken"> *
<-- extensibility element (2) --> *
<wsdl:input name="nmtoken"? > ?
<-- extensibility element (3) -->
</wsdl:input>
<wsdl:output name="nmtoken"? > ?
<-- extensibility element (4) --> *
</wsdl:output>
<wsdl:fault name="nmtoken"> *
<-- extensibility element (5) --> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
Das Attribut name legt einen eindeutigen Namen unter sämtlichen Anbindungs-Elementen innerhalb
des WSDL-Dokumentes fest und das type Attribut referenziert den korrespondierenden Porttyp des
WSDL-Dokumentes. Prinzipiell ist es möglich mehrere Anbindungen für einen Porttyp zu spezifizieren, um so flexibel mit mehreren Transport-Protokollen zu sein. Bei der Entwicklung des Prototypen
wurde sich allerdings auf Anbindungen mit dem weit verbreiteten Standard SOAP beschränkt. Eine
Anbindung darf jedoch jeweils immer nur ein Transport-Protokoll unterstützen und keine Angaben
über
Netzwerkadressen
machen,
die
erst
im
Port-Element
definiert
werden.
Die
<extensibility> Elemente stellen Platzhalter dar für weitere Spezifikationen. Eine exakte Darstellung des Anbindungs-Elementes würde den Rahmen dieser Diplomarbeit übersteigen, da das Anbindungs-Element sehr komplex ist. Es wird an dieser Stelle auf die Literatur [CCMW01] verwiesen.
Zum Einbinden des Client wird das generische Werkzeug WSDL2Java von Apache Axis [Axis04]
verwendet, welches ein implizites Anbinden der Porttyps auf SOAP durchführt. WSDL2Java wird in
Kapitel 3.1 eingeführt.
<service>
Ein Service ist eine Kollektion von Ports. Das Service-Element stellt somit alle angebotenen WebServices innerhalb eines WSDL-Dokumentes zusammen.
Die Struktur dieses Elementes:
<wsdl:service name="nmtoken"> *
<wsdl:port name="nmtoken" binding="qname"> *
</wsdl:service>
32
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
<port>
Das Kindelement eines Services, der Port, assoziiert einen Web-Service-Endpunkt durch Zuordnung
einer Netzwerkadresse zum vorliegenden Binding, welches über das Attribut binding identifiziert
wird. Der Port repräsentiert in WSDL einen Web-Service, der über die Netzwerkadresse eindeutig zu
erreichen ist.
Ein Beispiel für Port- und Service-Element aus dem Taschenrechner-Beispiel:
<wsdl:service name="prototype_Service">
<wsdl:port binding="calNS:CalSoapBinding" name="Calculator">
<wsdlsoap:address location="http://www.icsy.de/…/CalService"/>
</wsdl:port>
<wsdl:port>…</wsdl:port>
</wsdl:service>
Der Service namens prototype_Service gruppiert zwei Ports, wovon der zweite hier nur angedeutet ist. Der erste Port trägt den Namen Calculator und ihm wird eine Anbindung zugewiesen.
Innerhalb der Anbindung wird, wie oben bereits erklärt, dem Port ein Transport-Protokoll zugeordnet,
welches zum Senden der involvierten Operationen verwendet wird. Außerdem wird innerhalb des
Port-Elementes dem Port eine konkrete Netzwerkadresse zugeordnet über die der Web-Service zu
erreichen ist.
Nach dem Aufbau eines WSDL-Dokumentes und Einführung der Elemente wird nun der ImportMechanismus vorgestellt, mit der die soeben vorgestellten Elemente auf verschiedene Dokumente
verteilt werden können.
2.4.2
Modularisierung durch Importieren
WSDL bietet die Möglichkeit, WSDL-Dokumente modular aufzubauen. Es steht dazu der ImportMechanismus durch das Import-Element zur Verfügung. Damit können Elemente aus dem gleichen
und einem anderen Namensraum eingebunden werden. Hauptsächlich können Datentyp-Elemente in
eigenen XSD-Dokumenten ausgelagert werden. Die Elemente mit einem anderem Namensraum können sich im gleichen WSDL-Dokument befinden oder aus einem anderen XSD- und WSDLDokument importiert werden. Das Import-Element besitzt das Attribut namespace zum Definieren
des Namenraumes und location zur Angabe der URL des ausgelagerten Dokumentes. Das Attribut
location ermöglicht die physikalische Verteilung einzelner Elemente in unterschiedliche Dokumente und gibt eine Referenz auf dessen URL an. Durch das Attribut namespace können Elemente
aus einem anderen Namensraum importiert werden. Somit kann es innerhalb des WSDL-Dokumentes,
mit seinen importierten Elementen, zu Namensgleichheit von lokalen Elementnamen kommen. Die
eindeutige Identität eines Elementes wird allerdings immer in Kombination des Namens (lokaler Name) und dessen Namensraum gewährleistet. Zwei unterschiedliche komplexe Datentypen namens
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
33
„Adresse“ können somit z.B. zum einen die Adresse der Firma und zum anderen die Adresse von Mitarbeitern repräsentieren. Durch Zuordnung zweier separater Namensräume ist die Eindeutigkeit eingehalten, die von der WSDL-Spezifikation verlangt wird.
Durch den Import-Mechanismus können somit klarere, übersichtlichere WSDL-Dokumente verfasst
werden. Häufig verwendete Komponenten können in neue XSD- oder WSDL-Dokumente ausgelagert
werden. Durch diese Modularisierung der WSDL-Dokumente wird die Wiederverwendbarkeit erhöht.
WSDL-Dokumente können leicht nach dem Baukastenprinzip erstellt werden und die Lesbarkeit einzelner Dokumente wird durch die Reduktion der enthaltenen Komponenten pro Dokument erhöht.
Zusätzlich müssen häufig verwendete Komponenten nicht jedes Mal neu definiert werden. Durch die
Auslagerung von Datentyp-Elementen in externe XSD-Dokumente kann man sich z.B. eigene Bibliotheken mit spezifischen Datentypen für diverse Problemstellungen errichten. Je nachdem, welche Datenstrukturen der Web-Service benötigt, können diese dann importiert werden. Durch die Zusammenfassung von den Service-, Port- und Anbindungs-Elementen kann man die Elemente des konkreten Levels in ein WSDL-Dokument bündeln. In ein weiteres WSDL-Dokument könnte man die
Elemente des abstrakten Levels (Porttyp-, Nachrichten- und Datentyp-Element) zusammenfassen. So
kann man diese zwei logischen Levels trennen und durch Importieren zu einem vollständigen WSDLDokument vereinigen. Allerdings besteht natürlich auch die Möglichkeit die Granularität der Trennung innerhalb der logischen Levels noch zu erhöhen. Eine sinnvolle Trennung innerhalb des konkreten Levels wäre die Trennung des Service-Elementes auf der einen und dem Anbindungs-Element auf
der anderen Seite. Da die Möglichkeit besteht, verschiedene Transport-Protokolle als Anbindung zu
verwenden, könnten so verschiedene Anbindungs-Elemente erstellt werden und danach beliebig mit
dem Service-Element kombiniert werden. Die Granularität der Aufsplittung wird begrenzt auf Element-Ebene. Eine Trennung von Vater- und Kindelementen ist nicht erlaubt, <service> und
<port> können also nicht verteilt werden.
Beim Importieren ist darauf zu achten, dass man ein XSD- oder WSDL-Dokument jeweils immer nur
direkt importiert. Die Elemente des direkt importierten Dokumentes können aus dem importierenden
Dokument angesprochen werden, transitiv importierte Elemente sind allerdings nicht erlaubt. Transitives Importieren ist nicht erlaubt, da es Probleme beim Erkennen des Namensraumes geben kann. Beim
Importieren können Elemente mit dem gleichen oder einem anderen Namensraum importiert werden.
Beim direkten Importieren wird der neue Namensraum, falls ein anderer Namensraum verwendet
wird, dem importierenden Dokument übermittelt und ist somit auch in diesem Dokument bekannt.
Beim transitiven Importieren eines Dokumentes ist dieser Namensraum im transitiv importierenden
Dokument nicht bekannt, da lediglich der Namensraum dem direkt importierenden Dokument übermittelt wird. Dieser Sachverhalt wird in Abbildung 5 nochmals grafisch veranschaulicht.
34
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
direktes Importieren:
transitives Importieren:
Zugriff
WSDL 1
Zugriff
WSDL/
WSDL 1
XSD 2
<import>
<import>
WSDL/
WSDL/
XSD 2
XSD 3
<import>
Abbildung 5: direktes und transitives Importieren
Das linke Schaubild zeigt das erlaubte, direkte Importieren eines XSD- oder WSDL-Dokumentes. Auf
alle Elemente innerhalb von WSDL/XSD2 kann aus WSDL1 zugegriffen werden. Das rechte Schaubild zeigt hingegen einen unerlaubten, fehlerhaften Zugriff, der durch transitives Importieren entsteht.
Das von WSDL1 importierte WSDL/XSD2 importiert wiederum ein weiteres Dokument
(WSDL/XSD3). WSDL/XSD2 kann auf alle Elemente von WSDL/XSD3 zu greifen, WSDL1 allerdings nicht, da es WSDL/XSD3 nicht selbst (direkt) importiert. Der Namensraum von WSDL/XSD3
wird lediglich WSDL/XSD2 übermittelt. Importiert WSDL1 nun WSDL/XSD2, so ist in WSDL1 der
Namensraum von WSDL/XSD3 nicht bekannt. Aus diesem Grund darf WSDL1 nicht auf
WSDL/XSD3 zugreifen.
Es gibt keine Beschränkung in der Tiefe der Importhierarchie. Ein importiertes Dokument kann wiederum weitere Dokumente importieren, usw. Es muss lediglich darauf geachtet werden, dass der Zugriff
auf Elemente immer direkt auf das importierte Dokument gerichtet ist und nicht transitiv durchgeführt
wird. Russel Butek veröffentlicht in einem Artikel von IBM „Web Service Programming Tips and
Tricks: WSDL file imports“ [But04] ein Beispiel über den Import-Mechanismus bei WSDL 1.1. Der
interessierte Leser findet dort ein weiteres Beispiel für ein fehlerhaftes transitives Importieren, das
anschließend in zwei direkte Import-Anweisungen aufgelöst wird.
2.4.3
Vergleich WSDL 1.1 und WSDL 2.0
In der vorliegenden Arbeit wurde WSDL 1.1 verwendet, da noch keine Werkzeug-Unterstützung zur
Generierung von Java-Code für WSDL 2.0 vorliegt. Die erste Veröffentlichung des W3C von WSDL
2.0 erfolgte im November 2003 (Working Draft) [CGM+03]. Davor wurde WSDL 1.2 ebenfalls als
Working Draft spezifiziert, allerdings recht kurzfristig durch die neue Version 2.0 abgelöst. Die Betrachtung von WSDL 1.2 entfällt somit, da weder Werkzeug-Unterstützung, noch weitere Forschungsarbeiten sich mit dieser Version befassen. Die Entwickler der Werkzeuge haben zurzeit immer noch
einige nicht implementierte, offene Anforderungen bei der Generierung von Java-Code aus WSDL
1.1. Kapitel 3.2 beschäftigt sich nochmals ausführlich mit den offenen Anforderungen und Generierung von Java-Code aus WSDL. WSDL 2.0 liegt zurzeit als Working Draft vor, Veränderungen können also jederzeit vorgenommen werden. Dennoch werden die wichtigsten Veränderungen in diesem
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
35
Kapitel aufgeführt, die von Version 1.1 zu 2.0 entstanden. Für die weitere Entwicklung des Modells
und Prototypen finden diese Veränderungen allerdings keine Berücksichtigung. Da noch kein Standard
verabschiedet wurde für WSDL 2.0, können die nachfolgend angeführten Veränderungen von der
endgültigen Version variieren.
Operationen dürfen in Version 2.0 nicht mehr überladen werden. Bei WSDL 1.1 war es möglich Namensgleichheit bei Operationen zu erlauben und lediglich über die Anzahl der Parameter und Datentypen eine Unterscheidung vorzunehmen.
Das Element <porttyp> wurde in Version 2.0 in <interfaces> und <port> in <endpoint>
umbenannt. Die Funktionalität blieb jedoch unverändert. Das Attribut location des Elementes
<import> wurde in schemaLocation geändert. Die Namensänderungen lassen sich dadurch
erklären, da zur semantischen Beschreibung der alten Begriffe immer wieder die neuen verwendet
wurden. Da die neuen Namen dadurch intuitiver und geläufiger sind, wurden diese Änderungen vorgenommen.
Zusätzlich wurde die Möglichkeit zur Modularisierung von WSDL-Dokumenten verfeinert. Die Modularisierung stellt ein wichtiges Instrumentarium zur strukturierten Darstellung von WSDL und Wiederverwendung einzelner Komponenten dar. Wie im vorigen Unterkapitel bereits erwähnt, stand bisher in Version 1.1 lediglich der Import-Mechanismus dafür zur Verfügung. Nun besteht in der Version
2.0 die Möglichkeit XSD- und WSDL-Komponenten einzubetten (include) oder zu importieren (import). Die Möglichkeit der Modularisierung durch <import> wurde also durch <include> erweitert. Diese beiden Varianten werden nun vorgestellt und voneinander abgegrenzt.
Das Hauptunterscheidungsmerkmal beider Varianten der Modularisierung ist die unterschiedliche
Verwendung des Namensraumes. Bei einem <include> werden XSD- oder WSDL-Dokumente
eingebettet, die den gleichen Namensraum haben. Bei einem <import> hingegen werden XSD- oder
WSDL-Dokumente mit einem unterschiedlichen Namensraum importiert. Diese Unterscheidung fand
bei WSDL 1.1 nicht statt. Hier wurde sowohl das Einbinden von Elementen mit gleichen als auch mit
unterschiedlichen Namensräumen durch Importieren durchgeführt.
Durch diese Erweiterungen entstanden auch unterschiedliche Vorraussetzungen für das Importieren
von XSD- und WSDL-Dokumenten. Zuvor bei WSDL 1.1 wurden XSD und WSDL unter identischen
Vorraussetzungen eingebunden.
Ein bereits importiertes XSD darf beim Importieren in ein WSDL-Dokument kein weiteres XSD importieren. In diesem Fall muss das zweite importierte XSD ebenfalls in das WSDL-Dokument importiert werden (kein transitives Importieren erlaubt). Wird ein XSD allerdings eingebettet durch
<include>, so verhält sich das Einbetten wie ein „Cut and Paste“-Vorgang des XSD in das Datentyp-Element des WSDL-Dokumentes. Da das XSD- und das WSDL-Dokument den gleichen Namensraum haben, können alle Komponenten identifiziert werden. Das WSDL kann Komponenten innerhalb
des eingebetteten XSD ansprechen, so als wäre dieses physikalisch in das WSDL-Dokument eingebettet. Durch diese Eigenschaft entstehen einige Sonderfälle, die ein transitives Inkludieren von XSD
36
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
erlauben. Abbildung 6 zeigt jeweils ein Szenario für ein erlaubtes transitives Inkludieren und ein Fehlerhaftes.
erlaubtes Szenario:
WSDL 1
<Import> oder
<include>
XSD 1
fehlerhaftes Szenario:
XSD 2
<Include>
WSDL1
XSD 1
<Import> oder
<include>
XSD 2
<Import>
Abbildung 6: transitiver Zugriff auf XSD in WSDL 2.0
In der linken Skizze wird XSD2 von XSD1 eingebettet. Somit sind alle Komponenten von XSD2 in
XSD1 ansprechbar und werden so behandelt, als wären sie innerhalb des Datentyp-Elementes von
XSD1 eingebettet. XSD1 und XSD2 haben den gleichen Namensraum. Wird nun XSD1 von WSDL1
importiert oder eingebettet, so werden die Komponenten aus XSD2 übernommen, da sie den gleichen
Namensraum haben und als Komponenten innerhalb des Datentyp-Elementes angesehen werden.
Auf der rechten Seite importiert allerdings XSD1 XSD2. Somit besitzt XSD2 einen eigenen, anderen
Namensraum als XSD1. Beim Importieren oder Inkludieren von XSD1 in WSDL1 entstehen somit
Konflikte durch den unbekannten Namensraum von XSD2 in WSDL1.
Bei einem Einbetten von WSDL-Dokumenten können die Elemente, die den gleichen Namensraum
haben, auf mehrere WSDL-Dokumente verteilt werden. Beim Einbetten ist wie beim Importieren darauf zu achten, dass nur direktes Inkludieren möglich ist und kein transitives (anders als bei XSD)1.
Importiert nun das eingebettete WSDL-Dokument wiederum weitere XSD, so müssen diese im ursprünglichen WSDL-Dokument importiert werden, da unterschiedliche Namensräume vorliegen. Eingebettete XSD innerhalb eines inkludierten WSDL-Dokumentes sind allerdings erlaubt, da das eingebettete XSD als Teil des Datentyp-Elementes verstanden wird und den gleichen Namensraum aufweist. Nachfolgend sei noch ein Sonderfall aufgeführt, der in Abbildung 7 skizziert wird.
1
An dieser Stelle ist die Spezifikation des W3C sehr kurz gehalten. Darin wird lediglich ein transitives Inkludie-
ren verboten, allerdings keine Gründe dafür genannt. Zusätzlich ist eine nicht vorhandene Referenz auf die XSDSpezifikation an dieser Stelle angegeben. Beim transitiven Inkludieren von XSD wird dies explizit erlaubt, da
sich das Einbetten analog zu einem „Cut and Paste“-Verfahren verhält und bei allen Elementen der gleiche Namensraum vorliegt. Beim transitiven Inkludieren eines WSDL-Dokumentes wäre auch der gleiche Namensraum
vorhanden, meiner Meinung nach allerdings ohne offensichtlichen Grund nicht erlaubt.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
WSDL 1
<Import>
37
WSDL 2
<Include>
explizites
<Import> notwendig
XSD
Abbildung 7: Sonderfall beim Importieren in WSDL 2.0
Das importierte WSDL2-Dokument inkludiert XSD. Beim Einbetten wird, wie bereits erwähnt, eine
Namensraumgleichheit vorausgesetzt. XSD und WSDL2 verwenden somit den identischen Namensraum. Importiert nun WSDL1 WSDL2, so wird dem WSDL1-Dokument mitgeteilt, dass in WSDL2
ein anderer Namensraum zur Verwendung kommt. Allerdings erkennt WSDL1 nicht automatisch, dass
in XSD ebenfalls ein anderer Namensraum, der gleiche wie in WSDL2, verwendet wird. Aus diesem
Grund muss WSDL1 XSD explizit importieren, um auch diesen Namensraum zu erkennen, auch wenn
er identisch zum Namensraum in WSDL2 ist.
Wie die gerade angeführten Erläuterungen belegen, hat sich die Mächtigkeit zur Modularisierung erhöht, allerdings dadurch auch die Komplexität von erlaubten und verbotenen Szenarien innerhalb des
Importierens und Inkludierens. Bis auf diese Möglichkeit der modularen WSDL-Bildung und Namensänderungen hat sich die Technologie zurzeit im Wesentlichen nicht verändert.
2.5 Universal Description, Discovery and Integration (UDDI)
Universial Description, Discovery and Integration (UDDI) ist ein Plattform-unabhängiges Framework,
das die Möglichkeit bietet, Web-Services zu beschreiben, publizieren und suchen [Bel02]. UDDI wurde 2001 von IBM, Microsoft und Ariba ins Leben gerufen und mittlerweile haben sich über 300 Unternehmen dieser Initiative angeschlossen, die im Internet unter www.uddi.org zu finden ist. Mittlerweile liegt UDDI in Version 3 vor. UDDI bietet ein Schema zum Beschreiben eines Unternehmens
und dem angebotenen Dienst, ein globales Registrierungsverzeichnis, eine SOAP-API1 zum Registrieren und eine weitere zum Suchen eines Services. Die Definition der UDDI-Initiative verdeutlicht
nochmals die Funktion und Anwendbarkeit von UDDI, wobei UDDI nicht auf Web-Services beschränkt ist, sondern allgemein auf Geschäftsinformationen.
“Universal Description, Discovery and Integration, or UDDI, is the name of a group of web-based
registries that expose information about a business or other entity and its technical interfaces (or
API’s). These registries are run by multiple Operator Sites, and can be used by anyone who wants
1
SOAP-API: SOAP Applikation Programming Interface, SOAP- Programmierschnittstelle
38
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
to make information available about one or more businesses or entities, as well as anyone that
wants to find that information.”[BRY02]
Einige Unternehmen der Initiative, wie z.B.: IBM, HP, SAP und Microsoft, bieten RegistrierungsServer an, um Services zu veröffentlichen und zu suchen. Sämtliche Server werden regelmäßig synchronisiert, so dass die Auswahl eines Servers dem Benutzer freigestellt wird und eine äquivalente
Auswahl bietet. UDDI bietet fünf Datenstrukturen an, über welche man die Suche und Registrierung
durchführen kann. Da die UDDI-Verzeichnisse eine Analogie zu Telefonbüchern und den Gelben
Seiten aufweisen, kann man von den Datenstrukturen auf eine höhere Sicht abstrahieren. Abbildung 8
zeigt die drei abstrakten Sichten von UDDI und die dahinter liegenden Datenstrukturen.
Abstrakte Sicht:
Datenstrukturen eines UDDI-Dokumentes:
White
businessEntity:
Pages
Top-Level-Struktur
publisherAssertion
<Wer?>
Yellow
businessService
Pages
<Was?>
Green
Pages
bindingTemplate
tModel
<Wie?>
Abbildung 8: Übersicht der Datenstrukturen in Beziehung zur abstrakten Sicht auf UDDI
Die Sicht der weißen Seiten (White Pages) stellt das Unternehmen näher vor und liefert Informationen
über Unternehmensname, Geschäftsadresse, Webseite und weitere Kontaktinformationen. Die Datenstruktur businessEntity speichert diese Daten. Die gelben Seiten (Yellow Pages) liefern genaue geografische Informationen, den Unternehmenstyp und seine Produkte, sowie Taxonomienummern, die in
der Datenstruktur businessService gespeichert werden. Die grünen Seiten (Green Pages) beinhalten
technische Informationen über den Service wie z.B. Netzwerkadresse und Anbindungsinformationen,
sowie eine Referenz zu einem WSDL-Dokument. Diese Daten werden in der Datenstruktur bindingTemplate gehalten. Des Weiteren gibt es noch die Datenstruktur publisherAssertion, die Informationen
über Beziehungen zwischen verschiedenen Unternehmen bietet. Schließlich erweitern tModels die
Datenstruktur bindingTemplate und liefern eine Kollektion von Informationen über den Service und
technische Informationen. [New02b]
Somit bietet UDDI ein globales Verzeichnis zum Registrieren und Suchen von Services, das nicht nur
auf Web-Services eingeschränkt ist. Die Web Service Inspection Language (WS-Inspection) von IBM
und Microsoft bietet eine Alternative zu UDDI zum Suchen von Web-Services im Internet. Der aus-
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
39
schlaggebende Punkt für diese neue Entwicklung parallel zu UDDI ist dessen Komplexität und hoher
Anspruch. WS-Inspection bietet eine einfachere Registrierung von Services, in der neben WSDL auch
UDDI-basierte Beschreibungselemente eingebettet werden können. Eine ausführliche Beschreibung
von WS-Inspection findet der interessierte Leser unter [BEG+03].
2.6 SOAP
SOAP wurde 1998 von Microsoft unter dem Namen Simple Object Access Protocol1 entwickelt. Danach stießen einige weitere Unternehmen, wie z.B.: IBM, Lotus und Ariba, hinzu und im Mai 2000
veröffentlichte das W3C SOAP 1.1 als Note. Im Juni 2003 wurde schließlich SOAP 1.2 als W3C
Recommendation verabschiedet [Mit03]. SOAP definiert einen Plattform- und Programmiersprachenunabhängigen Protokollstandard zum typisierten Datenaustausch zwischen Applikationen in dezentralisierten, verteilten Umgebungen. SOAP packt dazu die vorliegenden Daten in ein protokollspezifisches XML-Format und sendet die Daten über bestehende Transport-Protokolle, wie z.B. HTTP, FTP,
SMTP oder BEEP. SOAP hat demnach den Vorteil gegenüber CORBA, RMI und DCOM, dass es
nicht an ein spezifisches Transport-Protokoll oder eine Sprache gebunden ist und über Systemgrenzen
mit anderen Applikationen Daten austauschen kann.
Die Definition des W3C verdeutlicht nochmals diesen Aspekt:
“SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of
underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.” [GHM+03]
Nachfolgend wird der Aufbau einer SOAP Nachricht und deren Hauptkomponenten erklärt und in
Abbildung 9 illustriert.
1
Der Name suggeriert allerdings, dass das Übertragungsprotokoll zum Austausch von Objekten entwickelt wur-
de. Allerdings werden alle Daten in XML serialisiert und übertragen. Deshalb schlug das W3C eine Namensänderung vor (u. a. XML Protocol). Die Abkürzung SOAP hatte sich allerdings schon so verbreitet und etabliert,
dass beschlossen wurde lediglich die Abkürzung von nun an als Namen zu verwenden.
40
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
SOAPMessage
SOAP-Part
Envelope
Header (optional)
Body
Attachment-Part (1..*)
MIME Header
Content
Abbildung 9: Aufbau einer SOAP-Nachricht
Eine SOAP-Nachricht besteht aus einem SOAP-Part und optional aus beigefügten Anhängen („Attachment-Part“ in Abb. 9). Der im SOAP-Part befindliche Umschlag („Envelope“ in Abb. 9) besteht
wiederum aus einem optionalen Kopf („Header“ in Abb. 9) und einem vorgeschrieben Körper („Body“ in Abb. 9). Der Kopf enthält Applikations-spezifische Informationen, die Angaben zur Authentifizierung, Autorisierung, Kostenabrechnung, Angabe von Zwischenempfängern und allgemeine Routinginformationen der Nachricht enthalten. Der Körper enthält die in XML-Syntax angegebene Nachricht mit den Nutz- und Anwendungsdaten, die gesendet werden soll. Dabei kann der Inhalt des Körpers auf zwei Arten interpretiert werden. Erstens kann der XML-Inhalt des Körpers Dokumentenbasiert (Document/literal) interpretiert werden. Der Inhalt des Körpers wird als Ganzes dem Empfänger übermittelt, der eine Auswertung des Inhalts vornimmt und die Daten ausliest. Zweitens kann der
Körper als Remote Procedure Call (RPC/encoded) interpretiert werden. Dabei wird spezifiziert, ob es
sich bei der SOAP-Nachricht um eine Anfrage, Antwort oder Fehlermeldung handelt. Dabei liegen die
einzelnen Parameter der SOAP-Nachricht kodiert vor.
Optional kann einer SOAP-Nachricht ein Anhang hinzugefügt werden. Sämtliche Daten innerhalb des
Umschlags werden XML-basiert dargestellt. Durch Hinzufügen eines Anhangs können die Daten oder
auch komplette Dateien nicht nur in XML kodiert vorliegen, sondern auch im ursprünglichen binären
Format erhalten bleiben. Die Daten werden im MIME-Format (Multipurpose Internet Mail Extensions) [RFC2045] mit Angabe des Typs im Kopf des Anhangs übertragen [ABB+04].
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
41
2.7 Zusätzliche Technologien
In diesem zweiten Kapitel wurden die wichtigsten Standards erläutert und spezifiziert. Zur Komplettierung und marktreifen Einführung der Web-Service-Architektur müssen noch zusätzliche Technologien herangezogen werden. Im Bereich Sicherheit, Prozess-Fluss, Transaktionskoordination und Routing von Nachrichten gibt es bereits eine große Anzahl von Technologien und Standards, auf die u. a.
Eric Newcomer in seinem Buch „Understanding Web Services“ [New02a] hinweist. Auf die einzelnen
Technologien wird in dieser Arbeit nicht eingegangen, lediglich inhaltlich sollen hier einige offene
Punkte angesprochen werden, wobei keine vollständige Auflistung aller eingesetzter Verfahren durchgeführt wird. Weitere Informationen können aus den Literaturangaben entnommen werden.
Beim Austausch geschäftssensibler Daten muss ein hoher Wert auf Sicherheit gelegt und dementsprechende Technologien eingebettet werden. Da SOAP-Nachrichten zwischen Web-Services primär über
HTTP gesendet werden, passieren sie Firewalls über Port 80 (es kann auch ein anderer Port spezifiziert werden). Somit stellen die übertragenen Daten eine Sicherheitslücke dar, da Angriffe auf lokale
Systeme gestartet werden können. Daher müssen Web-Services um sicherheitsrelevante Protokolle
erweitert werden, damit ein sicherer Betrieb gewährleistet werden kann. Stellvertretend für eine Fülle
von Sicherheitsprotokollen kann HTTP over Secure Socket Layer (HTTP over SSL, auch HTTPS
genannt) zur Authentifikation und Autorisation der Teilnehmer verwendet werden und SOAP über
HTTPS gesendet werden [RFC2818]. Ein weiteres Authentifizierungssystem ist die Security Assertions Markup Language (SAML) von der OASIS Initiative [MPM04]. XML Key Management Specifikation (XKMS) bietet ein Verschlüsselungsverfahren für die gesendeten Daten an [FBF+01].
Ebenso müssen Web-Services in den Geschäfts-Prozess-Fluss (Bussiness Process Flow) automatisch
eingebettet werden. Die Mächtigkeit von Web-Services liegt u. a. in der losen Orchestrierung verschiedener Services, die zusammen eine Aufgabe erfüllen. Zur Einbettung einzelner Web-Services in
den Geschäfts-Fluss kann XLANG von Microsoft [Tha01] oder die Web Service Flow Language
(WSFL) zur Beschreibung von Workflows herangezogen werden [Ley01].
Bei der Zusammenarbeit von Web-Services besteht immer die Möglichkeit, dass einer davon seinen
Dienst nicht erfüllen kann. Bei einem Reise-Reservierungssystem können z. B. verschiedene WebServices für die Reservierung von Hotel, Auto und Flug zuständig sein. Scheitert allerdings der Service zur Flugreservierung, benötigt der Benutzer auch kein Hotel und Auto vor Ort. Aus diesem Grund
sollte ein Transaktionsmanagement für zusammengehörige Web-Services eingeführt werden. Da
HTTP ein unzuverlässiger, nicht Verbindungs-orientierter Transportdienst ist, müssen zusätzliche
Protokolle länger laufende Transaktionen überwachen und managen. Das Business Transaction Protocol (BTP) kann diese Koordinierung in einem gesamten Transaktionskontext bewerkstelligen
[CDF+02].
Schließlich wäre eine zuverlässige Nachrichtenübertragung mit garantierten Übertragungen und zuvor
festgelegten Quality of Service-Aspekten (QoS) wünschenswert. Für die zuverlässige Übertragung
42
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
kann hier das Blocks Extensible Exchange Protocol (BEEP) [RFC3080] oder Reliable HTTP
(HTTPR) [BCC+04] eingesetzt werden.
Im Gegensatz zu den Kerntechnologien (WSDL, SOAP und UDDI) hat sich im Bereich der zusätzlichen Technologien für Web-Services noch kein einheitlicher Standard herauskristallisiert. Aus diesem
Grund kann nach Etablierung einiger Technologien der Protokoll-Stack von Web-Services, der in Abbildung 1 vorgestellt wurde, durch einige der genannten Technologien erweitert werden.
2.8
Zusammenfassung
Nachdem im ersten Kapitel auf Web-Services, deren Entwicklung und neue Rolle in der verteilten,
internetbasierten Softwareentwicklung eingegangen wurde, betrachtet das zweite Kapitel die technische Seite von Web-Services näher. Ein Web-Service ist demnach ein verteiltes Software-System zur
Maschinen-gesteuerten Interaktion über Netzwerke. Ein Web-Service bietet eine XML-basierte
Schnittstellenbeschreibung an, mit der die ausgetauschten Daten und Datentypen festgelegt werden.
Der Datenaustausch kann unabhängig von Plattform, Programmiersprache oder Betriebssystem über
gängige Transport-Protokolle wie z.B. HTTP durchgeführt werden. Jeder Web-Service ist modular
aufgebaut und kann beliebig kombiniert werden mit weiteren Web-Services. Diese Service-orientierte
Architektur bietet eine lose Kopplung von Web-Services je nach anstehendem Problem. Nach dieser
Definition von Web-Services und der Einordnung wurden die grundlegenden Technologien vorgestellt.
Die Markupsprache XML dient als Grundlage sämtlicher Standards, derer sich Web-Services bedienen. Mit Hilfe von XML werden die Daten strukturiert und in wohlgeformten Ausdrücken zur weiteren Verarbeitung bereitgestellt. In der XML Schema Definition Language (XSD) wird das Format der
einzelnen einfachen und komplexen Datentypen näher spezifiziert. Da XSD erweiterbar ist, können
damit beliebige eigene Datentypen spezifiziert werden. Kapitel 4.3 wird darauf nochmals im Detail
Bezug nehmen.
Anschließend wurde WSDL vorgestellt. WSDL beschreibt die Schnittstelle eines Web-Service und
bietet Maschinen als auch Anwendern eine Schnittstelle zu diesem und definiert die Kommunikation
zwischen beiden. Um die Komplexität innerhalb eines WSDL-Dokumentes zu beschränken, die Wiederverwendung zu erhöhen und die Lesbarkeit zu steigern, wurde durch den Import-Mechanismus die
Möglichkeit zur Auslagerung einzelner XSD- und WSDL-Komponenten ermöglicht. Da WSDL als
Ausgangsdokument zur Generierung einer GUI herangezogen wird und somit zentrales Thema dieser
Diplomarbeit ist, greift Kapitel vier nochmals auf WSDL zu.
Schließlich wurden die beiden Technologien SOAP und UDDI vorgestellt, die zusammen mit WSDL
die drei Haupttechnologien in der Web-Service-Architektur bilden. UDDI stellt Strukturen zum Publizieren und Finden von Web-Services bereit. Einerseits beschreibt ein Service-Anbieter seinen Service
in UDDI und kann ihn in einem Service-Verzeichnis veröffentlichen. Anderseits kann ein Service-
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
43
Nutzer über UDDI nach Web-Services suchen. Nachdem ein Web-Service gefunden wurde, muss ein
Datenformat für die auszutauschenden Daten festgelegt werden. SOAP spezifiziert ein solches Datenformat zum XML-basierten Datenaustausch. Im letzten Unterkapitel wurden einige ergänzende Technologien vorgestellt. Um die Architektur von Web-Services zu komplettieren, müssen in den Bereichen Sicherheit, Prozess-Fluss, Transaktionskoordination und Routing von Nachrichten weitere Standards zu den bestehenden hinzugefügt werden.
44
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Kapitel 3: Einordnung der Arbeit
Nachdem im vorigen Kapitel die theoretischen Grundlagen und Technologien der Web-ServiceArchitektur erläutert wurden, werden nun in diesem Kapitel einige Grundlagen zur Realisierung von
Web-Services vorgestellt. Unterkapitel 3.1 stellt das Projekt Axis und dessen Werkzeug WSDL2Java
vor. Das Projekt Axis der Apache Foundation stellt ein Framework zur Generierung von Client- und
Server-Software zur Verfügung. Mit Hilfe des Werkzeugs WSDL2Java, das zur Realisierung des Prototypen verwendet wurde, kann aus einem WSDL-Dokument Java-Code generiert werden. Sun Microsystems bietet ebenfalls ein Werkzeug zur Code-Generierung aus WSDL an. Das Werkzeug wscompile1 wird innerhalb des Web Service Developer Pack (WSDP) angeboten. Daher findet im Unterkapitel
3.2 ein Vergleich zwischen WSDL2Java und wscompile des Web Service Developer Pack von Sun
Microsystems statt. Die Open Source Gemeinschaft Sourceforge.net bietet eine Plattform für Entwickler, die ebenfalls ein Werkzeug namens „wsdlgenerator“ zur automatischen Code-Generierung
entwickeln. Allerdings befindet sich das Projekt noch in der Entwicklung und konnte daher nicht zum
Vergleich herangezogen werden.
Anschließend befasst sich Unterkapitel 3.3 mit den unterschiedlichen Möglichkeiten, einen Client in
einen Web-Service einzubinden. Dieser kann über Stubs, Dynamic Proxy oder Dynamic Invocation
Interface (DII) auf entfernte Methoden eines Web-Service zugreifen. Das JAX-RPC-Package dient
dabei als Grundlage, um entfernte Methoden eines Web-Service auszuführen. Daher wird das JAXRPC-Package ebenfalls vorgestellt.
Nachfolgend wird die neue Technologie Web Service for Remote Portlets (WSRP) von OASIS eingeführt. Mit WSRP können grafische Oberflächen innerhalb von Portalen für Web-Services dargestellt
werden. Diese Technologie hat eine ähnliche Zielsetzung wie diese Diplomarbeit. Daher wird neben
der Vorstellung dieser neuen Technologie ein Vergleich und eine Abgrenzung zur vorliegenden Arbeit
durchgeführt. Schließlich wird im letzten Unterkapitel eine Zusammenfassung dieses Kapitels geliefert.
3.1 Apache Axis und WSDL2Java
Das Apache EXtensible Interacion System (AXIS) der Apache Foundation wurde am 16.Juni 2003 in
der Version 1.1 veröffentlicht. Version 1.2 liegt zurzeit (Dezember 2004) erst als Release Kandidat
vor und wurde nicht in dieser Arbeit verwendet. Axis ist ein Nachfolgeprojekt der Apache SOAPImplementierung, die aus dem IBM Projekt SOAP4J hervorging. Die Open Source-Entwicklung Axis
ist eine SOAP-Engine und stellt ein Framework zur Konstruktion von SOAP-Prozessoren, Clients,
1
Homepage von Sun Microsystems zum Download des WSDP mit wscompile:
http://java.sun.com/webservices/downloads/webservicespack.html
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
45
Servern und Gateways zur Verfügung. Ursprünglich sollte das Framework unter dem Namen Apache
SOAP 3.0 veröffentlicht werden, allerdings stand der Name des SOAP-Protokolls beim W3C noch
nicht fest. Daher entschied man sich für den allgemein gehaltenen Namen Axis. Axis bietet eine APIUnterstützung an, um sowohl die Client- als auch die Serverseite eines Web-Service zu implementieren. In der vorliegenden Arbeit wird allerdings lediglich die Realisierung des Clients untersucht und
die serverseitige Implementierung eines Web-Service außen vorgelassen. Die serverseitige Nutzung
von Axis und die hier vorgestellten Funktionen können auf der Homepage des Projektes unter
http://ws.apache.org/axis/ nachgelesen werden. Axis ist zum einen ein Standalone-Server, kann aber
andererseits auch in bestehende Server integriert werden. AXIS unterstützt SOAP 1.1, teilweise auch
SOAP 1.2, und generiert aus WSDL 1.1 Java-Code und umgekehrt. Mit zwei integrierten Werkzeugen
kann mit JAVA2WSDL aus Java Beans ein WSDL-Dokument generiert werden. WSDL2Java generiert umgekehrt aus WSDL-Dokumenten Java-Klassen.
Zusätzlich bietet das Framework zwei weitere Werkzeuge an: TCPMonitor und SOAPMonitor.
Der TCPMonitor kann in den Kommunikationskanal zwischen Client und Server eingeklinkt werden. Bevor der Client eine Anfrage an den Server sendet, passieren die SOAP-Nachrichten den
TCPMonitor und werden zum Debugging angezeigt. Ebenso können Antworten vom Server zuerst
im TCPMonitor dargestellt werden, bevor der Client sie verarbeitet. Während der TCPMonitor
ständig den Port nach ein- und ausgehenden Nachrichten abhört, wird der SOAPMonitor über einen
speziellen Handler über auftretende SOAP-Nachrichten informiert. Der SOAPMonitor, der als
Applet im Browser läuft, stellt dann ebenfalls die ein- und ausgehenden SOAP-Nachrichten dar. Die
Wirkungsweise eines Handlers in diesem Framework wird im nächsten Abschnitt gesondert beschrieben.
Intern verwendet AXIS einen SAX-Parser zum Parsen eines WSDL-Dokumentes. Beim Parsen von
XML können prinzipiell zwei unterschiedliche Arten von Parsern mit spezifischen Eigenschaften eingesetzt werden. Daher werden die beiden Parserklassen DOM und SAX kurz vorgestellt und voneinander abgegrenzt. Das Document Object Model (DOM) ist ein vom W3C unterstützter Standard
(Recommendation), welcher eine Plattform- und Programmiersprachen-unabhängige Schnittstelle
bereit stellt. Mit dieser Schnittstelle werden Inhalt und Struktur von Baum-strukturierten Dokumenten
(z.B. HTML, XML) extrahiert und modifiziert. Der DOM-Parser hat die Möglichkeit innerhalb des
kompletten Dokumentes zu navigieren und Daten auszulesen oder zu manipulieren. DOM unterstützt
aber kein Eventhandling und hält die Baumstruktur während des Parsens als Objektmodell im Hauptspeicher, was zu Effizienzproblemen führen kann. Zusätzlich kann die Überführung von DOMInterfaces in eine sprachliche Datenstruktur sehr komplex werden. Daher wurde eine einfachere API
entwickelt. Das Simple API for XML (SAX) ist ein Ereignis-orientierter Parser, der mittels Events das
Auftreten von gesuchten Elementen signalisiert. Mit einem SAX-Parser ist nur eine lineare Bearbeitung von Dokumenten möglich. Lediglich das referenzierte Element kann gelesen werden. Der größte
Vorteil gegenüber dem DOM-Parser liegt in seiner besseren Effizienz.
46
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Axis wurde Transport-unabhängig entwickelt und kann unterschiedliche Protokolle, wie z. B. SMTP,
FTP und HTTP zum Senden der SOAP Nachrichten verwenden, die jeweils an das vorliegende Protokoll durch einen SOAP-Sender und SOAP-Listener angepasst werden. Alle Basisdatentypen von XSD
können auf Java-Datentypen abgebildet werden. Außerdem werden komplexe XSD-Daten durch eine
Abbildungsvorschrift (Type Mapping System) auf Java-Klassen abgebildet. Vor dem Senden und dem
Empfang von Nachrichten findet jeweils ein Serialisierungs- und Deserialisierungsprozess statt. Beim
Serialisierungsprozess werden vor dem Senden die Java-Objekte in XML transformiert, beim Empfang in einem Deserialisierungsprozess werden die XML-Elemente auf Java abgebildet. Dadurch
entsteht eine Unabhängigkeit der verwendeten Programmiersprache beim Anwender und WebService-Anbieter. Intern können beim Anwender Java-Objekte zum Speichern der Daten verwendet
werden. Bevor diese Benutzerdaten allerdings zum Web-Service gesendet werden, müssen diese serialisiert vorliegen. Eigene (De-) Serialisierer können implementiert werden, um benutzerdefinierte Abbildungen zwischen Java und XML zu realisieren.
SOAP kann Dokumenten-basierte und RPC-basierte Inhalte im Body führen, daher bietet Axis eine
API-Unterstützung zum Auslesen der Daten beider Inhaltstypen an. Axis implementiert auf der einen
Seite das JAX-RPC-Interface zum entfernten Prozeduraufruf und auf der anderen Seite auch das
SAAJ-Interface1 zum Übertragen von Anhängen (Attachments). Das Mitführen von Anhängen bei
einer SOAP-Nachricht ist allerdings noch fehlerhaft in der Version 1.1 und kann nur eingeschränkt
verwendet werden.
Abschließend wird der Kommunikationsvorgang eines Clients mit einem Web-Service und die Architektur von Axis in Abbildung 10 beschrieben.
Abbildung 10: Client-Architektur der AXIS-Engine [Axis04]
Die Axis-Engine besteht aus einer losen Kopplung von Handlern. Bevor eine Nachricht zu einem
Web-Service gesendet wird, durchläuft diese zuerst intern eine Kollektion von Service-, Global- und
Transporthandlern. Diese Reihenfolge muss aber nicht zwingend eingehalten werden und zudem kön1
SAAJ = SOAP with Attachments API for Java
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
47
nen Handler ausgelassen werden. Ein Handler ist eine wiederverwendbare, modifizierbare Klasse, die
diverse Bearbeitungen mit der SOAP-Nachricht durchführt, bevor die Nachricht letztendlich über ein
Transport-Protokoll gesendet wird. Um die Axis-Engine an eigene Bedürfnisse anzupassen, können in
diese Kette von Handlern weitere eingereiht werden. So kann z. B. ein Authorisationshandler einer
Nachricht Benutzerinformationen hinzufügen, ein Kompressionshandler kann die Daten der Nachricht
vor dem Senden komprimieren oder ein Encryptionhandler kann die Daten verschlüsseln. Ebenso kann
der weiter oben besprochene SOAPMonitor in diese Kette eingereiht werden, um die SOAPNachrichten in einem Applet anzuzeigen. Sämtliche Handler können über Konfigurationsdateien
selbst angepasst werden. Die Axis-Engine übernimmt allerdings automatisch die Konfiguration und
Aneinanderreihung der Handler, somit muss der Anwender nur bei speziellen Anforderungen Änderungen vornehmen.
Bevor der Client eine Anfrage an den Web-Service richten kann, müssen zuvor alle Daten serialisiert
und in eine SOAP-Nachricht verpackt werden. Diese SOAP-Nachricht wird durch einen
MessageContext referenziert. Der MessageContext ist eine Struktur, die Referenzen auf die
Anfrage- und Antwortnachricht
besitzt. Zu
Beginn des
Sendevorgangs
hat
somit
der
MessageContext eine Referenz auf die Antwort, die aber noch keine Inhalte hat. Der Client übergibt den MessageContext samt Anfragenachricht an die Kette von Handlern. In der Abbildung 10
werden die Handler als kleine Zylinder dargestellt und die großen Zylinder präsentieren jeweils eine
Kollektion von mehreren Handlern. Stellvertretend für die Modifikationen, die die einzelnen Handler
durchführen, werden zwei Funktionen nochmals hervorgehoben: Der Servicehandler legt u. a. fest, ob
der SOAP-Inhalt Dokumenten- oder RPC-basiert zu interpretieren ist. Der Transporthandler bestimmt
das zu verwendende Transport-Protokoll. Nachdem der MessageContext durch die Handler modifiziert wurde, leitet der Sender die SOAP-Nachricht an den Web-Service weiter. Erreicht eine Antwort
vom Web-Service die SOAP-Engine, so durchläuft sie in umgekehrter Reihenfolge die einzelnen
Handler, bis sie schließlich die Client-Applikation erreicht und dort zur weiteren Verarbeitung vorliegt.
Nach dieser Einführung in die Architektur von Axis soll nun das Werkzeug WSDL2Java vorgestellt
werden.
WSDL2Java
Das Werkzeug WSDL2Java parst ein WSDL-Dokument und erzeugt Java-Klassen für Server und
Client. Zur Erstellung des Prototypen werden allerdings nur die erzeugten Klassen für den Client benötigt, die in diesem Abschnitt erläutert werden. WSDL2Java kann als Systemprogramm ausgeführt
werden oder über eine Java-API in ein bestehendes Java-Programm integriert werden. WSDL2Java
generiert Stub-Klassen, über die ein Web-Service kontaktiert und Anfragen gestellt werden können.
Zusätzlich werden für komplexe Datentypen eigene Klassen generiert, die zur Speicherung der Einga-
48
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
bedaten des Anwenders verwendet werden. Nachfolgend werden die generierten Klassen beschrieben.
Das zugrunde liegende WSDL-Dokument ist im Anhang (Kapitel 8.4) zu finden.
Für jedes Porttyp-Element wird ein Interface generiert. Der Name leitet sich aus dem Namen des
Port-Elementes ab. Dieses Interface beschreibt für jede Operation eine Methode. Diese Methoden
repräsentieren wiederum die Methoden des Web-Service. Das Interface stellt die Schnittstelle zum
Web-Service da und wird daher auch Service Endpunkt Interface (SEI) genannt. Aus folgendem
WSDL-Fragment wird die Klasse Bib.java generiert:
<wsdl:portType name="Bib">
<wsdl:operation name="SearchBookByTitle">
<wsdl:input message="bookTitleRequest" name="bookTitleRequest"/>
<wsdl:output message="bookTitleResponse" name="bookTitleResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:message name="bookTitleRequest">
<part name="title" type="xsd:string"/>
</wsdl:message>
<wsdl:message name="bookTitleResponse">
<part name="book" type="bibNS:bookEntryData"/>
</wsdl:message>
Abbildung 11: WSDL-Fragment mit Porttyp- und Nachrichten-Element
Die Klasse Bib.java beschreibt die Operation SearchBookByTitle durch folgende Methode:
public BookEntryData searchBookByTitle(String title);
Der Parameter title ergibt sich für diese Methode durch das Part-Element der eingehenden Nachricht. Der Parameter der ausgehenden Nachricht legt den Rückgabewert der Methode fest. Durch
dieses Abbildungsschema werden für alle Operationen die entsprechenden Methoden generiert.
Für jedes Anbindungs-Element wird eine Stub-Klasse generiert. Diese Stub-Klasse implementiert das
Interface. Der Stub wird von der Axis-Engine als Stellvertreter (Proxy) für den Web-Service verwendet. Anfragen an den Web-Service werden an diesen Stub gerichtet, der dann anschließend die Anfrage weiterleitet. Der Name dieser Klasse setzt sich aus dem Namen des Port-Elementes und der Endung SOAPBindingStub.java zusammen, falls das SOAP-Protokoll als Binding verwendet wird.
Ansonsten wird die Endung BindingStub.java ohne Bezeichnung für das verwendete Protokoll
erzeugt. Innerhalb des Stubs wird nach der Übergabe der Parameter eine Serialisierung der Parameter
durchgeführt, falls erforderlich. Erst danach wird die Anfrage durch die Handlerkette der Axis-Engine
geleitet.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
49
Für das Service-Element des WSDL-Dokumentes werden zwei Klassen generiert. Einerseits ein weiteres Interface das seinen Namen aus dem Namen des Service-Elementes ableitet. Das Interface beinhaltet für jeden Port innerhalb des Service-Elementes eine get()-Methode, um den generierten Stub für
den Port zu erhalten und eine get<Portname>Address()-Methode, um die Adresse des Ports als
String zu erhalten. Außerdem wird eine Klasse generiert, die das Interface implementiert. Der Name
dieser Klasse setzt sich aus dem Namen des Service-Elementes und der Endung Locator.java
zusammen. Die Methoden des Interface werden implementiert und für jeden Stub wird eine Instanz
erzeugt. Neben den get()-Methoden für jeden Port liefert die Methode getPorts() eine Kollektion mit allen Ports zurück. Abbildung 12 veranschaulicht nochmals alle generierten Klassen und ihre
Beziehung zueinander.
Service-Interface
liefert
implementiert
Service-Locator
Porttype-Interface
implementiert
erzeugt
Bindingstub
liefert
Abbildung 12: Beziehung zwischen den generierten Klassen von WSDL2Java
Der Service-Locator implementiert das Service-Interface und beinhaltet eine getPort()-Methode
für jeden Port innerhalb des Service-Elementes. Der Service-Locator erzeugt jeweils einen Bindingstub für jeden Port. Dieser Bindingstub implementiert die Porttyp-Schnittstelle (PorttypeInterface) und repräsentiert lokal den entfernten Web-Service. Zusätzlich verfügt der Bindingstub über
alle Methoden, die auf dem Web-Service auszuführen sind. Wenn der Client eine Anfrage an den
Web-Service senden will, so wird die Anfrage an den zugehörigen Bindingstub gestellt, der die Anfrage dann weiterleitet.
Neben diesen Klassen, die aus den Elementen des WSDL-Dokumentes generiert werden, erzeugt
WSDL2Java auch Klassen für die XSD-Datentypen. Die generierten Klassen erhalten den Namen des
komplexen Datentyps und werden in einem Package gespeichert, das sich aus dem Namensraum des
Datentyps ableitet. Diese Namensableitungen werden im sechsten Kapitel nochmals untersucht, da es
hier zu Namenskollisionen mit reservierten Namen in der Programmiersprache Java kommen kann.
Jede Klasse besitzt eine get()- und set()-Methode, um die einzelnen Parameter zu setzen, bzw. zu
erhalten. Zusätzlich beinhalten alle generierten Klassen Methoden, um den spezifischen Serialiser und
Deserialiser zu erhalten, zwei Objekte dieses Typs auf Gleichheit zu testen, den Hashcode zu ermitteln
und eine Methode, um die qualifizierten Namen der Parameter zu erhalten. Diese Methoden werden
allerdings nicht weiter verwendet. Die qualifizierten Namen sind alle bekannt durch das Parsen des
WSDL-Dokumentes und die Serialisierer werden im Prototypen in einer eigenen Klasse bereitgestellt.
50
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Lediglich die get()- und set()-Methoden werden als Speichermedium gebraucht für Benutzereingaben und Antworten vom Web-Service.
Beispiel:
<xsd:complexType name="Author">
<xsd:all>
<xsd:element name="forename" type="xsd:Name"/>
<xsd:element name="name" type="xsd:Name"/>
</xsd:all>
</xsd:complexType>
Aus dem komplexen Datentyp Author wird die Klasse Author.java generiert. Diese Klasse
enthält für jedes Element eine get()- und set()-Methode. Für das Element namens forename
werden die Methoden getForename() und setForename(Name name) bereit gehalten. Im
WSDL-Dokument können einzelne Parameter sowohl als input als auch output deklariert werden.
Solche inout Parameter werden in einer speziellen Holder-Klasse gespeichert. Eine Holder-Klasse
besitzt zusätzlich eine Instanz von sich selbst im Konstruktor. An dieser Stelle werden aber lediglich
Parameter betrachtet, die entweder ein- oder ausgehende Parameter sind.
Abschließend sei vermerkt, dass WSDL2Java nicht alle Funktionalitäten unterstützt, die durch
WSDL 1.1 und XSD möglich wären. Dies mag zum Teil auch daran liegen, dass WSDL 1.1 kein verabschiedeter Standard des W3C ist. WSDL 1.1 wurde als „Note“ publiziert. Unter einem als „Note“
veröffentlichten Dokument des W3C wird ein Dokument bezeichnet, das einen formellen Zustimmungsprozess durchlaufen hat und veröffentlicht wird. Von Seiten des W3C gibt es keine Garantie der
Weiterbearbeitung. Mittlerweile arbeitet eine Arbeitsgruppe an der Version WSDL 2.0, die als „Working Draft“ vorliegt. Hier behält es sich das W3C ebenfalls vor Veränderungen vorzunehmen. Daher
bleibt es abzuwarten bis letztendlich WSDL als verabschiedeter W3C-Standard veröffentlicht wird.
Erst dann können Werkzeuge genau darauf abgestimmt werden. Nicht unterstützte Funktionen werden
im nächsten Kapitel aufgelistet und ein Vergleich mit wscompile von Sun Microsystems durchgeführt.
3.1.1
Vergleich von WSDL2Java mit wscompile von Sun Microsystems
Nachdem nun das Werkzeug WSDL2Java vorgestellt wurde, soll nun ein Vergleich dieses Werkzeugs
mit wscompile des Web Service Developer Pack von Sun Microsystems erfolgen.
Dazu wurden einige Bewertungskriterien erstellt und diese mit beiden Werkzeugen untersucht. Nach
dieser Testreihe wird der Vergleich der beiden Werkzeuge erörtert. In der folgenden Tabelle wurden in
der linken Spalte einige Bewertungskriterien aufgelistet und daneben die beiden Werkzeuge. In der
anschließenden Bewertung werden die wichtigsten Punkte nochmals aufgegriffen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Bewertungskriterien
Einfache Datentyp-Abbildung
WSDL2Java
51
wscompile
Unterstützt alle 44 XSD-
Nicht alle XSD-Datentypen
Datentypen
werden unterstützt, Abbildung
auf Strings bei Nichtunterstützung (z.B.: gDay)
Komplexe DatentypUnterstützung:
-einfaches Feld (Array)
-doppeltes Feld
-Fassetten innerhalb von Fel-
nein
nein
-Listen
nein
nein
Fassetten innerhalb von <simp-
Nein, generiert Klasse, aber
Nein, bricht mit einer Fehler-
leType>
ohne get()-Methoden
meldung ab
- Pattern (spezielle Fassette)
Nein, generiert separate Klasse
Nein, Pattern wird als Stringpa-
für Patternparameter
rameter deklariert
dern
- Aufzählung (Enumeration)
Generierte Klassen für Datentyp Eine Klasse pro Datentyp
2 oder 3 Klassen pro Datentyp,
für jeden Datentyp eine Klasse
mit Serialisierer
Generierte Klassen für WSDL-
Stub mit Serialisierer, Service-
Stub und für jede Nachricht
Elemente
Locator (siehe oben)
(input und output) eine Klasse
API
Eigene API vorhanden,
Keine API vorhanden, wscom-
WSDL2Java kann in Java inte-
pile wird als System-Programm
griert werden oder als System-
gestartet
Programm gestartet werden.
Kompositor1
-all
-choice
Nein, generiert aber Klasse mit
Nein, bricht Parsen ab
allen get()- und set()-Methoden
-sequence
Holderklassen
Abbildung 13: tabellarischer Vergleich von WSDL2Java und wscompile
1
Wird erst im Kapitel 4.4 eingeführt
52
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Beim Vergleich der beiden Werkzeuge fällt auf, dass beide nicht alle Bewertungskriterien erfüllen
konnten.
Das Werkzeug wscompile unterstützt nicht alle Datentypen. Erkennt das Werkzeug einen Datentyp
nicht, so wird dieser auf einen String abgebildet. WSDL2Java hingegen kann alle Datentypen erkennen und bildet sie auf einen Java-Datentyp ab. WSDL2Java verfeinert sogar noch XSD-Datentypen,
indem diese je nach den Binding-Informationen auf unterschiedliche Datentypen abgebildet werden.
Der binäre Datentyp base64Binary könnte einfach auf ein byte[] abgebildet werden. Es findet
aber eine Unterscheidung statt, welche Inhalte der binäre Datentyp repräsentiert. Wird ein Bild gespeichert, so wird base64Binary auf Image abgebildet, bei einer einfachen Textdatei auf String
(genauere Betrachtung im fünften Kapitel). Ein weiterer Vorteil von WSDL2Java ist die Möglichkeit
das Werkzeug über eine Java-API direkt in das Programm zu integrieren und von dort auszuführen.
Ein Vorteil von wscompile mag sein, dass für jede ein- und ausgehende Nachricht eine eigene Klasse
generiert wird. Dies könnte für manche Entwickler einen Vorteil bringen oder für gewisse Problemstellungen, wenn für sämtliche Nachrichten eine Klasse vorliegt. Für einfache Datentypen, die sich
nicht innerhalb eines komplexen Datentyps befinden, bietet WSDL2Java keine Klassen zum Speichern
an. Hier muss der Anwendungsentwickler selbst die Speicherung der Daten vornehmen. Wscompile
hingegen bietet die Möglichkeit, alle Datentypen in diesen Klassen zu speichern in Korrelation mit der
Nachricht. Für den Prototypen wurden allerdings separat für jeden einfachen Datentyp Klassen entwickelt mit grafischen Komponenten, so dass generierte Klassen überflüssig werden.
Allerdings zeigt sich bei dem Werkzeug wscompile ein gravierender Nachteil. Bei einigen Kriterien
bricht das Werkzeug mit einer Fehlermeldung ab und beendet nicht nur das Parsen des WSDLDokumentes, sondern es werden auch keine Klassen erzeugt. Innerhalb eines <simpleType> -Tag
können Fassetten zu dem zugrunde liegenden Datentyp spezifiziert werden. WSDL2Java kann ebenfalls die Fassetten nicht erfassen und in der generierten Klasse verarbeiten. Allerdings bricht
WSDL2Java nicht ab und erzeugt dennoch eine Klasse, die um die Funktionalität ergänzt werden
muss, aber durchaus verwendet werden kann.
Der letzte angeführte Punkt ist ausschlaggebend zur Bevorzugung von WSDL2Java gegenüber
wscompile. Die wichtigste Funktionalität des Prototypen ist die generische Erstellung einer GUI aus
einem WSDL-Dokument, welches vor der Laufzeit nicht bekannt ist und eine beliebige Komplexität
aufweisen kann. Der Prototyp muss also davon ausgehen, dass das Werkzeug immer das Parsen erfolgreich beendet, damit es auf die Klassen zugreifen kann. Wscompile scheidet daher für die Verwendung für diesen Prototyp aus, weil es das Parsen nicht immer erfolgreich beendet. WSDL2Java
zeigt zwar auch einige Schwachstellen auf, ist aber insgesamt gesehen besser geeignet und ausfallsicherer.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
53
3.2 Binding des Clients
Nachfolgend werden drei unterschiedliche Arten beschrieben, wie ein Client an einen Web-Service
gebunden wird. Der Client kann über Stubs, Dynamic Proxy oder das so genannte Dynamic Invocation
Interface (DII) an einen bestehenden Web-Service gebunden werden und dessen entfernte Methoden
aufrufen. Axis verwendet dazu das JAX-RPC-Package und erweitert dieses. Das JAX-RPC-Package
ist eine „Java API for XML based Remote Procedure Calls“. Diese von Sun Microsystems veröffentlichte Programmierschnittstelle spezifiziert eine Java-API zum Ausführen von entfernten Methoden.
Ein RPC simuliert lokal einen entfernten Prozeduraufruf über ein Netzwerk und ermöglicht das Ausführen einer Methode auf einem entfernten Rechner. Diese Programmierschnittstelle kann somit zur
Entwicklung von Web-Services und Anwender-Applikationen verwendet werden. Der Datenaustausch
zwischen beiden Parteien erfolgt über SOAP. Interne Daten müssen vor dem Sendevorgang nach
XML serialisiert und nach dem Empfang wieder deserialisiert werden. Durch den Serialisierungsprozess können Anwender und Web-Service-Anbieter unterschiedliche Plattformen und Programmiersprachen verwenden. JAX-RPC verbirgt die Komplexität der Datentypabbildung für den Anwender
und führt diese intern durch.
Neben dem JAX-RPC-Package verwendet Axis ebenfalls SOAP with Attachments API for Java
(SAAJ), um SOAP-Nachrichten mit Anhängen zu senden. SAAJ beschreibt auf einer niedrigeren,
weniger abstrakten Ebene als JAX-RPC den Aufbau einer SOAP-Nachricht. Somit kann mit dieser
API eine SOAP-Nachricht modelliert und Anhänge hinzugefügt werden.
Im Anschluss werden nun die drei verschiedenen Arten des Bindings eines Clients in Anlehnung an
das Java™ Web Services Developer Pack [OMM02] und The J2EE™ 1.4 Tutorial [ABB+04] vorgestellt und jeweils an dem Beispiel des Taschenrechner-Web-Service veranschaulicht.
Stubs:
Ein Stub ist so angelegt, dass der entfernte Methodenaufruf vereinfachend wie ein lokaler Methodenaufruf ausgeführt wird. Der Stub repräsentiert dabei das entfernte Objekt lokal auf dem Rechner, und
der Client führt seine Methodenaufrufe auf dem Stub aus. Der Stub nimmt den Methodenaufruf entgegen und führt eine Serialisierung (auch Marshalling genannt) durch und leitet so den Aufruf an den
Server weiter. Durch den Marshalling-Prozess wird der Methodenaufruf durch den Stub in das richtige
Format umgewandelt und an den Server weitergeleitet. Es findet eine Typüberprüfung der Parameter
statt, bevor der Methodenaufruf an den Server geschickt wird. Serverseitig nimmt eine so genannte
Tie-Klasse (in diversen Quellen auch Skeleton genannt) den Methodenaufruf entgegen. Die Tie-Klasse
wandelt die empfangene Nachricht in das verwendete Format, um (auch Unmarshalling genannt) und
führt den Methodenaufruf aus. In einem umgekehrten Prozess werden dann alle Daten zurück an den
Client gesendet.
54
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Wird ein Stub verwendet, so muss im Voraus bekannt sein, welche Parameter der Methodenaufruf
benötigt, der Name der Methode und des Ports. Diese Informationen werden benötigt, um den Code zu
schreiben. Liegen allerdings diese Informationen erst zur Laufzeit vor, so kann diese Art einen Client
einzubinden nicht verwendet werden. Abbildung 14 veranschaulicht das Einbinden des Clients mit
einem Stub. Der Service-Locator (service) und der Bindingstub (cal) sind generierte Klassen von
WSDL2Java, die in Kapitel 3.1 allgemein vorgestellt wurden.
01:
02:
03:
public class StubClient{
public static void main(String [] args) {
try {
04:
CalculatorService service = new CalculatorServiceLocator();
05:
Calculator cal = service.getCalculator();
06:
int result = cal.add(5, 3);
07:
08:
System.out.println(“result of 5+3: “+result;
} catch (Exception e) {…}
Abbildung 14: Code des Stub-Client
In Zeile 4 wird zunächst eine Instanz des Service-Locators erzeugt. Der Service-Locator implementiert
das Service-Interface und dessen getPort()-Methoden. Diese Instanz besitzt also für jeden Port des
Services eine get()-Methode, die den gewünschten Stub des vorliegenden Ports liefert. In Zeile 5
wird die Methode getCalculator() aufgerufen, die nun den lokalen Stub zum Einbinden des
Clients liefert. Da der Name des Ports bekannt ist, kann direkt getCalculator() aufgerufen werden, anstatt sich mit getPorts() erst alle Ports liefern zu lassen, um dann über Namensvergleiche
den richtigen Port zu finden. Auf diesem Stub kann man nun die beiden Methoden add() und
subtract() des Web-Service aufrufen. In diesem Beispiel wurde in Zeile 6 die Methode add()
ausgeführt mit den beiden Ganzzahlwerten 5 und 3. Nach Aufruf dieser Stubmethode findet ein Marshalling-Prozess statt und das Weiterleiten der Daten an den Server. Der Server bearbeitet diesen Aufruf und schickt das Ergebnis zurück zum Stub. In Zeile 7 kann nach Erhalt des Ergebnisses dieses
ausgegeben werden.
Dynamic-Proxy:
Eine Dynamic-Proxy-Klasse benötigt keine erzeugten Stubs, sondern lediglich das Service-EndpunktInterfaces (SEI), das von WSDL2Java generiert wird. Bei der Entwicklung des Anwender-Programms
muss also der benutzte Web-Service, die verwendete Methode mit Parametern und dessen ServiceInterface bekannt sein. Der Name des Ports muss hingegen bei der Erstellung des Codes nicht bekannt
sein. Diese Informationen können zur Laufzeit aus dem WSDL-Dokument extrahiert werden. Die
Proxy-Klasse erzeugt einen dynamischen Proxy zur Laufzeit durch die Methode getPort() des
SEI. Das JAX-RPC-Package enthält die abstrakte Klasse ServiceFactory. Mit dieser Klasse kann
man durch die Methode createService() ein neues Service-Objekt erzeugen. Die
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
55
ServiceFactory benötigt lediglich die URL des WSDL-Dokumentes und den Servicenamen. Das
erzeugte Service-Objekt bietet eine Schnittstelle auf den dahinter liegenden entfernten Web-Service.
Zum Aufruf einer Operation des Services wird die dynamisch erzeugte Proxy-Klasse verwendet. Abbildung 15 zeigt einen Ausschnitt aus dem Dynamic-Proxy-Client-Programm des TaschenrechnerWeb-Service1.
01:
import javax.xml.namespace.QName;
02:
import javax.xml.rpc.*;
03:
public class DynamicProxyClient {
04:
public static void main(String [] args) {
05:
try {
06:
String wsdlUrl = "http://www.icsy.de/Calculator.wsdl";
07:
String nameSpaceUri = "http://www.icsy.de/Cal";
08:
String serviceName = "CalculatorService";
09:
String portName = "Add";
10:
ServiceFactory serviceFactory = ServiceFactory.newInstance();
11:
Service service = serviceFactory.createService(new
java.net.URL(wsdlUrl),new QName(nameSpaceUri, serviceName));
12:
CalculatorServiceIntf proxy = (CalculatorServiceIntf)
service.getPort(new QName(nameSpaceUri, portName),
CalculatorServiceIntf.class);
13:
System.out.println(“result= " + proxy.add(5, 3));
14:
} catch (Exception e) {…}
Abbildung 15: Code des Dynamic-Proxy-Client
In Zeile 6 bis 9 wurden zum besseren Verständnis des Programms einzelne Variablen mit Werten aus
dem WSDL-Dokument deklariert. Diese Werte könnten auch erst zur Laufzeit feststehen und dann
direkt an die entsprechenden Methoden geleitet werden. Zunächst wird in Zeile 10 eine neue Instanz
einer ServiceFactory erzeugt. Diese Factory erzeugt dynamisch in der nächsten Zeile einen
Service (javax.xml.rpc.Service) durch Übergabe der URL des WSDL-Dokumentes und dem qualifizierten Namen des Web-Service. In Zeile 12 wird schließlich der Dynamic-Proxy(proxy) durch
die getPort()-Methode des Service erzeugt. Diese Methode benötigt als Parameter den Portnamen
und das Service-Interface. Die von WSDL2Java erzeugte Klasse wird hier übergeben. Der DynamicProxy wird erzeugt und stellt den implementierten Service lokal dar. Auf diesem Proxy können nun
die einzelnen Operationen, die der Service zur Verfügung stellt, ausgeführt werden. In dem Beispiel
wird in Zeile 13 die Operation add() durch Übergabe zweier Ganzzahlwerte ausgeführt und das Ergebnis dargestellt.
1
Zur übersichtlicheren Darstellung wurden einige Namen gekürzt, das zugrunde liegende WSDL-Dokument im
Anhang enthält die kompletten Namensangaben
56
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Dynamic Invocation Interface:
Das Dynamic Invocation Interface (DII) bietet die Möglichkeit entfernte Methoden eines Web-Service
auszuführen, ohne dessen Namen und Adresse bei der Erstellung des Anwenderprogramms zu kennen.
Zur Erstellung des Programm-Codes werden keine Informationen über den Web-Service benötigt. Zur
Laufzeit werden lediglich Informationen über die URL des Web-Service, den Portnamen, den Namensraum des Services, den Operationsnamen und die Parameter erforderlich. Diese Informationen
sind alle im WSDL-Dokument enthalten und können vor dem Ausführen des Aufrufs extrahiert werden. Durch die dynamische Übergabe der Parameter zur Laufzeit kann allerdings keine Typüberprüfung durchgeführt werden. Diese Überprüfung muss im Vergleich mit den Parameterangaben innerhalb des WSDL-Dokumentes geschehen. Der entfernte Methodenaufruf wird über ein Call-Objekt
(javax.xml.rpc.Call) ausgeführt. Das Service-Objekt erzeugt mit der Methode createCall() ein
Call-Objekt, das eine speicherinterne Repräsentation des WSDL-Dokumentes bereit hält und den
Web-Service beschreibt. Das Call-Objekt besitzt mehrere get()- und set()-Methoden zum
Setzen der Operationsnamen, Eingabeparameter, Rückgabeparameter, Rückgabetyp, ServiceEndpunkt-Adresse und Porttyp. Zwei der vier vorgestellten Transmissions-Primitiven von WSDL
werden vom Call-Objekt unterstützt (siehe Kapitel 2.4). Ein synchroner Request-Response kann
über die Methode invoke(Object[])durchgeführt werden. Der Client sendet eine Anfrage an den
Web-Service und wartet auf dessen Antwort. Neben der Möglichkeit eines Request-Response kann
über das Call-Objekt eine One-Way-Nachricht gesendet werden durch Aufruf der Methode
invokeOneWay(Object[]). Bei dieser Transmissions-Primitive sendet der Client eine Nachricht
an den Server ohne eine Rückmeldung zu erhalten. Nach dem Absenden ist der Client nicht blockiert,
da er auf keine Antwort wartet, und kann im Programmfluss weiterfahren.
In einem Objektfeld(Object[]) werden dem Call-Objekt alle Parameter der Operation übergeben. Wie bereits im vorigen Unterkapitel erwähnt, wird für jeden komplexen Datentyp durch das
Werkzeug WSDL2Java eine eigene Klasse generiert. Jede Java-Klasse Class erbt von Object.
Somit können alle Parameter über ein Object[]dem Call-Objekt übermittelt werden (alle einfachen Datentypen werden ebenso durch eine Klasse präsentiert, die von Objekt erbt).
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
57
Abbildung 16 zeigt für das Taschenrechner-Beispiel einen DII-Client.
01:
import javax.xml.rpc.Call;
02:
import javax.xml.rpc.Service;
03:
import javax.xml.namespace.QName;
04:
public class AddClient {
05:
06:
public static void main(String [] args) {
try {
07:
ServiceFactory factory = ServiceFactory.newInstance();
08:
Service service = factory.createService(newQName(service));
09:
Call call = (Call) service.createCall();
10:
call.setOperationName(new QName(namespace, operation));
11:
call.setTargetEndpointAddress(new URL(endpoint) );
12:
Integer ret= (Integer)call.invoke(new Object[]{op1,op2});
13:
14:
System.out.println(“result = " + ret);
} catch (Exception e) {… }
Abbildung 16: Code des DII-Client
Die Werte für alle unterstrichenen Parameter entstammen dem WSDL-Dokument und werden erst zur
Laufzeit festgelegt. Zunächst wird in Zeile 7 eine neue Instanz der ServiceFactory erzeugt. Mit
dieser Instanz wird ein Service-Objekt generiert mit dem qualifizierten Namen des Web-Service.
Auf dem Service-Objekt kann dann in Zeile 9 mit der Methode createCall() ein CallObjekt zum vorliegenden Service gebildet werden. Auf dem Call-Objekt werden einige der oben
genannten set()-Methoden ausgeführt. In Zeile 10 wird der Operationsname gesetzt und in Zeile 11
wird die Adresse des Web-Service benannt. Danach kann auf dem Call-Objekt das Object[] mit
den Parametern übergeben werden. In diesem Fall werden die beiden Ganzzahlwerte übergeben. Es
wird ein Request-Response-Aufruf durchgeführt und das Programm unterbricht, bis es die Antwort
vom Server erhalten hat. Danach findet in Zeile 12 ein Cast des Rückgabewertes statt, um das Ergebnis in der nächsten Zeile auszugeben.
3.3 Related Work: WSRP von OASIS
Web Service for Remote Portlets (WSRP) ist seit August 2003 in der Version 1.1 ein Standard von
OASIS. Der Standard geht u. a. aus der Zusammenlegung zweier weiterer Standards hervor, die sich
mit einer ähnlichen Problemstellung beschäftigten. Zum einen die Web Services Experience Language
(WSXL) von IBM [DLW02] und zum anderen dem Web Service User Interface (WSUI) [ACM01].
In Anlehnung an das Whitepaper von OASIS [DFLS02] und deren Spezifikation [KLT03] wird dieser
neue Standard vorgestellt und anschließend von der Herangehensweise in dieser Diplomarbeit abgegrenzt. Zur grafischen Darstellung eines Web-Service in Portalen musste man bisher für jeden WebService eine eigene GUI entwickeln. Oft war zusätzlich die Entwicklung mehrerer GUI-Versionen für
unterschiedliche Portalhersteller von nöten. In der bisherigen Entwicklung von Web-Services themati-
58
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
sieren die Technologien und Standards hauptsächlich die Darstellung der Daten, Datenstrukturen und
Austauschformate. Für eine grafische Darstellung der Daten gibt es noch keine Standardisierung. In
Abbildung 17 wird dieser Aspekt verdeutlicht. In diesem Beispiel wird der Ausdruck „Datenorientierter Web-Service“ verwendet. Dabei handelt es sich um herkömmliche Web-Services, die auch
in dieser Arbeit als Grundlage dienen. Durch Hervorhebung der Datenorientierung wird verdeutlicht,
dass bei diesen Web-Services die Daten und nicht die Präsentation im Vordergrund stehen.
Abbildung 17: Daten-orientierter Web-Service [DFLS02]
In der Abbildung wird anhand zweier Web-Services (Aktienkurs- und Wetterdienst-Web-Service)
dargelegt, dass für jeden Web-Service zur grafischen Darstellung eine eigene GUI erzeugt werden
muss. Mit steigender Anzahl von einzubindenden Web-Services steigt natürlich auch proportional der
Programmieraufwand zur Erstellung der GUI. Dieses Problem der Portal-Betreiber soll durch den
WSRP-Standard gelöst werden. Durch WSRP werden Web-Services durch ein Benutzerinterface erweitert, welches der Anbieter entwickelt und zur Verfügung stellt. In Abbildung 18 wird diese Erweiterung grafisch veranschaulicht.
Abbildung 18: WSRP-Erweiterung für Web-Services [DFLS02]
Der Entwickler eines Web-Service erstellt nach dieser Spezifikation neben dem eigentlichen Service
noch GUI-Informationen. Diese GUI ist aus parametrisierten Markup-Fragmenten aufgebaut, die in
eine generische GUI innerhalb eines Portals eingebettet wird. Die GUI des Portals benutzt die
Markup-Fragmente des Web-Service, um dessen Elemente grafisch darzustellen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
59
Das Hauptziel von WSRP ist es also, statt der Entwicklung von Daten-orientierten, klassischen WebServices zu Präsentations-orientierten Web-Services zu wechseln. Diese können leichter in bestehende
Portale integriert werden. Auf der einen Seite entsteht durch diesen neuen Standard eine Arbeitserleichterung für Portalentwickler, die lediglich neue Services integrieren müssen, statt eine komplette
GUI zu entwickeln. Zusätzlich kann der Web-Service-Anbieter seine eigene GUI entwickeln und so
gezielt Schwerpunkte setzen oder Editierhilfen anbieten. Der Anbieter kann alle Komponenten nach
Belieben auf der Seite platzieren und dadurch eine strukturierte Oberfläche entwickeln. Aus marktwirtschaftlicher Sicht bietet sich der weitere Vorteil, eigene oder externe Werbung einzubauen,
wodurch neue Einnahmequellen entstehen.
Auf der anderen Seite entsteht für Web-Service-Anbieter mehr Programmieraufwand. Hauptsächlich
müssen Updates für alte Web-Services vorgenommen werden, um sie konform mit dem neuen Standard zu halten. Es besteht die Gefahr, dass dadurch eine der wichtigsten Eigenschaften von WebServices verloren geht, nämlich deren Interoperabilität zwischen diversen Web-Services. Nicht nach
diesem neuen Standard entwickelte Web-Services können dadurch nicht mehr in Portale integriert
werden, was die Komposition mehrerer Web-Services einschränkt. Die Einführung soll erst in ein paar
Jahren erfolgen, was zur Folge hat, dass bis dahin die Menge an Web-Services weiter gestiegen ist
und evtl. neue Standards zwischenzeitlich entstehen.
Der Hauptunterschied zur vorliegenden Diplomarbeit besteht in der Erweiterung der Web-ServiceStandards. Bei der Lösung mit WSRP muss sich dieser Standard erst etablieren bzw. davor erst fertig
spezifiziert werden. Außerdem stellt der Standard einen erheblichen Mehraufwand bei der Entwicklung von Web-Services dar und beschränkt sich zurzeit auf die grafische Darstellung in Portalen. Der
Ansatz zur grafischen Darstellung von Web-Services in dieser Arbeit verwendet nur existierende,
etablierte Standards. Schnittstellen eines Web-Service werden in WSDL spezifiziert, um den genauen
Datenaustausch und Datentypen festzulegen. Daher liegt es nahe, dieses ohnehin schon vorhandene
Dokument zur grafischen Präsentation von Web-Services heranzuziehen. Das WSDL-Dokument beinhaltet alle Daten, die der Anwender mit dem Web-Service-Anbieter austauscht und zusätzlich auch das
Format der Datentypen. Da WSDL auf XML aufbaut, kann somit das WSDL-Dokument geparst werden, um so generisch eine GUI aufzubauen. Neben der generisch erstellten Präsentation, beinhaltet das
WSDL-Dokument sämtliche in XSD angegebene Validierungsangaben zu den einzelnen Datentypen.
Bei WSRP soll die Validierung möglichst Anwender-nah durchgeführt werden durch Verwendung
von XForms im Browser. XForms sind XML-basierte Eingabefelder, die die Funktionalität von
HTML-Formularen erweitern. Bei der Generierung der GUI direkt aus dem WSDL-Dokument kann
die Validierung direkt eingebettet werden und erspart dem Anwender die Benutzung von XForms, die
zurzeit ohnehin nicht von jedem Browser unterstützt werden.
60
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
3.4 Zusammenfassung
Das dritte Kapitel beschäftigt sich mit der praktischen Einbettung eines Clients und den benutzten
Werkzeugen dazu. Das Framework Axis der Apache Foundation bietet mit WSDL2Java ein Werkzeug
an zum Generieren von Java-Code aus einem WSDL-Dokument. Besonders von Interesse für die Erstellung des Prototypen ist die Generierung von Java-Klassen für komplexe Datentypen. Diese Klassen werden als Objekte zum Speichern der Daten während des Editiervorgangs verwendet. Die Daten
werden vor dem Senden einer Anfrage aus den Klassen ausgelesen und in XML serialisiert, damit sie
innerhalb einer SOAP-Nachricht an den Web-Service gesendet werden können.
Anschließend wurden die beiden Werkzeuge WSDL2Java und wscompile des WSDP verglichen.
Durch eine Reihe von praktisch durchgeführten Tests konnte der Vorteil von WSDL2Java gegenüber
wscompile aufgezeigt werden. Das Werkzeug wscompile bricht bei einigen XSD-Elementen mit einer
Fehlermeldung ab und kann deswegen nicht verwendet werden. Daraus resultiert die Entscheidung für
WSDL2Java beim Entwurf für den Prototypen. Danach wurde das JAX-RPC-Package vorgestellt.
Diese Java-API dient als Grundlage zum Aufruf einer entfernten Methode eines Web-Service. Die
unterschiedlichen Arten zum Einbinden eines Clients wurden nochfolgend aufgeführt. Das Kapitel
Realisierung greift diesen Aspekt nochmals auf und zeigt die Umsetzung innerhalb des Prototypen.
WSRP von OASIS widmet sich einem ähnlichen Themengebiet wie diese Diplomarbeit. Mit WSRP
soll Web-Service-Anbietern die Möglichkeit gegeben werden eine GUI für ihren Web-Service zu entwickeln Diese GUI wird dann innerhalb von Portalen generisch zur Anzeige des Web-Service verwendet. Für die Portalentwicklung stellt dieser neue Standard eine große Vereinfachung dar, da man
lediglich ein Framework anbietet und grafische Oberflächen können dynamisch eingebettet werden.
Allerdings entsteht ein großer Programmieraufwand, da für jeden bestehenden Web-Service erst einmal diese GUI-Elemente entworfen werden müssen. Daher grenzt sich dieser neue Standard von der
Vorangehensweise in dieser Diplomarbeit ab. Beim Ansatz in dieser Diplomarbeit werden keine neuen
Technologien herangezogen, um eine GUI für einen Web-Service generisch zu erzeugen. Lediglich
WSDL dient als Informationsquelle zu Generieren der GUI.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
61
Kapitel 4: Modellbildung
In diesem Kapitel wird das Modell eines Frameworks zum generischen Aufbau einer grafischen Oberfläche aus einem WSDL-Dokument schrittweise entwickelt und vorgestellt. Zunächst wird das Gesamtsystem beschrieben, bevor danach der Entwurf verfeinert wird und auf einzelne Details des Modells eingegangen wird. Die Entscheidung für ein solches Top Down-Verfahren zur Entwicklung des
Modells wurde aufgrund der Problemstellung und der daraus resultierenden komplexen Detailanforderungen abgeleitet. Aus einem WSDL-Dokument mit enthaltenen XSD-Datentypen soll generisch eine
GUI aufgebaut werden. Der Aufbau und die Verteilung der Komponenten hängt somit von der Gestaltung des WSDL-Dokumentes und von den in XSD spezifizierten Datentypen ab, wobei die Komplexität nicht eingeschränkt werden kann. Das Modell und der daraus resultierende Prototyp sollen für alle
WSDL-Dokumente eine einheitliche GUI aufbauen. Diese soll komfortabel zu bedienen sein und trotz
nicht bekannter Komplexität immer einen gleichen strukturellen Aufbau haben. Daher sollen zuerst
grundlegende Anforderungen an das Modell der GUI festgelegt werden, bevor in einem weiteren Verfeinerungsschritt Details zur Gesamtlösung hinzugenommen werden.
Zunächst wird eine Beschreibung des Gesamtsystems des zu entwickelnden Frameworks herausgearbeitet. In mehreren Anwendungsfällen (UML Use Cases) wird die Schnittstelle zwischen Anwender
und Gesamtsystem definiert. Danach folgt eine Vorstellung der grafischen Elemente, die in diesem
Modell verwendet werden. Parallel dazu werden die verschiedenen Möglichkeiten zur Validierung von
Benutzereingaben vorgestellt.
Nach der Beschreibung des Frameworks folgt im Unterkapitel 4.2 in Form eines Anfragekatalogs eine
Festlegung diverser Anforderungen, die das Modell berücksichtigen soll. Nach Zusammenstellung der
wichtigsten Anforderungen wird der allgemeine Aufbau der GUI festgelegt. Dazu findet eine Analyse
der WSDL-Komponenten statt. Diese Komponenten legen den Gesamtaufbau der grafischen Oberfläche fest und strukturieren diese. Danach wird eine detailliertere Sicht der GUI durch Beschreibung der
XSD-Datentypen und deren spätere Darstellung vorgenommen. Unterkapitel 4.4 beschäftigt sich mit
semantischen Aspekten, die bei der Erstellung der GUI berücksichtigt werden müssen. Die abschließende Zusammenfassung stellt nochmals die wichtigsten Arbeitsschritte zur Entwicklung des Modells
dar.
4.1 Beschreibung des Frameworks
Durch Anwendungsfälle wird die Benutzung des Systems durch den Anwender veranschaulicht. In
den Anwendungsfällen wird die Schnittstelle zwischen dem Anwender und dem Modell spezifiziert.
Nach dieser ersten Beschreibung des Systems folgt eine Einführung möglicher grafischer Elemente
zum Aufbau der GUI. Parallel dazu wird das Modell zur Validierung der Benutzereingaben entwi-
62
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
ckelt. Es wird heraus gearbeitet, wie die Auswahl der grafischen Elemente die Validierungsmöglichkeiten beeinflusst.
4.1.1
Anwendungsfälle
Abbildung 19 veranschaulicht die wichtigsten Interaktionen eines Anwenders mit dem Web-ServiceFramework und zeigt fünf Anwendungsfälle zwischen System und Anwender. Durch die einzelnen
Anwendungsfälle wird die Funktionalität des Gesamtsystems festgelegt. Die Anwendungsfälle sind
chronologisch geordnet und beschreiben das Interaktionsverhalten des Systems nach dem Start bis
zum Empfang einer Antwort durch einen angesprochenen Web-Service.
WebServiceFramework
setWSDL
createService
showServiceGUI
«verwendet»
Parser
selectOperation
«verwendet»
showEditorGUI
DatatypeAlternative
createEditor
«verwendet»
reutilisation
takeDatatype
edit
Anwender
status
validate
send
«verwendet»
showResult
sendWebService
Axis
getHelp
showHelp
help
Abbildung 19: UML-Anwendungsfälle zwischen Anwender und Gesamtsystem
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
63
createService
Die erste Schnittstelle eines Anwenders mit dem Gesamtsystem besteht im Übermitteln einer WSDLURL. In einem Eingabefenster wird der Anwender aufgefordert die Netzwerkadresse in Form einer
Zeichenkette (String) zu übergeben mit setWSDL. Das System nimmt die Eingabe entgegen und
startet das Parsen des WSDL-Dokumentes unter Verwendung eines internen Anwendungsfalls
Parser. Existiert das WSDL-Dokument unter angegebener URL, so werden alle relevanten Informationen des WSDL-Dokumentes zur Darstellung aller Web-Services und deren Operationen innerhalb
des Parsers extrahiert. In diesem Anwendungsfall werden noch keine Details über einzelne Parameter innerhalb von Operationen extrahiert. Lediglich eine komplette Auswahl aller Web-Services mit
allen Operationen innerhalb dieses WSDL-Dokumentes werden erstellt. Der Parser liefert die aufbereiteten Informationen zurück und innerhalb des Anwendungsfalls createService wird die
GUI zum Anzeigen der enthalten Web-Services und ihren Operationen generiert. Durch die Assoziation showServiceGUI wird dem Anwender die GUI zur weiteren Interaktion angezeigt.
createEditor
Der Anwendungsfall createEditor lässt sich nochmals in zwei Anwendungsszenarien unterteilen,
die chronologisch aufeinander aufbauen. Der Anwender kann im ersten Schritt unter den aufgeführten
Web-Services mit ihren Operationen eine Operation zur Nutzung aussuchen. Seine Auswahl teilt er
mit selectOperation dem System mit. Anschließend werden alle Parameter dieser Operation
durch ihre grafischen Komponenten in einer Eingabemaske untereinander aufgereiht. Befindet sich
unter den Parametern ein komplexer Datentyp, so ermittelt der Parser in einem weiteren Arbeitsschritt den Aufbau und zerlegt den komplexen Datentyp in seine elementaren Datentypen oder Listendatentypen (siehe Kapitel 4.3). Dieser Vorgang kann bei verschachtelten komplexen Datentypen
mehrmals durchgeführt werden, bis alle Datentypen durch eine grafische Komponente dargestellt werden können. Übersteigt die Anzahl der Komponenten den sichtbaren Bereich der GUI, so werden die
Elemente in mehreren Ebenen angeordnet. Über Navigationshilfen können diese jeweils ebenenweise
auf dem Bildschirm sichtbar angezeigt werden. Nach der Aufbereitung aller Parameter wird durch
showEditorGUI dem Anwender die komplette Eingabemaske präsentiert.
Im zweiten Anwendungsszenarium kann zum anderen nach Anzeige der Eingabemaske ausgewählt
werden, ob früher getätigte Eingaben wieder verwendet werden sollen. Diese Wiederverwendung wird
allerdings nur für komplexe Daten ermöglicht und setzt natürlich voraus, dass der Anwender schon
Eingaben für diesen Datentyp getätigt hat. Liegen Daten von früheren Eingaben zu dem gerade aktuell
angezeigten komplexen Datentyp vor, so bietet das System die Möglichkeit der Wiederverwendung
durch
DatatypeAlternative
an.
Dazu
wird
die
Wiederverwendungskomponente
reutilisation kontaktiert von createEditor, die alle Eingaben für komplexe Datentypen
persistent speichert. Innerhalb einer angezeigten Liste kann der Anwender alle getätigten Eingaben
64
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
einsehen und bei Bedarf mit takeDatatype dem System mitteilen, dass eine Eingabe wieder verwendet wird. Diese Eingaben werden in der Eingabemaske angezeigt und können vor dem Senden
abgeändert werden, d.h. der Anwender muss nicht alle Eingaben exakt übernehmen.
validate
Dieser Anwendungsfall läuft während des Editierens der Daten ständig im Hintergrund. Der Anwender tätigt über edit seine Eingaben in der Eingabemaske. Im Hintergrund überprüft das System permanent, ob die Eingaben korrekt sind und den Anforderungen des Datentyps entsprechen. Liegt eine
Verletzung vor, z.B. eine Bereichsübertretung, ein unzulässiges Zeichen, oder ein Verstoß gegen bestehende Fassetten, so wird der Anwender durch eine status-Meldung über den Fehler informiert.
Über status werden lediglich Fehler angezeigt, korrekte Eingaben werden nicht kommentiert.
sendWebService
Dieser Anwendungsfall nimmt alle Daten der Eingabemaske entgegen und sendet eine Anfrage an den
entsprechenden Web-Service. Über send teilt der Anwender dem System mit, dass alle Eingaben
vorgenommen wurden. Nach einer systemseitigen Überprüfung der Daten auf Korrektheit und Vollständigkeit wird die komplette Anfrage an die Axis-Komponente weitergeleitet, die den Sendevorgang ausführt. Nach Erhalt der Antwort leitet Axis die Antwortdaten an das System und
sendWebService bereitet die Daten grafisch auf. Danach wird durch showResult dem Anwender das Ergebnis seiner Anfrage präsentiert.
Diese vier vorgestellten Anwendungsfälle erläutern aus der Sicht des Anwenders eine typische Benutzung des Gesamtsystems. Der Anwender hat darüber hinaus noch mehr Interaktionsmöglichkeiten mit
dem System, die aber an dieser Stelle zum Verständnis des Gesamtsystems nicht beitragen und erst bei
detaillierter Betrachtung erläutert werden. Lediglich ein weiterer Anwendungsfall soll an dieser Stelle
neben dem eigentlichen Erstellen der Anfrage und Erhalt der Antwort betrachtet werden.
help
Der Anwender hat die Möglichkeit zu jedem Zeitpunkt während der Systemnutzung eine Hilfefunktion aufzurufen. Durch getHelp kann der Anwender allgemeine Hilfethemen nach Informationen
durchsuchen oder direkt Komponenten anklicken, um spezielle Hilfe über diese angezeigt zu bekommen. Sofern eine Hilfefunktion vorliegt wird diese über showHelp dem Anwender in einem Extrafenster angezeigt, damit diese Hilfe parallel zur Editierung verwendet werden kann.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
65
4.1.2 Grafische Komponenten
Nachfolgend werden die wichtigsten grafischen Komponenten des Modells vorgestellt. Zur Interaktion
mit einzelnen grafischen Komponenten stehen dem Anwender üblicherweise Tastatur und Maus zur
Verfügung. Die äußerste, grafische Komponente stellt ein Fenster dar und ist somit Sammelcontainer
für alle anderen Komponenten. Die Größe dieses Fenster soll variabel sein, damit das Fenster je nach
verwendeter Bildschirmauflösung angepasst werden kann. Darauf folgend werden nun grafische
Komponenten vorgestellt, die zur Darstellung der Informationen zur Verfügung stehen. Eine Zuordnung der grafischen Komponenten zu den Elementen des WSDL- und XSD-Dokumentes erfolgt in
den nachfolgenden Unterkapiteln.
Die einfachste Möglichkeit zur Darstellung von Informationen ist die textuelle Präsentation. Informationen können nacheinander als Texte innerhalb des Fensters dargestellt werden. Der Platz, den ein
Text einnimmt, wird durch die Länge der Information bestimmt. Ist ein Text länger als die Breite des
umschließenden Fensters, so wird er entweder abgeschnitten oder durch einen Zeilenumbruch in der
nächsten Zeile des Fensters fortgesetzt. Ein Text kann lediglich zur Darstellung verwendet werden,
aber nicht, um Interaktionen des Anwenders entgegen zu nehmen. Zur Präsentation von Informationen
können Texte verwendet werden, aber um Benutzereingaben entgegen zu nehmen, muss ein Element
die Fähigkeit haben Aktionen des Anwenders zu registrieren und weiterzuleiten.
Ein Button führt jeweils eine zuvor definierte Funktion aus, nachdem der Anwender ihn betätigt hat.
Jeder Button repräsentiert dabei genau eine festgelegte Aktion und kann keine weiteren Aktionen ausführen. Die Größe eines Buttons kann beliebig skaliert werden. Daher bietet sich die Verwendung
eines Buttons an, wenn Aktionen benötigt werden, zu deren Darstellung entweder wenig Platz zur
Verfügung steht oder genau eine Aktion ausgeführt werden soll..
Ein Eingabefeld nimmt Eingaben über die Tastatur entgegen und stellt dafür einen zuvor begrenzten
Raum zur Verfügung. Die Eingabe sämtlicher druckbarer Zeichen erscheint als Echo innerhalb des
Eingabefeldes. Diese Eingabemöglichkeit kann prinzipiell zur Eingabe sämtlicher textueller Informationen verwendet werden, da von der Komponente keine Einschränkungen vorgenommen werden.
Diese Komponente zeigt jeweils einen beschränkten Inhalt der Eingabe an, wenn dieser die Länge des
Sichtbereichs überschreitet. Durch Bewegung des Cursors können die Inhalte des Eingabefeldes in den
sichtbaren Bereich verschoben werden.
Neben dem Eingabefeld bieten auch Checkboxen und Auswahlboxen die Möglichkeit, Eingaben des
Benutzers entgegen zu nehmen. Allerdings erlauben diese beiden Elemente keine unbegrenzte Eingabemöglichkeit. Vielmehr bieten sie eine Auswahl von zuvor festgelegten Möglichkeiten an, die per
Maus selektiert werden können.
Eine Checkbox stellt einen Wert einer Menge (z. B.: einen Text oder eine Zahl aus einer Zahlenmenge) dar und bietet durch Voranstellen eines Buttons die Möglichkeit, den dahinter dargestellten Wert
zu aktivieren. Werte aus einer begrenzten Menge können somit durch eine Gruppe von aneinander
gereihten Checkboxen aufgebaut werden, von der jeder einen Wert darstellt. Der benötigte Platz in-
66
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
nerhalb der GUI für diese Komponente variiert mit der darzustellenden Anzahl von Werten, da für
jeden Wert eine Checkbox generiert wird. Kann die Menge der Werte nicht eingeschränkt werden, so
wird dieses Element nicht verwendet. Die generierte GUI soll übersichtlich und leicht zu bedienen
sein. Daher wird dieses Element nur benutzt, wenn die Größe zuvor kalkuliert werden kann.
Die Auswahlbox bietet dem Anwender ebenfalls eine Auswahl von Werten an, hat aber im Gegensatz
zu einer Checkbox-Gruppe immer die gleiche Größe. Die Auswahlbox zeigt dazu immer den zuletzt
ausgewählten Wert an. Alle anderen Werte werden transparent in einer Liste gehalten. Nach Aktivierung kann der Inhalt der Liste angezeigt werden, um eine neue Auswahl zu treffen.
Bei Checkboxen und Auswahlboxen ist darauf zu achten, dass die Anzahl der Werte beschränkt sein
sollte. Bei steigender Wertemenge steigt proportional der Platzanspruch der Checkbox-Gruppe und bei
der Auswahlbox wird die Liste der inaktiven Werte unübersichtlicher.
Letztendlich benötigt das Modell eine Komponente, die das Laden und Speichern von Daten übernimmt. Diese Komponente nimmt Daten in Form einer Datei oder eines Feldes von Bytes an und leitet
die Daten weiter an das Framework oder an das Dateisystem. Diese Komponente sollte beim Speichern die Möglichkeit aufweisen, Namen und Ort für die Speicherung der Daten frei zu wählen. Beim
Laden der Daten sollte man die Möglichkeit haben, durch Suche im Dateisystem eine Auswahl der
Daten zu treffen. Diese Komponente wird während der Realisierung weiter spezifiziert.
Validierung der dargestellten Informationen
Jede der vorgestellten Komponenten kann eine Validierung der verwendeten Informationen vornehmen. Zur späteren Auswahl einer Komponente ist dieser Aspekt wichtig und beeinflusst die Wahl
einer Komponente. Prinzipiell könnte die Validierung der Informationen und Daten von einer externen
Komponente des Frameworks übernommen werden. Die vorgestellten Komponenten könnten lediglich
zur Darstellung der Informationen verwendet werden und abschließend könnte, z. B. vor dem Sendevorgang, eine Validierung erfolgen. Allerdings würden dann punktuell viele Fehler auf einmal angezeigt werden. Außerdem müssten jeweils die Stellen gesucht werden, bei denen der Fehler aufgetreten
ist. Dadurch entsteht ein Zeitverlust zur Erstellung einer Anfrage für den Anwender. Ferner können
Folgefehler auftreten, die nicht während des Editierens erkannt werden. Ein Anwender könnte den
Wertebereich eines Datentyps falsch verstehen und mehrmals falsche Angaben machen. Würde er
gleich bei der ersten Eingabe den Fehler erkennen, so kann dieser Fehler bei mehrmaliger Anwendung
vermieden werden. Aus diesen Gründen scheidet also eine Validierung der Daten nach Abschluss der
Eingaben aus.
Für Texte und Buttons wird keine Validierung der Informationen benötigt. Diese zeigen immer nur
Informationen oder Funktionen des Systems an. Ein Text und ein Button werden nicht zur Eingabe
durch den Anwender verwendet, daher entfällt die Überprüfung der Daten.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
67
Ein Eingabefeld validiert die eingetippten Daten nach jedem Tastendruck oder beim Bestätigen mit
„Return“. Durch diese permanente Validierung können fehlerhafte Eingaben schnellstmöglich erkannt
werden.
Eine Checkbox und die Auswahlbox erzeugen nur valide Werte. Die Menge der Werte ist vor der grafischen Darstellung bekannt. Es werden lediglich die vom System generierten, korrekten Daten dargestellt. Der Anwender kann keine falschen Werte eingeben, da nur eine Auswahl zur Verfügung steht
und nicht selbst Werte hinzugefügt werden können.
Die Komponente zum Laden und Speichern kann durch einen Filter festlegen, welche Daten verwendet werden können. Diese Überprüfung kann durch Einschränkung der Dateienden oder durch Überprüfung des Inhalts der Daten (Vergleich von einzelnen Bytes) erfolgen.
4.2 Anforderungskatalog
Die nicht funktionalen Anforderungen an das Modell werden nun sukzessive in einem Anfragekatalog
entwickelt.
Internationalisierung
Der zu entwickelnde Prototyp wird in englischer Sprache verfasst, bietet aber die Möglichkeit leicht in
jede andere Sprache übersetzt zu werden. Die Richtlinien zur Internationalisierung eines Programms
wurden u. a. dem Java Tutorial von Sun Microsystems entnommen [SUN04]. Innerhalb des Codes
werden keine festkodierten, sprachspezifischen Texte oder Beschriftungen eingefügt. Sämtliche
sprachabhängigen Texte (wie z.B. Beschriftung der Buttons, Dialoge, Fehlermeldungen und Benutzerführungen) werden in einer Skriptdatei gesammelt und über ein Ressourcenbündel (Resource Bundle)
dynamisch eingebunden. Somit können an einer zentralen Stelle Veränderungen bezüglich der verwendeten Sprache durchgeführt werden. Landesabhängige Formate (wie z.B.: Postleitzahlen, Telefonnummern), Maß- und Währungseinheiten werden im WSDL-Dokument vom jeweiligen Web-ServiceAnbieter festgelegt und durch die GUI lediglich dargestellt. Daher brauchen diese Richtlinien bei der
Entwicklung nicht beachtet zu werden. Legt ein Anbieter beispielsweise ein Format für eine Artikelnummer aus einer bestimmten Sequenz von Ziffern und Buchstaben fest, so kann er dies innerhalb
eines Pattern spezifizieren. Dieses Pattern wird dann generisch in der Eingabemaske angezeigt und
erlaubt lediglich die festgelegten Eingabesequenzen. Zusätzlich wird das Pattern dem Benutzer in der
Hilfefunktion angezeigt und erklärt, was die einzelnen Formatangaben als Eingabe benötigen. Somit
ist eine leichte Umstellung auf verschiedene Sprachen gewährleistet. Lediglich die Leserichtung von
links nach rechts und oben nach unten wurde festgelegt.
68
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Wiedererkennung
Bei der Generierung der GUI wurde großer Wert auf eine einheitliche grafische Präsentation mit Wiedererkennungswert gelegt. Unabhängig vom verwendeten Web-Service soll der Aufbau der GUI jeweils einen gleichen Grundaufbau vorweisen. Dieser Aspekt wird im nächsten Unterkapitel bei der
Darstellung der WSDL-Komponenten aufgegriffen. Die GUI soll ein einheitliches Erscheinungsbild
aufweisen, egal ob ein Web-Service aus einer Operation oder aus einer beliebigen Anzahl besteht.
Somit kann ein Anwender das Programm nach Kennen lernen der Funktionalität immer auf die gleiche
Art und Weise benutzen.
Dynamische Größenanpassung
Jede Komponente, die in der GUI dargestellt wird, kann je nach vorhandenem Platz verschiedene
Größen annehmen. Eine Komponente hat eine bevorzugte Größe, die immer angenommen wird, solange der Platz dafür vorhanden ist. Bei Verringerung des Platzangebots können die Komponenten
ihre Größe bis zu einer minimalen Größe verringern. Ab einer unteren Schranke wird die Komponente
abgeschnitten, da sie ihre Größe nicht weiter verringern kann. Somit erreicht man beim Minimieren
des Fensters eine Schwelle, bei der die angezeigten Komponenten nicht kleiner und näher zusammenrücken können. Beim Füllen der Eingabemaske mit Komponenten der Datentypen wird jeweils die
aktuelle Größe des Fensters verwendet, um die Anzahl der Komponenten für eine sichtbare Seite in
Abhängigkeit zu ihrer Größe zu bestimmen. Übersteigt die Anzahl der Komponenten die maximale
Anzahl der Komponenten, die auf einmal angezeigt werden können, so werden die Komponenten in
mehreren Ebenen aufgeteilt. Die Ebenen sind dann über entsprechende Navigationselemente erreichbar.
Portabilität
Das Framework wird in der Programmiersprache Java entwickelt und ist somit plattformunabhängig.
Entwickelt und getestet wurde das System auf Windows- und Linux-Plattformen. Die Struktur der
Dateiverzeichnisse und Pfadnamen wird vom jeweiligen Betriebssystem generiert und ist somit variabel anpassbar. Lediglich das grafische Erscheinungsbild wird vom jeweiligen Betriebssystem beeinflusst. Dieser Punkt wird in Kapitel sechs bei der Vorstellung des Layouts nochmals erläutert.
Hilfefunktion und Zusatzinformationen
Die Hilfefunktion soll dem Benutzer Hilfestellung bei jedem Schritt der Erstellung der Anfrage an den
Web-Service bis zum Erhalten und Anzeigen der Antwort bieten. Die Hilfe soll innerhalb des Menüs
und der Symbolleiste geöffnet werden können und dem Anbieter sämtliche Schritte verdeutlichen und
erklären. Zusätzlich kann über eine Suchfunktion selbstständig nach Hilfefunktionen gesucht werden
oder extern über eine Linksammlung relevante Themen nachgeschlagen werden. Neben dieser allge-
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
69
meinen Hilfefunktion soll eine spezifische Hilfefunktion angeboten werden. Nach Aktivierung dieser
zusätzlichen Hilfe kann man innerhalb der GUI Komponenten mit der Maus anklicken und erhält eine
gesonderte Beschreibung. Diese Funktion wurde vor allem wegen der hohen Anzahl von unterschiedlichen Datentypen entwickelt. Da jeder Datentyp nur spezifische Eingaben erlaubt, die überprüft werden und somit vom Anwender beachtet werden müssen, können für jedes Eingabefeld eines Datentyps
durch diese Hilfefunktion Informationen angezeigt werden. Als Beispiel sei hier das unterschiedliche
Format der beiden XSD-Datentypen Name und NCName angeführt. Beide Datentypen dürfen nicht
mit einer Ziffer beginnen, bei Name darf ein Doppelpunkt an beliebiger Stelle auftreten, bei NCName
ist der Doppelpunkt gänzlich verboten. Bei Missachtung dieser Formatvorschriften wird ein Fehler im
Programm angezeigt. Um dem Anwender die Eingabe zu erleichtern, kann er sich die Hilfeseite per
Mausklick anzeigen lassen. Somit kann er jeden Datentyp fehlerfrei editieren, auch wenn dieser zuvor
nicht bekannt war.
Korrektheitsüberprüfung
Für sämtliche Benutzereingaben, die über die Eingabemaske oder zusätzliche Bearbeitungsfenster
eingegeben werden, findet sofort eine Validierung statt. Diese Validierung wird durchgeführt nach
jedem Tastendruck oder nachdem die Eingabekomponente den Fokus verloren hat. Bei fehlerhafter
Editierung wird ein Fehler angezeigt, bei Erkennung der Art des Fehlers, zusätzlich eine detaillierte
Fehlerbeschreibung. Nur nach korrekter Eingabe eines Datentyps wird dieser temporär in einem Objekt bis zum Senden gespeichert. Somit ist gewährleistet, dass nur korrekte Daten an den Web-Service
beim Sendevorgang weitergeleitet werden. Zusätzlich wird vor dem Senden überprüft, ob der Anwender alle erforderlichen Eingaben betätigt hat. Falls dies nicht der Fall ist, bekommt der Anwender angezeigt welche Eingaben noch durchzuführen sind. Durch diese beiden Mechanismen ist gewährleistet, dass nur korrekte und vollständige Anfragen an einen Web-Service geleitet werden.
Benutzertypen
Die Verwendung des Programms ist primär für Anwender ausgelegt, die Web-Services noch nie oder
selten benutzt haben und keine Computerexperten sind. Es werden keine technischen Kenntnisse über
die Realisierung von Web-Services oder die verwendeten Technologien vorausgesetzt. Durch Einbeziehen von Hilfefunktionen kann die Erstellung der Anfrage erleichtert werden. Allerdings wird zusätzlich die Anforderung an den Aufbau der GUI gestellt, dass diese selbsterklärend ist und leicht mit
Maus und Tastatur zu bedienen ist. Des weiteren sollen auch Funktionen für fortgeschrittene Benutzer
angeboten werden. Diese werden im Menü platziert, so dass sie bei einfacher Nutzung des Programms
nicht stören oder ablenken. Dem interessierten Benutzer soll die Möglichkeiten gegeben werden, sämtliche ein- und ausgehenden SOAP Nachrichten einzusehen. Zusätzlich kann die Struktur des WSDLDokumentes und extrahierte Service-Informationen aufgelistet werden oder eine baumgesteuerte Na-
70
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
vigation durch das WSDL-Dokument steht zur Auswahl der Operationen. Somit kann jeder Benutzertyp das Framework nach seiner Fasson nutzen.
Zeitrestriktionen
Es können keine Zeitgarantien bis zum Anzeigen der einzelnen Ports und Operationen des WebService in der Start-GUI angegeben werden, nachdem der Anwender eine WSDL-URL übermittelt
hat. Je nach der Komplexität, Tiefe der Importhierarchie und Anzahl der Ports und Operationen kann
der Ladevorgang unterschiedlich lange dauern, bevor die erzeugte GUI dargestellt wird.
Über das Antwortverhalten eines Web-Service und das Anzeigen der Antwort kann ebenfalls keine
Zeitgarantie gegeben werden. Da es sich bei Web-Services um verteilt arbeitende Systeme handelt,
können keine Zeitgarantien bis zum Erhalt einer Antwort nach dem Absenden einer Anfrage gegeben
werden. Sämtliche Daten werden üblicherweise über das zustandslose Transport-Protokoll HTTP
übertragen, das keine Garantie über den fehlerlosen Transport und Übertragungszeiten festlegt. Nach
einem Timeout und Nichterhalten einer Antwort muss der Anwender die Anfrage erneut starten.
Erweiterbarkeit
Das Modell und der daraus resultierende Prototyp können für zukünftige Neuerungen erweitert werden. Eine externe Bearbeitung der Parameter für einige Datentypen kann dadurch simuliert werden. So
kann man einen String über ein separates Eingabefenster modifizieren oder Datumseingaben über
eine grafische Oberfläche eingeben, die beide separat zur eigentlichen Eingabemaske zur Verfügung
stehen (siehe nächstes Kapitel). Bei Weiterentwicklung könnten hier externe Programme für die Modifizierung einzelner Datentypen herangezogen werden. Zusätzlich kann das Modell leicht durch Hinzunehmen neuer Datentypen erweitert werden. Jeder Datentyp wird separat behandelt und erhält eine
spezifische Eingabekomponente. In XSD Version 1.1, seit dem 16.07.2004 Working Draft des W3C,
werden zurzeit Diskussionen über die Hinzunahme weiterer Datentypen geführt. Nach Etablierung von
XSD 1.1 als W3C-Standard können somit diese weiteren Datentypen eingebunden werden durch Hinzufügen der entsprechenden Eingabekomponenten. Neben Erweiterungen können auch Veränderungen
der grafischen Komponenten für einzelne Datentypen modular ausgeführt werden. Durch das Modell
wird jedem Datentyp eine grafische Komponente zugeordnet. Dadurch kann für jeden Datentyp eine
Neuregelung der Komponente erfolgen, ohne das restliche System zu verändern.
Skalierbarkeit
Die Skalierbarkeit des Systems ist teilweise gegeben. Der grafische Aufbau und das Layout des Modells sind beliebig skalierbar, die benötigte Zeit zum Aufbau der GUI allerdings nicht.
Die Struktur und der Aufbau eines WSDL-Dokumentes ist bekannt, allerdings werden Inhalt und
Komplexität erst zur Laufzeit erkannt. Somit ist das Modell unter der Vorraussetzung unbekannter
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
71
Komplexität entwickelt worden und kann somit dynamisch alle WSDL-Dokumente darstellen. Der
Grundaufbau der GUI ändert sich nicht mit steigender Komplexität das WSDL-Dokumentes. Dieser
Aspekt wird im nächsten Kapitel aufgegriffen. Wie bei der Anforderung der Zeitrestriktion schon
erwähnt, kann keine Aussage über die Dauer bis zum vollständigen GUI-Aufbau gemacht werden.
Daher ist die Skalierbarkeit nur auf das Erscheinungsbild der GUI gegeben. In der praktischen Anwendung sollten allerdings die Ladezeiten bis zum Aufbau der GUI nicht zu lange ausfallen. WebServices zeichnen sich gerade durch die Eigenschaft aus, dass sie eine überschaubare Teilaufgabe in
einem komplexen Verbund mit weiteren Web-Services erledigen. Ein Web-Service sollte daher modular und einfach aufgebaut sein und daher die Ladezeit nicht zu lange benötigen bis zur vollständigen
Darstellung der GUI.
4.3 Aufbau der GUI
Der Aufbau der grafischen Oberfläche wird nun schrittweise entwickelt. Die nachfolgende Abbildung
zeigt die Einteilung der Oberfläche des Prototypen in verschiedene Segmente. Durch diese Einteilung
wird eine erste Festlegung zur Platzierung der einzelnen Komponenten erstellt und Platzhalter für die
Informationen aus dem WSDL-Dokument geschaffen. In zwei weiteren Unterkapiteln wird festgelegt,
welche Informationen aus dem WSDL-Dokument extrahiert und grafisch dargestellt werden und welche Informationen aus den enthalten XSD-Daten relevant sind. Die Informationen aus WSDL und
XSD komplettieren somit den Aufbau der GUI.
Hauptfenster
Menüleiste
Symbolleiste
Servicesegment
1
Editorsegment (1..n)
zusätzliches Editorsegment (1..n)
2
2
Eingabemaske mit
Eingabemaske mit
Datentypkomponenten
Datentypkomponenten
Statussegment
3
Abbildung 20: allgemeiner Aufbau der GUI
72
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Abbildung 20 zeigt den allgemeinen Aufbau des Hauptfensters der GUI. Die kariert unterlegten Menüund Symbolleisten werden unabhängig vom vorliegenden WSDL-Dokument modelliert und bieten
zusätzliche Dienste, die im sechsten Kapitel bei der Implementierung dargelegt werden. Die beiden
Leisten sind nicht Teil der generischen Erstellung der GUI, da Menü- und Symbolleiste unabhängig
vom WSDL-Dokument immer den gleichen Aufbau vorweisen. Die Menü- und Symbolleiste benötigen lediglich einen minimalen Platz. Das Menü öffnet nach Aktivieren eines Menüpunktes ein PopupMenü, das nach Auswahl eines Menüeintrags danach wieder deaktiviert wird. In der Symbolleiste
werden in einer Reihe Buttons, mit bestimmten Funktionen, aufgeführt.
Die anderen Komponenten werden inhaltlich durch Informationen aus den WSDL- und XSD-Daten
gefüllt. Nach dem Start des Systems sind lediglich die Positionen innerhalb der GUI festgelegt. Nachdem der Anwender dem System die URL des WSDL-Dokumentes übermittelt hat, werden alle WebServices (Ports) und deren Operationen durch Parsen ermittelt und in dem Servicesegment angezeigt
(Stern 1, siehe auch Anwendungsfall createService). Aus den dargebotenen Operationen kann
der Anwender eine Operation selektieren. Für jede Operation wird ein Editorsegment und ein zusätzliches Editorsegment zum Anzeigen von erweiterten Eingaben erzeugt (Stern 2). Die graue Unterlegung
dieser beiden Segmente und des Servicesegmentes soll anzeigen, dass sie aus WSDL-Elementen aufgebaut werden. Informationen über XSD-Datentypen werden nicht benötigt zum Generieren dieser
Komponenten. Innerhalb des Editorsegmentes werden alle Parameter dieser Operation in einer Eingabemaske aufgereiht (Stern 2, siehe Anwendungsfall createEditor). Bestehen die Parameter aus
komplexen Datentypen, so werden diese komplexen Datentypen in einfache zerlegt, wie oben bereits
geschildert. Nach diesen beiden Schritten ist die GUI generisch aufgebaut und kann zur Editierung der
Parameter verwendet werden. Das Editorsegment wird aus Informationen des Operations-Elementes
und Porttyp-Elementes aus dem WSDL-Dokument erzeugt. Der Inhalt allerdings wird durch die enthaltenen Parameter, die in XSD spezifiziert werden, generiert. Dieser Sachverhalt wurde durch den
angedeuteten Rahmen (gestrichelte Begrenzung) verdeutlicht. Das Editorsegment beinhaltet die Eingabemaske und wird daher primär zum Editieren der Daten verwendet. Daher soll diesem Segment der
größte Raum zugeordnet werden.
Tritt eine fehlerhafte Eingabe auf bei der Editierung der Daten, so wird dies über die Statusmeldungen
im Statussegment der GUI angezeigt. Somit ergibt sich der Inhalt dieser Komponente erst nach Aufbau und Verwendung des Editorsegmentes zur Laufzeit (Stern 3). Die Fehlermeldung besteht meistens
nur aus einem kurzen Text. Daher wird für diese Komponente ein minimaler Platz angeboten.
Durch diese Teilung des GUI-Aufbaus wird die Komplexität reduziert. Ein komplettes Parsen am Anfang, das alle Informationen aufbereitet, könnte sehr lange Zeit in Anspruch nehmen. Denn in diesem
Fall müssten alle Parameter innerhalb jeder Operation zur Darstellung vorbereitet werden. Unter Umständen möchte der Anwender aber nur eine Operation von einem Web-Service nutzen. Er müsste
allerdings warten, bis alle Informationen vorliegen, die er zur Erstellung seiner Anfragen nicht benö-
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
73
tigt. Daher wurde eine Zweiteilung des Parsens eingeführt, um die Komplexität und Wartezeiten einzuschränken.
Die ersten beiden Schritte können beliebig oft wiederholt werden, um andere Operationen darzustellen
und auszuführen. Die Anzahl der Editorsegmente ist durch die Anzahl vorhandener Operationen im
WSDL-Dokument beschränkt. Jede Operation wird höchstens einmal angezeigt.
4.3.1 WSDL-Komponenten
Das Servicesegment baut sich wie oben beschrieben aus allen Ports und deren Operationen auf. Abbildung 21 zeigt in einem aufspannenden Baum die Problematik, dass die Komplexität mit Hinzunahme
von weiteren Ports und Operationen schnell ansteigen kann.
Service
Port
Port
Operation … Operation
…
Port
…
Operation … Operation
Port
Port
Operation … Operation
Abbildung 21: Komplexitätsentstehung durch Ports mit korrespondierenden Operationen
Daher werden die Operationen und Ports in Auswahlboxen repräsentiert, die unabhängig von der Anzahl ihrer Elemente immer den gleichen Platz beanspruchen. In den Auswahlboxen kann der Anwender seine Selektion vornehmen. Zur Wahl stehen drei Auswahlboxen. Eine Auswahlbox beinhaltet
eine Liste mit allen Ports und Operationen, die in der Form „Portname:Operationsname“ angegeben
werden. Hier findet der Anwender auf einen Blick alle Operationen. Bei geringer Anzahl ermöglicht
sie einen schnellen Zugriff auf gegebene Operationen. Bei großer Anzahl von Ports und Operationen
kann diese Auswahl jedoch sehr unübersichtlich werden. Daher wird eine zweite Auswahlmöglichkeit
angeboten. In jeweils einer Auswahlbox werden Ports und Operationen getrennt voneinander geführt.
Durch Wahl des Ports, werden nur jeweils dessen Operationen in der anderen Auswahlbox aufgeführt.
Dem Anwender stehen also immer zwei Möglichkeiten zur Auswahl einer Operation zur Verfügung.
Die Entwurfsentscheidung fiel auf die Verwendung von Auswahlboxen und gegen die Verwendung
von Buttons, Checkbox-Gruppe oder textueller Aufreihung. Eine Anforderung an das System ist neben
der einfachen Bedienung die Wiedererkennung. Würde man Buttons, Checkbox-Gruppe oder eine
textuelle Aufreihung verwenden, so variiert die Anzahl bei jedem WSDL-Dokument. Die Komplexität
kann schnell ansteigen, wie Abbildung 21 verdeutlicht. Die Größe des Servicesegmentes müsste also
auch variieren und würde dem Anwender jeweils eine andere Sicht bieten. Die Auswahlboxen nehmen
einen einheitlichen Platz in Anspruch, unabhängig von der Anzahl der enthaltenen Elemente, und sind
somit ideal zum Generieren des Servicesegmentes geeignet.
74
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Zusätzlich können im Menü oder der Symbolleiste eine Baumdarstellung aller Ports und Operationen
in einem zusätzlichen Fenster angeführt werden. Das Wurzelelement bildet das Service Element, das wie in Abbildung 21 angezeigt- einen Baum aufspannt. Im Baum kann somit auch eine Operation
ausgewählt werden. Diese Option ist primär für erfahrenere Anwender, die den Umgang mit Baumstrukturen kennen.
Nachdem der Grundaufbau der GUI vorgestellt wurde, sollen nun im nächsten Unterkapitel die einzelnen grafischen Komponenten für die XSD-Datentypen bestimmt werden.
4.3.2
Datentypen in XSD
Im nächsten Schritt werden die Datentypen und einige Strukturen des XML-Schema vorgestellt und
anschließend ein Modell zur grafischen Darstellung entwickelt. Die Informationen über die Datenstrukturen sind der überarbeiteten XSD-Spezifikation 1.0 Part 1 des W3C entnommen [BM04a] und
die Informationen über die Datentypen findet man in der XSD-Spezifikation Part 0 [FW04] und XSDSpezifikation Part 2 [BM04a]. Die angeführten Definitionen entstammen der deutschen Übersetzung
der XSD-Spezifikation 1.0 [BEG+01].
Zunächst wird das verwendete Vokabular durch folgende Definitionen eingeführt. Ein Datentyp kann
durch ein Tripel beschrieben werden, das aus einem Wertebereich, einem lexikalischen Bereich und
Fassetten besteht.
Definition 1:
Wertebereich
„Ein Wertebereich ist eine Menge von Werten zu einem gegebenen Datentyp. Jeder Wert im Wertebereich eines Datentyps ist durch ein oder mehrere Literale im lexikalischen Bereich bezeichnet."
Definition 2:
Lexikalischer Bereich
„Ein lexikalischer Bereich ist eine Menge von zulässigen Literalen für einen Datentyp.“
Definition 3:
Fassette
„Eine Fassette ist ein Aspekt der Definition des Wertebereichs. Allgemein gesagt, jede Fassette
charakterisiert einen Wertebereich entlang unabhängiger Achsen oder Dimensionen.”
Ein Datentyp besteht demnach aus einem Wertebereich, der die Menge aller erlaubten Literale festlegt.
Für einen Datentyp sind nur Eingaben erlaubt, deren Werte sich im Wertebereich befindet. Somit liefert der Wertbereich den ersten Ansatzpunkt zur Validierung der Benutzereingaben. Weiterhin kann
ein Wertebereich durch Angabe von Fassetten weiter spezifiziert werden. Die Fassetten schränken den
Wertebereich nochmals weiter ein und werden somit ebenfalls zur Validierung herangezogen.
Einfache Datentypen
Durch den Wertebereich eines Datentyps wird für das Modell des Prototypen festgelegt, welche Eingaben für dessen grafische Komponente durch den Benutzer erlaubt sind. Nur Eingaben, die den Literalen des Wertebereichs entsprechen, werden als gültig angesehen. Somit wird durch den gegebenen
Wertebereich die Validierung eines Datentyps festgelegt. Der Datentyp short wird z. B. durch den
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
75
Wertebereich mit Ganzzahlwerten zwischen -32768 (-215) und 32767 (215-1) definiert. Nur Eingaben
innerhalb dieses Intervalls sind zulässig. Bei Eingabe von Sonderzeichen, Buchstaben oder Zahlen, die
den Werteberreich über- oder unterschreiten, wird durch die Validierungskomponente dieses Datentyps eine Fehlermeldung erzeugt. Da dem Anwender nicht alle Wertebereiche bekannt sind, bietet die
Hilfefunktion zu jedem Datentyp eine Übersicht des vorgeschriebenen Wertebereichs. Zusätzlich kann
ein Datentyp durch Angabe von Fassetten innerhalb seines zulässigen Wertebereichs weiter eingeschränkt werden. Daher werden die Fassetten ebenfalls zur Validierung verwendet. Die Fassetten werden in einem weiteren Absatz nochmals näher erläutert. Zunächst wird eine Einteilung der einfachen
Datentypen vorgenommen. Datentypen unterscheiden sich in einigen grundlegenden Charakteristiken
und können dadurch in Gruppen unterteilt werden.
Datentypen können in atomare, Listen- und Vereinigungsdatentypen unterteilt werden. Atomare Datentypen können nicht weiter unterteilt oder zerlegt werden. Listendatentypen bauen sich aus einer
Sequenz von atomaren Datentypen zusammen. Vereinigungsdatentypen „sind solche, deren Wertebereiche und lexikalische Bereiche die Vereinigung der Wertebereiche und lexikalischen Bereiche von
einem oder mehreren anderen Datentypen darstellen.“ [BEG+01]
Ein nächstes Unterscheidungsmerkmal teilt die Datentypen in primitive und abgeleitete Datentypen.
Primitive Datentypen werden nicht durch andere Datentypen definiert und können daher als gegeben
angesehen werden. Abgeleitete Datentypen werden dagegen durch andere Datentypen definiert und
sind von diesen abgeleitet. Bei abgeleiteten Datentypen leitet sich auch automatisch der Wertebereich
und die gegebenen Fassetten von dem abgeleiteten Datentyp ab.
Ein weiteres Unterscheidungsmerkmal teilt die Datentypen in vordefinierte und benutzerdefinierte
Datentypen ein. Ein vordefinierter Datentyp kann ein primitiver oder abgeleiteter Datentyp sein und
wird durch die XSD-Spezifikation vorgeschrieben. Benutzerdefinierte Datentypen sind abgeleitete
Datentypen, die zuzüglich zu den vordefinierten Datentypen von einem Entwickler modelliert werden.
Abbildung 22 zeigt eine hierarchische Übersicht über alle vordefinierten Datentypen in XSD.
76
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Abbildung 22: Übersicht der XSD-Datentyp-Hierarchie (nach Quelle [BM04b])
Die erste Einteilung in dieser Übersicht aus der XSD-Spezifikation teilt die Datentypen in komplexe
und einfache auf. Die einfachen Datentypen werden weiter unterteilt, die komplexen Datentypen und
deren Ableitung werden erst im Anschluss betrachtet. Der Datentyp anySimpleType stellt den
Urtyp unter den Datentypen dar und ist der Basistyp für alle primitiven Datentypen. Der Wertebereich
ergibt sich aus der Vereinigung der Wertebereiche aller primitiven Datentypen. Darunter reihen sich
die vordefinierten („built-in“ in Abb.22), primitiven Datentypen und die von diesen abgeleiteten („derived“ in Abb.22), primitiven Datentypen ein. Abgeleitete Datentypen werden entweder durch eine
Einschränkung („derived by restriction“ in Abb.22) oder durch Listenbildung („derived by list“ in
Abb.22) abgeleitet. Als Beispiel für eine Listenbildung sei der Datentyp NMTOKENS angeführt. Dieser
setzt sich aus einer Sequenz, bestehend aus einzelnen NMTOKEN, zusammen und bildet somit eine
Liste von NMTOKEN. Der Datentyp short leitet sich durch Einschränkung von int ab. Der Datentyp
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
77
int kann Ganzzahlwerte zwischen -2147483648 (-231) und 2147483647 (231-1) darstellen, Grenzen
eingeschlossen. Der Wertebereich vom short wird eingeschränkt auf Werte zwischen -32768 (-215)
und 32767 (215-1), einschließlich Grenzen.
Nach dieser Definition von einfachen Datentypen werden deren grafische Komponenten an jeweils
einem Beispiel vorgestellt. Im Anhang (Kapitel 8.3) befindet sich eine Übersicht, die zu jedem einfachen Datentyp zum einen den abgebildeten Java-Datentyp anzeigt und zum anderen die grafische
Komponente, mit der dieser Datentyp dargestellt wird. In dieser Übersicht werden schon die JavaSwing-Komponenten aufgelistet. An dieser Stelle werden die Datentypen auf sprachunabhängige
Komponenten abgebildet. Da allerdings diese Zuordnung nicht vollständig an dieser Stelle erläutert
wird, sei daher auf den Anhang verwiesen.
Grafische Komponenten für einfache Datentypen
Bei der Auswahl der grafischen Komponenten muss für jeden Datentyp gewährleistet werden, dass
alle Literale des Wertebereichs durch die Komponente eingegeben werden können. Ein Eingabefeld,
das Tastatureingaben entgegen nimmt, kann prinzipiell für jeden Datentyp verwendet werden und
kann als Basiskomponente angesehen werden. Durch die Verknüpfung mit einer Validierungseinheit
können die Eingaben auf Korrektheit überprüft werden. Diese Überprüfung findet jeweils nach der
Eingabe statt. Ideal wäre eine Eingabemöglichkeit, die nur korrekte Eingaben anbietet. Diese ist aber
nur bei einigen Datentypen realisierbar, deren Wertebereich sehr klein ist, so dass dieser aufgelistet
werden kann.
Bei den meisten Datentypen ist allerdings der Wertebereich zu komplex, um eine Einschränkung vorab vorzunehmen. Daher wird bei diesen Datentypen ein Eingabefeld verwendet, das alle Tastatureingaben entgegen nimmt. Der Datentyp float wird z. B. durch ein Eingabefeld grafisch repräsentiert.
Der Wertebereich setzt sich aus Gleitkommazahlen mit den Grenzen m×2e (m ist eine Ganzzahl, deren
Absolutwert kleiner als 224 ist, und e ist eine Ganzzahl zwischen -149 und 104, Grenzen eingeschlossen).
Neben dieser einfachen Verwendung eines Eingabefelds werden beim Datentyp QName zwei Eingabefelder verwendet. Ein QName baut sich aus einem lokalen Namen und aus einem Namensraum auf.
Diese Eingabe könnte man auch in einem Eingabefeld entgegen nehmen und beide Eingaben durch
Komma oder Leerzeichen trennen. Allerdings besteht bei einem QName auch die Möglichkeit, den
Namensraum nicht anzugeben und nur den lokalen Namen zu verwenden. Diese Eingabe würde bei
nur einem Eingabefeld zu Problemen führen und könnte den Anwender zu falschen Eingaben verleiten. Daher wurden im Modell zwei separate Eingabefelder eingeführt, die durch Bezeichnung dem
Anwender die erforderliche Eingabe signalisieren.
Bei Datentypen mit überschaubarem Wertebereich wird eine Auswahlbox als grafische Komponente
generiert. In dieser Auswahlbox kann der Anwender per Mausklick eine Selektion vornehmen. Das
78
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
einfachste Beispiel stellt hier der Datentyp boolean dar. Der Wertebereich dieses Datentyp besteht
nur aus wahr oder falsch (alternativ 1 oder 0). Die Auswahlbox beinhaltet also lediglich diese beiden
Werte. Ein weiterer Datentyp in dieser Gruppe ist gMonth. Dieser Datentyp baut sich aus einer
Auswahlbox mit allen Monaten auf. Bei allen Datentypen mit überschaubaren Wertebereich wird eine
Auswahlbox zur Präsentation verwendet. Der Hauptvorteil dieser Komponente ist, dass sie jeweils den
gleichen Platz innerhalb der Eingabemaske einnimmt, unabhängig von der Anzahl ihrer Elemente.
Ferner besteht nicht die Möglichkeit, dass der Anwender eine falsche Eingabe betätigt. Die Komponente enthält nur gültige Werte, die aus dem WSDL-Dokument entnommen werden und generisch die
Auswahlbox füllen. Eine Checkbox-Gruppe würde auch nur gültige Werte enthalten, aber sie würde
mehr Platz beanspruchen. Für den Datentyp gMonth bräuchte man 12 einzelne Checkboxen. Zudem
würde der Platzbedarf mit jedem Wert aus dem Wertebereich steigen. Dadurch würde die grafische
Oberfläche zu viele Elemente enthalten und der Überblick würde verloren gehen. Die Auswahlbox
zeigt zudem immer nur den ausgewählten Wert an. So kann der Anwender auch schneller überblicken,
welche Werte er ausgewählt hat. Aus letzterem Grund wurde auch für den Datentyp boolean die
Auswahlbox ausgesucht, obwohl auch bei der Checkbox-Gruppe, bestehend aus zwei Checkboxen, der
Platzbedarf gering ist. Der Anwender sieht die getroffene Wahl und wird durch keine weiteren Angaben abgelenkt. Bei der Checkbox würde er beide Möglichkeiten sehen, wovon eine selektiert ist. Bei
einer schnellen Prüfung seiner Angaben könnte der Anwender sich aber dennoch täuschen bei der
Kontrolle seiner Angaben.
Das Eingabefeld und die Auswahlbox stellen die beiden verwendeten Eingabemöglichkeiten innerhalb
der Eingabemaske dar (außer bei binären Daten). Zusätzlich bauen sich einige Datentypen aus Kombinationen dieser beiden Komponenten auf. Der Datentyp date baut sich z. B. aus zwei Auswahlboxen
und einem Eingabefeld auf und wird zur Eingabe eines Datums verwendet. In den Auswahlboxen
können Angaben über Monat und Tag selektiert werden und im Eingabefeld kann eine Jahreszahl eingegeben werden.
Einige Datentypen generieren noch eine zweite Eingabemöglichkeit. Neben der Komponente innerhalb der Eingabemaske wird für diese Datentypen ein separates Fenster geöffnet. In diesem Fenster
kann über ein Editor Eingaben für einen string und über eine grafische Darstellung eines Kalenders
Datumsangaben eingeben werden für date, duration, dateTime, gYearMonth und
gMonthDay. Die extra Eingabemöglichkeit für einen string wurde hinzugefügt, da bei einem
string die Länge beliebig lang sein kann. Über string kann man z.B. auch ganze Texte eingeben.
Für lange Eingaben wäre das Eingabefeld sehr unflexibel in der Benutzung. Man würde immer nur
einen kleinen Ausschnitt seiner Eingabe auf einmal sehen, da die Größe des Eingabefeldes beschränkt
ist. Durch die Nutzung eines zusätzlichen Fensters kann man dort den eingegebenen Text komplett
anzeigen. Die Eingabekomponente und das separate Fenster müssen synchronisiert werden, so dass
Veränderungen überall übernommen werden und der Text im Eingabefeld und Fenster gleich ist. Für
Datumseingaben wird in dem separaten Fenster eine grafische Komponente angezeigt, die für jeden
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
79
ausgewählten Monat dessen Tage grafisch anzeigt samt Zuordnung zu einzelnen Wochentagen. Zum
einen hat der Anwender dadurch eine komfortable Bedienung und zum anderen kann somit eine externe Bearbeitung der Daten simuliert werden.
Binäre Daten (base64Binary und hexBinary) können durch ein Auswahlfenster aus dem Dateisystem hoch geladen werden. Handelt es sich dabei um ein Bild, so wird dieses im zusätzlichen Editorsegment angezeigt. Handelt es sich allgemein um eine Datei, deren Inhalt nicht bekannt ist, so wird
der Dateiname nach der Auswahl einer Datei angegeben. Analog zum Hochladen, können Dateien
auch wieder beim Empfang einer Antwort gespeichert werden. Der Name kann frei gewählt werden
beim Speichern. Handelt es sich um ein Bild, so wird dieses im zusätzlichen Editorsegment angezeigt.
Durch Klick auf das Bild kann man das Bild in voller Größe in einem extra Fenster ansehen. Ebenso
besteht die Möglichkeit einen Text direkt in einem extra Fenster anzeigen zu lassen.
An dieser Stelle kann das Modell noch erweitert werden, indem für mehrere Dateitypen eine Behandlung direkt mit dem Programm stattfindet. Alternativ kann man auch einfach die Möglichkeit anbieten
die empfangene Datei mit einem Programm zu öffnen, das man aus einer Liste auswählt oder indem
man den Pfad angibt.
Einschränkende Fassetten
Jeder der Datentypen in XSD kann durch Angabe spezifischer Fassetten seinen Wertebereich einschränken. Insgesamt gibt es 12 einschränkende Fassetten. Ein Datentyp kann von diesen 12 Fassetten
jeweils eine Teilmenge anwenden. Im Anhang (Kapitel 8.1 und 8.2) befindet sich eine Liste mit allen
Fassetten für alle vordefinierten, primitiven Datentypen und eine Liste mit abgeleiteten Datentypen
und ihren Fassetten. Die Fassetten werden innerhalb der Validierung des Datentyps ausgewertet. Für
Fassetten, außer der Fassette enumeration, werden daher keine extra grafischen Komponenten
benötigt, da die Komponente des Datentyps verwendet wird. Lediglich eine textuelle Aufreihung aller
verwendeter Fassetten wird dem Anwender in der Eingabemaske mit angezeigt, damit er seine Eingaben dementsprechend abstimmen kann. Die Fassette enumeration stellt eine Ausnahme dar, da sie
nicht nur den Wertebereich des Datentyps einschränkt, sondern auch eine Aufzählung aller erlaubten
Werte angibt. Daher wird für diese Fassette eine Auswahlbox verwendet, egal welche grafische Komponente der zugrunde liegende Datentyp normalerweise hat.
Sind dem Anwender die verwendeten Fassetten unbekannt, so kann er auf einer Hilfeseite Informationen über alle Fassetten erhalten. Nachfolgend werden alle Fassetten vorgestellt und jeweils an einem
Beispiel erklärt. Zuvor wird der allgemeine Aufbau des XSD-Tags zur Angabe von Fassetten für einfache Datentypen angegeben. Fassetten können auch bei komplexen Datentypen verwendet werden,
dies wird allerdings im nächsten Abschnitt gesondert behandelt.
80
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Allgemeiner Aufbau:
<simpleType name= ”name”>
<restriction base= ”datatype”>
<facette with attributes>*
</restriction>
</simpleType>
Innerhalb des Tags <simpleType> werden eine oder mehrere Fassetten für einen Datentypen angegeben. Sobald man für einen einfachen Datentypen Fassetten angibt, wird der Datentyp als ein benutzerdefinierter, komplexer Datentyp behandelt. <simpleType> erhält einen Namen über das Attribut
name. Im Tag <restriction> wird mit dem Attribut base der Datentyp festgelegt, für den der
Wertebereich durch Fassetten eingeschränkt wird. Innerhalb des Tags <restriction> werden
schließlich die einschränkenden Fassetten angegeben, auf die nun eingegangen wird.
Die ersten drei Fassetten length, minLength und maxLength werden bei allen Datentypen, die
von string abgeleitet sind, string, base64Binary, hexBinary und Listen angewendet.
Listen sind die Datentypen ENTITIES, IDREFS und NMTOKENS (siehe Übersicht in Abbildung 22).
length
Definition 4:
length
„length gibt die Anzahl der Längeneinheiten an, wobei die Längeneinheiten je nach Typ, von dem
abgeleitet wird, variieren. Der Wert von length muss vom Typ nonNegativeInteger sein.“
Der Wert von length ist immer eine positive Zahl oder 0. Bei string und davon abgeleiteten Datentypen gibt length die Anzahl der Charakterwerte an. Bei base64Binary und hexBinary
hingegen wird durch length die Anzahl der Bytes angegeben. Bei Listen wird die Anzahl der Elemente festgelegt.
Beispiel:
<simpleType name= ”lengthFacetteExample”>
<restriction base= ”NCName”>
<length =”10” fixed=”true”/>
</restriction>
</simpleType>
In diesem Beispiel wird der Datentyp NCName, der von string abgeleitet ist, in seinem Wertebereich beschränkt. Eingaben für diesen Datentyp müssen exakt die Länge 10 haben. Das Attribut
fixed gibt an, dass bei Verwendung dieses Datentyps innerhalb eines anderen Datentyps, die Fassette nicht nochmals anders belegt werden darf. Bei der Belegung des Attributs fixed=“false“ darf
die Fassette innerhalb eines anderen Datentyps diesen Wert ändern und ersetzen. Initial ist der Wert
immer false und muss nicht angegeben werden. Das Attribut fixed wird bei der Fassette
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
81
length einmal im Beispiel verwendet, bei den anderen Fassetten wird das Attribut nicht mehr angegeben, kann aber bei allen Fassetten verwendet werden.
minLength
Definition 5:
minLength
„minLength gibt die minimale Anzahl von Längeneinheiten an, wobei die Längeneinheiten je nach
Typ, von dem abgeleitet wird, variieren. Der Wert von minLength muss vom Typ nonNegativeInteger
sein.“
Der Wert von minLength ist immer eine positive Zahl oder 0. Bei string und davon abgeleiteten
Datentypen gibt minLength die minimale Anzahl der Charakterwerte an. Bei base64Binary
und hexBinary hingegen wird durch minLength die minimale Anzahl der Bytes angegeben. Bei
Listen wird die Mindestanzahl der Elemente festgelegt.
Beispiel:
<simpleType name= ”minLengthFacetteExample”>
<restriction base= ”NMTOKENS”>
<minlength =”1”>
</restriction>
</simpleType>
In diesem Beispiel wird der Datentyp NMTOKENS, der eine Liste des Datentyps NMTOKEN ist, in der
Anzahl seiner Elemente beschränkt. Es wird festgelegt, dass mindestens ein Element in der Liste enthalten sein muss, sie also nicht leer sein darf.
maxLength
Definition 6:
maxLength
„maxLength gibt die maximale Anzahl von Längeneinheiten an, wobei die Längeneinheiten je nach
Typ, von dem abgeleitet wird, variieren. Der Wert von maxLength muss vom Typ nonNegativeInteger
sein.“
Der Wert von maxLength ist immer eine positive Zahl oder 0. Bei string und davon abgeleiteten
Datentypen gibt maxLength die maximale Anzahl der Charakterwerte an. Bei base64Binary
und hexBinary hingegen wird durch maxLength die maximale Anzahl der Bytes angegeben. Bei
Listen wird die Höchstanzahl der Elemente festgelegt.
Beispiel:
<simpleType name= ” maxLengthFacetteExample”>
<restriction base= ”hexBinary”>
<maxLength =”1024”>
</restriction>
</simpleType>
82
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
In diesem Beispiel wird der Datentyp hexBinary auf eine Größe von 1024 Bytes beschränkt. Die
eingefügte Datei darf also diese Größe nicht überschreiten.
pattern
Definition 7:
pattern
„pattern ist eine Beschränkung des Wertebereiches eines Datentyps; dies wird erreicht, indem der lexikalische Bereich auf Literale beschränkt wird, die in ein bestimmtes Muster passen. Der Wert von
pattern muss ein regulärer Ausdruck sein.“
Ein pattern gibt also ein Muster an, welches der Datentyp erfüllen muss. Das Muster wird durch
einen regulären Ausdruck angegeben. Die Definition eines regulären Ausdrucks ist komplex und für
das Verständnis eines Pattern nicht unbedingt erforderlich und kann in der Spezifikation nachgelesen
werden.
Beispiel:
<simpleType name= ”patternFacetteExample”>
<restriction base= ”string”>
<pattern value="\d{3}-[A-Z]{2}"/>
</restriction>
</simpleType>
Der Datentyp string wird durch das gegebene Muster („\d{3}-[A-Z]{2}“) in seinem Wertebereich
beschränkt. Das Muster spezifiziert in diesem regulären Ausdruck die erlaubten Eingaben bei Verwendung dieses Datentyps. Die Zeichenkette „\d“ steht für die Kategorie „Dezimalzahlen“. In Geschweiften Klammern dahinter wird die Anzahl festgelegt. Die Zeichenkette „[A-Z]“ steht stellvertretend für alle Buchstaben. Das Muster erlaubt demnach Eingaben, die mit drei Ziffern beginnen, danach ein Bindestrich aufweisen und mit 2 Buchstaben enden. Eine erlaubte Eingabe bei diesem Muster
wäre demnach „123-XY“. Bei der Darstellung eines Pattern in der Eingabemaske wird immer das
Muster mit angezeigt. In der Hilfeseite sind dann alle Erklärungen und Ersetzungsregeln für die Zeichenketten innerhalb des Musters. Allerdings könnten die Ersetzungsregeln bei komplexen Mustern
für unerfahrene Anwender keine triviale Aufgabe werden. Daher wäre ein Beispiel, beigefügt als Dokumentation vom Web-Service-Anbieter, sehr hilfreich.
enumeration
Definition 8:
enumeration
„Die Aufzählung enumeration beschränkt den Wertebereich auf bestimmte benannte Werte.“
Diese Fassette kann für alle Datentypen außer boolean angewendet werden. Bei der Aufzählung
(englisch: enumeration) werden Werte des Wertebereichs aufgereiht und einer kann ausgewählt werden. Eine Aufzählung hat immer eine endliche Anzahl von Werten und wird daher in einer Auswahl-
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
83
box angezeigt. Unabhängig vom verwendeten Datentyp werden in einer Aufzählung immer alle Werte
als Strings angegeben. Diese werden dann in der Auswahlbox angezeigt und der Anwender kann einen
Wert mit der Maus selektieren.
Beispiel:
<simpleType name= ”enumerationFacetteExample”>
<restriction base= ”string”>
<enumeration value=”Niederlande”/>
<enumeration value=”Belgien”/>
<enumeration value=”Luxemburg”/>
</restriction>
</simpleType>
Bei dieser Aufzählung werden drei strings namentlich aufgeführt. Diese drei Werte können dann
in der Auswahlbox angezeigt werden. Diesen Datentyp könnte man beispielsweise verwenden, um ein
Beneluxland auszuwählen.
whiteSpace
Definition 9:
whiteSpace
„whiteSpace beschränkt den Wertebereich von Typen, die von string abgeleitet sind so, dass verschiedene Verhaltensweisen, die in Attribute Value Normalization in [XML 1.0 (Second Edition)] spezifiziert sind, in Kraft treten. Der Wert von whiteSpace muss einer der folgenden sein: {preserve, replace,
collapse}.“
Diese Fassette regelt die Behandlung und Einfügung von Leerzeichen bei einem Datentyp, der von
string abgeleitet ist und string selbst. Die Fassette kann drei Werte annehmen. preserve
bedeutet, dass keine Normalisierung vorgenommen wird. Bei replace werden
alle
von Tab, Zeilenvorschub und Return durch ein Leerzeichen ersetzt. collapse entfernt
Vorkommen
schließlich
führende und abschließende Leerzeichen. Zusätzlich werden mehrere Leerzeichen zu einem zusammengefasst.
Beispiel:
<simpleType name= ”whiteSpaceFacetteExample”>
<restriction base= ”QName”>
<whiteSpace value=”collapse”>
</restriction>
</simpleType>
Bei diesem Beispiel wird collapse als Wert für die Fassette beim Datentyp QName angewendet.
Ein Anwender könnte folgende Eingaben betätigen: Als lokalen Namen gibt er „ Diplom arbeit “
und als Namensraum „
www.icsy.de
“ ein. Nach Anwendung der Regel ergibt sich dann für den
lokalen Part „Diplom arbeit“ und für den Namensraum „www.icsy.de“. Die führenden und abschlie-
84
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
ßenden Leerzeichen werden abgeschnitten und die drei Leerzeichen in der Mitte des lokalen Parts
werden zu einem zusammengefasst.
maxInclusive, maxExclusive
Definition 10:
maxInclusive
„maxInclusive gibt die obere inklusive Schranke des Wertebereichs für einen Datentyp mit der geordnet-Eigenschaft an. Der Wert von maxInclusive muss im Wertebereich des Basistyps liegen.“
Definition 11:
maxExclusive
„maxExclusive gibt die obere exklusive Schranke des Wertebereichs eines Datentyps mit der geordnet-Eigenschaft an. Der Wert von maxExclusive muss im Wertebereich des Basistyps liegen.“
Diese beiden Fassetten geben Schranken für den Datentyp an, welche selbst innerhalb des Wertebereichs des Datentyps liegen müssen. Bei maxInclusive müssen die Werte kleiner oder gleich der
Schranke sein und bei maxExclusive müssen die Werte kleiner als die Schranke sein. Bei
maxInclusive ist also die Schranke auch ein erlaubter Wert, bei maxExclusive allerdings nicht.
Beispiel:
<simpleType name= ”maxInclusiveFacetteExample”>
<restriction base= ”int”>
<maxInclusive value=”10”>
</restriction>
</simpleType>
In dem Beispiel dürfen alle Ganzzahlwerte im Wertebereich von int, die kleiner oder gleich 10 sind
eingegeben werden. Der Wert 11 oder größer würde zu einem Fehler führen. Bei der Fassette
maxExclusive und einem Wert von 10 dürften alle Ganzzahlwerte die kleiner sind als 10 eingegeben werden. Hier wäre die Eingabe von 10 oder größer ein Fehler.
minExclusive, minInclusive
Definition 12:
minInclusive
„minInclusive gibt die inklusive untere Schranke des Wertebereichs eines Datentyps mit der geordnetEigenschaft an. Der Wert von minInclusive muss im Wertebereich des Basistyps liegen.“
Definition 13:
minExclusive
„minExclusive gibt die exklusive untere Schranke der Wertebereich eines Datentyps mit der geordnetEigenschaft an. Der Wert von minExclusive muss im Wertebereich des Basistyps liegen.“
Diese beiden Fassetten geben Schranken für den Datentyp an, welche selbst innerhalb des Wertebereichs des Datentyps liegen müssen. Bei minInclusive müssen die Werte größer oder gleich der
Schranke sein und bei minExclusive müssen die Werte größer als die Schranke sein. Bei
minInclusive ist also die Schranke auch ein erlaubter Wert, bei minExclusive allerdings nicht.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
85
Beispiel:
<simpleType name= ”minExclusiveFacetteExample”>
<restriction base= ”short”>
<minExclusive value=”10”>
</restriction>
</simpleType>
In dem Beispiel dürfen alle Ganzzahlwerte im Wertebereich von short eingegeben werden, die größer als 10 sind. Der Wert 10 oder kleiner würde zu einem Fehler führen. Bei der Fassette
minInclusive und einem Wert von 10 dürften alle Ganzzahlwerte, die größer oder gleich als 10
sind, eingegeben werden.
totalDigits, fractionDigits
Definition 14:
totalDigits
„totalDigits gibt die maximale Anzahl von Dezimalstellen in Werten an, die von decimal abgeleitet
sind. Der Wert von totalDigits muss vom Typ positiveInteger sein.“
Definition 15:
fractionDigits
„fractionDigits gibt die maximale Anzahl von Nachkommastellen bei Werten, die von decimal abgeleitet sind, an. Der Wert von fractionDigits muss vom Typ nonNegativeInteger sein.“
Diese beiden Fassetten können auf allen Datentypen angewendet werden, die von decimal abgeleitet
sind und decimal selbst. totalDigits gibt an, wie viele Ziffern insgesamt verwendet werden
dürfen. Die Ziffern vor und nach dem Komma addiert dürfen nicht größer sein als der Wert von
totalDigits. Dieser Wert muss ein positiveInteger sein, kann also ein Ganzzahlwert größer oder gleich 1 annehmen. fractionDigits gibt an wie viele Ziffern maximal nach dem Komma vorkommen dürfen. Der Wert wird als nonNegativeInteger angegeben. Es sind also für
diesen Wert Ganzzahlwerte größer oder gleich 0 erlaubt.
Beispiel:
<simpleType name= ”total_fractionDigitsFacetteExample”>
<restriction base= ”decimal”>
<totalDigits value=”5”>
<fractionDigits value=”2”>
</restriction>
</simpleType>
Bei diesem Beispiel dürfen nur Zahlen des Datentyps decimal eingegeben werden, die höchstens
drei Ziffern vor dem Komma haben und bis zu zwei Nachkommazahlen. Insgesamt dürfen höchstens
fünf Ziffern verwendet werden. Einige erlaubte Eingaben: „-20,33“,
“100,00“.
„45,6“,
„42“, „-999,99“,
86
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Komplexe Datentypen
In diesem Abschnitt wird die Darstellung für komplexe Datentypen modelliert. Gibt man eine einschränkende Fassette für einen einfachen Datentyp an und spezifiziert somit das Tag
<simpleType>, so wird aus dem einfachen Datentyp ein komplexer. Diese Darstellung wurde im
vorigen Absatz diskutiert. Bei der Definition der komplexen Datentypen und der grafischen Komponenten kann aufgrund der Komplexität der XSD-Spezifikation nicht auf alle Details und Möglichkeiten eingegangen werden. Es werden daher die wichtigsten Elemente vorgestellt, die auch durch den
Prototypen verwirklicht werden.
Definition 16:
Vereinigung
„Der Wertebereich und der lexikalische Bereich einer Vereinigung entsprechen der Vereinigung der
Wertebereiche und der lexikalischen Bereiche der an der Vereinigung beteiligten memberTypes …
Ein Vereinigungs-Datentyp kann von einem oder mehreren atomaren, Listen- oder VereinigungsDatentypen abgeleitet sein. Das sind die sog. memberTypes dieses Vereinigungs-Datentyps.“
Dieser komplexe Datentyp setzt sich aus einem oder mehreren Basisdatentypen (atomaren-, Listenoder
weiteren
Vereinigungsdatentypen)
zusammen.
Die
Basisdatentypen
werden
auch
memberTypes genannt. Grafisch werden die einzelnen Basisdatentypen mit ihren entsprechenden
Komponenten dargestellt. Der Benutzer wird darauf aufmerksam gemacht, dass es sich um eine Vereinigung handelt.
Beispiel:
<simpleType name= ”unionMonth”>
<union>
<simpleType name= ”listOfInt”>
<list item=”1 2 3 4 5 6 7 8 9 1 0 11 12”/>
</simpleType>
<simpleType>
<restriction base= ”string”>
<enumeration value=”January”/>
<enumeration value=”February”/>
…
<enumeration value=”December”/>
</restriction>
</simpleType>
<union>
</simpleType>
Der Vereinigungsdatentyp unionMonth besteht aus der Vereinigung von dem Listendatentyp
listOfInt (Auflistung wird im nächsten Absatz eingeführt) und einer Aufzählung des einfachen
Datentyps string. Der Listendatentyp besteht aus einer Liste von 12 Ganzzahlwerten, beginnend bei
dem Wert 1. Die Aufzählung besteht aus 12 Elementen (hier nur 3 aufgeführt) des Datentyps
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
87
string. Jedes Element stellt den Namen eines Monats dar. Mit dieser Vereinigung können Monate
angegeben werden. Alternativ kann der Anwender entweder eine Zahl eingeben oder aus der Auswahlbox einen Monatsnamen selektieren. Eine der beiden Möglichkeiten kann der Anwender verwenden. Durch die Vereinigung wird also dem Anwender eine äquivalente Auswahl von Eingaben angeboten, die den gleichen Sachverhalt darstellen. Eine Eingabe von „7“ ist also äquivalent mit der Eingabe von „July“.
Definition 17:
Auflistung
„Ein Listen-Datentyp muss von einem atomaren oder einem Vereinigungs-Datentyp abgeleitet sein,
dem sog. itemType des Listen-Datentyps. Daraus entsteht ein Datentyp, dessen Wertebereich aus Sequenzen endlicher Länge von Werten aus dem Wertebereich des itemType besteht und dessen lexikalischer Bereich sich aus durch Leerraum getrennte Listen von Literalen zusammensetzt.“
Bei der Auflistung kann ein Vereinigungs- oder atomarer Datentyp als Basis (itemType) genommen
werden. Die Auflistung ist eine Aneinanderreihung dieser Basis. Dargestellt wird dieser Datentyp aus
der Komponente der Basis im Editorsegment. Überdies wird im zusätzlichen Editorsegment eine Liste
angezeigt. Nachdem der Anwender den Wert für die Basis editiert hat, kann er durch Druck auf einen
Button signalisieren, dass das Editieren abgeschlossen ist und der Wert wird in der Liste übernommen.
Nach der Übernahme befindet sich der Wert am Ende der Liste, die sich dadurch sukzessive aufbaut
und die Eingabekomponente wird zurückgesetzt. Bei einem Eingabefeld werden die eingegebenen
Werte gelöscht und bei einer Auswahlbox wird der erste Wert selektiert dargestellt. Im zusätzlichen
Editorsegment wird neben der Liste noch ein Editierungsbutton angebracht. Nach Auswahl eines Elementes in der Liste kann dieses durch Druck auf den Button wieder in der Eingabekomponente angezeigt werden. Nach erfolgreicher Editierung wird der neue Wert anstatt des alten in der Liste weiter
geführt.
Beispiel:
<simpleType name= ”listofBytes”>
<list item=”byte”/>
</simpleType>
In diesem Beispiel wurde der komplexe Datentyp listofBytes spezifiziert. Er besteht aus einer
Liste von Werten des Datentyps byte.
Model Group Definition:
Durch eine Model Group Definition kann ein komplexer Datentyp strukturiert werden. Durch eine
Model Group wird angegeben, wie die Elemente des komplexen Datentyps zusammengesetzt werden.
Die Elemente eines komplexen Datentyps können wiederum komplex sein. So können komplexe Datentypen beliebig verschachtelt werden. Die grafische Präsentation baut sich aus den Komponenten
der einzelnen Elemente auf. Bestehen einzelne Elemente wiederum aus einem komplexen Datentyp, so
88
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
wird dieser ebenfalls in seine Elemente zerlegt. Diese Zerlegung wird solange fortgesetzt, bis schließlich nur noch Elemente aus Basisdatentypen (atomaren-, Listen- oder Vereinigungsdatentypen) vorliegen. Bei der Realisierung im fünften Kapitel und den Implementierungsaspekten im folgenden Kapitel
wird ein mehrfach verschachtelter, komplexer Datentyp vorgestellt.
Eine Model Group zur Strukturierung baut sich folgendermaßen zusammen:
{compositor} :
Auswahl der Komposition: all, choice or sequence.
{particles} :
Liste von Partikeln
{annotation} :
optionale Dokumentationen
Gruppierungsmöglichkeiten durch Komposition:
Durch die Komposition wird angegeben, wie die einzelnen Elemente innerhalb des komplexen Datentyps auszuwerten sind. An zwei Beispielen werden die drei Gruppierungsmöglichkeiten veranschaulicht.
sequence:
Die Reihenfolge der Deklarationen muss eingehalten werden.
choice:
Eine der angegebenen Deklarationen muss vorkommen.
Beispiel für sequence und choice:
<complexType name=„Time">
<sequence>
<element name=”hour” type=„int"/>
<choice>
<element ref=„pm"/>
<element ref=„am"/>
</choice>
</sequence>
</complexType>
Der komplexe Datentyp „Time“ baut sich aus einer Sequenz auf. Die Sequenz besteht aus dem einfachen Datentyp int und einem weiteren komplexen Datentyp, der sich aus einer Auswahl (choice)
aufbaut. Die Auswahl erlaubt entweder „pm“ oder „am“ auszuwählen. Der komplexe Datentyp baut
sich also aus einem Ganzzahlwert auf, der die Uhrzeit präsentiert und der Möglichkeit „pm“ oder
„am“ auszuwählen. Die grafischen Komponenten in diesem Fall wären ein Eingabefeld und eine Auswahlbox. Bestünde das choice-Element wiederum aus einem komplexen Datentyp, so würde der
Anwender durch einen Text aufgefordert werden, die nachfolgenden komplexen Datentypen als Auswahl anzusehen und sich für einen zu entscheiden.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
all:
89
Entweder alle angegebenen Deklarationen oder keine (Reihenfolge unerheblich) müssen
vorkommen.
Beispiel für all:
<complexType name=“AuthorName“>
<all>
<element name=”firstName” type=”string”/>
<element name=”familyName” type=”string”/>
</all>
</complexType>
Der komplexe Datentyp AuthorName baut sich aus den beiden Elementen firstName und
familyName auf. Durch Angabe des Partikels all wird festgelegt, dass entweder beide Elemente
angegeben werden müssen oder keine. Wenn man für firstName einen Wert angibt, so muss dies
auch für familyName erfolgen.
Ein Partikel kann das minimale Vorkommen (minOccurs) oder das maximale Vorkommen (maxOccurs) eines Elementes innerhalb eines komplexen Datentyps angeben. Außerdem kann der Partikel
wieder eine Model Group, Wildcards oder eine Elementdeklaration beinhalten.
Beispiel:
<element name=„writtenBooks" type="String" minOccurs="0"
maxOccurs="unbounded"/>
Dieses Element kann innerhalb eines komplexen Datentyps enthalten sein. Der Basisdatentyp ist ein
string und es wird festgelegt, dass dieses Element entweder nicht vorkommt (minOccurs=0)
oder beliebig oft verendet werden kann. Dieser Teil eines komplexen Datentyps gibt den Namen von
Büchern an, die ein Autor bisher geschrieben hat. Entweder hat er noch kein Buch veröffentlicht oder
eine beliebige Anzahl von Büchern.
Felder (Arrays):
Felder werden an dieser Stelle stellvertretend für Kollektionen vorgestellt. Deren Aufbau und Präsentation gleicht dem Aufbau einer Liste. Eine zyklische Feldinitialisierung ist nicht erlaubt. Ein Feld
kann als Datentyp nicht wieder das aufrufende Feld sein, verschachtelte Felder sind aber erlaubt. Ein
Feld kann als Datentyp wiederum ein anderes Feld haben. Ebenso kann ein Feld aus einem komplexen
Datentypen bestehen.
Die grafische Darstellung eines Feldes baut sich aus der Komponente des Feldtyps auf. Ist dieser ein
einfacher Datentyp, so wird dessen Komponente angezeigt. Bei einem komplexen Datentyp wird die
Komponente, wie im vorigen Absatz beschrieben, aufgebaut und angezeigt. Der Anwender erhält als
Information angezeigt, dass es sich um ein Feld handelt und den Namen des Feldtyps. Außerdem wird
die Begrenzung des Feldes (minOccurs, maxOccurs) angezeigt, falls diese angegeben wurde. Im zusätzlichen Editorsegment wird eine Liste angezeigt, die die Elemente des einfachen Feldes beinhaltet.
90
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Felder können verschiedene Felddimensionen haben. Das Modell nimmt keine Einschränkungen einer
maximalen Felddimension vor. Ein fertig editiertes Feld wird jeweils in das Feld höherer Dimension
eingefügt. Als Beispiel wird die Editierung eines doppelten Feldes besprochen. Mehrdimensionale
Felder bauen sich analog auf. Bei einem doppelten Feld ist noch eine zweite Liste im zusätzlichen
Editorsegment angelegt. Sobald man das erste einfache Feld editiert hat, kann man durch Druck auf
einen Button dieses einfache Feld in das doppelte Feld einfügen. Danach wird die Anzeige im einfachen Feld zurück gesetzt und ein neues einfaches Feld kann eingegeben werden. Möchte man ein bereits eingefügtes einfaches Feld nochmals editieren, so muss zunächst im doppelten Feld ein einfaches
Feld ausgewählt werden. Dieses einfache Feld wird dann in der Anzeige für das einfache Feld aufgelistet. In dieser Auswahl kann man dann wiederum ein Element auswählen, das dann in der normalen
Eingabemaske angezeigt wird und editiert werden kann. Mehrdimensionale Felder bauen sich ebenfalls analog nach diesem Schema auf.
Beispiel eines Feldes:
<complexType name="KeyWordSearchArray">
<complexContent>
<restriction base="Array">
<attribute ref="arrayType" arrayType="string[][]"/>
</restriction>
</complexContent>
</complexType>
Das Beispiel zeigt ein doppeltes Feld, das aus dem einfachen Datentyp string besteht. Dieses Beispiel wird im sechsten Kapitel nochmals angeführt und die grafische Präsentation angezeigt.
4.4 Einbettung semantischer Informationen
WSDL-Dokumente beschreiben die Schnittstelle zu einem Web-Service und wurden primär entwickelt, um von Parsern gelesen zu werden und danach den präsentierten Web-Service dynamisch in
Applikationen einzubinden. Die maschinelle Verarbeitung steht dabei im Vordergrund. Maschinen
benötigen keine semantischen Informationen über einen verwendeten Dienst. Sie extrahieren die Informationen und Daten des WSDL-Dokumentes und Verarbeiten die gesendeten und empfangenen
Daten. Für Anwender ist es allerdings wichtig semantische Informationen zu erhalten, um den WebService richtig zu nutzen und zu verstehen.
WSDL und XSD machen keine Vorgaben für Entwickler, dass diese semantische Informationen mit
einbinden müssen. Vorgeschrieben ist lediglich die Einhaltung einer korrekten Syntax. Ein Beispiel
dafür ist die Namensgebung von Parametern und Operationen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
91
Eine Addition mit zwei Ganzzahlwerten könnte man in WSDL folgendermaßen darstellen:
<wsdl:message name="xyz">
<wsdl:part name="userName" type="xsd:int"/>
<wsdl:part name="password" type="xsd:int"/>
</wsdl:message>
Für eine Maschine ist lediglich der Datentyp und Anzahl der Parameter zur Anfrage an den WebService wichtig, damit die richtigen Werte übergeben werden und der Name der Operation. Da der
Prototyp die GUI generisch aus dem WSDL-Dokument aufbaut und keine weiteren Dokumente zur
Verfügung hat, kann er nach dem Parsen auch lediglich die angegeben Namen in der GUI anzeigen.
Der Anwender würde in diesem Beispiel in der Eingabemaske für eine Addition zwei Felder für
Ganzzahlwerte sehen mit den entsprechenden Namen userName und password. Durch die Namensgebung wäre dem Benutzer nicht intuitiv klar, dass es sich hier wirklich um eine Addition handelt und nicht um einen Einwahlvorgang. Durch dieses Beispiel soll eine entscheidende Schwäche des
Modells, aber auch von WSDL aufgezeigt werden. Da der Prototyp lediglich vorhandene Namen aus
dem WSDL-Dokument zur Darstellung verwenden kann, ist der Anwender auf eine menschenlesbare
Wahl der Namen durch die Entwickler angewiesen. Die GUI-Generierung aus folgendem WSDLAusschnitt wäre für den Anwender leichter verständlich und würde nicht irritieren.
<wsdl:message name="summation">
<wsdl:part name="addend1" type="xsd:int"/>
<wsdl:part name="addend2" type="xsd:int"/>
</wsdl:message>
Wünschenswert wäre die Aufnahme einer semantischen Namensgebung in einer der folgenden
WSDL-Spezifikationen. Eine komplett semantisch zweifelsfreie Namensgebung wird eher unwahrscheinlich sein, aber erste Richtlinien würden die generische Erzeugung einer GUI für Anwender erleichtern.
Semantik kann nicht nur durch Verwendung von eindeutigen Namen erreicht werden, sondern auch
durch gezielte Dokumentation. Ein Datentyp Adresse kann unterschiedlich verwendet und interpretiert werden. Eine Unterscheidung allein durch den Namen ist in diesem Fall nicht möglich. Innerhalb
eines WSDL-Dokumentes kann der gleiche Datentyp Adresse zur Angabe der Privatanschrift und z.
B. des Arbeitsplatzes verwendet werden. Diese Mehrdeutigkeiten kann eine WSDL-interne Dokumentation beheben. Zu jedem Parameter kann eine Dokumentation hinzugefügt werden, dadurch kann der
Benutzer die Verwendung des Parameters leichter verstehen. Denn lediglich der Name des Parameters
reicht oft nicht zur unmissverständlichen Erkennung. Im Modell soll diese Möglichkeit zur Verfügung
gestellt werden, auch wenn die Dokumentation zurzeit noch nicht ausreichend von den Web-ServiceAnbietern genutzt wird. Das Modell bietet die Möglichkeit, Dokumentation auf drei Ebenen anzubieten. Eine Dokumentation kann für einen Parameter, eine Operation oder einen ganzen Port angegeben
werden.
92
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Wird für einen Parameter auch eine Dokumentation im WSDL-Dokument gefunden, so wird bei der
zugehörigen grafischen Komponente ein Informationsbutton hinzugefügt. Durch Anklicken wird diese
in einem separaten Fernster aufgeführt. Alternativ könnte man auch alle Dokumentationen für die
Parameter einer Operation gebündelt innerhalb einer Hilfeseite anbieten. Allerdings würde diese Seite
dann sämtliche Dokumentationen zu den Parametern führen. Bei steigender Komplexität ginge leicht
der Überblick verloren. Deshalb fiel die Entscheidung zur Realisierung dieser Hilfefunktion in Form
von individuellen Buttons. Ein weiterer Vorteil dieses Entwurfs liegt in der transparenten Bekanntmachung der Dokumentation. Wären sämtliche Informationen innerhalb einer Hilfeseite, so müsste man
diese erst durchsuchen, um die gewünschte Information zu erhalten. Ist die Information aber gar nicht
vorhanden, so entdeckt der Anwender dies erst nach gründlichem Studium der Hilfeseite. Wird allerdings für jede vorhandene Dokumentation zu einem Parameter ein Button generiert, entfällt die Suche.
Ist zu einem Parameter kein Button generiert worden, so wird dem Anwender sofort signalisiert, dass
keine Dokumentation vorhanden ist.
Zusätzlich könnten die Dokumentationen auch immer zu dem gerade aktivierten Parameter automatisch in der Statusanzeige oder einem Extrafenster angezeigt werden. Die Statusanzeige ist primär zur
Anzeige von Fehlern vorgesehen. Sobald ein Fehler auftritt, wird er in der Anzeige angegeben. Aus
diesem Grund kann die Dokumentation nicht in der Statusanzeige angeführt werden. Daher müsste die
dauerhafte Anzeige der Dokumentationen in einem Extrafenster realisiert werden. Sobald eine Eingabekomponente aktiviert wird zur Eingabe der Daten, könnte die zugehörige Dokumentation im separaten Fenster angezeigt werden. Dies würde allerdings den Bearbeitungsfluss stören. Der Anwender
würde unnötig von der Eingabe seiner Daten abgelenkt werden. Bei der Anzeige in einem Extrafenster
würde der Text der Dokumentation bei jedem Wechsel des Parameters durch den Fokuswechsel auch
seinen Inhalt variieren. Selbst wenn dies in einem Extrafenster durch geführt wird, so wird der Anwender dennoch davon Kenntnis nehmen und abgelenkt werden. Daher wird die zusätzliche Information zu einem Parameter durch einen Button angeboten, der nur bei Gebrauch aktiviert wird.
Zusätzlich können Dokumentationen zu einer Operation oder einem Port angezeigt werden. Falls eine
Dokumentation zu einer Operation vorliegt, wird im unteren Segmentbereich des Editors ein entsprechender Button generiert. Die Dokumentation des korrespondierenden Ports wird ebenfalls mit angezeigt. Da jede Operation im Kontext des Ports benutzt wird, können diese Informationen im Zusammenhang mit den Informationen des Ports stehen. Anders als bei den Parametern kann hier keine Informationsüberflutung entstehen, da lediglich die Information zu einem Port angezeigt wird. Des Weiteren kann eine Operation innerhalb mehrerer Ports verwendet werden. Daher ist es unter Umständen
wichtig zu wissen, welche spezifischen Unterschiede diese Ports aufweisen und in welchem Zusammenhang die Operation verwendet wird.
Die Reihenfolge bei der Darstellung der Parameter sollte bei der Generierung der GUI nicht geändert
werden. Bei vorhandenem Platz auf einer Ebene könnte man zwar vom Platzverbrauch kleinere Kom-
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
93
ponenten noch zu einer Ebene dazu fügen, um den Platz optimal zu nutzen. Dieses Vorgehen ist allerdings durch das Modell nicht erlaubt. Die Reihenfolge der Parameter soll beibehalten werden, da darin
evtl. auch semantische Informationen des Entwicklers stecken. Eine Eingabe im hinteren Bereich der
Operation könnte sich auf Eingaben davor beziehen. Eine Umstrukturierung der Parameter könnte so
Probleme bereiten. Beispielsweise könnte der Anwender aufgefordert werden seine private und seine
geschäftliche E-Mail-Adresse anzugeben. Danach wird gefragt welche E-Mail-Adresse bevorzugt
verwendet werden soll, um aktuelle Informationen über Angebote zu senden. Erfolgt diese Abfrage
zuerst, weiß der Anwender nicht, was mit dieser Frage gemeint ist. Daher wird bei der Generierung
der GUI die Reihenfolge stets beibehalten, auch wenn dadurch u. U. Lücken am unteren Ende einer
Ebene entstehen, falls die nächste, darzustellende Komponente das restliche Platzangebot übersteigt.
Bei der Entwicklung des Modells wurden somit Möglichkeiten geschaffen, semantische Aspekte zu
verwirklichen. Durch den späteren Prototypen soll herausgearbeitet werden, dass eine semantisch einwandfreie Interpretation der angezeigten Daten erreicht werden kann. Auch wenn diese Daten generisch erzeugt werden und somit eine Kontrolle des GUI-Aufbaus zur Laufzeit nicht möglich ist. Durch
die Entwicklung dieses Modells sollten einige Anregungen gegeben und später in der Realisierung
gezeigt werden, dass das Modell in der Praxis einsetzbar ist. Sämtliche Vorgaben müssten allerdings
erst einmal von den Web-Service-Anbietern übernommen und verwirklicht werden.
4.5 Zusammenfassung
In diesem Kapitel wurde das Modell für den Prototypen sukzessive nach dem Top Down Verfahren
entwickelt. Zunächst wurde die Beschreibung des Gesamtsystems aus der Sicht des Anwenders geschildert, um einen Überblick über die einzelnen Interaktionsschritte bei der Benutzung des Systems
zu erhalten.
Der anschließende Aufbau der grafischen Oberfläche erfolgte in zwei Schritten. Zunächst werden alle
Web-Services und deren Operationen angezeigt. Aus dieser Auswahl kann der Anwender eine Operation auswählen. In einem zweiten Schritt werden dann die Details dieser Operation in einer Eingabemaske angezeigt. Dieser zweigeteilte Aufbau ist erforderlich, um einen schnellstmöglichen GUIAufbau zu gewährleisten und somit nur die nötigsten Informationen aus dem WSDL-Dokument zu
extrahieren.
Des weiteren wurden die einfachen und komplexen Datentypen und ihre grafischen Eingabekomponenten vorgestellt. Ein einfacher Datentyp baut sich entweder aus einer Auswahlbox auf, wenn der
Wertebereich überschaubar klein ist, oder aus einem Eingabefeld. Die Eingabemaske für eine Operation baut sich sukzessive aus den einzelnen Komponenten auf. Die Anzahl der Parameter innerhalb
einer Operation kann beliebig komplex sein, da sich die Komponenten bei Übersteigung des Platzbedarfs generisch auf mehrere Ebenen verteilen. Schließlich wurde versucht eine Sensibilisierung zur
Schaffung semantischer Informationen innerhalb eines WSDL-Dokumentes zu geben. Das Modell ist
94
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
zwar in der Lage sämtliche WSDL-Dokumente in der GUI darzustellen, ob die abgebildeten Informationen aber vom Anwender verstanden werden, kann nicht garantiert werden. Das Modell bietet die
Möglichkeit gezielte Dokumentationen anzuzeigen, diese müssen aber vom Web-Service-Anbieter
auch bei der Erstellung des WSDL-Dokumentes integriert werden.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
95
Kapitel 5: Realisierung
Nach dem Entwurf des Modells zur Generierung der GUI wird in diesem Kapitel die Realisierung des
Modells durch die Entwicklung eines Prototypen vorgestellt. Der Prototyp realisiert das entworfene
Modell und zeigt die Umsetzung der erarbeiteten Ergebnisse.
Zunächst wird die Architektur des Frameworks erläutert und durch zwei statische Strukturdiagramme
illustriert. Die Architektur wird dabei in zwei Verfeinerungsschritten aus dem Modell entwickelt. Ein
UML-Paketdiagramm stellt zunächst die verwendete Package-Struktur (Paket-Struktur) des Prototypen vor. Im nächsten Verfeinerungsschritt werden in einem UML-Klassendiagramm einzelne Klassen
und ihre Funktionen innerhalb des Prototypen vorgestellt. Anschließend wird der Aufbau und die Generierung der grafischen Komponenten eingeführt. Dazu werden die beteiligten Klassen nochmals
genauer untersucht und der Prozess vom Extrahieren der Informationen aus dem WSDL-Dokument bis
zum Fertigstellen der grafischen Komponenten für einzelne Parameter beschrieben. Darauf folgend
wird der Aufbau der Eingabemaske der GUI diskutiert, die sich aus den grafischen Komponenten aufbaut und diese übersichtlich anordnet. Anschließend wird das eingesetzte Verfahren zum Binden des
Client an einen Web-Service erörtert. Darauf aufbauend wird in diesem Zusammenhang das Senden
von binären Daten angesprochen. Diese können kodiert und innerhalb der SOAP-Nachricht gesendet
werden oder als Anhang im ursprünglichen Format hinzugefügt werden. Zum Schluss findet eine Zusammenstellung der wichtigsten Punkte der Realisierung statt.
96
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
5.1 Architektur des Frameworks
Die Architektur des Frameworks beschreibt die Realisierung und Umsetzung des Modells. Das UMLPaketdiagramm in Abbildung 23 zeigt zunächst die Package-Struktur und die Kommunikation zwischen den einzelnen Packages. Somit wird ein erster Gesamtüberblick über den Prototypen vermittelt.
«verwendet»
«verwendet»
guiFramework
«verwendet»
«verwendet»
externPrg
xsdDatatypes
«verwendet»
resources
«verwendet»
«verwendet»
libraries
Abbildung 23: UML-Paketdiagramm des Prototypen
Das Package guiFramework stellt das zentrale Package innerhalb des zu entwickelnden Prototyps
dar. In diesem Package wird die grafische Oberfläche des Frameworks generiert, das WSDLDokument geparst, Eingaben des Benutzers validiert, Eingaben für komplexe Datentypen persistent
gespeichert und der Sende- und Empfangsvorgang in Kombination mit der Axis-Engine durchgeführt.
Wegen der zentralen Bedeutung dieses Packages innerhalb des Prototypen wird es im folgenden Klassendiagramm detailliert beschrieben. Dieses Package greift zur Erstellung seiner Dienste auf andere
Packages zu. Das Package externPrg ist als Schnittstelle zum Einbinden externer Programme vorgesehen. Bei Erweiterung des Prototypen können hier externe Programme zum Editieren der Datentypen eingebunden werden. Zur Demonstration wurde ein Programm zur grafischen Darstellung von
Datumseingaben eingebunden. Für Datumseingaben steht also nicht nur die normale generierte Komponente innerhalb der Eingabemaske zur Verfügung, sondern auch die Möglichkeit über ein zusätzliches Fenster Eingaben zu betätigen. Prinzipiell könnte bei einer Erweiterung des Prototypen in diesem
Package für jeden Datentyp ein Programm zur externen Editierung involviert werden.
Neben dem Package guiFramework stellt das Package xsdDatatypes das zweite zentrale Package des Prototypen dar. Innerhalb dieses Packages wird für jeden der zurzeit 44 einfachen XSDDatentypen eine eigene Klasse zur Speicherung der Eingabedaten, Erzeugung der grafischen Eingabekomponente und Validierung bereit gestellt. Die Struktur dieser Klassen unterliegen einem einheitlichen Modell. Der Aufbau einer Klasse wird im Kapitel 6.2 vorgestellt und im Anhang (Kapitel 8.5)
befindet sich beispielhaft ein Programmlisting für den Datentyp float. Zusätzlich enthält das Packa-
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
97
ge Klassen für Fassetten und Kollektions-Datentypen. Angesprochen werden alle Klassen über eine
Wrapper-Klasse, die ein einheitliches Interface für alle Datentyp-Klassen bietet und diese transparent
kapselt. Anfragen an eine Datentyp-Klasse werden an den Wrapper gesendet, der die Daten durch ein
Mapping an die entsprechende Klasse des Datentyps weiterleitet.
Im Package resources befinden sich Dateien, die innerhalb des guiFrameworks zum Aufbau
der GUI benötigt werden. Darin enthalten sind alle Bilddateien, Skripte mit landesspezifischen Texten
und sämtliche lokalen HTML-Seiten, die innerhalb der Hilfefunktion angezeigt werden. Das letzte
Package libraries beinhaltet alle verwendeten JAR-Dateien, die von allen anderen Packages verwendet werden. Darunter befinden sich u. a. JAR-Dateien von Axis, Xerces oder Sun Microsystems.
Auf die einzelnen JAR-Dateien wird an dieser Stelle nicht weiter eingegangen.
Abbildung 24 zeigt im nächsten Verfeinerungsschritt das UML-Klassendiagramm der beiden Packages guiFramework und xsdDatatypes. In diesem Klassendiagramm werden lediglich die Klassen aufgeführt ohne auf Interna einzugehen. Zur besseren Übersicht wurden die Methoden nicht aufgeführt. Die Funktionen der einzelnen Methoden werden allgemein in der Beschreibung der Klasse mit
integriert.
guiFramework
xsdDatatypes
«verwendet»
Helper
Reutilisation «verwendet»
XSDDateTime
«verwendet»
GuiBuilder
ButtonFactory
«verwendet»
«verwendet»
«verwendet»
«verwendet»
ComponentFactory «verwendet» «Schnittstelle»
XSDWrapper
«verwendet»
XSDString
«verwendet»
XSDFacettes
«verwendet»
ExtraWindow
WSDLFactory
SynchronisationFactory
Abbildung 24: UML-Klassendiagramm des Prototypen
Zentrale Klasse innerhalb des guiFramework-Packages bildet die Klasse GuiBuilder. Diese
Klasse erstellt die grafische Oberfläche und stellt Anfragen an andere Klassen innerhalb des Packages.
Die Klasse erzeugt das Menü, die Symbolleiste (Toolbar), die Hilfefunktion und präsentiert die Eingabemaske zum Editieren der Anfrage und Anzeige der Antwort. Die Klasse ButtonFactory generiert diverse Buttons für GuiBuilder, darunter u. a. ein Informations-, Sende-, Reset- und CloseButton für jede Operation und ein Navigationspanel, falls die Eingabemaske über mehrere Ebenen
hinweg die Parameter anzeigt. Bei jeder neuen Operation wird neben der Eingabemaske auch die Buttons generiert und im Editorsegment angezeigt.
98
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
In der Klasse ExtraWindow können zusätzliche Fenster erzeugt werden zum Anzeigen von Informationen, Hilfethemen, grafische Eingabemöglichkeit von Datumsangaben und Dokumentationen aus
dem WSDL-Dokument. Durch die zusätzlichen Fenster wird eine Informationsüberflutung im Hauptfenster verhindert und somit die übersichtliche Darstellung bewahrt. Außerdem können die separaten
Fenster bei der Bearbeitung der Anfrage im Hintergrund geöffnet bleiben und bei Bedarf eingesehen
werden. Dies ist vor allem bei der Hilfefunktion von Vorteil, die dem Anwender nach dem Öffnen zur
Verfügung steht, aber durch die Darstellung in einem separaten Fenster den normalen Programmfluss
nicht stört.
In der Klasse WSDLFactory wird das WSDL-Dokument geparst und alle benötigten Informationen
zum Erstellen der grafischen Oberfläche GuiBuilder zugänglich gemacht. Sämtliche Elemente des
WSDL-Dokumentes werden extrahiert und in dieser Klasse gespeichert. Zusätzlich werden sämtliche
Dokumentationen einzelner Elemente aufbereitet zur späteren Anzeige. Nach Anfrage des Anwenders
können diese in der GUI dargestellt werden.
Über die Klasse Reutilisation können bereits getätigte Eingaben für komplexe Datentypen geladen und wieder verwendet werden. Vor jedem Sendevorgang werden die Daten der Eingabemaske für
jeden komplexen Datentypen nach einer Abfrage gespeichert. Bearbeitet der Anwender eine Operation, die komplexe Datentypen verwendet und für die bereits Eingaben getätigt wurden, so können diese
wieder verwendet werden.
Die Klasse ComponentFactory dient als Schnittstelle zum Package xsdDatatpyes. Innerhalb
der ComponentFactory werden die einzelnen grafischen Komponenten für die Parameter einer
Operation zusammengestellt. Besteht ein Parameter aus einem komplexen Datentyp, so wird
WSDLFactory kontaktiert, damit dieser Datentyp geparst wird. Sind die einzelnen Datentypen bekannt, so wird über die Klasse XSDWrapper eine Anfrage gestellt, um die grafische Komponente des
jeweiligen Datentyps zu erhalten. Die Klasse XSDWrapper wird als Interface benutzt und leitet alle
Anfragen an die jeweiligen Klassen weiter (stellvertretend wurden einige Klassen aufgelistet). Nach
Erhalt der grafischen Komponenten für alle Datentypen werden diese in einer Eingabemaske gruppiert
und wieder zurück an die Klasse GuiBuilder geleitet, um sie in der GUI anzuzeigen. Das nachfolgende Unterkapitel beschreibt nochmals detailliert diesen Sachverhalt.
Die Klasse SynchronisationFactory wird zum Synchronisieren der Daten vor dem Senden
und dem Empfang verwendet. Für einfache Datentypen, komplexe Datentypen und binäre Daten stellt
die Klasse Serialisierer bereit. In Kapitel 5.4 wird ein Beispiel angeführt. Schließlich beinhaltet die
Hilfsklasse Helper einige Methoden, die von mehreren Klassen verwendet werden. Die Klasse enthält z. B. Methoden zum Ausführen von WSDL2Java und TCP-Monitor, zum Auslesen des Datenstroms einer WSDL-URL oder Datei oder zum Erzeugen von Objekten der generierten Klassen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
99
5.2 Aufbau der grafischen Komponenten
Der Aufbau der grafischen Komponenten für die Parameter einer Operation aus den Daten des WSDLDokumentes stellt eine zentrale Funktion innerhalb der GUI-Generierung dar. Aus diesem Grund wird
in Abbildung 25 der Prozess zum Aufbau einer grafischen Komponenten illustriert und die beteiligten
Klassen vorgestellt. Die Abbildung zeigt die fünf beteiligten Klassen und durch nummerierte Pfeile
wird der Datenaustausch zwischen ihnen chronologisch dargestellt.
GuiBuilder
1: Operationsname
9: Eingabemaske
8: Aufbau der
Eingabemaske
2: fordert Datentypen an*
ComponentFactory
-getComponent()
WSDLFactory
3: Liste der Datentypen*
7: grafische
4: fordert graf. Komponente für XSD-
Komponente
Datentyp
5: erzeugt Instanz
XSDWrapper
Java-Datentyp
- Mapping
- Eingabekomp.
- Validierung
6: grafische Komponente
Abbildung 25: Aufbau der grafischen Komponenten
Der Ausgangspunkt zum Generieren der Komponenten stellt die Selektion einer Operation dar. Nachdem eine Operation durch den Anwender ausgewählt wurde, müssen die Parameter der Operation
ermittelt werden. Die Klasse GuiBuilder übergibt der Klasse ComponentFactory den selektierten Operationsnamen (1). Zusätzlich wird auch der Portname übermittelt, damit die Operation eindeutig zugeordnet werden kann, da mehrere Ports die gleiche Operation verwenden können. Zum
Aufbau der GUI ist diese Information redundant, da die Operation immer die gleiche GUI generiert,
unabhängig vom verwendeten Port. Allerdings werden die erzeugten grafischen Komponenten im
Zusammenhang mit dem Portnamen gespeichert, damit beim Sendevorgang auch die richtigen Eingaben verwendet werden. Beispielhaft könnte eine Operation von zwei Ports angeboten werden und der
Anwender möchte beide Ports verwenden mit unterschiedlichen Daten. Daher wird für jeden Port eine
Eingabemaske für die Operation erzeugt und die Daten unabhängig voneinander gespeichert.
100
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Die Klasse ComponentFactory startet nun eine Anfrage in der Methode getComponent() an
die Klasse WSDLFactory und fordert alle Datentypen der eingehenden Nachricht (<input
message>) der ausgewählten Operation an (2). WSDLFactory ermittelt die Parameternamen der
Part-Elemente der eingehenden Nachricht und liefert eine Liste mit allen Parameternamen und deren
Datentypen zurück (3). Die Parameter samt Datentypen wurden zuvor in der WSDLFactory gespeichert und liegen nun für alle Operationen vor. ComponentFactory wertet nun in der Methode
nacheinander alle Parameter dieser Liste aus. Ist der Datentyp eines Parameters ein Basisdatentyp, so
wird mit dem 4. Schritt fortgefahren.
Bei einem komplexen Datentyp wird Schritt 2 und 3 modifiziert wiederholt, damit man die Basisdatentypen (z. B.: einfache Datentypen, Listendatentypen, Felder) ermitteln kann. Dafür wird die Methode getComponent() rekursiv aufgerufen und erneut eine Anfrage an die WSDLFactory gestartet. Bei einem komplexen Datentyp benötigt man zur Darstellung seine Basisdatentypen. Zur Einhaltung der Reihenfolge der Parameter muss zunächst der komplexe Datentyp komplett dargestellt
werden. Daher wird nun der komplexe Datentyp übermittelt (2*) und WSDLFactory parst das Datentyp-Element und extrahiert seine Parameter und Datentypen. Die Parameter und Datentypen des
komplexen XSD-Datentypen werden dann zurückgeliefert (3*) und diese neue Liste erneut ausgewertet. Durch den rekursiven Aufruf der Methode zur Zusammenstellung der Basisdatentypen wird die
Reihenfolge der Basisdatentypen eingehalten, da jeweils die Liste mit den restlichen Parametern gespeichert und nachträglich abgearbeitet wird. Zusätzlich wird bei jedem rekursiven Aufruf ein Ebenenzähler inkrementiert. Die Ebene gibt für einen Basisdatentyp an, wie viele komplexe Datentypen
um die Komponente geschachtelt sind.
Die Methode getComponent() der Klasse ComponentFactory enthält letztendlich mehrere
Listen mit Basisdatentypen (falls komplexe Datentypen vorhanden sind) oder eine Liste mit Basisdatentypen, die sukzessive abgearbeitet wird. Die Klasse XSDWrapper wird nun mit einem Basisdatentyp aufgerufen (4). Intern wird der Datentyp auf die entsprechende, stellvertretende Klasse abgebildet,
von der eine neue Instanz gebildet wird (5). Dadurch wird eine entsprechende grafische Komponente
und Validierungseinheit erzeugt (vgl. Modellbildung). Die grafische Komponente besteht aus einer
Eingabekomponente und einem Label, welches den Datentyp angibt (nächstes Unterkapitel stellt die
grafische Komponente nochmals detailliert vor). Diese Komponente wird wieder zurück an den
XSDWrapper geleitet (6), der die Komponente weiter an die ComponentFactory schickt (7). Die
grafische Komponente wird nun in die Eingabemaske eingefügt. Zuvor wird der grafischen Komponenten der Parametername zugeordnet und falls Dokumentationen enthalten sind im WSDLDokument für diesen Parameter zusätzlich ein Button. Im 8. Schritt werden die Schritte 4 bis 7 für alle
Basisdatentypen der Operation wiederholt. Bei einem Basisdatentyp innerhalb eines komplexen Datentyps wird die grafische Komponente durch den Wert des Ebenenzählers eingerückt. Neben dem
Einrücken der Komponenten, können zusammengehörige Komponenten zusätzlich durch einen umschließenden Rahmen gekennzeichnet werden. Dieser Rahmen wird verwendet zum Kennzeichnen
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
101
eines komplexen Datentyps innerhalb eines Feldes (siehe Kapitel 6.2). Zum Schluss wird die Eingabemaske zurück an die Klasse GuiBuilder geschickt, die die Eingabemaske im Editorsegment darstellt (9).
5.3 Anordnung der grafischen Komponenten
Im vorigen Unterkapitel wurde der Aufbau der grafischen Komponenten diskutiert und an dieser Stelle
soll die Anordnung dieser Komponenten in der GUI beschrieben werden. Während der Modellbildung
in Kapitel 4.3 wurde bereits der Grundaufbau der GUI eingeführt. In der Abbildung 26 wird dieser
Grundaufbau weiter verfeinert und zeigt die Umsetzung des Modells. Das Menü, die Symbolleiste und
das Statussegment wurden nicht weiter beachtet, da sie unabhängig vom WSDL-Dokument immer
identisch sind.
Servicesegment
Port-Liste
Operations-Liste
Port:Operations-Liste
Editorsegment
Operation XY
Eingabemaske
zusätzliches Editorsegment
einfacher Datentyp
Name
I
Typ+Eingabe Zusatzinfo
Kollektionen
komplexer Datentyp
Name
Name
x/y
I
I
Liste für Werte von
Typ+Eingabe Zusatzinfo
C
R
Binäre Daten anzeigen
Wieder verwendbare
Datentypen anzeigen
Typ+Eingabe Zusatzinfo
I
S
Abbildung 26: Anordnung der GUI-Komponenten
Das Servicesegment wird nach dem ersten Parsen des WSDL-Dokumentes mit Informationen der vorhanden Ports und Operationen gefüllt. Es werden drei Auswahlboxen zum Auswählen einer Operation
angeboten. Die beiden linken Auswahlboxen werden in Kombination zueinander verwendet. Die Linke Auswahlbox beinhaltet eine Liste mit allen Ports des WSDL-Dokumentes. Nach Auswahl eines
Ports werden alle korrespondierenden Operationen in der zweiten Auswahlbox angezeigt. In dieser
Operations-Liste kann eine Operation zum Editieren der Daten selektiert werden. Die dritte Auswahl-
102
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
box dient als Alternative und beinhaltet alle Operationen auf einmal und gibt jeweils den Portnamen
mit an.
Nach Selektion einer Operation wird ein Editorsegment geöffnet, das die Eingabemaske der Operation
beinhaltet und ein zusätzliches Editorsegment für weitere Daten. Jedes Editorsegment erhält einen
eindeutigen Namen. Wird die Operation von keinem anderen Port verwendet, so erhält das Editorsegment den Namen der Operation („Operation XY“ in Abb. 26). Ansonsten wird der Name des Ports mit
angegeben. Somit können mehrere Editorsegmente geöffnet werden und jeweils eindeutig über den
Namen ausgewählt und sichtbar gelegt werden. Jeweils eine Operation ist aktiv und wird angezeigt,
die anderen Operationen werden im Hintergrund gehalten und können durch Auswahl der Operation
aktiviert werden.
Bevor die grafischen Komponenten der Eingabemaske im Editorsegment angezeigt werden, wird zuerst die aktuelle Höhe des Segmentes ermittelt. Können nicht alle Eingabekomponenten auf einmal
angezeigt werden, so verteilen sich die Komponenten auf mehreren Ebenen. Sukzessive wird immer
eine Komponente der Eingabemaske auf die aktuelle Ebene hinzugefügt. Zur Berechnung des Platzbedarfs wird dabei die bevorzugte Höhe der Komponente herangezogen. Überschreitet die Summe der
eingefügten Komponentenhöhen die Segmenthöhe, so wird eine neue Ebene eingefügt. In diese werden die weiteren Komponenten aus der Eingabemaske eingefügt.
Im sichtbaren Editorsegment wurde beispielhaft eine Eingabemaske mit einem einfachen Datentyp
und einem komplexen Datentyp, der wiederum aus zwei einfachen besteht, skizziert. Die grafischen
Komponenten innerhalb des komplexen Datentyps werden eingerückt, damit die Zugehörigkeit zu
dem übergeordneten komplexen Datentyp erkenntlich wird. Die grafische Komponente für einen einfachen Datentyp besteht primär aus dem Namen des Parameters und einem Eingabefeld mit Angabe
des Datentyps. Zusätzlich kann bei vorliegender Dokumentation ein Informations-Button hinter den
Namen eingefügt werden und bei bestimmten einfachen Datentypen zusätzliche Informationen angegeben werden. Zu den Zusatzinformationen gehören u. a. die Angabe von Fassetten, ein weiterer Button zum externen Editieren der Eingabedaten oder weitere Informationen über den Datentyp.
Unterhalb der Eingabemaske befindet sich in jedem Editorsegment eine Interaktionsleiste. Links in der
Interaktionsleiste befinden sich 2 Buttons und eine Textanzeige. Durch die beiden Buttons kann zwischen den Ebenen gewechselt werden. Neben den beiden Richtungs-Buttons wird jeweils die aktuelle
Position im Bezug auf die Anzahl der Ebenen angezeigt. In der Mitte befindet sich ein InformationsButton zum Anzeigen von Dokumentationen über den Port und die Operation. Beinhaltet das WSDLDokument keine Dokumentation für den jeweiligen Port oder Operation, so wird dieser Button auch
nicht angezeigt. In der rechten Ecke der Interaktionsleiste befindet sich eine weitere Button-Gruppe.
Der linke Button schließt die Operation (Close), der mittlere Button setzt alle Eingaben der aktiven
Operation zurück (Reset) und der rechte Button leitet den Sendevorgang der Operation ein (Send).
Das zusätzliche Editorsegment wird verwendet, um weiterführende Informationen zu einem Parameter
anzuzeigen. Besteht der Parameter aus einem Kollektions-Datentyp (z. B. ein Feld), so wird in diesem
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
103
Editorsegment die Liste mit den einzelnen Einträgen für das Feld angezeigt. Bei binären Daten mit
bekanntem Inhalt, kann dieser im zusätzlichen Editorsegment angezeigt werden. Außerdem kann bei
der Wiederverwendung von Eingabedaten für komplexe Datentypen, diese bereits getätigten Eingaben
in einer Liste zur Auswahl angeboten werden. Im Kapitel Implementierung wird nochmals auf das
zusätzliche Editorsegment eingegangen und durch Beispiele die Verwendung verdeutlicht.
5.4 Realisierung des Bindings
In Kapitel 3.2 wurden drei Arten vorgestellt zum Einbinden eines Clients an einen Web-Service. Der
Client kann über Stubs, Dynamic Proxy, oder das so genannte Dynamic Invocation Interface (DII) an
einen Web-Service gebunden werden. Zur Realisierung des Prototypen wurde das Dynamic Invocation
Interface zum Aufrufen der entfernten Methoden des Web-Service verwendet. Bei der Verwendung
eines Stubs oder Dynamic Proxy müssen vor der Implementierung der Name der Methode und die
Namen der Parameter bekannt sein. Beim Stub müssen zusätzlich Informationen über den Namen des
Ports vorliegen. Der Prototyp wird allerdings unter der Annahme entwickelt, dynamisch zur Laufzeit
erst diese Informationen durch das WSDL-Dokument mitgeteilt zu bekommen. Der Prototyp ist also
nicht mit bestimmten Web-Services fest in einem Verbund stehend, sondern kann mit jedem WebService kommunizieren, der durch ein WSDL-Dokument beschrieben wird.
Beim Einbinden durch das DII wird ein Call-Objekt verwendet, welches vor dem Senden die benötigten Informationen übergeben bekommt (siehe Kapitel 3.2).
Vor dem Senden müssen dem Call-Objekt zusätzlich die Serialisierer und Deserialisierer für die
einzelnen Datentypen übergeben werden, damit die Daten der Parameter nach XML serialisiert, bzw.
beim späteren Empfang der Antwort wieder zurück in das ursprüngliche Format transformiert werden
können. Axis bietet dazu eine Reihe von (De-)Serialisierer an. Der Autor G. Bong listet in dem Artikel
„Apache SOAP type mapping, Part 1: Exploring Apache´s serialization API´s” [Bo02] Serialisierer für
einfache und komplexe Datentypen auf, die außerdem in der API von Axis in aktuellerer Form aufgeführt werden. Allerdings weist der Autor auch darauf hin, dass binäre Daten, je nach der Darstellung
im WSDL-Dokument, durch drei unterschiedliche Serialisierer nach XML transformiert werden können. Bei Verwendung des Datentyps base64Binary wird der Base64Serializer von Axis
verwendet und beim Datentyp hexBinary wird der HexSerializer eingesetzt. In beiden Fällen
werden die binären Daten durch das jeweilige Format kodiert und als Parameter dem Call-Objekt
übergeben. Beim Kodieren der binären Daten in das jeweilige Format steigt aber die Größe zur Darstellung der Daten. Bei base64Binary wird die Größe um etwa 50% gegenüber dem Originalformat erhöht und bei hexBinary verdoppelt sich sogar die Größe. [Ma04]
Daher kann die Datenmenge bei Verwendung dieser beiden Datenformaten schnell ansteigen und eine
Anfrage an einen Web-Service kann dadurch lange dauern. Binäre Daten können jedoch auch durch
104
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Angabe des MIME-Formats als Anhang einer SOAP-Nachricht zum Web-Service gesendet werden.
Die binären Daten müssen nicht kodiert werden, sondern können in ihrem ursprünglichen Format erhalten bleiben. Dadurch kann die Datenmenge gegenüber den anderen beiden Varianten verringert
werden. Werden die binären Daten als Anhang gesendet wird zur Serialisierung der
JAFDataHandlerSerializer von Axis verwendet.
Der Prototyp muss somit neben der Parameterübergabe an das Call-Objekt auch die Möglichkeit
realisieren die Daten als Anhang beizufügen.
5.5 Zusammenfassung
Zuerst wurden aus dem Modell zwei Strukturdiagramme erstellt, die einen Überblick über die Funktionalität des Prototypen festlegen. Daraufhin wurde der Aufbau der grafischen Komponenten für die
Parameter einer Operation beschrieben. Nachdem eine Operation in der GUI ausgewählt wurde, werden für alle Parameter die korrespondierenden grafischen Komponenten erstellt. Besteht ein Parameter
aus einem Basisdatentyp, so kann direkt die grafische Komponente erstellt werden und der Eingabemaske hinzugefügt werden. Ein komplexer Datentyp muss allerdings zuerst in seine Basisdatentypen
zerlegt werden, bevor er grafisch durch die Komponenten seiner Basisdatentypen dargestellt werden
kann. Die einzelnen Komponenten der Eingabemaske werden schließlich in einem Editorsegment
angeordnet. Komponenten eines komplexen Datentyps werden dabei eingerückt oder durch einen
Rahmen markiert. Übersteigt die Anzahl der Komponenten den sichtbaren Bereich des Eingabefensters, so werden die Komponenten unter Beibehaltung der Reihenfolge auf mehrere Ebenen verteilt.
Nach der Komposition der einzelnen Komponenten innerhalb der GUI wurde danach das verwendete
Verfahren zum Binden des Prototypen an einen Web-Service vorgestellt. Über das Dynamic Invocation Interface führt der Prototyp die Methoden des Web-Service aus. Bei diesem Verfahren können alle
relevanten Informationen zum Kontaktieren des Web-Service dynamisch zur Laufzeit eingebunden
werden. Vor dem Senden einer Anfrage an den Web-Service müssen zuvor alle Parameter der Anfrage
serialisiert werden. In diesem Zusammenhang wurde die Möglichkeit aufgezeigt, binäre Daten einerseits in kodierter Form als Parameter einer SOAP-Nachricht zu verwenden oder andererseits im Originalformat als Anhang beizufügen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
105
Kapitel 6: Implementierung
Der Prototyp wurde in der Programmiersprache Java1 entwickelt und die grafischen Komponenten mit
Java Swing realisiert. Zusätzlich zu der Swing-API wurde eine Erweiterung dieser API zum Entwickeln des Prototypen verwendet. Die Java GUI Programming Extensions (Java-GPE)2 sind eine Kollektion von Klassen zur Erstellung grafischer Oberflächen mit Java. Zunächst wird der Aufbau der
grafischen Oberfläche durch Swing-Komponenten erläutert. Danach wird die Abbildung einfacher
XSD-Datentypen auf Java-Klassen angesprochen und die Swing-Komponenten eingeführt. Mit dem
Werkzeug WSDL2Java des Projekts Axis wurden zum einen Klassen für komplexe Datentypen generiert und zum anderen der Prototyp an den jeweils verwendeten Web-Service gebunden. In diesem
Kapitel wird die Verwendung der generierten Klassen aufgegriffen und die Einbettung in den Prototypen vorgestellt.
Unterkapitel 3.4 zeigt eine Möglichkeit zum Einbetten von semantischen Informationen. Wie bereits
in der Modellbildung erwähnt, kann durch gezieltes Anzeigen von Dokumentationen die Eingaben für
den Anwender erleichtert werden. Durch drei Beispiele wird die Verwendung von Dokumentationen
verdeutlicht. Abschließend werden einige Implementierungsaspekte vorgestellt, um verschiedene
Schwerpunkte während der Entwicklung des Prototypen herauszustellen.
6.1 Gestaltung der grafischen Oberfläche
In diesem Unterkapitel wird der Aufbau der grafischen Oberfläche durch Java Swing-Komponenten
erläutert. Neben dem allgemeinen Aufbau der GUI wird zusätzlich der verwendete Layout-Manager
und der Aufbau des Menüs und der Symbolleiste vorgestellt.
Aufbau der GUI
Die GUI wurde nach den Vorgaben der Realisierung des Modells entwickelt (siehe Kapitel 5.3). Anhand einer grafischen Übersicht werden die einzelnen Swing-Komponenten eingeführt, die zum Implementieren der GUI verwendet wurden. Abbildung 27 bietet einen Gesamtüberblick über die generierte GUI.
1
Internetseite der Java-API 1.4.2: http://java.sun.com/j2se/1.4.2/docs/api/
2
Homepage von Markus Hillenbrand mit Dokumentationen und Downloadangebot der Java-GPE:
http://www.markus-hillenbrand.de/javagpe
106
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Abbildung 27: Aufbau der GUI
Nach dem Start des Prototypen baut sich das Hauptfenster des Programms auf, welches durch ein
HFrame1 implementiert wurde. Im oberen Bereich des Hauptfensters befinden sich das Menü und die
Symbolleiste. Beide Kontrollstrukturen werden später detailliert vorgestellt. Der übrige Teil der grafischen Oberfläche kann in drei vertikal angeordnete Segmente unterteilt werden. Jedes Segment wird
durch einen JPanel dargestellt. Jedes der Panels dient als Container zum Einfügen weiterer SwingKomponenten. Das obere Panel stellt das Service-Panel dar und beinhaltet Informationen über sämtliche Web-Services und ihre Operationen. Das mittlere Panel dient als Editor und wird zur Eingabe der
Benutzereingaben verwendet. Darunter schließt sich das Status-Panel an zur Anzeige von fehlerhaften
Eingaben.
Das Service-Panel besteht aus den drei Auswahlboxen zur Selektion einer Operation. Es werden drei
HComboBox–Elemente (Auswahlboxen) zum Auswählen einer Operation angeboten. Das mittlere
Panel nimmt räumlich den größten Platz in Anspruch. In diesem Editor-Panel werden die Parameter
einzelner Operationen editiert. Der Editor-Panel ist nochmals horizontal unterteilt. In der linken Hälfte
1
Alle Swing-Komponenten, die mit einem „H“ beginnen, entstammen der Java-GPE. Diese Komponenten er-
weitern jeweils die ursprüngliche Swing-Komponente. Sofern die Erweiterungen zum Verständnis der Komponenten nicht relevant sind, werden diese nicht angegeben und können in der API der Java-GPE nachgelesen
werden.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
107
wird die Eingabemaske für die ausgewählten Operationen angezeigt und in der rechten Hälfte werden
zusätzliche Informationen zu einzelnen Datentypen angebracht.
Für jede Operation wird ein JTabbedPane erzeugt und alle Parameter in der Eingabemaske angezeigt. Die Eingabemaske wird in einem HCardPanel gespeichert. Ein HCardPanel stellt eine
Erweiterung und Vereinfachung zu einem JPanel mit dem java.awt.CardLayout dar. In einem HCardPanel können auf verschiedenen Ebenen Swing-Komponenten angebracht werden und
jeweils eine Ebene sichtbar dargelegt werden. Die Komponenten werden dazu auf Karten (Cards)
verteilt, die in beliebiger Reihenfolge durch einen eindeutigen Namen sichtbar gelegt werden können.
Die Elemente der Eingabemaske werden auf mehrere Karten verteilt, wenn das Platzangebot nicht für
alle Komponenten ausreichend ist. Über die JButtons im Navigations-Panel kann zwischen den
Karten beliebig gewechselt werden.
Jeweils die aktivierte Operation ist sichtbar und der Anwender kann die einzelnen Parameter editieren.
Im Hintergrund befindliche, inaktive JTappedPanes können durch einen Mausklick innerhalb des
jeweiligen Etiketts (Tab) in den Vordergrund transferiert werden. Die jeweils aktivierte Eingabekomponente hat den Fokus und kann die Benutzerdaten entgegennehmen. Somit ist die Bearbeitung mehrerer Operationen durch Wechsel der JTabbedPanes möglich. Die Anzeige des Ergebnisses wird
ebenfalls in einer eigenen JTabbedPane dem Benutzer zur Einsicht angeboten.
Im unteren Bereich jeder JTabbedPane befindet sich eine Interaktionsleiste mit diversen
JButtons. Links befindet sich das Navigations-Panel und in der rechten Ecke des JTabbedPanes
befindet sich eine JButton-Gruppe. Liegt für die Operation oder deren Port eine Dokumentation vor,
so wird ein Button zur Anzeige generiert (linker Button). Der zweite Button v. l. setzt alle Eingaben
der aktiven Operation zurück, der dritte Button v. l. schließt die Operation und der rechte leitet den
Sendevorgang der Operation ein. In der rechten Hälfte des Editor-Panels werden zwei HCardPanels
eingesetzt. Für jeden Parameter einer Operation wird jeweils eine Ebene (Karte) in den
HCardPanels für weitere Darstellungen reserviert. Das untere Panel wird ferner zur Anzeige von
fehlerhaften Eingaben verwendet.
Layout
Als Layout-Manager wurde das GridBag-Layout ausgewählt, da es unter den vorhandenen LayoutManagern in Swing am besten geeignet ist für die gegebene Problemstellung. Dieser Layout-Manager
ist sehr flexibel und kann am besten komplexe Inhalte darstellen. Alle Komponenten werden in einem
Gitter (Netz, Rechteckschema) von Reihen und Spalten angeordnet. So spannt sich ein Netz aus einzelnen Zellen auf. Eine Komponente kann nun innerhalb einer Zelle platziert werden oder auch mehrere Zellen überspannen. Innerhalb einer Komponente (z. B. ein JPanel) kann wiederum ein Gitter
aufgespannt werden und mit weiteren Komponenten aufgefüllt werden. Dadurch kann die GUI sehr
detailliert aufgebaut werden und beliebige Verschachtelungstiefen aufweisen. Zusätzlich passen sich
108
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
die Größen der einzelnen Zellen proportional zu der Gesamtgröße des Fensters an. Beim Skalieren des
Fensters werden die Größen der Inhalte somit angepasst. Im Java Swing Tutorial, ein Unterkapitel des
Java Tutorials, findet der interessierte Leser weitere Informationen über das GridBag-Layout und weitere Layout-Manager von Swing [SUN04].
Menü und Symbolleiste
Das Menü (JMenu) ist aus den Untermenüs „File“, „Configuration“, „View“ und „Help“ aufgebaut.
Im Untermenü „File“ kann ein neuer Web-Service gestartet oder das Programm beendet werden. Zum
Starten eines neuen Web-Service wird ein Eingabefenster geöffnet, das die URL des WSDLDokumentes entgegennimmt. Danach wird aus dem WSDL-Dokument die GUI generiert. Das Untermenü „Configuration“ bietet die Möglichkeit das angegebene WSDL-Dokument in einem separaten
Fenster einzusehen oder speziell extrahierte Informationen und Dokumentationen aus dem WSDLDokument über Service-, Port- und Anbindings-Informationen zu erhalten. Im Untermenü „View“
kann das optische Erscheinungsbild der GUI verändert werden. Zusätzlich kann der TCP-Monitor von
Axis geöffnet werden, um ein- und ausgehende SOAP-Nachrichten einzusehen. Letztlich kann in diesem Untermenü eine Baumstruktur aller Ports mit ihren angebotenen Operationen dargestellt werden.
In diesem Baum kann navigiert werden, um eine Operation auszuwählen und sie im Editor anzuzeigen. Schließlich kann im letzten Untermenü, neben einer allgemeinen Information über das Programm, die Hilfefunktion ausgewählt werden. „Help“ öffnet die allgemeine Hilfeseite, von der aus die
Suche nach spezifischen Informationen gestartet werden kann.
Zum besseren Verständnis der einzelnen Menüpunkte wird beim Kontakt der Maus ein Tooltip mit
einer Kurzinformation angezeigt. Jeder Menüpunkt kann über eine Tastenkombination (Accelerator)
ohne vorherige Aktivierung des Menüs ausgewählt werden. Ist ein Menü aktiviert und das entsprechende Untermenü wird angezeigt, kann durch Druck des zugeordneten Buchstabens (Mnemonik) der
Menüpunkt ausgewählt werden. Die wichtigsten Menüpunkte wurden zudem separat in der Symbolleiste, die durch eine HToolBar implementiert wurde, zum schnelleren Zugriff ausgelagert. Zusätzlich wurde in der Symbolleiste eine weitere Hilfefunktion zugefügt. Der rechte Button „ContextHelp“
aktiviert einen Zeiger, mit dem eine Komponente der GUI angeklickt werden kann. Darauf wird eine
eigens für diese Komponente entwickelte Hilfeseite angezeigt. Diese Funktion wurde primär dazu
entwickelt, um Informationen über die Datentypen zu erhalten. Für jeden Datentyp wird eine Hilfeseite bereit gestellt. Abbildung 28 zeigt das Menü und Symbolleiste des Prototypen (as Untermenü „File“
wurde in die Grafik integriert).
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
109
Abbildung 28: Aufbau des Menüs und Toolbar
Das Eingabefenster zum Eingeben einer WSDL-URL kann somit über die Tastenkombination (Strg +
N), den Menüpunkt „New“ im Untermenü „File“ oder über den „New“-Button (linker Button) in der
Symbolleiste geöffnet werden.
Im Menü wurden zusätzliche Funktionen, wie der TCP-Monitor, die Baumstruktur und extrahierte
Informationen über das WSDL-Dokument integriert. Diese Informationen werden zum Erstellen einer
Anfrage und Empfang der Antwort nicht benötigt. Sie stellen lediglich zusätzliche Funktionen für
interessierte Anwender bereit. Damit der Programmablauf jedoch nicht unnötig gestört wird, wurden
diese Funktionen in das Menü ausgelagert.
6.2 Abbildung der Datentypen auf Java
Für einfache Datentypen generiert das Werkzeug WSDL2Java keine Klassen. Daher wurde zur Realisierung des Modells eine einheitliche Klassenstruktur entworfen und für jeden einfachen Datentyp
eine eigene Klasse vorbereitet. In jeder Klasse wird neben der Speicherung der Eingabewerte, auch die
Validierung und Erstellen einer Eingabekomponente durchgeführt.
Lediglich für benutzerdefinierte Datentypen werden Klassen generiert von WSDL2Java, die durch
get()-und set()-Methoden Zugriff auf die internen Datentypen bieten. Der Name für die Klasse
leitet sich aus dem Namen des Datentyps ab. Die Klassengenerierung bei verwendeten Fassetten wird
durch WSDL2Java nur unzureichend unterstützt. Lediglich für die Fassette enumeration wird eine
Klassenstruktur generiert, die zur Speicherung der Eingabedaten verwendet werden kann. Bei anderen
Fassetten wird entweder keine Klasse generiert, und das Auftreten der Fassette einfach ignoriert, oder
eine Klasse wird generiert, die nicht verwendet werden kann. Daher werden für alle Fassetten ebenfalls eine eigene Klasse entworfen. Diese Klasse prüft für einen gegebenen Datentyp samt der Benutzereingabe die Korrektheit der Eingabe durch Vergleich mit den angegebenen Fassetten. Nachfolgend
wird zuerst eine Klasse für einen einfachen Datentyp vorgestellt, danach folgen die Beschreibung einer Klasse für einen benutzerdefinierten, komplexen Datentyp und eine Klasse zur Speicherung von
Feldern (stellvertretend für Listen und Kollektionen).
einfacher Datentyp
Die Grundfunktionalität der Klasse für einen einfachen Datentyp baut sich aus der Bereitstellung einer
grafischen Komponente und die Validierung der Benutzereingaben auf. Im vierten Kapitel wurde ein
110
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Modell entwickelt, um für jeden Datentyp eine geeignete grafische Komponente zu ermitteln. Die
Klasse JComponent der Java Swing-API ist die Basisklasse für alle verwendeten grafischen SwingKomponenten zur Darstellung der grafischen Komponenten. Von dieser Klasse leiten sich die verwendeten grafischen Komponenten ab. Nachfolgend werden die Abbildungen der grafischen Komponenten auf ihr Java-Äquivalent vorgestellt werden. Diese vorgestellten Komponenten werden zur Darstellung der einfachen Datentypen verwendet und spezialisieren JComponent.
Ein Eingabefeld wird durch ein HFormattedTextField realisiert. Dieses Textfeld erweitert
JFormattedTextField, indem es u. a. zusätzlich eine Redo-Undo-Funktion anbietet. Das Textfeld bietet die Möglichkeit vordefinierte oder eigene Formatierungen durchzuführen, die nach jeder
Eingabe eines Zeichens aufgerufen werden. Somit können verschiedene Validierungen bereits durch
das Textfeld durchgeführt werden. Eine vordefinierte Formatierung ist z. B. das Festlegen einer
Nummerneingabe. Das Textfeld nimmt in diesem Fall nur Ziffern als korrekte Eingaben entgegen.
Diese erste Validierung der Eingabe kann danach durch Überprüfen von Wertebereichsübertretungen
verfeinert werden. Die Validierungsvorgaben für einen Datentyp leiten sich jeweils aus der XSDSpezifikation des Datentyps ab. Durch den Wertebereich des Datentyps werden die erlaubten Eingaben spezifiziert.
Eine Auswahlbox wird durch eine HComboBox realisiert. Dieser Komponente werden die einzelnen
Werte des Wertebereichs übergeben. Jeweils der ausgewählte Wert wird angezeigt und die anderen
Werte können aus einer aufspannenden Liste ausgewählt werden.
Für binäre Daten wird die Möglichkeit angeboten, eine Datei im Dateisystem zu suchen und danach
hochzuladen, um die Daten in der Datentyp-Klasse zu speichern. Die verwendete Komponente
HFileString besteht aus einem Button und einem Textfeld. Über den Button kann ein Auswahlfenster angezeigt werden, über das im Dateisystem navigiert werden kann. Nach Auswahl einer Datei
wird anschließend der Pfad im Textfeld angezeigt. HFileString wird ebenso beim Empfang von
binären Daten zum Speichern verwendet. Dazu wird lediglich der Modus geändert und die Daten werden in einer Datei mit frei wählbarem Namen gespeichert.
Zusätzlich zur grafischen Komponente wird ein Label (JLabel) erzeugt, das den Namen des Datentyps angibt. In dem Label werden auch verwendete Fassetten des Datentyps angegeben. Dadurch werden dem Anwender alle Restriktionen auf diesem Datentyp angezeigt und er kann dementsprechend
seine Eingaben betätigen.
Abbildung 29 zeigt die Swing-Komponenten zur Darstellung eines einfachen Datentyps.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
111
Abbildung 29: grafische Komponenten für einfache Datentypen
Die Abbildung zeigt für den Parameter „wrong_Value“ eine falsche Eingabe. Das Label des Textfelds
weist den Anwender darauf hin, welcher Datentyp verwendet werden soll. Dieser Datentyp (int)
erlaubt nur Ganzzahlwerte. Dementsprechend wird durch die Formatierung des Textfelds lediglich
Ziffern als Eingabe erlaubt. Bei Eingabe von Buchstaben oder Sonderzeichen erkennt die Klasse des
Datentyps den Fehler schon nach Eingabe des ersten falschen Zeichens und sendet eine Nachricht an
die Klasse GuiBuilder, welche den Fehler im Status-Panel anzeigt. Der Parameter „base64Binary“
ist ein binärer Datentyp. Daher wird ein Button angezeigt, der nach Mausklick ein Fenster zum Hochladen einer binären Datei öffnet. Aus dem Dateisystem kann eine Datei ausgesucht werden. Der Dateiname wird danach in einem Textfeld angezeigt. Bei bekanntem Datentyp (Bild oder Text) kann
zusätzlich der Inhalt der Datei in der rechten Hälfte des Editor-Panels angezeigt werden. Der Parameter „JFormattedTextField“ zeigt die Darstellung eines qualifizierten Namens (QName) an. Durch zwei
zusätzliche Textangaben wird der Anwender auf die richtige Verwendung der beiden Textfelder hingewiesen. Der dritte Parameter zeigt die Verwendung einer Combobox, die zwei Werte zur Auswahl
anbietet. Diese beiden Werte stellen den ganzen Wertebereich des Datentyps boolean dar und stehen dem Anwender in einer Liste zur Auswahl, die durch Mausklick auf den aktuell ausgewählten
Wert geöffnet wird.
Nachfolgend wird nun die Klassenstruktur für einfache Datentypen vorgestellt. Jede Klasse für einen
einfachen Datentyp ist nach der gleichen Grundstruktur aufgebaut. Ein Programmlisting für eine JavaKlasse des Datentyps float befindet sich als Beispiel im Anhang (Kapitel 8.5). Durch Bildung einer
Instanz der Klasse wird die grafische Komponente erzeugt und mit der Validierung verknüpft. Jede
112
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Klasse speichert die Benutzereingaben in einer Variablen value. Des weiteren hat jeder dieser Klassen Methoden, die über den Wrapper ausgeführt werden können:
getPanel():
Die Methode liefert ein JPanel zurück mit dem spezifischen JComponent und
dem JLabel. Bei einigen Datentypen wird zusätzlich noch ein beschreibender
Text (siehe Abbildung 29, QName) dem Panel zugefügt oder ein Button zum externen Editieren der Eingabedaten (siehe Kapitel 6.4).
getValue():
Die Methode wird verwendet, um die gespeicherte Eingabe der Variable value zu
erhalten. Die Methode wird vor dem Senden verwendet, um die Eingabe des Anwenders zu bekommen.
setValue(Object obj): Diese Methode übergibt einen Wert für die Variable value. Der
Wert wird zusätzlich in der grafischen Komponente angezeigt. Sie wird z. B. verwendet, um einen gespeicherten Wert eines einfachen Datentyps innerhalb eines
komplexen Datentyps bei der Wiederverwendung zu setzen.
setResult(Object obj):
Die Methode ruft setValue(Object obj) auf und zusätzlich
wird die grafische Komponente mit der Eigenschaft versehen, nicht mehr editierbar
zu sein. Bei der Anzeige eines Ergebnisses sollen die Werte nicht verändert werden
können und lediglich angezeigt werden.
reset():
Die Methode löscht den Wert der Variable value und setzt die grafische Komponente zurück. Ein Textfeld zeigt danach ein Leerzeichen an und die Combobox
wird auf den ersten Wert in der Liste gesetzt.
setFacettes(Object[] facettes): Diese Methode wird ausgeführt, falls Fassetten für
den Datentyp angegeben wurden. Dadurch wird die Validierung beeinflusst. Bevor
ein Wert gespeichert werden kann, wird zuerst die Klasse Fassettes mit allen
gesetzten Fassetten aufgerufen. Diese überprüft, ob diese Fassetten erfüllt sind. Das
übergebene Object[] hat die Länge 12. Für jede der 12 Fassetten kann ein spezifischer Wert aus dem WSDL-Dokument übergeben werden. Beispielhaft könnte
für den Datentyp token im WSDL-Dokument die Fassette minLength mit „5“
und die Fassette maxLength mit „10“ angegeben werden. Der Klasse des Datentyps werden an der jeweiligen Position innerhalb des Feldes diese beiden Werte
übergeben, ansonsten Null-Werte. Die Klasse Fassettes wird aufgerufen und
überprüft die Benutzereingabe mit den angegeben Fassetten und liefert das Ergebnis der Überprüfung. Bei einer Eingabe, deren Anzahl von Literalen kleiner als 5
und größer als 10 ist, würde eine Fehlermeldung durch die Klasse erzeugt, die
durch GuiBuilder angezeigt wird.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
113
benutzerdefinierter, komplexer Datentyp
Ein komplexer Datentyp baut sich letztendlich aus seinen Basisdatentypen auf, die innerhalb der Eingabemaske dargestellt werden. Der Aufbau eines komplexen Datentyps wurde bereits in Kapitel 5.2
vorgestellt. An dieser Stelle soll auf die grafische Präsentation, Speicherung der Eingabedaten und
Namenskonventionen eingegangen werden.
Abbildung 30 zeigt den komplexen Datentyp „bookEntryData“ der Operation „bookEntry“.
Abbildung 30: grafische Darstellung eines benutzerdefinierten, komplexen Datentyps
Der komplexe Datentyp „bookEntryData“ besteht aus zwei komplexen Datentypen („Author“ und
„Address“), zwei einfachen Datentypen („Title“ und „Key“) und einem Feld („Key_words“). Die letzten drei Datentypen sind Basisdatentypen und können direkt dargestellt werden. Die beiden komplexen Datentypen werden nochmals weiter zerlegt. Der Datentyp „Address“ besteht u. a. wiederum aus
einem komplexen Datentyp „Phone“. Sobald ein komplexer Datentyp innerhalb eines anderen komplexen Datentyps auftritt, wird er mit einem Bindestrich gekennzeichnet und seine unmittelbaren Parameter eine Ebene eingerückt. Befindet sich unter diesen Parametern wiederum ein komplexer, erfolgt wiederum eine Einrückung. Zusätzlich wird in diesem Beispiel ein separates Eingabefenster für
einen String angezeigt. Die Klasse des Datentyps String erzeugt neben dem normalen Eingabefeld
einen Button, über den ein separates Fenster geöffnet werden kann. In dem Beispiel wird für den Parameter „Title“ das separate Fenster geöffnet (rechts unten in der Abbildung). Die Eingabe im Fenster
und Textfeld wird synchronisiert und zeigt den identischen Text an. Der Parameter „Key_words“ ist
ein einfaches Feld aus String-Werten. Felder werden im nächsten Abschnitt separat erklärt. Der
114
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Parameter „Country“ ist eine Aufzählung von String-Werten. Auf dem einfachen Datentyp
String wurde in diesem Fall die Fassette Enumeration angewendet. Die Combobox zeigt alle
Werte dieser Aufzählung an. Der Anwender kann eins von drei Ländern aus der Liste auswählen.
Letztendlich zeigt der Parameter „Key“ die Fassette Pattern. Dieses Beispiel wurde aus der Modellbildung übernommen und kann dort eingesehen werden.
Anhand dieses Datentyps soll nun die Speicherung der einzelnen Eingabedaten und die spätere Speicherung in der generierten Klasse von WSDL2Java erklärt werden. Erst vor dem Senden werden alle
Eingabedaten angefordert und in die generierte Klasse eingefügt. Nachdem alle Eingaben in der generierten Klasse gespeichert sind, wird ein Objekt dieser Klasse dem Call-Objekt übergeben. Danach
erfolgt über das Call-Objekt der entfernte Methodenaufruf. Bei dieser Operation wird ein Objekt der
Klasse BookEntryData an das Call-Objekt übergeben.
Für alle Basisdatentypen wurde eine Klasse entwickelt im Prototypen, die die Eingaben des Anwenders speichert. Durch die Methode getValue() wird der Eingabewert für den Basisdatentyp zurückgeliefert. Die Klasse BookEntryData besitzt set()-Methoden für alle unmittelbaren Parameter („Author“, „Address“, „Title“, „Key“ und „Key_words“). Bei dem Parameter „Title“ wäre das z.
B. ein String. Für alle Basisdatentypen liegen die Werte vor und können gesetzt werden, aber für
die weiteren komplexen Datentypen („Author“ und „Address“) noch nicht.
Der Parameter „Title“ wird durch die Methode setTitle(String title) gesetzt. Der Parameter „Address“ wird allerdings durch die Methode setAddress(Address address) gesetzt.
Zum Speichern dieses komplexen Datentyps muss somit eine weitere komplexe Klasse Address
verwendet werden, die aber noch keine Werte gespeichert hat. Jeder innere, komplexe Parameter wird
ebenfalls durch eine generierte Klasse vertreten. Aus diesem Grund muss die Speicherung der Eingabedaten zuerst bei der innersten, komplexen Klasse durchgeführt werden. Wurden für eine innere
Klasse alle Werte gesetzt, so kann diese dann in der ihr umschließenden Klasse gesetzt werden.
Zur Realisierung der Speicherung aller Werte in der äußeren, komplexen Klasse wurde die Datenstruktur java.util.Stack (dt. Stapel) verwendet. Diese Datenstruktur eignet sich am besten zur
Implementierung der gegebenen Problemstellung, weil ein Stack nach dem LIFO-Prinzip (last in first
out) geleert wird. Der Stack wird bereits bei der Generierung der Eingabemaske gefüllt, indem immer
Objekte des komplexen Datentyps mit Objekten seiner unmittelbaren Parameter hinzugefügt werden.
In den Stack wird jeweils ein Object[] der Größe vier eingefügt. Das Object[] beinhaltet als
Vater (Position 0) ein Objekt der generierten Klasse des komplexen Datentyps. Als Kind (Position 1)
wird entweder ein Objekt des Basisdatentyps, der den Eingabewert speichert, oder ein weiterer innerer, komplexer Datentyp gespeichert. Zusätzlich wird der Name des Parameters (Position 3) gespeichert, um die richtige set()-Methode aufzurufen. Ferner wird an Position 4 vermerkt, ob es sich bei
dem Kind um einen Basis- oder komplexen Datentyp handelt. Der Stack wird während des rekursiven
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
115
Aufbaus der Eingabemaske gefüllt (siehe Kapitel 5.2), wobei der Vater immer der komplexe Datentyp
ist, dessen Basisdatentypen ermittelt werden.
Da der Stack wieder in umgekehrter Reihenfolge geleert wird, kann garantiert werden, dass ein innerer, komplexer Datentyp schon die Werte seiner Basisdatentypen gespeichert hat, bevor er in den ihn
umschließenden komplexen Datentyp gespeichert wird.
Bei der Abbildung der XSD-Namen auf Java-Namen muss schließlich noch auf einige Konventionen
geachtet werden. Axis bildet die Namen von XSD-Datentypen nach bestimmten Regeln auf JavaNamen ab. Da die generierten Klassen für komplexe Datentypen vom Prototypen zum Speichern der
Eingabedaten verwendet werden, müssen diese Konventionen beachtet werden. Ein komplexer XSDDatentyp wird durch einen qualifizierten Namen im WSDL-Dokument referenziert. Der Name der
generierten Java-Klasse ergibt sich aus dem lokalen Namen, der immer mit einem Großbuchstaben
beginnt. Die Java-Klasse wird zusätzlich einem Package zugeordnet, das sich aus dem Namensraum
des Datentyps ergibt. Der Datentyp mit dem Namensraum „www.icsy.de/myNamespace“ wird auf das
Package „de.icsy.www.myNamespace“ abgebildet. Die Axis-API bietet eine Methode an, die für einen
Namensraum den Package-Namen ermittelt. Alternativ könnte man das Werkzeug WSDL2Java konfigurieren, dass alle Datentypen in ein benutzerdefiniertes Package abgebildet werden. Allerdings entstehen dann Probleme, wenn im WSDL-Dokument zwei Datentypen den gleichen lokalen Namen
haben und nur durch ihren Namensraum unterschieden werden können. Daher wird die abgebildete
Package-Struktur beibehalten.
Des weiteren können bei der Bildung der Klassennamen für komplexe Datentypen Konflikte mit der
Javakonvention auftreten. Reservierte Namen wie z.B. „class“, „extends“ oder „implements“ werden
mit einem beginnenden Unterstrich auf Java abgebildet. Aus dem XSD-Namen „class“ entsteht die
Java-Klasse „_class“ (Umwandlung in einen Großbuchstaben am Anfang entfällt wegen dem Unterstrich). Namen, die reserviert sind innerhalb einer Klasse, wie z. B. „Object“, „String“, „int“ usw.
können als Klassennamen verwendet werden, da sie keine reservierte Bedeutung auf Klassenebene
haben. Zusätzlich werden noch weitere Abbildungsregeln festgelegt, wie z. B. führende Zahlen und
Leerzeichen werden entfernt, die aber nicht weiter erläutert werden. Die Namenskonvention gilt nicht
nur auf Klassenebene, sondern auch für die Parameter eines komplexen Datentyps.
komplexer Datentyp: Felder
Die Vorstellung der grafischen Präsentation und Speicherung von Feldern wird stellvertretend für
Listen- und Kollektions-Datentypen (wie z. B.: Vektoren, Map und Hashtable) ausgeführt, da diese
Datentypen einen ähnlichen Aufbau haben.
Für Felder wurden beim Prototypen eine eigene Klasse implementiert, da die Unterstützung durch das
Werkzeug WSDL2Java nicht ausreichend ist. Für ein Feld, das innerhalb eines komplexen Datentyps
verwendet wird, generiert WSDL2Java keine eigene Klasse. Lediglich bei einem Feld ohne äußeren
116
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
komplexen Datentyp wird eine Holderklasse zur Speicherung der Daten generiert. Daher wurde zur
allgemeinen Behandlung von Feldern eine eigene Klasse implementiert. WSDL2Java unterstützt allerdings lediglich höchstens zweidimensionale Felder, bei der Speicherung eines Feldes innerhalb eines
komplexen Datentyps. Daher beschränkt sich die Realisierung im Prototyp auf diese Felddimension.
Einschränkende Fassetten in Feldern werden zwar von WSDL2Java ebenfalls nicht unterstützt, wurden aber dennoch übernommen aus dem Modell und separat entwickelt im Prototyp. Die Klasse für
ein Feld erzeugt ein eigenes Label, in dem der Name des Feldes und der Name des komplexen- oder
Basisdatentyps angezeigt wird. Zusätzlich können die verwendeten einschränkenden Fassetten angezeigt werden. Das Eingabefeld wird allerdings von der Klasse des Feld-Datentyps erzeugt. Durch die
Methode getPanel() kann man das Eingabefeld samt Label eines einfachen Datentyps erhalten.
Die Feldklasse ruft diese Methode bei der Feld-Datentyp-Klasse auf und fügt es zu seinem Label. Der
Feld-Datentyp kann entweder ein einfacher Datentyp sein oder ein komplexer, der sich wiederum aus
Basisdatentypen aufbaut. Bei einem komplexen Feld-Datentyp wird um diesen ein Rahmen gelegt,
damit der Anwender erkennt, dass alle Eingaben innerhalb dieses Rahmens, einen Wert des Feldes
darstellen. Abbildung 31 zeigt die Hervorhebung eines Feldeintrags.
Abbildung 31: grafische Darstellung eines Feldes mit komplexem Inhalt
Aus dieser Abbildung wird ebenfalls deutlich, dass sich die Eingabemaske für ein Feld aus den Eingabefeldern der Basisdatentypen aufbaut. Ein Eintrag im Feld baut sich demnach aus den beiden Basisdatentypen „forename“ und „name“ auf. Die beiden Textfelder wurden von den jeweiligen Basisdatentypen erzeugt und lediglich durch die Klasse des Feldes innerhalb eines Rahmens angezeigt. Die
nächste Abbildung zeigt ein doppeltes Feld. Anhand dieser Abbildung wird die grafische Präsentation
eines Feldes erläutert und zusätzlich auf die interne Struktur der Klasse eingegangen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
117
Abbildung 32: grafische Darstellung eines doppelten Feldes
Zum Einfügen eines Eintrags in das Feld stehen zwei Buttons zur Verfügung. Entweder kann der Wert
ans Ende eingefügt werden (Button „last“ in Abb. 32) oder an der Stelle, die mit dem Cursor zuvor
markiert wurde (Button „cursor“ in Abb. 27). In dem zusätzlichen Editor-Panel werden dann beide
Felder durch eine Liste (JList) dargestellt. Die obere Liste präsentiert das einfache Feld, das nach
dem Editieren in das doppelte Feld (unten) eingefügt wird. Jedes Feld bietet die Möglichkeit an jeweils eine Position zu in- oder dekrementieren, ein Feldeintrag kann gelöscht oder wieder editiert
werden. Soll ein Eintag editiert werden, so wird sein Wert wieder in die Eingabemaske transferiert.
Beim doppelten Feld wird der Eintrag zuerst ins einfache Feld transferiert und dort kann wiederum ein
Wert ausgewählt werden zum Editieren in der Eingabemaske. Die Werte im Feld werden in einer Liste
aufgereiht und erst wenn das Feld zur weiteren Verarbeitung benötigt wird, werden die Felder in der
Klasse java.lang.reflect.Array gespeichert. Mit dieser Klasse kann dynamisch auf unbekannte Objektfelder zugegriffen werden. Ein weiterer Vorteil dieser späten Speicherung in einem Feld
ist, dass die Werte im Feld nicht ständig umgeordnet werden müssen. Die Reihenfolge der Werte kann
sich stets ändern durch Einfügen an einer Position oder durch Löschen eines Wertes.
6.3 Anzeigen von Dokumentationen
Um semantisch eindeutige Eingabemasken zu erstellen, bedarf es oft zusätzlicher Informationen. In
der Eingabemaske können lediglich der Name eines Parameters und dessen Typ angezeigt werden.
Aus diesen Informationen und evtl. noch dem Namen der Operation und dem Port muss der Anwender
Rückschlüsse ziehen auf die Verwendung des Parameters. In der Modellbildung wurde gezeigt, dass
es dabei zu Problemen kommen kann und eine eindeutige Verwendung der Parameter nicht immer
gegeben ist. Daher muss dem Anwender zusätzlich Hilfestellung angeboten werden, damit er zweifelsfrei seine Eingaben betätigen kann. Da WSDL die Möglichkeit der Dokumentation für jedes Element
anbietet, soll mit dem Prototypen gezeigt werden, wie diese sinnvoll eingesetzt werden kann. Die Vorraussetzung ist natürlich, dass der Web-Service-Anbieter entsprechende Dokumentationen in das
118
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
WSDL-Dokument einbettet. Im Modell wurden drei abstrakte Ebenen zum Einbetten der Dokumentation entwickelt. Eine Dokumentation kann für jeden Parameter, jede Operation und jeden Port angezeigt werden. Diese drei Möglichkeiten sollen nun an einem Beispiel verdeutlicht werden.
In Abbildung 33 werden einige Parameter innerhalb der Operation „enterBookForAuthor“ angeführt,
die namentlich zu Missverständnissen und Fehlinterpretationen führen. Es werden drei namentlich fast
identische Parameter direkt hintereinander dargestellt.
Abbildung 33: Einbinden von Dokumentationen für Parameter
Die drei Parameter tragen die Namen „Name1“, „Name2“ und „Name3“. Durch den Namen können
diese drei Parameter nicht unterschieden werden. Der Name der Operation wurde so gewählt, dass der
Anwender eine gewisse Vorstellung über den Inhalt und Verwendung der Parameter hat. Allerdings
kann mit dieser Information keine Eingabe durchgeführt werden.
Vor dem Eingabefeld ist für jeden dieser drei Parameter ein Informations-Button platziert. Durch
Klick kann die Dokumentation für den jeweiligen Parameter angezeigt werden. Aus dieser Dokumentation geht hervor, dass ein Parameter sich auf den Namen des Autors, einer auf den Namen des Buchs
oder der letzte auf den Namen des Verlags bezieht. Durch diese zusätzlichen Informationen kann nun
die Eingabe eindeutig durchgeführt werden.
Im nächsten Beispiel wird die Anwendung von Dokumentation auf Operationsebene verdeutlicht. Die
Operation trägt den Namen „enterPhone“ und als Eingabemaske wird ein komplexer Datentyp mit
zwei Eingabefeldern für die Vorwahl und Durchwahl angezeigt. Die Eingabe für die einzelnen Parameter ist in diesem Beispiel eindeutig. Allerdings ist die Verwendung dieser Operation nicht eindeutig. Durch den Namen der Operation wird nur suggeriert, dass eine Telefonnummer verlangt wird als
Eingabe. Es wird aber keine Angaben gemacht, ob z. B. die Telefonnummer des Autors oder des Verlags erwünscht ist. Abbildung 34 zeigt daher die Verwendung der Dokumentation auf Operationsebene.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
119
Abbildung 34: Einbinden von Dokumentationen für Operationen
Für Operationen wird der Informations-Button unterhalb der Eingabemaske angezeigt. Somit ist dieser
bei der Bearbeitung auf mehreren Ebenen innerhalb der Eingabemaske immer sichtbar. Die angezeigte
Dokumentation bettet die angezeigte Operation in einen Kontext. Dem Anwender wird mitgeteilt, dass
der Web-Service-Anbieter Informationen über die Autoren veröffentlichen möchte und daher für
Rückfragen die Telefonnummer der Autoren benötigt.
Im letzten Beispiel wird der Einsatz von Dokumentationen auf Portebene vorgestellt. Ein Port repräsentiert einen Web-Service, welcher durch einen Aufruf einer Operation kontaktiert wird. Daher ist die
Dokumentation für einen Port immer im Zusammenhang mit der angeboten Operation zu betrachten.
Die Dokumentation für einen Port wird immer durch den gleichen Button wie die Dokumentation für
eine Operation angezeigt. Das Beispiel in Abbildung 35 zeigt, dass die Operation „add“ von zwei
Web-Service-Anbietern (repräsentiert durch zwei Ports) angeboten wird. Der Port „Calculator“ und
„CalculatorXtra“ bieten beide die gleiche Operation an.
120
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Abbildung 35: Einbinden von Dokumentationen für Ports
Durch die Dokumentation wird dem Anwender mitgeteilt, dass der Web-Service-Anbieter „CalculatorXtra“ für den identischen Service wie der zweite Anbieter weniger berechnet und zusätzlich auch
die Anfrage schneller beantwortet.
Die Dokumentation für die beiden letzten Beispiele kann natürlich auch kombiniert dargestellt werden. Liegen Dokumentationen Für eine Operation und den verwendeten Port vor, so werden diese
zusammen in einem Fenster angezeigt. Daher wird bei der Darstellung der Dokumentation immer eine
einleitende Zeile automatisch generiert. Diese Zeile gibt an, für welches Element die Dokumentation
angezeigt wird und wie der Name lautet. Diese drei Beispiele verdeutlichen, dass Hintergrundinformationen bei manchen Eingaben erforderlich sind. Der Prototyp bietet die Möglichkeit an, diese Informationen zielgerecht dem Anwender anzubieten. Diese Dokumentationen wurden dem WSDL-Dokument
entnommen und sind somit inhaltlich vom Anbieter abhängig. Daher müssen Web-Service-Anbieter
für eine gute Qualität ihrer Dokumentation sorgen.
Zusätzlich zu den WSDL-bedingten Problemen können allerdings auch Probleme mit dem Prototypen
oder mit der Editierung der Daten auftreten. Ferner sind dem Anwender vielleicht nicht alle verfügbaren XSD-Datentypen bekannt, womit er den Wertebereich nicht kennt und somit fehlerhafte Eingaben
tätigen kann. Daher wurde eine Hilfefunktion für den Prototypen entwickelt.
Zum Anzeigen und Verwalten der Hilfefunktion wurde die JavaHelp-API von Sun Microsystems verwendet1. Diese API bietet ein Hilfeformat an zum XML- und HTML-basierten Anzeigen von Informationen. Das Hilfe-System bietet die Möglichkeit zum Suchen, Navigieren und Anzeigen von Informationen, die als HTML-Seiten angezeigt werden. Das Hilfe-System generiert die Hilfefunktion durch
Aufruf eines Helpset-Dokumentes. In diesem XML-Dokument können verschiedene Sichten (Views)
1
Dokumentation und Download von JavaHelp: http://java.sun.com/products/javahelp/
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
121
festgelegt werden. Zum Aufbau der Hilfefunktion wurden drei Sichten verwendet. Eine Sicht bietet
ein thematisch geordnetes Inhaltsverzeichnis der angebotenen Hilfefunktionen an. Eine weitere Sicht
kann zum indexierten Suchen nach Informationen verwendet werden. Beide Sichten bieten jeweils
eine andere Art der Darstellung der gleichen Informationen an. In einer Map-Datei wird für einen eindeutigen Schlüssel eine HTML-Seite festgelegt. Die beiden Sichten ordnen jeweils ihre Schlüssel anders, bieten aber die gleichen Informationen an. Die dritte Sicht ermöglicht die Suche im Internet. Die
Eingaben im Suchfeld werden an eine Suchmaschine von Sun Microsystems weitergeleitet.
Die Hilfe wird zur besseren Programmübersicht in einem separaten Fenster aufgebaut. Somit wird im
Hauptfenster kein Platz für Hilfefunktionen vergeudet und der Benutzer kann das Hilfefenster im Hintergrund offen lassen, wenn er mit der Editierung der Daten fortfährt und gelegentlich Hilfe zur Editierung der Daten benötigt. Das Hilfefenster kann auf zweierlei Weise geöffnet werden.
Zum einen wird das Fenster im Menü und Symbolleiste zum Öffnen angeboten und zum anderen kann
man eine Kontexthilfe aktivieren. Mit einem Hilfezeiger kann man eine grafische Komponente eines
Datentyps anklicken und erhält die entsprechende Dokumentation und Hilfestellung angezeigt. Jedem
Datentyp und dessen grafischer Komponente wurden eindeutige Identifikationsnummern zugewiesen.
Dadurch kann durch Suche in der Map-Datei die gewünschte Hilfeseite angezeigt werden. So kann für
jeden Datentyp eine spezielle Dokumentation angelegt werden, die dem Benutzer Angaben über den
Wertebereich, erlaubte Zeichen und die verwendeten Fassetten angibt oder allgemeine Hilfestellung
zum Aufbau und Benutzung der GUI.
122
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Abbildung 36 zeigt das Hilfe-System von JavaHelp:
Abbildung 36: Hilfefunktion für den Datentyp Float
Im linken Bereich des Hilfefensters kann zwischen den drei Sichten ausgewählt werden. Die aktivierte
Ebene zeigt das Inhaltsverzeichnis mit verschiedenen Themenbereichen. In der rechten Seite wird die
Hilfeseite für den Datentyp float angezeigt, die durch die Kontexthilfe ausgewählt wurde. Durch
Aktivierung der Kontexthilfe und Klick auf das Textfeld des Datentyps wurde diese Hilfeseite geöffnet
6.4 Zusätzliche Implementierungsaspekte
An dieser Stelle werden einige weitere Implementierungsaspekte aufgelistet. Zunächst wird der verwendete Parser WSDL4J von IBM vorgestellt, der einzelne Daten aus dem WSDL-Dokument extrahiert und dem Prototyp zur weiteren Verarbeitung zur Verfügung stellt. Nachfolgend wird der Mechanismus zur konsistenten Speicherung von komplexen Datentypen vorgestellt. Ferner wird die Problematik eines Timeouts während des Sendevorgangs angesprochen, bevor schließlich auf die Möglichkeit zum externen Editieren von Datentypen eingegangen wird.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
123
Parser WSDL4J
Intern verwendet Axis als Parser WSDL4J von IBM1. Dieser Parser realisiert die Referenzimplementierung der Java API for WSDL (JWSDL). [DF03] JWSDL ist ein Java Specification Request (JSR110)2 der unter dem Java Community Process (JCP) entwickelt wurde. Zunächst wird der Parser
WSDL4J vorgestellt, bevor auf die Erweiterung durch die Axis-API eingegangen wird.
Der Parser kann verwendet werden zum Lesen, Schreiben, Erzeugen und Modifizieren von WSDLDokumenten. Der Prototyp benötigt allerdings lediglich die Funktion des Auslesens von Informationen aus dem WSDL-Dokument. Über die zur Verfügung stehende API können alle Service-, Port-,
Porttyp-, Anbindungs-, Operations-, Nachrichten- und Datentyp-Elemente extrahiert werden. Nach der
Übergabe der URL des WSDL-Dokumentes parst WSDL4J das WSDL-Dokument und alle korrekt
importierten WSDL-Dokumente und bietet Zugriff auf alle Elemente. Sämtliche extrahierten Elemente
können über eine eigens für dieses Element zugeschnittene API weiter untersucht werden. Beispielhaft
werden zwei Methoden zur Bearbeitung von Elementen angeführt:
Für
ein
Port-Element
kann
über
die
Methode
getBinding()
der
Klasse
com.ibm.wsdl.PortImpl das entsprechende Binding für diesen Port ermittelt werden. Die Methode getParameterOrdering()der Klasse com.ibm.wsdl.OperationImpl liefert bei
einem Operations-Element die vorgegebene Parameterreihenfolge innerhalb der Operation.
WSDL4J bietet eine komfortable API zum Zugriff auf das WSDL-Dokument. Allerdings wurde
WSDL4J lediglich zum Parsen von WSDL entwickelt und nicht für XSD. Es wird zwar das DatentypElement extrahiert, allerdings wird keine Möglichkeit geboten zum Parsen einzelner komplexer Datentypen in XSD.
Die Axis-API bietet beim Parsen von XSD-Datentypen eine Erweiterung des WSDL4J-Parsers an. In
Verbindung mit dem Dom-Parser der Java-API (org.w3c.dom) kann eine Symboltabelle mit allen
Datentypen
generiert
werden.
Dazu
wird
lediglich
ein
geparstes
Dokument
(org.w3c.dom.Document) des WSDL-Dokumentes vom Dom-Parser benötigt, um diese Tabelle
zu erzeugen. Danach kann mit der Axis-API auf die XSD-Datentypen zugegriffen werden. Der unbekannte Datentyp kann durch Abfragen Schritt für Schritt näher spezifiziert werden. Zur Einordnung
des Datentyps muss dabei aber auf Erkenntnisse der XSD-Spezifikation zurückgegriffen werden. Beispielhaft kann getestet werden, ob der vorliegende Datentyp ein <complexType> oder
<simpleType> ist. Nach dieser ersten Kategorisierung kann der Datentyp weiter untersucht werden.
Die Axis-API bietet dazu eine Reihe von Methoden an. Bei einem <simpleType> kann man sich
z.B. den Basisdatentyp geben lassen und danach den einfachen Datentyp nach Attributen untersuchen.
Bei einem <complexType> kann eine Abfrage erstellt werden, ob der vorliegende Datentyp ein
1
Dokumentation und Download von WSDL4J: http://www-124.ibm.com/developerworks/projects/wsdl4j/
2
Informationen über JSR-110 im Internet: http://www.jcp.org/jsr/detail/110.jsp
124
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Feld ist. Falls dies der Fall ist, kann man sich den Feld-Datentyp geben lassen. Außerdem kann man
bei einem <complexType> die enthalten Elemente mit ihren Datentypen extrahieren. Diese Elemente werden durch eine Komposition („all“, „sequence“ oder „choice“) gruppiert (siehe Kapitel 4.3). Es
werden lediglich die Elemente geliefert, aber nicht die zugehörige Komposition. Diese kann durch den
DOM-Parser ermittelt werden und somit die Verwendung der Elemente festgelegt werden. Die AxisAPI weist somit einige Lücken auf beim Parsen von XSD-Datentypen. Daher müssen Kenntnisse aus
der XSD-Spezifikation verwendet werden, um die verschiedenen Datentypen richtig einzuordnen.
Durch diese Kategorisierung der Datentypen können letztendlich die Datentypen bestimmt werden.
Nach der Identifizierung kann danach eine grafische Komponente zugeordnet werden (siehe Kapitel
5.2).
Persistente Speicherung komplexer Datentyp-Objekte
Der Prototyp speichert jede Editierung eines komplexen Datentyps vor dem Senden, wenn der Anwender dies wünscht. Aus Gründen des Datenschutzes wird der Anwender gefragt, ob er eine dauerhafte Speicherung seiner Eingabedaten zur Wiederverwendung erlaubt. Möchte ein Anwender erneut
eine Anfrage an einen Web-Service richten, so wird ihm angeboten bereits durchgeführte Editierungen
nochmals zu verwenden. Für komplexe Datentypen generiert WSDL2Java Klassen, deren erzeugte
Objekte jeweils vor dem Senden mit Benutzereingaben gefüllt werden.
Zur persistenten Speicherung der Objekte dieser Klassen müssen die Objekte zuvor serialisiert und in
einer XML-Datei gespeichert werden. Zum Serialisieren der Objekte wird die Klasse
java.beans.XMLEncoder verwendet und zum Deserialisieren java.beans.XMLDecoder.
Zum Serialisieren wird das Objekt zuvor einer java.util.ArrayList hinzugefügt. In dieser
Liste befinden sich alle Objekte von komplexen Datentypen. Außerdem können mehrere Objekte des
gleichen Datentyps in der Liste aufgereiht werden. Diese Liste wird dann anschließend durch den
XMLEncoder serialisiert und in einer XML-Datei gespeichert. Um Speicherplatz zu sparen, kann
alternativ ein komprimierter Datenstrom in der Datei gespeichert werden. Zum Deserialisieren wird
aus der Datei die ArrayList extrahiert und die einzelnen enthaltenen Objekte werden namentlich
mit dem aktuellen Datentyp der Operation verglichen. Alle Objekte dieses Datentyps werden dann in
einem Feld gespeichert. Dieses Feld wird dann wie oben beschrieben als einfaches Feld dem Anwender präsentiert. Wählt er ein Feldelement an, so werden die Werte für die einzelnen Parameter in der
entsprechenden grafischen Komponenten der Eingabemaske angezeigt. Der Anwender kann anschließend diese Daten nochmals neu editieren und zur Erstellung der Anfrage nutzen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
125
Timeout beim Senden
Axis unterstützt zwei der vier möglichen Transmissions-Primitiven von WSDL (siehe Kapitel 2.4.1).
Einerseits kann ein „One-Way-Request“ durchgeführt werden. Der Prototyp sendet eine Nachricht an
den Web-Service und arbeitet weiter im Programmfluss. Bei dieser Transmission findet keine Blockierung des Prototypen statt und die Bearbeitung kann fortgesetzt werden. Anderseits kann ein „RequestResponse-Request“ erstellt werden. Der Prototyp sendet eine Nachricht an den Web-Service und unterbricht den Programmfluss bis eine Antwort wieder eintrifft. Dies ist die primäre Benutzung des
Prototypen. Bei diesem synchronem Request-Response kann es zu Fehlern kommen, falls die Verbindung über das Transport-Protokoll HTTP unterbrochen wird. HTTP ist ein zustandsloses, unzuverlässiges Transport-Protokoll und kann keine Garantien für eine Verbindung geben. Zusätzlich könnte ein
Web-Service nicht auf eine Anfrage eingehen, weil evtl. intern ein Fehler vorliegt, eine falsche Adresse angegeben wurde oder der Web-Service nicht aktiv ist. Da also bei der Kommunikation Fehler auftreten können, darf das Programm nicht dauerhaft blockiert sein durch einen fehlerhaften Aufruf. Daher wurde ein Timeout eingeführt. Nach Ablauf des Timeouts bricht das Programm den Sendevorgang
ab und ist nicht mehr blockiert. Die Operation muss dann erneut gesendet werden oder eine andere
Operation wird bearbeitet.
Externes Editieren der Daten
JCalendar ist eine Open Source Entwicklung eines grafischen Kalendar-Programms zur Anzeige eines
übergebenen Datums von Kai Toedter1. Dieses Programm unterliegt der GNU Lesser General Public
License2 und ist somit frei zugänglich und kann in den bestehenden Prototypen eingebunden werden.
Eine Teilmenge dieses Packages wurde verwendet und für den vorliegenden Prototyp angepasst. Dieses Programm wurde in den Prototypen im Package externPrg integriert, damit eine externe Editierung der Eingabedaten simuliert werden kann. Das Programm liefert nach der Editierung Daten zurück
zum Prototypen, der diese entgegen nimmt und in der Eingabemaske für den entsprechenden Datentyp
anzeigt. Durch diese Simulation externer Editierung soll die Erweiterbarkeit des Prototypen demonstriert werden.
Die eingebettete Komponente erhält als Eingabe Ganzzahlwerte für Jahr, Monat und Tag und zeigt
diese Daten in einer grafischen Übersicht an. Abbildung 37 zeigt die die grafische Darstellung des
Datums in einem separaten Fenster.
1
Homepage: http://www.toedter.com/en/jcalendar/
2
Informationen über GNU Lesser General Public License: http://www.gnu.org/copyleft/lesser.html
126
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Abbildung 37: Screenshot des JCalendar zum Anzeigen eines Datums
Über eine Combobox kann der Monat ausgewählt werden und über einen Spinner kann das Ausgangsjahr jeweils um eins in- oder dekrementiert werden. Für den ausgewählten Monat erscheint eine Monatsübersicht in der ein Tag per Mausklick ausgewählt werden kann. Durch Betätigen des UpdateButtons werden die Editierungen übernommen und ein entsprechendes Update in den Eingabefeldern
des aufrufenden Datentyps durchgeführt. Jeder Datentyp, der Datumseingaben entgegen nimmt
(Date, Duration, DateTime, gYearMonth und gMonthDay), erzeugt neben seinen spezifischen Eingabefeldern einen Button zum Öffnen dieser separaten Komponente. Der Benutzer hat also
die Möglichkeit über die generierten Eingabefelder oder über dieses grafische Ergänzungsprogramm
seine Editierung von Datumsinformationen einzugeben.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
127
Kapitel 7: Zusammenfassung und Ausblick
In der vorliegenden Diplomarbeit wurde ein generisches Framework zur Ansprache von Web-Services
entwickelt. Es wurde untersucht, inwieweit die Schnittstellen-Beschreibungssprache WSDL zur Generierung einer GUI ausreichend Informationen liefert. Durch das Framework sollen Anfragen an einen
Web-Service erstellt und anschließend die Antwort ebenfalls wieder angezeigt werden. Zur Erreichung
dieses Ziels wurde zunächst die Architektur von Web-Services, ihre Bedeutung für die Internetentwicklung und die eingesetzten Technologien erläutert.
Ein Web-Service ist ein Softwaresystem, das in verteilten, heterogenen Systemlandschaften mit anderen Softwaresystemen interagiert, um gemeinsam Aufgaben zu erfüllen. Ein Web-Service verwendet
dazu vorhandene XML-basierte Technologien, wie u. a. WSDL, SOAP und UDDI, um unabhängig
von verwendeter Plattform, Programmiersprache und Transport-Protokoll mit anderen Services zu
kommunizieren.
Die Schnittstelle eines Web-Service wird dabei durch die Web Service Description Language (WSDL)
beschrieben. Diese Beschreibungssprache legt fest, wie andere Systeme mit dem Web-Service kommunizieren können und abstrahiert von der dahinter liegenden Implementierung des Dienstes. Der
Protokollstandard SOAP packt die Übertragungsdaten in ein XML-basiertes Format und ermöglicht
den typisierten Datenaustausch zwischen Web-Services. Die Universal Description, Discovery and
Integration (UDDI) ist ein Plattform-unabhängiges Framework zum Beschreiben, Veröffentlichen und
Suchen von Web-Services.
Der Schwerpunkt dieser Diplomarbeit lag in der Analyse von WSDL und der XML Schema Definition
Language (XSD), mit der die verwendeten Datentypen in WSDL spezifiziert werden. WSDL wird als
Ausgangsdokument zur Generierung der GUI herangezogen und wurde daher ausführlich vorgestellt.
Zur Reduzierung der Komplexität innerhalb eines WSDL-Dokumentes, Erhöhung der Wiederverwendung und Steigerung der Lesbarkeit, können durch den Import-Mechanismus einzelne XSD- und
WSDL-Elemente ausgelagert werden. Zusätzlich wurde analysiert, wie die Daten aus dem WSDLDokument zur Generierung einer GUI verwendet werden können, ohne zusätzliche Informationen
heranzuziehen.
In der anschließenden Modellbildung fand zunächst eine Analyse möglicher grafischer Komponenten
statt. Es wurde ein Entwurf einer grafischen Oberfläche entwickelt, die unabhängig von der Komplexität des WSDL-Dokumentes jeweils einen identischen Grundaufbau hat. Nach dieser Festlegung konnten Detailinformationen aus dem WSDL-Dokument extrahiert werden. Des weiteren wurde eine Abbildungsvorschrift entwickelt, wie einzelne XSD-Datentypen innerhalb einer Eingabemaske grafisch
dargestellt und editiert werden können. Die Modellbildung und spätere Entwicklung des Prototypen
zeigen, dass prinzipiell die Generierung einer GUI aus einer WSDL-Beschreibung möglich ist. Das
Hauptproblem bei der generierten GUI ist allerdings das Fehlen semantischer Informationen.
128
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
WSDL wurde primär entwickelt, um von Parsern verarbeitet zu werden und danach den präsentierten
Web-Service dynamisch in bestehende Applikationen einzubinden. Die maschinelle Verarbeitung
steht dabei im Vordergrund bei der Entwicklung dieses Standards. Maschinen benötigen keine semantischen Informationen zum Verständnis eines Dienstes. Die Namen von Operationen und Parametern
können frei gewählt werden und müssen keinen semantischen Bezug zur Funktion des Web-Service
haben. Zur Darstellung innerhalb der GUI besteht allerdings nur die Möglichkeit diese Namen zu extrahieren und anzuzeigen. Aus diesem Grund wurde eine Heuristik aufgestellt zur gezielten Integration
von Dokumentationen innerhalb der grafischen Oberfläche. Dadurch wurde mit dem Einbinden von
Dokumentationen die Möglichkeit geschaffen, semantische Aspekte zu verwirklichen und eine selbstbeschreibende GUI aufzubauen.
Im Gegensatz zu verwandten Arbeiten, wie beispielsweise WSRP von OASIS, wurde in dieser Arbeit
eine Möglichkeit aufgezeigt zur generischen Darstellung eines Web-Services in einer GUI durch vorhandene Technologien. Mit WSRP sollen Web-Service-Anbieter aus parametrisierten MarkupFragmenten eine zusätzliche GUI für den angebotenen Web-Service entwickeln, der dann in einem
Portal integriert wird. Ein Vorteil des Ansatzes dieser Diplomarbeit liegt in der Nutzung vorhandener
Standards. Es müssen keine neuen Technologien entwickelt und integriert werden.
Im Prototypen wird ein gezielter Einsatz von Dokumentationen vorgestellt. Lediglich eine Sensibilisierung der Web-Service-Anbieter zur gezielten Verwendung der Dokumentationsmöglichkeit müsste
erreicht werden. In diesem Zusammenhang könnte man den WSDL-Standard dahingehend verändern,
dass Richtlinien zur Erstellung dieser Dokumentationen erstellt werden. Ebenso könnte die Verwendung der Dokumentationen nicht mehr nur optional angeboten werden. Durch ein verbindliches Einbinden von Dokumentationen könnte die generierte GUI um die fehlenden semantischen Informationen ergänzt werden.
Vielleicht können Erkenntnisse, die bei der Entwicklung des Semantic Web errungen werden, auf die
fehlende Semantik innerhalb von WSDL-Dokumenten übertragen werden. Tim Berners-Lee schrieb in
einem Artikel über das Semantic Web:
„The concept of machine-understandable documents does not imply some magical artificial intelligence which allows machines to comprehend human mumblings. It only indicates a machine's ability
to solve a well-defined problem by performing well-defined operations on existing well-defined data.
Instead of asking machines to understand people's language, it involves asking people to make the
extra effort.” [BL98]
Auch wenn zurzeit noch keine konkreten anwendbaren Konzepte für ein Einbinden semantischer Aspekte in WSDL-Dokumenten vorliegen, so können diese durch Forschungsarbeiten in den nächsten
Jahren sicherlich voran getrieben werden. Durch die Diplomarbeit konnte ein erster Ansatzpunkt zur
gezielten Verwendung von Dokumentationen dargestellt werden. Insbesondere wurde gezeigt, dass die
Möglichkeit zum generischen Aufbau einer GUI aus Informationen des WSDL-Dokumentes bestehen.
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
129
Kapitel 8: Anhang
8.1 Vordefinierte, primitive Datentypen und ihre Fassetten
XSD-Datentypen\
L
minL maxL pat E
wS maxI maxE minI maxE tD fD
Fassetten
xsd:string
X X
X
X
X
X
xsd:gMonth
X
X
X
X
X
X
X
xsd:gDay
X
X
X
X
X
X
X
xsd:gMonthDay
X
X
X
X
X
X
X
xsd:gYear
X
X
X
X
X
X
X
xsd:gYearMonth
X
X
X
X
X
X
X
xsd:date
X
X
X
X
X
X
X
xsd:time
X
X
X
X
X
X
X
xsd:dateTime
X
X
X
X
X
X
X
xsd:duration
X
X
X
X
X
X
X
xsd:boolean
X
X
xsd:base64Binary
X X
X
X
X
X
xsd:hexBinary
X X
X
X
X
X
xsd:float
X
X
X
X
X
X
X
xsd:double
X
X
X
X
X
X
X
X
X
X
X
xsd:anyURI
X X
X
X
X
X
xsd:QName
X X
X
X
X
X
xsd:NOTATION
X X
X
X
X
X
X
X
X
xsd:decimal
Legende:
X
L = length, minL = minLength, maxL = maxLength, pat = pattern, E = enumeration,
wS = whiteSpace, maxI = maxInclusive, maxE = maxExclusive, minI = minInclusive,
minE = minExclusive, tD = totalDigits, fD = fractionDigits
Quelle: [BM04b]
X
130
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
8.2 Abgeleitete Datentypen und ihre Fassetten
XSD-Datentypen\
L
minL maxL pat E
wS maxI maxE minI maxE tD fD
Fassetten
xsd:integer
X
X
X
X
X
X
X
X
X
xsd.long
X
X
X
X
X
X
X
X
X
xsd:int
X
X
X
X
X
X
X
X
X
xsd:short
X
X
X
X
X
X
X
X
X
xsd:byte
X
X
X
X
X
X
X
X
X
xsd: nonPositiveIn-
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
xsd:negativeInteger
X
X
X
X
X
X
X
X
X
xsd:unsignedLong
X
X
X
X
X
X
X
X
X
xsd:positiveInteger
X
X
X
X
X
X
X
X
X
xsd:unsignedInt
X
X
X
X
X
X
X
X
X
xsd:unsignedShort
X
X
X
X
X
X
X
X
X
xsd:unsignedByte
X
X
X
X
X
X
X
X
X
teger
xsd: nonNegativeInteger
xsd:normalizedString X X
X
X
X
X
xsd:token
X X
X
X
X
X
xsd:language
X X
X
X
X
X
xsd:Name
X X
X
X
X
X
xsd:NCName
X X
X
X
X
X
xsd:NMTOKEN
X X
X
X
X
X
xsd:NMTOKENS
X X
X
X
X
xsd:ID
X X
X
X
X
X
xsd:IDREF
X X
X
X
X
X
xsd:IDREFS
X X
X
X
X
xsd:ENTITY
X X
X
X
X
xsd:ENTITIES
X X
X
X
X
Legende:
X
L = length, minL = minLength, maxL = maxLength, pat = pattern, E = enumeration,
wS = whiteSpace, maxI = maxInclusive, maxE = maxExclusive, minI = minInclusive,
minE = minExclusive, tD = totalDigits, fD = fractionDigits
Quelle: [BM04b]
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
131
8.3 Übersicht: XSD-Datentypen, Java-Datentypen und SwingKomponenten
XSD Datentypen
Swing Komponenten
Java Datentypen
xsd:anySimpleType
java.lang.String
JFormattedTextField (JFT)
xsd:gMonth
org.apache.axis.types.Month
JComboBox
xsd:gDay
org.apache.axis.types.Day
JComboBox
xsd:gMonthDay
org.apache.axis.types.MonthDay
2*JComboBox + JCalendar1
xsd:gYear
org.apache.axis.types.Year
JComboBox
xsd:gYearMonth
org.apache.axis.types.YearMonth
2*JComboBox + JCalendar
xsd:date
java.util.Calendar
2*JComboBox(Tag, Monat)
+JFT (Jahr)+ JCalendar
xsd:time
org.apache.axis.types.Time
2*JComboBox (Stunde, Minute)
xsd:dateTime
java.util.Calendar
Kombination von xsd:date +
xsd:time
xsd:duration
org.apache.axis.types.Duration
Siehe XSD :dateTime+
2*JComboBox (Sek., Auswahl
positive o. negative)
xsd:boolean
boolean
JCheckBox (true,false)
xsd:base64Binary2
javax.mail.internet.MimeMultipart,
de.hillenbrand.swing.HFileString
(Auswahlfenster zum Laden und
org.apache.axis.attachments.OctetStream,
javax.xml.transform.Source, java.lang.String, java.awt.Image
Speichern der binären Daten),
Extra-Anzeige je nach MIME
Typ
xsd:hexBinary
Siehe xsd:base64Binary
Siehe xsd:base64Binary
xsd:float
float
JFormattedTextField
xsd:double
double
JFormattedTextField
xsd:anyURI
java.lang.String
JFormattedTextField
xsd:QName
javax.xml.namespace.QName
Zwei JFT für lokalen Bezeichner
und Namensraum
xsd:NOTATION
org.apache.axis.types.Notation
Komponente baut sich aus
NCName und 2+URI auf
xsd:decimal
java.math.BigDecimal
JFormattedTextField
xsd:integer
java.math.BigInteger
JFormattedTextField
1
JCalendar: Grafische Kalender-Darstellung in einem Extra-Fenster
2
je nach verwendeten MIME-Typ bei der Bindung wird ein unterschiedlicher Java-Datentyp verwendet
132
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
xsd.long
long
JFormattedTextField
xsd:int
int
JFormattedTextField
xsd:short
short
JFormattedTextField
xsd:byte
byte
JFormattedTextField
xsd: nonPositiveInte-
org.apache.axis.types.NonPositiveInteger
JFormattedTextField
xsd: nonNegativeInte-
org.apache.axis.types. NonNegativeInte-
JFormattedTextField
ger
ger
xsd:negativeInteger
org.apache.axis.types.NegativeInteger
JFormattedTextField
xsd:unsignedLong
org.apache.axis.types.UnsignedLong
JFormattedTextField
xsd:positiveInteger
org.apache.axis.types.PositiveInteger
JFormattedTextField
xsd:unsignedInt
org.apache.axis.types.NegativeInteger
JFormattedTextField
xsd:unsignedShort
org.apache.axis.types.UnsignedShort
JFormattedTextField
xsd:unsignedByte
org.apache.axis.types.UnsignedByte
JFormattedTextField
xsd:string
java.lang.String
JFormattedTextField + Extra
ger
Eingabefenster für längere Eingaben
xsd:normalizedString
org.apache.axis.types.NormalizedString
JFormattedTextField
xsd:token
org.apache.axis.types.Token
JFormattedTextField
xsd:language
org.apache.axis.types.Language
JFormattedTextField
xsd:Name
org.apache.axis.types.Name
JFormattedTextField
xsd:NCName
org.apache.axis.types.NCName
JFormattedTextField
xsd:NMTOKEN
org.apache.axis.types.NMToken
JFormattedTextField
xsd:NMTOKENS
org.apache.axis.types.NMTokens
JFormattedTextField
xsd:ID
org.apache.axis.types.Id
JFormattedTextField
xsd:IDREF
org.apache.axis.types.IDRef
JFormattedTextField
xsd:IDREFS
org.apache.axis.types.IDRefs
JFormattedTextField
xsd:ENTITY
org.apache.axis.types.Entity
JFormattedTextField
xsd:ENTITIES
org.apache.axis.types.Entities
JFormattedTextField
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
133
8.4 Modulares WSDL-Dokument durch Importieren
Zur besseren Übersicht werden lediglich im ersten WSDL-Dokument sämtliche Namensräume aufgeführt. Die Dokumentationen wurden nur für die drei Beispiele aus Kapitel 6.3 angeführt. Zusätzlich
wurden einige Internetadressen verkürzt, damit die WSDL-Dokumente übersichtlicher wurden. Die
Abkürzung „www“ steht dabei stellvertretend für „www.icsy.de/~s_apfel“.
8.4.1 prototype.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://www.icsy.de/da/apfel/wsdl/prototype"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:calNS="http://www.icsy.de/da/apfel/wsdl/Cal"
xmlns:bibNS="http://www.icsy.de/da/apfel/wsdl/Bib"
xmlns:serviceNS="http://www.icsy.de/da/apfel/wsdl/prototype"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--
IMPORT SOAP-BINDINGS
-->
<import namespace="http://www.icsy.de/da/apfel/wsdl/Bib"
location="http://www/prototype_Bib_SoapBinding.wsdl"/>
<import namespace="http://www.icsy.de/da/apfel/wsdl/Cal"
location="http://www/prototype_Calculator_SoapBinding.wsdl"/>
<import namespace="http://www.icsy.de/da/apfel/wsdl/Cal"
location="http://www/prototype_Calculator2_SoapBinding.wsdl"/>
<!--
SERVICE AND PORT DEFINITION
-->
<wsdl:service name="da_prototype_Service">
<wsdl:port binding="calNS:CalculatorSoapBinding" name="Calculator">
<wsdlsoap:address location="http://localhost:8008/axis/Calculator"/>
</wsdl:port>
<!--
DOCUMENTATION FOR A PORT
-->
<wsdl:port binding="calNS:CalculatorSoapBinding" name="CalculatorXtra">
<documentation>
This Web-Service is cheaper and faster than the other CalculatorService!
</documentation>
<wsdlsoap:address location="http://localhost:8008/axis/CalculatorXtra"/>
</wsdl:port>
<wsdl:port binding="bibNS:BibSoapBinding" name="Bib">
<documentation>
This Web-Service is used to store authors and their published books in
a database and offers some operations to access information about the
stored data.
</documentation>
134
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
<wsdlsoap:address location="http://localhost:8008/axis/BibService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
8.4.2
prototype_Calculator_SoapBinding.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://www.icsy.de/da/apfel/wsdl/Cal"
xmlns:calNS="http://www.icsy.de/da/apfel/wsdl/Cal">
<!--
IMPORT PORTTYPE
-->
<import namespace="http://.../wsdl/Cal"
location="http://www/prototype_Calculator_Porttype.wsdl"/>
<!--
BINDING DEFINITION
-->
<wsdl:binding name="CalculatorSoapBinding" type="calNS:Calculator">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="add"><wsdlsoap:operation soapAction=""/>
<wsdl:input name="addRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://.../wsdl/Cal" use="encoded"/>
</wsdl:input>
<wsdl:output name="addResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://.../wsdl/Cal" use="encoded"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="subtract"> <wsdlsoap:operation soapAction=""/>
<wsdl:input name="subtractRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://.../wsdl/Cal" use="encoded"/>
</wsdl:input>
<wsdl:output name="subtractResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://.../wsdl/Cal" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>
8.4.3
prototype_Bib_SoapBinding.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://www.icsy.de/da/apfel/wsdl/Bib"
xmlns:bibNS="http://www.icsy.de/da/apfel/wsdl/Bib">
<!--
IMPORT PORTTYPE
-->
<import namespace="http://www.icsy.de/da/apfel/wsdl/Bib"
location="http://www/prototype_Bib_Porttype.wsdl"/>
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
<!--
BINDING DEFINITION
-->
<wsdl:binding name="BibSoapBinding" type="bibNS:Bib">
<wsdlsoap:binding style="rpc" transport="http://…/soap/http"/>
<wsdl:operation name="bookEntry"><wsdlsoap:operation soapAction=""/>
<wsdl:input name="bookEntryRequest">
<wsdlsoap:body encodingStyle="http://.../encoding/"
namespace="http://.../wsdl/Bib" use="encoded"/>
</wsdl:input>
</wsdl:operation>
<wsdl:operation name="enterBookForAuthor">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="enterBookDocRequest">
<wsdlsoap:body encodingStyle="http://.../encoding/"
namespace="http://.../wsdl/Bib" use="encoded"/>
</wsdl:input>
</wsdl:operation>
<wsdl:operation name="enterPhone">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="enterPhoneDocRequest">
<wsdlsoap:body encodingStyle="http://.../encoding/"
namespace="http://.../wsdl/Bib" use="encoded"/>
</wsdl:input>
</wsdl:operation>
<wsdl:operation name="SearchBookByTitle"><wsdlsoap:operation soapAction=""/>
<wsdl:input name="bookTitleRequest">
<wsdlsoap:body encodingStyle="http://.../encoding/"
namespace="http://.../wsdl/Bib" use="encoded"/>
</wsdl:input>
<wsdl:output name="bookTitleResponse">
<wsdlsoap:body encodingStyle="http://.../encoding/"
namespace="http://.../wsdl/Bib" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>
8.4.4 prototype_Calculator_porttype.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://www.icsy.de/da/apfel/wsdl/Cal"
xmlns:calNS="http://www.icsy.de/da/apfel/wsdl/Cal">
<!--
Import MESSAGES
-->
<import namespace="http://.../wsdl/Cal"
location="http://.../prototype_Cal_Messages.wsdl"/>
<!--
PORTTYPE DEFINITION
-->
135
136
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
<wsdl:portType name="Calculator">
<wsdl:operation name="add" parameterOrder="addend1 addend2">
<wsdl:input message="calNS:addRequest" name="addRequest"/>
<wsdl:output message="calNS:addResponse" name="addResponse"/>
</wsdl:operation>
<wsdl:operation name="subtract" parameterOrder="operand">
<wsdl:input message="calNS:subtractRequest" name="subtractRequest"/>
<wsdl:output message="calNS:subtractResponse" name="subtractResponse"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
8.4.5
prototype_Bib_porttype.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://www.icsy.de/da/apfel/wsdl/Bib"
xmlns:bibNS="http://www.icsy.de/da/apfel/wsdl/Bib">
<!--
Import MESSAGES
-->
<import namespace="http://.../wsdl/Bib"
location="http://www/prototype_Bib_Messages.wsdl"/>
<!--
PORTTYPE DEFINITION
-->
<wsdl:portType name="Bib">
<wsdl:operation name="bookEntry">
<wsdl:input message="bibNS:bookEntryRequest" name="bookEntryRequest"/>
</wsdl:operation>
<wsdl:operation name="enterBookForAuthor">
<wsdl:input message="bibNS:enterBookDocRequest"
name="enterBookDocRequest"/>
</wsdl:operation>
<!--
DOCUMENTATION FOR A OPERATION
-->
<wsdl:operation name="enterPhone">
<documentation>
Phone number of the author required! We want to publish a short story
about all authors.
</documentation>
<wsdl:input message="bibNS:enterPhoneDocRequest"
name="enterPhoneDocRequest"/>
</wsdl:operation>
<wsdl:operation name="SearchBookByTitle">
<wsdl:input message="bibNS:bookTitleRequest" name="bookTitleRequest"/>
<wsdl:output message="bibNS:bookTitleResponse" name="bookTitleResponse"/>
</wsdl:operation>
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
</wsdl:portType>
</wsdl:definitions>
8.4.6 prototype_Calculator_Messages.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://www.icsy.de/da/apfel/wsdl/Cal"
xmlns:calNS="http://www.icsy.de/da/apfel/wsdl/Cal">
<!--
DATATYPE DEFINITION
-->
<wsdl:types>
<xsd:complexType name="SubType">
<xsd:element name="Minuend" type="xsd:float"/>
<xsd:element name="Subtrahend" type="xsd:float"/>
</xsd:complexType>
</wsdl:types>
<!--
MESSAGE DEFINITION
-->
<wsdl:message name="subtractRequest">
<wsdl:part name="operand" type="calNS:SubType"/>
</wsdl:message>
<wsdl:message name="subtractResponse">
<wsdl:part name="subtractResult" type="xsd:float"/>
</wsdl:message>
<wsdl:message name="addResponse">
<wsdl:part name="addResult" type="xsd:int"/>
</wsdl:message>
<wsdl:message name="addRequest">
<wsdl:part name="addend1" type="xsd:int"/>
<wsdl:part name="addend2" type="xsd:int"/>
</wsdl:message>
</wsdl:definitions>
8.4.7 prototype_Bib_Messages.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://www.icsy.de/da/apfel/wsdl/Bib"
xmlns:bibNS="http://www.icsy.de/da/apfel/wsdl/Bib">
<!--
Import XSD DATATYPES
-->
<wsdl:types>
<xsd:schema targetNamespace=".../wsdl/Bib" >
<xsd:import namespace=".../wsdl/Bib"
schemaLocation="http://www/prototype_Bib_Datatypes.xsd" />
</xsd:schema>
137
138
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
</wsdl:types>
<!--
MESSAGE DEFINITION
-->
<wsdl:message name="bookEntryRequest">
<part name="bookEntry" type="bibNS:bookEntryData"/>
</wsdl:message>
<wsdl:message name="bookTitleResponse">
<part name="book" type="bibNS:bookEntryData"/>
</wsdl:message>
<wsdl:message name="bookTitleRequest">
<part name="title" type="xsd:string"/>
</wsdl:message>
<!--
DOCUMENTATION FOR A PARAMETER
-->
<wsdl:message name="enterBookDocRequest">
<part name="Name1" type="xsd:Name">
<documentation>
enter the name of the author
</documentation>
</part>
<part name="Name2" type="xsd:Name">
<documentation>
enter the title of the book
</documentation>
</part>
<part name="Name3" type="xsd:Name">
<documentation>
enter the name of the publisher of this book
</documentation>
</part>
</wsdl:message>
<wsdl:message name="enterPhoneDocRequest">
<part name="title" type="bibNS:Phone"/>
</wsdl:message>
</wsdl:definitions>
8.4.8
prototype_Bib_Datatypes.xsd
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://www.icsy.de/da/apfel/wsdl/Bib"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:bibNS="http://www.icsy.de/da/apfel/wsdl/Bib">
<!-<!--
XSD DATATYPES DEFINITION -->
USER-DERIVED DATATYPE -->
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
<complexType name="bookEntryData">
<all>
<element name="Author" type="bibNS:Author"/>
<element name="Address" type="bibNS:Address"/>
<element name="Title" type="string"/>
<element name="key_words" type="bibNS:SearchArray"/>
<element name="key" type="bibNS:Key_Pattern"/>
<element name="first_appearance" type="date"/>
</all>
</complexType>
<!--
FACETTE FOR THE DATATYPE STRING: PATTERN -->
<simpleType name="Key_Pattern">
<restriction base="string">
<pattern value="\d{3}-[A-Z]{2}"/>
</restriction>
</simpleType>
<!--
USER-DERIVED DATATYPE -->
<complexType name="Address">
<all>
<element name="Street" type="string"/>
<element name="City" type="string"/>
<element name="Country" type="bibNS:Country"/>
<element name="Phone" type="bibNS:Phone"/>
<element name="EMail" type="string"/>
</all>
</complexType>
<!--
USER-DERIVED DATATYPE -->
<complexType name="Phone">
<all>
<element name="areaCode" type="int"/>
<element name="directDial " type="int"/>
</all>
</complexType>
<!--
FACETTE FOR THE DATATYPE STRING: ENUMERATION -->
<simpleType name="Country">
<restriction base="string">
<enumeration value="Germany"/>
<enumeration value="England"/>
<enumeration value="USA"/>
</restriction>
</simpleType>
<!--
USER-DERIVED DATATYPE -->
<complexType name="Author">
<all>
<element name="name" type="Name">
139
140
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
<documentation>
PLEASE ENTER THE FORE NAME FOR THIS PARAMETER.
</documentation>
<element/>
<element name="name" type="Name">
<documentation>
PLEASE ENTER THE FAMILY NAME FOR THIS PARAMETER.
</documentation>
<element/>
</all>
</complexType>
<!--
COLLECTION DATATYPE: ARRAY -->
<complexType name="SearchArray">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType" wsdl:arrayType="string[]" />
</restriction>
</complexContent>
</complexType>
</schema>
8.5 Java-Klasse des XSD-Datentyps float
// package for all xsd datatypes
package de.icsy.da.apfel.xsdDatatypes;
// imports
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.text.NumberFormat;
import java.text.ParseException;
import javax.help.CSH;
import javax.swing.*;
import de.hillenbrand.system.UIPreferences;
import de.icsy.da.apfel.guiFramework.*;
/**
* this class represent the xsd datatype float
* xsd datatype float is represented by the Java datatype Float
* XSDWrapper is used to communicate with this class
*/
public class XSDfloat {
// for validation, tests if the input from the user is a number
private NumberFormat numFormat=NumberFormat.getNumberInstance();
// field to edit the parameter in the GUI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
private JFormattedTextField ftf = new JFormattedTextField(numFormat);
// constraints for the GridBag Layout
private GridBagConstraints c = new GridBagConstraints();
// all graphical informations of this datatype are stored in this panel
private JPanel panel=new JPanel(new GridBagLayout());
// variable to store the value of the users edit
private Float value=null;
// Object, used to test if all the specified facettes are handled correct
private Facettes facettes;
// Object[] with 12 values, one for each of the 12 given facettes from xsd
// one item of the array: nullfacette not used; !=nullvalue of the
// facette
private Object[] facettesValues=null;
/**
* Constructor
* Creates a new Object and the presentation panel.
* Validation and facettes tests are handled here.
*/
public
XSDfloat(){
JLabel typeLabel =createTypLabel();
ftf.setColumns(20);
ftf.addPropertyChangeListener(new PropertyChangeListener() {
public void propertyChange(PropertyChangeEvent e) {
String test = ftf.getText();
try{
if(test.length()>0){
GuiBuilder.setFaultContent(null);
ftf.commitEdit();
// tries to create a float from the users edit
float fl=((Number)ftf.getValue()).floatValue();
// tests if the value from the user is in the right range
if(fl>Float.MIN_VALUE || fl<Float.MAX_VALUE){
value=new Float(fl);
// tests, if there are facettes specified
if(facettesValues!=null){
facettes= new Facettes(facettesValues);
// calls the facette-object with the value, but only when
// facettes are specified in the wsdl
boolean facettesCorrect=facettes.getResult(value);
if(!facettesCorrect){
reset();
//fault, value is out of the range from the facettes
GuiBuilder.setFaultContent(Helper.GRS("JReqTools.FacFault"));
}
}else{
GuiBuilder.setFaultContent(null);
}
}
// value is higher than max_value or smaller than min_value
141
142
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
else GuiBuilder.setFaultContent(Helper.GRS("JReqTools.FloatFault2"));
}
}catch (NumberFormatException ne){
// fault, value is not a number
GuiBuilder.setFaultContent(Helper.GRS("JReqTools.FloatFault"));
}
catch (ParseException pe) {
// fault, value is not a number
GuiBuilder.setFaultContent(Helper.GRS("JReqTools.FloatFault"));
}
}
});
// graphical presentation of the datatype, consists of the textfield and
// a label
c.gridx = 0; c.gridy=0;c.gridwidth =2;c.gridheight=1; c.weightx = 1;
panel.add(createTypLabel(), c);
c.gridx = 0; c.gridy=1;c.gridwidth =1;c.gridheight=1; c.weightx = 1;
panel.add(ftf, c);
// field help ID for the textfield, when the user uses the contextHelp
// then a help-side opens with specific informations about the datatype
CSH.setHelpIDString(ftf, "xsd:float");
}
/**
* method sets datatype result variable to null and deletes the displayed
* value in the textfield
*/
public void reset(){
value=null;
ftf.setText("");
ftf.setValue(null);
}
/**
* method creates the datatype label, the label gives information which
* datatype is used
*/
private JLabel createTypLabel(){
JLabel typeLabel = new JLabel("xsd:float");
typeLabel.setFont(UIPreferences.getAcceleratorFont());
return typeLabel;
}
/**
* the parameter facettesValues is filled with all facettes values from the
* wsdl for the given datatype, if facettes are specified
*/
public void setFacettes(Object[] facettesValues){
this.facettesValues=facettesValues;
}
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
143
/**
* returns the presentation panel of this datatype with the label and
* textfield inside
*/
public JPanel getPanel(){
return panel;
}
/**
* returns the value of the datatype object, the users edit is stored in the
* variable value
*/
public Float getValue(){
return value;
}
/**
* sets the value for the datatype object, in the variable “value” the new
* value is stored and also displayed in the textfield
*/
public void setValue(Float value){
this.value=value;
ftf.setText(value.toString());
ftf.setValue(value);
}
/**
* method is used to set the result from an answer
* sets the value of the datatype object and mark all presentation
* components uneditable
* @param value
*/
public void setResult(Float value){
setValue(value);
ftf.setEditable(false);
}
}
144
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Literaturverzeichnis
[ABB+04]
E. Armstrong, J. Ball, S. Bodorf, D. Bode Carson, I. Evans, D. Green, K. Haase, E.
Jendrock: The J2EE™ 1.4 Tutorial, 2004, Sun Microsystems, verfügbar im World
Wide Web: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/
[ABFG04]
D. Austin, A. Barbir, C. Ferris, S. Garg.: Web Services Architecture Requirements,
W3C Working Group Note 11 February 2004, 2004, W3C, verfügbar im World Wide
Web: http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211
[ACM01]
E. Anuff, M. Chaston; D. Moses: Web Service User Interface (WSUI) 1.0, Working
Draft – 22 June 2001, 2001, Epicentric Inc, verfügbar im World Wide Web:
http://www.wsui.org/doc/20010622/WD-wsui-20010622.html
[Axis04]
Homepage von Apache, Projekt AXIS: http://ws.apache.org/axis/
[BCC+04]
A. Banks, J. Challenger, P. Clarke, R. P. King, K. Witting, A. Donoho, T. Holloway,
J. Ibbotson, S. Todd: Specification: HTTPR Specification, 2002, IBM, verfügbar im
World Wide Web: http://www-106.ibm.com/developerworks/webservices/library/wshttprspec/
[BEG+01]
T. Baier, M. Ebert, A. Geissel, M. Jeckle, N. Klever, E. Meier, S. Werner: XML Schema Teil 2: Datentypen, W3C Empfehlung 02.Mai.2001, deutsche Übersetzung, 2001,
W3C, verfügbar im World Wide Web: http//www.w3.org/TR/2001/Rec-xmlschema2-20010502
[BEG+03]
K. Ballinger, D. Ehnebuske, M. Gudgin, M. Nottingham, P. Yendluri: Basic Profile
Version 1.0a, final Specification, 2003, Web Services Interoperability Organization
(WS-I), verfügbar im World Wide Web: http://www.wsi.org/archive/Profiles/Basic/2003-08/BasicProfile-1.0a.htm
[Bel02]
T. Bellwood.: UDDI Version 2.04 API Specification, UDDI Committee Specification,
2002, verfügbar im World Wide Web: http://uddi.org/pubs/ProgrammersAPI-V2.04Published-20020719.htm
[BG04]
D. Brickley, R. V. Guha: RDF Vocabulary Description Language 1.0: RDF Schema,
W3C Recommendation 10 February 2004, 2004, W3C, verfügbar im World Wide
Web: http://www.w3.org/TR/rdf-schema/
[BHM+04]
D. Booth, H. Haas, F. McGabe, E. Newcomer, C. Ferris, D. Orchard: Web Services
Architecture, W3C Working Group Note 11 February 2004, 2004, W3C, verfügbar im
World Wide Web: http://www.w3.org/TR/2004/NOTE-ws-arch-20040211
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
[BL98]
145
T. Berners-Lee: What the Semantic Web can represent, 1998, W3C, verfügbar im
World Wide Web: http://www.w3.org/DesignIssues/RDFnot.html
[BM04a]
P.V. Biron, A. Malhotra: XML Schema Part1: Structures Second Edition, W3C Proposed Edited Recommendation 18 March 2004, 2004, W3C, verfügbar im World
Wide Web: http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/
[BM04b]
P.V. Biron, A. Malhotra: XML Schema Part2: Datatypes Second Edition, W3C Proposed Edited Recommendation 18 March 2004, 2004, W3C, verfügbar im World
Wide Web: http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/
[Bo02]
G. Bong: Apache SOAP type mapping, Part 1: Exploring Apache´s serialization
API´s, 2002, IBM, verfügbar im World Wide Web: http://www106.ibm.com/developerworks/library/ws-soapmap1/
[BPS+04]
T. Bray, J. Poali, C. M. Sperberg-McQueen, E. Maler, F. Yergeau: Extensible Markup
language (XML) 1.0 (Third Edition), W3C Recommendation 04 february 2004, 2004,
W3C, verfügbar im World Wide Web: :http://www.w3.org/TR/2004/REC-xml20040204/
[Bur04]
M. Burner: Service Orientation and its Role in Your Connected Systems Strategy,
2004, Microsoft Corporation, verfügbar im World Wide Web:
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnbda/html/SrOrientWP.asp
[But04]
R.Butek : Web Service Programming Tips and Tricks: WSDL file imports, 2004,
IBM, verfügbar im World Wide Web: http://www106.ibm.com/developerworks/xml/library/ws-tip-imports.html
[CCMW01]
E. Christensen, F. Curbera, G. Meredith, S.Weerawarana.: Web Service Description
Language (WSDL) 1.1, W3C Note 15 March 2001, 2001, W3C, verfügbar im World
Wide Web: http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[CDF+02]
A. Ceponkus, S. Dalal, T. Fletcher, P. Furniss, A. Green, B. Pope: Business Transaction Protocol, AN OASIS Committee Specification, 2002, OASIS, verfügbar im World
Wide Web: http://www.oasis-open.org/committees/download.php/1184/2002-0603.btp%20cttee-spec-1.0.pdf
[Cer02]
E. Cerami: Web Services, Essentials, 2002, O´Reilly, p. 10
[CGMW04]
R. Chinnici, M. Gudgin, J.-J- Moreau, S. Weerawarana : Web Service Description
Language (WSDL) Version 1.2 Part 1: Core Language, W3C Working Draft 11 June
2003, 2003, W3C, verfügbar im World Wide Web: http://www.w3.org/TR/2003/WDwsdl12-20030611
146
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
[CGM+03]
R. Chinnici, M. Gudgin, J.-J. Moreau, J. Schlimmer, S.Weerawarana.: Web Service
Description Language (WSDL) 2.0 Part 1: Core Language, W3C Working Darft 10
November 2003, 2003, W3C, verfügbar im World Wide Web:
http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[CGM+04]
R. Chinnici, M. Gudgin, J.-J. Moreau, J. Schlimmer, S. Weerawarana.: Web Service
Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Working
Draft 26 March 2004, 2004, W3C , verfügbar im World Wide Web:
http://www.w3.org/TR/wsdl20/
[CHY+97]
P. E. Chung, Y. Huang, S.Yajnik, D. Liang, J. C. Shih, Y. M. Wang: DCOM and
CORBA Side by Side, Step by Step, and Layer by Layer, 1997, Microsoft, verfügbar im
World Wide Web:
http://research.microsoft.com/~ymwang/papers/HTML/DCOMnCORBA/S.html
[Coy02]
F. P. Coyle: XML, Web Services, and the Data Revolution, 2002, Indianapolis (USA),
Addison-Wesley-Verlag, pp. 13-21
[DF03]
M. J. Duftler, P. Fremantle: Java™APIs for WSDL (JWSDL), 2003, IBM, verfügbar
im World Wide Web:
[DFLS02]
A. Diaz, P. Fischer, C. Leue, T. Schäck: Web Services for Remote Portals (WSRP)
WhitePaper, 2002, IBM, verfügbar im World Wide Web:
http://www.ibm.com/developerworks/library/ws-wsrp/
[DLW02]
A. Diaz, J. Lucassen, C. F. Wiecha: Web Services Experience Language Version
2.Spezifikation , 2002, IBM, verfügbar im World Wide Web: http://www106.ibm.com/developerworks/library/ws-wsxl/
[EDI04]
Homepage von UNECE (United Nations Economic Commission for Europe,
Themengebiet EDI: http://www.unece.org/trade/untdid/welcome.htm
[FBF+01]
W. Ford, P. Hallam-Baker, B. Fox, B. Dillaway, B. LaMacchia, J. Epstein, J. Lapp:
XML Key Management Specification (XKMS), W3C Note 30 March 2001, 2001, W3C,
verfügbar im World Wide Web: http://www.w3.org/TR/xkms/
[FW04]
D. C. Fallside, P. Walmsley: XML Schema Part0: Primer Second Edition, W3C Proposed Edited Recommendation 18 March 2004, 2004, W3C, verfügbar im World
Wide Web: http://www.w3.org/TR/2004/PER-xmlschema-0-20040318/
[GHM+03]
M. Gudgin, M. Hadley, N. Mendelsohn, J,-J. Moreau, N. F. Nielsen: SOAP Version
1.2. Part 1: Messaging Framework, W3C Recommendation 24 June 2003, 2003, W3C
verfügbar im World Wide Web: http://www.w3.org/TR/2003/REC-soap12-part120030624/
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
[HHP+01]
147
I. Horrocks, F. van Harmelen, P Patel-Schneider, T. Berners-Lee, D. Brickley, D.
Connolly, M. Dean, S. Decker, D. Fensel, R. Fikes, P. Hayes, J. Heflin, J. Hendler, O.
Lassila, D. McGuinness, L. A. Stein: DAML+OIL(March 2001), 2001, verfügbar im
World Wide Web: http://www.daml.org/2001/03/daml+oil-index.html
[KLT03]
A. Kropp, C. Leue, R. Thompson: Web Services for Remote Portals Specification,
2003, OASIS, verfügbar im World Wide Web: http://www.oasisopen.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf
[KW02]
M. Kuschke, L. Wölfel: Web Services kompakt, 2002, Heidelberg, Berlin, Spektrum
Akademischer Verlag GmbH, 1. Auflage, p. 4
[Ley01]
F. Leymann: Web Service Flow Language (WSFL 1.0), 2001, IBM, verfügbar im
World Wide Web: http://www306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf
[Ma04]
B. Marchal: Tip: Passing files to a Web service, SOAP and binary data, 2004, IBM,
verfügbar im World Wide Web: http://www-106.ibm.com/developerworks/library/xtippass.html
[Mit03]
N. Mitra: SOAP Version 1.2. Part 0: Primer, W3C Recommendation 24 June 2003,
2003, W3C, verfügbar im World Wide Web: http://www.w3.org/TR/2003/RECsoap12-part0-20030624/
[MPM04]
P. Mishra, R.Philpott, E. Maler: Conformance Requirements for the OASIS Security
Assertion Markup Language (SAML) V2.0 Committee Draft 02, 2004, OASIS, verfügbar im World Wide Web: http://www.oasisopen.org/committees/download.php/9452/sstc-saml-conformance-2.0-cd-02.pdf
[New02a]
E. Newcomer: Understanding Web Services. XML, WSDL, SOAP, and UDDI, 2002, o.
O, Addison Wesley, pp. 219-253
[New02b]
E. Newcomer: Understanding Web Services. XML, WSDL, SOAP, and UDDI, 2002, o.
O, Addison Wesley, pp. 159-168
[OMG04]
OMG (ohne Autor): Common Object Request Broker Architecture: Core Specification, 03. 2004, OMG, verfügbar im World Wide Web:
http://www.omg.org/technology/documents/formal/corba_iiop.htm
[OMM02]
E. Ort, R. Mandava, B. Mehta: Java™ Web Services Developer Pack. Part2: RPCCalls, Messaging and the JAX-RPC and JAXM-API, 2002, Sun Microsystems, verfügbar im World Wide Web: http://java.sun.com/webservices/tutorial.html
[RFC821]
J. B. Postel: Simple Mail Transfer Protocol, 1982, Information Sciences Institute University of Southern California, verfügbar im World Wide Web:
http://www.ietf.org/rfc/rfc821.txt
148
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
[RFC959]
R. Braden: Requirements for Internet Hosts – Application and Support, 1989, Internet
Engineering Task Force, verfügbar im World Wide Web:
http://www.ietf.org/rfc/rfc1123.txt
[RFC2045]
N. Freed, N. Borenstein: Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies, 1996, verfügbar im World Wide Web:
http://www.ietf.org/rfc/rfc2045.txt
[RFC2396]
T. Berners-Lee, R. Fielding, U. C. Irvine, L. Masinter: Uniform Resource Identifiers
(URI) Gneric Syntax, 1998, verfügbar im World Wide Web:
http://www.ietf.org/rfc/rfc2396.txt
[RFC2616]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee:
Hypertext Transfer Protocol – HTTP/1.1, 1999, verfügbar im World Wide Web:
http://www.ietf.org/rfc/rfc2616.txt
[RFC2818]
E. Rescorla: HTTP Over TLS, 2000, RFTM Inc, verfügbar im World Wide Web:
http://www.ietf.org/rfc/rfc2818.txt
[RFC3080]
M. Rose: The Blocks Extensible Exchange Protocol Core, 2001, Invisible Worlds Inc,
verfügbar im World Wide Web: ftp://ftp.isi.edu/in-notes/rfc3080.txt
[RMI03]
Sun (ohne Autor): Java RMI Specification, 2003, Sun Microcsystems, verfügbar im
World Wide Web: http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmiTOC.html
[STK02]
J. Snell, D. Tidwell, P. Kulchenko: Webservice-Programmierung mit SOAP, 2002,
o.O, O´Reilly Verlag & Co. KG (deutsche Ausgabe, übersetzt von G.Selke) pp. 179181
[SUN04]
Sun (ohne Autor): The Java Tutorial, 2004, Sun, verfügbar im World Wide Web:
http://java.sun.com/docs/books/tutorial.
[Tha01]
S. Thatte: XLANG Web Services for Business Process Design, 2001, Microsoft, verfügbar im World Wide Web: http://www.gotdotnet.com/team/xml_wsspecs/xlangc/default.htm
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
149
Abbildungsverzeichnis
Abbildung 1: Übersicht des Protokoll-Stacks eines Web-Service nach [Cer02] .................................. 16
Abbildung 2: Service-orientierte Architektur mit Web-Service-Technologien .................................... 19
Abbildung 3: vereinfachter Aufbau eines WSDL-Dokumentes ............................................................ 24
Abbildung 4: WSDL-Dokument des Taschenrechner-Web-Service .................................................... 26
Abbildung 5: direktes und transitives Importieren ................................................................................ 34
Abbildung 6: transitiver Zugriff auf XSD in WSDL 2.0 ...................................................................... 36
Abbildung 7: Sonderfall beim Importieren in WSDL 2.0 ..................................................................... 37
Abbildung 8: Übersicht der Datenstrukturen in Beziehung zur abstrakten Sicht auf UDDI ............... 38
Abbildung 9: Aufbau einer SOAP-Nachricht ....................................................................................... 40
Abbildung 10: Client-Architektur der AXIS-Engine [Axis04] ............................................................. 46
Abbildung 11: WSDL-Fragment mit Porttyp- und Nachrichten-Element ............................................ 48
Abbildung 12: Beziehung zwischen den generierten Klassen von WSDL2Java .................................. 49
Abbildung 13: tabellarischer Vergleich von WSDL2Java und wscompile ........................................... 51
Abbildung 14: Code des Stub-Client .................................................................................................... 54
Abbildung 15: Code des Dynamic-Proxy-Client .................................................................................. 55
Abbildung 16: Code des DII-Client ...................................................................................................... 57
Abbildung 17: Daten-orientierter Web-Service [DFLS02] ................................................................... 58
Abbildung 18: WSRP-Erweiterung für Web-Services [DFLS02] ........................................................ 58
Abbildung 19: UML-Anwendungsfälle zwischen Anwender und Gesamtsystem ................................ 62
Abbildung 20: allgemeiner Aufbau der GUI......................................................................................... 71
Abbildung 21: Komplexitätsentstehung durch Ports mit korrespondierenden Operationen ................. 73
Abbildung 22: Übersicht der XSD-Datentyp-Hierarchie (nach Quelle [BM04b]) ............................... 76
Abbildung 23: UML-Paketdiagramm des Prototypen........................................................................... 96
Abbildung 24: UML-Klassendiagramm des Prototypen ....................................................................... 97
Abbildung 25: Aufbau der grafischen Komponenten ........................................................................... 99
Abbildung 26: Anordnung der GUI-Komponenten ............................................................................ 101
Abbildung 27: Aufbau der GUI .......................................................................................................... 106
Abbildung 28: Aufbau des Menüs und Toolbar .................................................................................. 109
Abbildung 29: grafische Komponenten für einfache Datentypen ....................................................... 111
Abbildung 30: grafische Darstellung eines benutzerdefinierten, komplexen Datentyps .................... 113
Abbildung 31: grafische Darstellung eines Feldes mit komplexem Inhalt ......................................... 116
Abbildung 32: grafische Darstellung eines doppelten Feldes ............................................................. 117
150
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Abbildung 33: Einbinden von Dokumentationen für Parameter ......................................................... 118
Abbildung 34: Einbinden von Dokumentationen für Operationen...................................................... 119
Abbildung 35: Einbinden von Dokumentationen für Ports ................................................................. 120
Abbildung 36: Hilfefunktion für den Datentyp Float .......................................................................... 122
Abbildung 37: Screenshot des JCalendar zum Anzeigen eines Datums ............................................. 126
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
151
Glossar
B2B, B-to-B
Business-to-Business:
Geschäftliche Beziehungen und E-Commerce zwischen verschiedenen Unternehmen.
BEEP
Blocks Extensible Exchange Protocol:
Das asynchrone Protokoll basiert auf TCP/IP und wurde als Alternative zu HTTP für
den XML-Datenaustausch von Peer-to-Peer entwickelt.
BTP
Business Transaction Protocol:
Koordinierung mehrerer Prozesse und Zuordnung einer choreografischen Sequenz.
Das XML-basierte Protokoll verwaltet komplexe Transaktionen durch ein MultilevelTransaktionsmodell, wobei allerdings keine Rücksetzmaßnahmen (Recovery) im Fehlerfall eingeleitet werden.
CORBA
Common Object Request Broker Architecture:
Architektur und Infrastruktur der Object Management Group (OMG). CORBAProgramme können unabhängig von Plattform und Programmiersprache miteinander
kommunizieren und Objekte austauschen, wobei beide Teilnehmer allerdings eine
CORBA-Implementierung und Bibliotheken benötigen.
DAML
DARPA Agent Markup Language:
DAML ist eine Erweiterung von XML und RDF, um Ontologien zu erstellen und Informationen maschinell zu verarbeiten und interpretieren.
DCOM
Das Component Object Model (COM) sind von Microsoft entworfene Objekte, deren
Funktionalität über eine Schnittstellenbeschreibung definiert wird. Innerhalb einer
Distributed COM Architektur (DCOM) können diese auf Windows-Plattformen verteilt vorliegen und angesprochen werden.
DTD
Document Type Definition:
DTD ist eine textuelle Deklaration, um in SGML- und XML-Dokumenten die Struktur
festzulegen.
FTP
File Transfer Protokoll:
Auf TCP-basiertes Protokoll zum Transfer von Daten zwischen verteilten Systemen.
HTTP
Hyper Text Transfer Protocol:
Protokoll zum verteilten Austausch von Hyermedia-Informationen übers Internet.
Standardprotokoll zum Datenaustausch im Internet seit 1990.
HTTPR
Reliable HTTP:
Das zustandslose HTTP soll um zuverlässige Aspekte erweitert werden im Bezug auf
Transaktionsschutz und QoS bei der Datenübertragung zwischen Systemen, um Nachrichten und Daten zuverlässig über HTTP zu verschicken. (Vorschlag von IBM)
152
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
HTTPS
HTTP over Secure Socket Layer:
Protokoll zur Authentfikation und Autorisation von Netzwerk-Teilnehmern.
MIME
Multipurpose Internet Mail Extension:
Kodierstandard zur Strukturierung und Aufbau von E-Mails und Nachrichten bei der
Datenübertragung übers Internet.
Namensraum
Objekte können identische Namen besitzen. Eindeutigkeit kann erreicht werden, wenn
Objekten neben dem lokalen Namen noch Namensräume (Kontextinformation) zur
eindeutigen Identifizierung zugeordnet werden. Dadurch können Namenskollisionen
verhindert werden.
OASIS
Organization for the Advancement of Structured Information Standards:
1993 unter dem Namen „SGML Open“ gegründete Standardisierungkommision zur
Entwicklung von E-Business-Lösungen und Standards, Homepage: http://www.oasisopen.org
OMG
Object Management Group:
1989 gegründetes herstellerunabhängiges Industriekonsortium, das die Object Management Architecture (OMA) und CORBA-Implementierungen entwirft und weiter
entwickelt.
QName
qualifizierter Name:
Ein Tupel, bestehend aus lokalem Namen und einem Namensraum. Objekte können
über einen QName eindeutig referenziert werden.
RDF
Ressource Description Framework:
Austausch und Verwenden von Metadaten im Internet. Die Metadaten geben Auskunft
über Inhalte von beschriebenen Dokumenten.
RFC
Requests for Comments:
RFC sind Diskussionspapiere mit einer fortlaufenden Nummerierung, die sich mit
technischen Konzepten des Internets befassen. Themen wie u. a. Netzwerk-Protokolle,
Programme, Prozeduren, Konzepte rund um das Internet sind in diesen Dokumenten
enthalten. Jeder Standard ist in einem RFC-Dokument festgehalten, aber nicht alle
RFC´s
sind
Standards.
Weitere
Informationen
findet
man
unter:
http://www.ietf.org/rfc
RMI
Remote Method Invocation:
RMI ist eine Java-API zur Kommunikation zwischen entfernten, verteilten JavaObjekten in heterogenen Systemen.
SAML
Security Assertions Markup Language:
Authentifizierungssystem von der OASIS-Initiative entwickelt zur gesicherten Kommunikation von Netzwerk-Teilnehmern.
SGML
Standard Generalized Markup Language:
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
153
SGML ist eine Metasprache, mit deren Hilfe man verschiedene Auszeichnungssprachen (markup languages) für Dokumente definiert. XML wurde aus SGML abgeleitet.
SMTP
Simple Mail Transfer Protocol:
Protokoll zum zuverlässigen Liefern von Mails über das Internet.
SOAP
XML-basiertes Protokoll zum Datenaustausch in dezentralen, verteilten Umgebungen.
Zum Austausch der Informationen wird dabei auf vorhandene Internetprotokolle zurückgegriffen, wie z.B. HTTP.
UDDI
Universal Description, Discovery and Integration:
Protokoll zum Beschreiben, Veröffentlichen und Suchen von Web-ServiceKomponenten in einem Register (Analogie zu den gelben Telefonbuchseiten besteht).
URI
Unified Resource Identifier:
Generischer Ausdruck um Namen und Adressen von Objekten im Internet eindeutig
zu beschreiben. (URL ist Untermenge)
URL
Unified Resource Locator:
Eine URL legt eine globale Adresse von Ressourcen im Internet fest.
W3C
World Wide Web Consortium:
1994 gegründete Organisation zum Definieren von Standards und Spezifizieren von
Technologien fürs Internet zur Erhöhung der Interoperabilität (z.B.: XML, HTML,
DOM, CSS). Homepage: http://www.w3.org/
W3C Note
Das vom W3C veröffentlichte Dokument hat einen formellen Zustimmungsprozess
durchlaufen und wird veröffentlicht. Von Seiten des W3C gibt es keine Garantie der
Weiterbearbeitung.
W3C Recommendation
Spezifikation nach Konsensbildung der W3C-Mitglieder, ähnlich zu einem Standard
von anderen Organisationen (z.B.: ISO).
W3C Working Draft
Ein vom W3C veröffentlichtes Dokument zur Einsicht und Diskussion durch die Öffentlichkeit, Veränderungen werden vorbehalten.
W3C Working Group Note
Eine von einer Arbeitsgruppe erstellte Spezifikation, die den aktuellen Arbeitsstand
der Öffentlichkeit zur Diskussion stellt.
Web-Service
Ein
selbstbeschreibender,
Plattform-,
Netzwerk-
und
Programmiersprachen-
unabhängiger Service, der auf XML-basierten Nachrichten und Technologien beruht,
um in heterogenen, verteilten Umgebungen Dienste auszuführen und Daten auszutauschen.
WSDL
Web Service Description Language:
154
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
XML-basierte Beschreibungssprache zum Definieren des Interface, Implementierungsdetails und Verbindungsinformationen eines Web-Service.
WSFL
Web Service Flow Language:
WSFL beschreibt den Prozess-Fluss innerhalb eines Unternehmens zwischen internen
Web-Services und den externen Austausch von Nachrichten zwischen Web-ServiceNutzern
XForms
W3C-Recommendation seit 2003. XML-basierte Technologie, die Daten von der Präsentation kapselt. XForms stellen erweiterte Funktionalitäten als HTML-basierte Eingabemasken zur Verfügung.
XKMS
XML Key Management Services:
XKMS ist eine Kollektion von Sicherheits- und Vertrauensdiensten. XKMS bietet ein
Verschlüsselungsverfahren für die gesendeten Daten an.
XLANG
Eine von Microsoft entwickelte Nachrichten-zentrierte Flusssprache, um einzelne
Nachrichten innerhalb eines WSDL-Dokumentes in einen Geschäfts-Prozess-Fluss zu
binden.
XML
Extensible Markup Language:
Universelles Format zum Strukturieren von Daten und Dokumenten durch Tags, die
selbst gebildet werden können. XML ist eine Spezifikation des W3C und stellt eine
Untermenge von SGML (Standard Generalized Markup Language) dar.
XSD
XML Schema Definition:
W3C-Recommendation seit Mai 2001 zum Beschreiben der Struktur und Grammatik
von XML-Dokumenten.
