Deutsche Telekom AG – Fachhochschule Leipzig Datenstrukturen innerhalb von XML Web Services Diplomarbeit Axel Schneider Deutsche Telekom AG – Fachhochschule Leipzig Vergleichende Analyse von Varianten zur Übergabe von komplexen Datenstrukturen innerhalb von XML Web Services mit Fuzzy-Logik Angefertigt von: Schneider, Axel, 00420 Beginn: 01.09.2004 Ende: 14.01.2005 (16.00 Uhr) Erstprüfer / Betreuer: Prof. Dr.-Ing. Sabine Wieland Deutsche Telekom AG – Fachhochschule Leipzig Zweitprüfer / Betreuer: Dipl. Wirtschaftsinformatiker (FH) Jörg Hastreiter T-Systems International Multimedia Solutions GmbH Inhaltsverzeichnis Inhaltsverzeichnis I Abkürzungsverzeichnis V Glossar VII Abbildungsverzeichnis XV Tabellenverzeichnis XVII Listings XX 1 Einleitung 1 1.1 Zielstellung 1 1.2 Gliederung 2 2 Vorbereitende Betrachtungen 3 2.1 Varianten zur Übertragung komplexer Datenstrukturen 3 2.1.1 Einleitung 3 2.1.2 Variante FLADA 6 2.1.3 Variante HIDA 9 2.1.4 Aufbau komplexer Datenstrukturen 11 2.2 Szenarien 12 2.3 Betrachtungskriterien 14 2.4 Fuzzy-Logik 15 2.4.1 Grundbegriffe der Fuzzy-Logik 16 2.4.1.1 Unscharfe Mengen 16 2.4.1.2 Linguistische Variablen 17 2.4.1.3 Unscharfe Regeln 20 2.4.2 Rückschlussmethoden 22 2.4.3 Theoretische Modellierung eines Fuzzy Systems 22 2.4.4 Verwendung einer Applikation zur Erstellung von FIS 24 2.4.5 Schlussfolgerung 24 3 Systemanalyse 25 3.1 Festlegen von Schlüsselelementen 26 3.1.1 Schnittstellendefinition 26 3.1.2 Entwicklung 27 3.1.3 Deployment 27 3.1.4 Test 28 3.1.5 Performance 28 3.1.6 Fehleranfälligkeit 29 3.1.7 Erweiterbarkeit 29 3.2 Beziehungen 30 3.3 Gewichtung 31 3.4 Zusammenfassung 31 4 Prototypische Modellierung eines FIS 32 4.1 Festlegen linguistischer Variablen 32 4.1.1 Linguistische Grundmenge 32 4.1.2 Setzen von Minima und Maxima 33 4.1.3 Partitionierung und Verlauf der Zugehörigkeitsfunktion 34 4.1.4 Deklaration in Matlab-Quellcode 35 4.2 Definition einer Wissensbasis 36 4.3 Wahl einer Defuzzyfizierungsmethode 40 4.4 Automatisierte Auswertung 41 5 Vergleich der Varianten 43 5.1 Anmerkungen zum Ablauf des Vergleichs 43 5.1.1 Ziel 43 5.1.2 Abgrenzung 43 5.1.3 Vorgehensweise 43 5.1.4 Hinweis 44 5.2 Beschreibung des Szenarios 45 5.3 Schnittstellendefinition 45 5.3.1 Ziel 45 5.3.2 These 45 5.3.3 Aufbau, Erstellung und Probleme mit WSDL Dokumenten 46 5.3.3.1 Aufbau eines WSDL Dokumentes 46 5.3.3.2 Vorgehensweisen zum Erstellen einer WSDL-Datei 48 5.3.3.3 Probleme beim Erstellen eines WSDL Dokumentes 48 5.3.4 Bestimmung der Komplexität 49 5.3.5 Zusammenfassende Interpretation 52 5.4 Entwicklung 53 5.4.1 Ziel 53 5.4.2 These 53 5.4.3 Erstellen eines XML Web Services 53 5.4.3.1 Vorgehensweisen zum Erstellen 53 5.4.3.2 Variantenspezifisches Ausprogrammieren der Web Services 56 5.4.4 Bestimmung des Entwicklungsmehraufwandes 57 5.4.5 Zusammenfassende Interpretation 59 5.5 Deployment 61 5.5.1 Ziel 61 5.5.2 These 61 5.5.3 Ablauf eines Deployment-Prozesses 61 5.5.4 Bestimmung des Deployment-Mehraufwandes 63 5.5.5 Zusammenfassende Interpretation 64 5.6 Test 66 5.6.1 Ziel 66 5.6.2 These 66 5.6.3 Von der Theorie zur Praxis des Testens 66 5.6.3.1 Notwendige Arten von Softwaretests für XML Web Services 66 5.6.3.2 Klassifikation der Sichtweisen 67 5.6.3.3 Unterstützung während des Testprozesses 67 5.6.4 Bestimmung des Testmehraufwandes 68 5.6.5 Zusammenfassende Interpretation 69 5.7 Performance 71 5.7.1 Ziel 71 5.7.2 These 71 5.7.3 Performance-Betrachtungen 72 5.7.3.1 Codeausführung: Early Bindung vs. Late Binding 72 5.7.3.2 Manuelles Messen und Auswerten 72 5.7.3.3 Toolbasiertes Messen und Auswerten 72 5.7.4 Bestimmung des Performance-Mehraufwandes 72 5.7.5 Zusammenfassende Interpretation 74 5.8 Fehleranfälligkeit 76 5.8.1 Ziel 76 5.8.2 These 76 5.8.3 Konzepte um Fehler zu minimieren 76 5.8.3.1 Allgemeine Programmierkonzepte 76 5.8.3.2 Design by Contract 77 5.8.3.3 Sicherheit durch architektonische Maßnahmen 78 5.8.4 Bestimmung der Fehleranfälligkeit 78 5.8.5 Zusammenfassende Interpretation 80 5.9 Erweiterbarkeit 82 5.9.1 Ziel 82 5.9.2 These 82 5.9.3 Bestimmung der Erweiterbarkeit 82 5.9.4 Zusammenfassende Interpretation 84 5.10Zusammenfassung 86 6 Entwurf einer Strategie zur Entscheidungsfindung 89 6.1 Strategien 89 6.1.1 Strategie nach MASCHA 89 6.1.2 Ausschlussstrategie 91 6.1.3 Favoritenstrategie 91 6.2 Eingrenzung und Wahl einer Strategie 91 6.3 Vorgehensweise nach der Favoritenstrategie 92 6.3.1 Erstellen der Fragenkataloge 92 6.3.2 Bewertung der Fragen 93 6.3.3 Anwendung am Service „Chat“ 95 7 Abschließende Zusammenfassung und Ausblick 98 7.1 Ergebnisse 98 7.2 Ausblick 99 Literaturverzeichnis 100 Internetquellen 103 Hilfsmittelverzeichnis 105 Anlagenverzeichnis 106 Anlage1 – Linguistische Variablen 107 Anlage2 – Fuzzy-Systeme 119 Anlage3 – Status-Quo-Szenario 147 Inhalt der CD-Rom 161 Selbstständigkeitserklärung 162 Abkürzungsverzeichnis A2A Application to Application API Application Programm Interface CoA Center of Area CORBA Common Object Request Broker Architecture CSC Customer Self Care DCOM Distributed Component Object Model FTP File Transfer Protocol IDL Interface Definition Language FIS Fuzzy Inference System FLADA Flache Datenstruktur HIDA Hierarchische Datenstruktur HTTP Hypertext Transfer Protocol IIS Internet Information Services ISP Internet Service Provider LOC Lines Of Code MoM Mean of Maximum MS.Net Microsoft .Net OSS Operational Support System RPC Remote Procedure Call SMTP Simple Mail Transfer Protocol SOA Service Oriented Architectur SSL Secure Socket Layer TC Technischer Konfigurator TRIMF Triangular Shaped Membership Function TRAPMF Trapezodial Shaped Membership Function TSI-MMS T-Systems International Multimedia Solutions GmbH UDDI Universal Description, Discovery and Integration WSDL Web Service Description Language WSP Web- und Shop Relaunch XML Extensible Markup Language Glossar .Net-Framework ist ein Software Development Kit zur Entwicklung und Verteilung von Software, die auf der .NET Plattform basiert. API ist ein zur Verfügung stehendes Set von Funktionalitäten, das über Schnittstellen Zugriff auf diese Funktionalitäten bietet und so eingesetzt werden kann, um bestimmte Abläufe und Algorithmen zu realisieren. Client ist das anfordernde Programm in einer Client-Server-Beziehung. Es fordert Informationen von einem anderen Computer bzw. Programm (Server) an. Client/Server Prinzip, das die Beziehung zwischen einem Programm, dem Client, das einen Dienst von einem anderen Programm, dem Server, anfordert beschreibt. CoA bezeichnet eine Defuzzyfizierungsmethode. Sie repräsentiert den Flächenschwerpunkt als den Wert, der die unscharfe Ausgangsmenge am besten repräsentiert. CORBA ist ein Standard für Komponenten, die unabhängig von der verwendeten Programmiersprache, Hard- und Software-Plattform miteinander interagieren. DCOM ist die Weiterentwicklung des Komponentenmodells COM von Microsoft und ermöglicht die Interaktion von Komponenten über Rechnergrenzen hinweg. FLADA Ist eine Variante zur Übertragung komplexer Datenstrukturen innerhalb von XML Web Services. Dabei werden die Daten in einer XML-Struktur innerhalb eines Strings definiert. Diese enthält auch den eigentlichen Funktionsaufruf. Fuzzy-Logic Theorie, welche die Unschärfe des menschlichen Denkens bzgl. Wissenspräsentation und Entscheidungsfindung modelliert. HIDA Ist eine Variante zur Übertragung komplexer Datenstrukturen innerhalb von XML Web Services. Dabei werden die Daten als komplexe XML-Typen übergeben. Die Signaturen der XML Web Service Methoden sowie die Datenstrukturen werden mittels WSDL-Dokument definiert. HTTP ist das Protokoll zur Übertragung von Text, Bildern, Sound oder Video oder anderer Multimedia- Dateien über das WWW. Das HTTP läuft auf der Basis des TCP/IP. IDL im Deutschen auch als Schnittstellendefinitionssprache bezeichnet – universelle Sprache zur Beschreibung der Schnittstellen (Interfaces) von Software-Komponenten (entwickelt in unterschiedlichen Programmiersprachen). Integrationstest bezeichnet das Testen eines Teilsystems (Softwarekomponente) im Gesamtsystem. Interaktion bezeichnet das Wechselspiel von Aktionen des Anwenders und Reaktionen des Programms. Internet ist ein weltweites System von heterogenen Computernetzwerken. Ein Nutzer kann von jedem Computer aus auf jeden beliebigen anderen Computer zugreifen, wenn er die entsprechende Berechtigung hat. Das Internet basiert auf dem Protokoll TCP/IP. Interoperabilität bezeichnet die Möglichkeit der Zusammenarbeit zwischen verschiedenen Programmen. Intranet ist ein privates Computernetzwerk innerhalb eines Unternehmens. Ein Intranet kann über verschiedene Unternehmensstandorte verteilt aufgebaut werden und besteht meist aus mehreren miteinander verbundenen lokalen Netzwerken. Ein Intranet ist über entsprechende Knotenpunkte mit dem Internet verbunden. MASCHA ist ein Entwurf einer Strategie, die auf Grundlage eines Szenarios den Entscheidungsprozess, ob FLADA oder HIDA zur Übertragung komplexer Datenstrukturen umgesetzt wird, vereinfachen soll. MoM bezeichnet eine Defuzzyfizierungsmethode. Sie repräsentiert den Mittelpunkt (der Ausgangsmenge mit der größten Zugehörigkeit) als den Wert, der die unscharfe Ausgangsmenge am besten repräsentiert. OSS besteht aus Programmen und Systemen, die Kommunikationsdiensteanbietern die Möglichkeit geben, ihre Netze und ihre Diensteinfrastruktur zu planen, zu monitoren, zu analysieren und zu überwachen. Provisioning bezeichnet den Vorgang des Verteilens von Daten. RPC stellen Methoden- oder Funktionsaufrufe über ein Netzwerk dar. CORBA und DCOM basieren auf RPC. Request stellt eine Anfrage an eine Softwarekomponente dar. Response stellt die Antwort auf eine Anfrage an eine Softwarekomponente dar. Server bietet Services für andere Computer und Programme. Ein Server behandelt die Anfragen anderer Computer bzw. Programme und sendet entsprechende Daten zurück an diese Clients. Service Chat ist ein Dienst, der eine textbasierte Online-Unterhaltung über das Internet ermöglicht. Service Datenbank ist ein Dienst, welcher die Verwaltung und Nutzung von Datenbanken übernimmt. Service Domainverwaltung ist ein Dienst, der eine bestimmte URL (First-Level-Domain) automatisch bei der nationalen Domain-Vergabestelle (DeNIC1) einträgt und diese URL mit WWW-Seiten, die darunter zu erreichen sein sollen, verbindet. Service Forum ist eine WWW-Seite, über die durch das Einstellen von Beiträgen und entsprechenden Antworten Diskussionen geführt werden können. Service Mail ist ein Dienst, welcher die Verwaltung und Nutzung von eMail-Konten übernimmt. Service Shop ist eine WWW-Seite, welche einen Einkaufskanal darstellt. In einen Shop können Waren mit Hilfe eines „Einkaufskorbes“ gesammelt und nachfolgend ein Kaufvertrag in Form einer online- Bestellung geschlossen werden. 1 Die DeNIC (Deutsches Network Information Center) ist eine eingetragene Genossenschaft, die aus verschiedenen deutschen ISPs besteht und die Funktion des Network Information Center für den deutschen Teil des Internet übernommen hat. – http://www.denic.de SOA stellt einen Architekturansatz dar, der den Austausch von Daten und die Funktionalität zwischen Anwendungen (A2A) beinhaltet. Eine SOA besteht aus Service-Anbieter, Service-Verzeichnis und Service-Konsumenten. SOAP Ein auf XML beruhendes Protokoll für den Austausch von Informationen. (Früher bekannt als Simple Object Access Protokol.) TC Konfigurationsoberfläche des verteilten Systems (ISP-System) des Projektes WSP. TCP/IP ist ein Kommunikationsprotokoll zur Kommunikation in Computernetzen. Das TCP/IP ist das Basisprotokoll des Internets. TRIMF beschreibt mathematisch eine dreiecksförmige Funktion. TRAPMF beschreibt mathematisch eine trapezförmige Funktion. TSI-MMS ist eines der größten Multimedia-Unternehmen in Europa und kompetenter e-Business Enabler im Telekom-Konzernverbund. UDDI ist ein universelles (Service-) Verzeichnis, in dem Unternehmen sich selbst und die angebotenen Dienstleistungen beschreiben und in Form eines WSDL-Dokumentes ablegen können. Unit-Test bezeichnet den von einem Software-Entwickler programmierten Test, um Softwarekomponenten auf deren korrekte Ausführung unter bestimmten Situationen zu testen. Verteilte Systeme bestehen aus Komponenten, die auf mehreren Rechnern verteilt, miteinander durch den Austausch von Nachrichten interagieren. Webseitengenerator ist ein Dienst, welcher WWW-Seiten automatisch durch Drag-And-Drop generiert. Dabei steht, je nach Branche, eine Vielzahl von Layout-Vorlagen zur Verfügung. Andere Dienste wie Shop, Chat oder Forum können durch den Webseitengenerator eingebunden werden. WSDL ist eine standardisierte IDL zur Beschreibung von XML Web Services. WSP Akronym für das Projekt „T-ComWeb- und Shop Relaunch“. WWW (World Wide Web) ist ein Teil des Internets. Das WWW nutzt das HTTP-Protokoll. XML ist eine flexible Möglichkeit, um Datenformate zu erstellen und sowohl diese Formate als auch die darin gespeicherten Daten zwischen verschiedenen Systemen auch über das Internet auszutauschen. XML Web Services bezeichnet verteilte, lose gekoppelte Software-Komponenten, die standardisierte Technologien (XML, SOAP, WSDL) verwenden. Abbildungsverzeichnis Abbildung 1: Beispiel eines Workflows innerhalb des verteilten Systems des Projektes WSP 4 Abbildung 2: Interaktion des Service-Nutzers mit einem Service-Anbieter 5 Abbildung 3: Interaktion des Service-Nutzers mit einem Service-Anbieter mittels FLADA 6 Abbildung 4: Interaktion des Service-Nutzers mit einem Service-Anbieter mit HIDA 9 Abbildung 5: Request-Datenstruktur für das Anlegen eines Chatraumes 10 Abbildung 6: Response-Datenstruktur nach erfolgreichem Anlegen eines Chatraumes 10 Abbildung 7: Szenariotrichter 13 Abbildung 8: Subjektive Interpretation menschlicher Sprache 16 Abbildung 9: Mathematische Beschreibung eines dreiecksförmigen Funktionsverlaufs 19 Abbildung 10: Mathematische Beschreibung eines trapezförmigen Funktionsverlaufs 19 Abbildung 11: Visualisierung der linguistischen Variablen „intIntParams“ 20 Abbildung 12: Bereich möglicher Verknüpfungen nach [Iwe00] 21 Abbildung 13: Vergleich von Defuzzyfizierungsmethoden nach [I-Koi] 22 Abbildung 14: Grundkonfiguration eines FIS mit 4 Hauptkomponenten nach [Iwe00] 23 Abbildung 15: Für den Variantenvergleich berücksichtigte Aufgaben 25 Abbildung 16: Beziehungen der Betrachtungskriterien 30 Abbildung 17: Entwurf von Regeln für Abhängigkeiten zwischen den Schlüsselelementen 37 Abbildung 18: Entwurf von Regeln für Abhängigkeiten zwischen Betrachtungskriterien 38 Abbildung 19: Beschreibung des Inferenzschrittes in drei Schritten 39 Abbildung 20: Verarbeitungsreihenfolge der Matlab-Files 41 Abbildung 21: Aufbau eines WSDL-Dokumentes nach [Kus02] 47 Abbildung 22: Darstellung der linguistischen Variablenwerte (Schnittstellendefinition, Status- Quo) 50 Abbildung 23: Vergleich des Kriterium-Faktors aller Szenarien (Schnittstellendefinition) 51 Abbildung 24: Erstellung eines XML Web Services nach „Code First“ 54 Abbildung 25: Erstellung eines XML Web Services nach „Contract First“ 54 Abbildung 26: Vergleich der linguistischen Variablen (Entwicklung, Status-Quo) 58 Abbildung 27: Entwicklungsmehraufwand aller Szenarien im Vergleich 59 Abbildung 28: Deployment-Prozess 62 Abbildung 29: Vergleich der linguistischen Variablenwerte (Deployment) 63 Abbildung 30: Vergleich der Kriterium-Faktoren aller Szenarien (Deployment) 64 Abbildung 31: Vergleich der linguistischen Variablen (Test, Status-Quo) 68 Abbildung 32: Testmehraufwand aller Szenarien im Vergleich 69 Abbildung 33: Vergleich der linguistischen Variablen (Performance, Status-Quo) 73 Abbildung 34: Performance-Änderung aller Szenarien im Vergleich 74 Abbildung 35: Vergleich der linguistischen Variablen (Fehleranfälligkeit, Status-Quo) 79 Abbildung 36: Fehleranfälligkeiten aller Szenarien im Vergleich 80 Abbildung 37: Vergleich der linguistischen Variablen (Erweiterbarkeit, Status-Quo) 83 Abbildung 38: Erweiterbarkeit aller Szenarien im Vergleich 84 Abbildung 39: Prozentuale Verteilung der Vorteile je Betrachtungskriterium 87 Abbildung 40: Prozentuale Verteilung der Nachteile je Betrachtungskriterium 88 Abbildung 41: Lösungsstrategie nach MASCHA 90 Abbildung 42: Beantwortung des ersten Fragenkataloges zu Gunsten von FLADA 94 Abbildung 43: Beantwortung des zweiten Fragenkataloges zu Gunsten von FLADA 94 Abbildung 44: Beantwortung von Fragen des dritten Fragenkataloges 95 Abbildung 45: Ansicht aller Regeln der Schnittstellendefinition-DS 123 Abbildung 46: Ansicht aller Regeln der Schnittstellendefinition 124 Abbildung 47: Ansicht aller Entwicklungsregeln 127 Abbildung 48: Ansicht aller Deployment-Regeln 130 Abbildung 49: Ansicht aller Testregeln 133 Abbildung 50: Ansicht aller Performanceregeln 137 Abbildung 51: Ansicht aller Fehleranfälligkeitsregeln 141 Abbildung 52: Ansicht aller Erweiterbarkeitsregeln 146 Abbildung 53: Vergleich der Status-Quo-Szenarien mit Hilfe der Betrachtungskriterien 159 Abbildung 54: Vergleich der Best-Case-Szenarien mit Hilfe der Betrachtungskriterien 159 Abbildung 55: Vergleich der Worst-Case-Szenarien mit Hilfe der Betrachtungskriterien 160 Tabellenverzeichnis Tabelle 1: Möglichkeit der Datenübertragung (FLADA) 11 Tabelle 2: Möglichkeiten der Datenübertragung (HIDA) 11 Tabelle 3: Definition einer linguistischen Grundmenge für die Komplexität einer Datenstruktur 18 Tabelle 4: Beispiel einer linguistischer Regeln zur Berechnung der Komplexität einer Datenstruktur 21 Tabelle 5: Schlüsselelemente des Betrachtungskriteriums Schnittstellendefinition (1/2) 26 Tabelle 6: Schlüsselelemente des Betrachtungskriteriums Schnittstellendefinition (2/2) 27 Tabelle 7: Schlüsselelemente des Betrachtungskriteriums Entwicklung 27 Tabelle 8: Schlüsselelemente des Betrachtungskriteriums Deployment 28 Tabelle 9: Schlüsselelemente des Betrachtungskriteriums Test 28 Tabelle 10: Schlüsselelemente des Betrachtungskriteriums Performance 28 Tabelle 11: Schlüsselelemente des Betrachtungskriteriums Fehleranfälligkeit 29 Tabelle 12: Schlüsselelemente des Betrachtungskriteriums Erweiterbarkeit 29 Tabelle 13: Definition der linguistischen Grundmenge der Eingabevariablen 33 Tabelle 14: Definition der linguistischen Grundmenge der Ausgabevariablen 33 Tabelle 15: Festlegen der Minima und Maxima 34 Tabelle 16: Partitionierung und Zuweisung der Funktionsverläufe der Eingabevariablen 34 Tabelle 17: Partitionierung und Zuweisung der Funktionsverläufe der Ausgabevariablen 35 Tabelle 18: Beispiele linguistischer Regeln, um die Komplexität einer Datenstruktur zu berechnen 36 Tabelle 19: Legende zur Bewertung der variantenspezifischen Vor- und Nachteile 44 Tabelle 20: Werte aller linguistischen Variablen (Schnittstellendefinition) 50 Tabelle 21: Anzahl der Beschreibungszeilen je Szenario und Variante 50 Tabelle 22: Vor- und Nachteile bei der Schnittstellenbeschreibung 53 Tabelle 23: Werte aller linguistischen Variablen (Entwicklung, Status-Quo) 57 Tabelle 24: Vor- und Nachteile bei der Entwicklung 60 Tabelle 25: Werte der linguistischen Variablen (Deployment) 63 Tabelle 26: Vor- und Nachteile beim Deployment 65 Tabelle 27: Werte aller linguistischen Variablen (Test, Status-Quo) 68 Tabelle 28: Vor- und Nachteile des Tests 71 Tabelle 29: Werte aller linguistischen Variablen (Performance, Status-Quo) 73 Tabelle 30: Vor- und Nachteile der Performance-Änderung 76 Tabelle 31: Werte aller linguistischen Variablen (Fehleranfälligkeit, Status-Quo) 78 Tabelle 32: Vor- und Nachteile der Fehleranfälligkeit 82 Tabelle 33: Werte aller linguistischen Variablen (Erweiterbarkeit, Status-Quo) 83 Tabelle 34: Vor- und Nachteile der Erweiterbarkeit 86 Tabelle 35: Auflistung der Summen aller Vor- und Nachteile je Betrachtungskriterium 87 Tabelle 36: Fragen, die auf Grund der Vorbedingungen eine Variante bevorzugen 92 Tabelle 37: Fragen, die Ressourcenaspekte einbeziehen 93 Tabelle 38: Antworten zu den Fragenkatalogen 96 Tabelle 39: Definition der linguistischen Variablen für eine Teilevaluierung des Betrachtungskriteriums „Schnittstellendefinition“ 108 Tabelle 40: Definition der linguistischen Variablen für das Betrachtungskriterium Schnittstellendefinition 109 Tabelle 41: Definition der linguistischen Variablen für das Betrachtungskriterium Entwicklung 110 Tabelle 42: Definition der linguistischen Variablen für das Betrachtungskriterium Deployment 111 Tabelle 43: Definition der linguistischen Variablen für das Betrachtungskriterium Test 112 Tabelle 44: Definition der linguistischen Variablen für das Betrachtungskriterium Performance (Teil 1/2) 113 Tabelle 45: Definition der linguistischen Variablen für das Betrachtungskriterium Performance (Teil 2/2) 114 Tabelle 46: Definition der linguistischen Variablen für das Betrachtungskriterium Fehleranfälligkeit (Teil 1/2) 115 Tabelle 47: Definition der linguistischen Variablen für das Betrachtungskriterium Fehleranfälligkeit (Teil 2/2) 116 Tabelle 48: Definition der linguistischen Variablen für das Betrachtungskriterium Erweiterbarkeit (Teil 1/2) 117 Tabelle 49: Definition der linguistischen Variablen für das Betrachtungskriterium Erweiterbarkeit (Teil 2/2) 118 Tabelle 50: Merkmale des Status-Quo-Szenarios der Variante FLADA am Beispiel „Chat“ 148 Tabelle 51: Merkmale des Status-Quo-Szenarios der Variante HIDA am Beispiel „Chat“ 152 Tabelle 52: Werte der linguistischen Variablen der Szenarien Status-Quo, Best-Case und Worst- Case 156 Tabelle 53: Bedeutung der in Tabelle 52 genutzten Akronyme 157 Tabelle 54: Zuordnung von Szenarien, der Anzahl von Ein- und Ausgabeparametern und Hierarchieebenen 157 Tabelle 55: Ergebnisse der Fuzzy-Systeme nach Eingabe der Merkmalswerte 158 Tabelle 56: Inhalt der CD-Rom 161 Listings Listing 1: Request als String 7 Listing 2: Request als XML Datenstruktur 7 Listing 3: Response als String 8 Listing 4: Response als XML Datenstruktur 8 Listing 5: Darstellung einer unscharfen Menge U als Zugehörigkeitsfunktion µU 17 Listing 6: Auszug der Deklarierung der Eingabevariablen „intIntParams“ in Matlab-Quellcode 35 Listing 7: Auszug der Deklarierung der Ausgabevariablen „intIntFuzzy“ in Matlab-Quellcode 36 Listing 8: Auszug aus dem Regelwerk in Matlab-Quellcode 39 Listing 9: SOAP-Request 49 Listing 10: Generieren einer Value-Object-Klasse aus einem XML Schema 52 Listing 11: Generieren des XML Web Service als Server-Klasse 55 Listing 12: Generieren des XML Web Service-Clients als Proxy-Klasse 56 Listing 13: Beispielausführung des Fuzzy-Systems „Schnittstellendefinition-DS“ 120 Listing 14: Fuzzy-System der „Schnittstellendefinition-DS“ 121 Listing 15: Beispielausführung des Fuzzy-Systems „Schnittstellendefinition“ 121 Listing 16: Fuzzy-System der „Schnittstellendefinition“ 123 Listing 17: Beispielausführung des Fuzzy-Systems „Entwicklung“ 125 Listing 18: Fuzzy-System der „Entwicklung“ 126 Listing 19: Beispielausführung des Fuzzy-Systems „Deployment“ 128 Listing 20: Fuzzy-System für das „Deployment“ 129 Listing 21: Beispielausführung des Fuzzy-Systems „Test“ 131 Listing 22: Fuzzy-System der „Test“ 132 Listing 23: Beispielausführung des Fuzzy-Systems „Performance“ 134 Listing 24: Fuzzy-System der „Performance“ 137 Listing 25: Beispielausführung des Fuzzy-Systems „Fehleranfälligkeit“ 138 Listing 26: Fuzzy-System der „Fehleranfälligkeit“ 141 Listing 27: Beispielausführung des Fuzzy-Systems „Erweiterbarkeit“ 142 Listing 28: Fuzzy-System der „Erweiterbarkeit“ 145 1 Einleitung Mit dem Einzug von XML Web Services in die Welt des Inter- und Intranets ist die Kommunikation zwischen Rechnern einfacher geworden. Langner ([Lan04]) behauptet sogar, sie seien die „Erlösung der Entwicklergemeinde von der Flut unterschiedlicher Standards“, denn mit RPC, COM oder CORBA standen bereits vor XML Web Services interoperable Client-Server- Systeme zur Verfügung, deren Standards jedoch nicht von allen Herstellern eingehalten wurden. Mit XML Web Services scheint ein Standard gefunden worden zu sein, an den sich alle Hersteller halten. Das ist der Grund, weshalb ein Hype um Schlagworte wie XML Web Services oder Service Oriented Architecture (SOA) entstanden und nicht mehr aus den Köpfen der Entwickler und Entscheidungsträger wegzudenken ist. ([Lan04]) Nutzen daraus ziehen vor allem große Service-Anbieter wie Google1 oder Amazon2, indem sie bspw. eine API zu ihren eigenen Daten anbieten. Auch die T-Systems International Multimedia Solutions GmbH (TSI-MMS) in Dresden setzt XML Web Services im Java und Microsoft.Net-Umfeld ein, um eine interoperable Kommunikation zwischen Applikationen (A2A) zu gewährleisten. Dass bei der Entwicklung von XML Web Service jedoch immer noch mehrere Wege zum Ziel führen, ist in der Offenheit der nutzbaren Standards begründet. Besonders die Definition, wie die zu übertragenden Nachrichten gesendet und empfangen werden, kann quasi beliebig erfolgen, beeinträchtigt allerdings viele Phasen der späteren Software-Entwicklung. 1.1 Zielstellung Der Vergleich von zwei Varianten, wie Nachrichten innerhalb von XML Web Services definiert werden können, ist das Ziel dieser Arbeit. Der Schwerpunkt liegt darin, die Varianten auf sieben Betrachtungskriterien zu vergleichen und variantenspezifische Vor- und Nachteile zu analysieren. Um subjektiven Eindrücken bei der Bewertung der Ergebnisse keine tragende Rolle zukommen zu lassen, wird eine linguistische Logik gewählt - die Fuzzy-Logik. Sie soll visualisierbare und vor allem vergleichbare Werte liefern. 1 Google-API: http://www.google.com/apis/ 2 Amazon-API: http://www.amazon.com/webservices/ Da ein Projekt eine gewisse Einmaligkeit aufweist, werden außerdem verschiedene Szenarien erstellt. Mit Hilfe dieser Szenarien werden schließlich eine oder mehrere Strategien erarbeitet, welche die Entscheidung erleichtern, unter welchen Projektbedingungen die passende Nachrichtenübertragungsvariante gewählt wird. Durch die gewonnenen Erkenntnisse des Vergleichs und deren Einbindung in eine Strategie, werden Vor- und Nachteile einer Variante bereits vor Beginn der Entwicklungsarbeiten evaluierbar. 1.2 Gliederung Zuerst werden in Kapitel 2 die Varianten vorgestellt und die zum Vergleich notwendigen Techniken kurz beschrieben. Dabei wird auf die Szenario-Technik, die zu vergleichenden Betrachtungskriterien und die Logik der Unschärfe eingegangen. In Kapitel 3 und 4 erfolgt die Grundlagenarbeit, die für den Vergleich notwendig ist. Dabei werden in Kapitel 3 wichtige Parameter für jedes Betrachtungskriterium festgelegt, bestehende Beziehungen aufgezeigt und das Setzen von Gewichtungen erläutert. Kapitel 4 erläutert kurz theoretische Grundlagen und zeigt ein zur Fuzzy-Logik gehörendes System am Beispiel des ersten Betrachtungskriteriums „Schnittstellendefinition“. Darauf aufbauend erfolgt in Kapitel 5 ein Vergleich je Betrachtungskriterium. Dabei wird jeweils ein Ziel definiert und eine These aufgestellt, die mittels der ausgewerteten und interpretierten Werte der Vergleichsparameter evaluiert werden. Abschließend erfolgt eine Zusammenfassung aller Ergebnisse. Alle gewonnenen Erkenntnisse werden dann in Kapitel 6 für Ideen einer oder mehrerer Strategien genutzt. Die Strategien werden vorgestellt, deren Einsatzfähigkeit geprüft und nachfolgend eine davon exemplarisch entworfen und an einem Szenario getestet. Die Ergebnisse dieser Arbeit werden in Kapitel 7 zusammengefasst. Weiterhin werden vom Autor kurz die notwendigen Schritte zur Weiterführung der Arbeit aufgezählt und es erfolgt ein Ausblick der verwendeten Technologien für die Zukunft.