Thomas Faust, Andreas Linke, Steffen Schäfer

Aufbau Integrierter Informationssysteme Integration durch Einsatz von XML und Web Services
Thomas Faust, Andreas Linke, Steffen Schäfer Martin-Luther-Universität Halle-Wittenberg Hauptseminar - Halle

Gliederung Grundlagen Web Services XML SOAP & WSDL UDDI
Ausblick & Zusammenfassung © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

Web Services (1) Programm-zu-Programm Kommunikationsmodell
Selbstbeschreibende, in sich geschlossene und modulare Anwendungen Integration von Anwendungen Kombinierbar mit anderen Web Services zu Produkten oder Prozessen © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

Web Services (2) Basierend auf offenen (Internet-) Standards:
Web Services (2) Basierend auf offenen (Internet-) Standards: HTTP, SMTP XML – eXtensible Markup Language SOAP – Simple Object Access Protocol WSDL – Web Services Description Language UDDI – Universal Description, Discovery and Integration Unabhängig von: der Plattform dem Objekt-Modell der Programmiersprache © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Web Services Modell Service Registry Werkzeuge Rollen Service Registry
Service Description Werkzeuge Rollen Service Registry Service Requestor Service Provider Find Publish Bind Tätigkeiten WSDL, UDDI Service Requestor Service Provider © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

XML - Eigenschaften XML ist eine Meta-Sprache:
XML - Eigenschaften XML ist eine Meta-Sprache: Zur Beschreibung von Auszeichnungssprachen z. B. mit XML definierte Sprachen: XHTML, WML, XSL, ... Trennung zw. Struktur, Inhalt und Format Struktur der Informationen: sowohl syntaktisch als auch semantisch Inhalt Format: das Layout wird für ein bestimmte Struktur vorgegeben Von einem Computer auswertbar Dient der Beschreibung von logischen Dokumenten-Strukturen Definiert keine Markierung (Markierung z.B. HTML <p>) © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

XML - Komponenten XML - Dokument DTD XML - Schema XSL XSLT Namespace
XML - Komponenten XML - Dokument DTD XML - Schema XSL XSLT <?xml version="1.0" encoding="ISO „ standalone="no"?> <!DOCTYPE brief SYSTEM "brief.dtd"> <brief> <anrede geschlecht="f" sozial="du">Nora</anrede> <text>habe gerade den Ulysses beendet. Mal sehen, wann der in den USA gedruckt werden darf...</text> <gruss>J.J.</gruss> </brief> <!–- the end --> Namespace XLink XPointer XPath © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

XML – Aufbau eines Dokuments
XML – Aufbau eines Dokuments Prolog <?xml version="1.0" encoding="ISO " standalone="no"?> <!DOCTYPE brief SYSTEM "brief.dtd"> <brief> <anrede geschlecht="f" sozial="du">Nora</anrede> <text>habe gerade den Ulysses beendet. Mal sehen, wann der in den USA gedruckt werden darf...</text> <gruss>J.J.</gruss> </brief> <!–- the end --> Elemente Epilog brief.xml © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

brief.xml (1) DTD‘s - Document Type Definition
brief.xml (1) <?xml version="1.0" encoding="ISO " standalone="no"?> <!DOCTYPE brief SYSTEM "brief.dtd"> Prolog Verarbeitungsanweisungen DTD‘s - Document Type Definition <!–- the end --> Epilog weitere Verarbeitungsanweisungen und Kommentare © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

brief.xml (2) Wurzel-Element Markierungen
brief.xml (2) <brief> <anrede geschlecht="f" sozial="du">Nora</anrede> <text>habe gerade den Ulysses beendet. Mal sehen, wann der in den USA gedruckt werden darf...</text> <gruss>J.J.</gruss> </brief> Elemente Wurzel-Element Markierungen Element bezeichnet den eingeschlossenen Inhalt der Markierungen Jedes Element kann Attribute enthalten, hinter dem Element-Namen werden dazu Name-Wert-Paare geschrieben © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

DTD – Document Type Definition (1)
DTD – Document Type Definition (1) DTD’s beschreiben die Struktur von XML-Dokumenten Legt fest welche Elemente & wie ineinander geschachtelt Verwendung von DTD’s um Einhaltung von Namenskonventionen für Markierungen bzw. eine einheitliche Struktur für gleichartige XML-Dokumente automatisch sicherzustellen © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

DTD - Document Type Definition (2)
DTD - Document Type Definition (2) <!ELEMENT brief ( anrede, text, gruss ) > <!ELEMENT anrede ( #PCDATA ) > <!ELEMENT text ( #PCDATA ) > <!ELEMENT gruss ( #PCDATA ) > <!ATTLIST anrede geschlecht ( f | m ) #REQUIRED sozial (du | sie ) #REQUIRED > brief.dtd Definiert Elemente, Attribute, Entities 2 Nachteile: keine Typ-Definition von Elementen möglich (Postleitzahl sollte nur aus Ziffern bestehen) und DTD’s sind selbst keine XML-Dokumente © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

XML Schema XML-basierte Sprache (XML-Schemata sind XML-Dokumente)
Konstrukte zur Spezifikation von Struktur, Inhalt und Semantik von XML-Dokumenten, insbesondere Datentypen Definition eigener Datentypen möglich Einige Datentypen sind fest vorgegeben, z.B. date für Datumsangaben © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

Konformität Beim Überprüfen auf Korrektheit eines Dokumentes sieht die XML-Spezifikation 2 Stufen vor: Wohlgeformtes Dokument (well-formed) bei richtigem Syntax: Prolog + mind. ein Element Gesamtes Dokument in einem Wurzelelement Korrekte Verschachtelung Alle Attribute in Anführungszeichen Gültiges Dokument (valid) wenn die Struktur einer DTD oder einem XML-Schema entspricht: Dokument ist wohlgeformt Es ist eine existierende DTD definiert, die verfügbar ist Das Dokument entspricht den aufgestellten Regeln © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

Ausgabe von XML – Dokumenten (1)
Ausgabe von XML – Dokumenten (1) Die Darstellung von XML-Dokumenten wird mit sog. Stylesheets definiert: XSL - XML Stylesheet Language CSS - Cascading Style Sheet Der Standard ist XSL, bestehend aus 2 Komponenten: XSL beschreibt die Ausgabe (Formatierungssprache) XSLT ermöglicht eine Transformation eines XML-Dokuments in ein anderes Format (Transformationssprache) XSL-Stylesheets sind XML-Dokumente © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Ausgabe von XML – Dokumenten (2)
Ausgabe von XML – Dokumenten (2) DTD XML - Schema XSL XSLT XML - Dokument <?xml version="1.0" encoding="ISO „ standalone="no"?> <!DOCTYPE brief SYSTEM "brief.dtd"> <brief> <anrede geschlecht="f" sozial="du">Nora</anrede> <text>habe gerade den Ulysses beendet. Mal sehen, wann der in den USA gedruckt werden darf...</text> <gruss>J.J.</gruss> </brief> <!–- the end --> ... © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

brief.xsl brief.html brief.xml brief.xsl
<?xml version="1.0" encoding="ISO "?> <xsl:stylesheet version="1.0" xmlns:xsl=" xmlns=" <xsl:output method="html"/> <xsl:template match="/"> <html> <body> <xsl:apply-templates/> </body> </html> </xsl:template> <xsl:template match="anrede"> <p> <xsl:choose> <xsl:when <xsl:text>Liebe</xsl:text> <xsl:if <xsl:text>r</xsl:text> </xsl:if> <xsl:text> </xsl:text> </xsl:when> <xsl:when ... <xsl:text>,</xsl:text> </p> </xsl:stylesheet> brief.xsl brief.html brief.xml brief.xsl © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

Namespaces Durch die freie Wahl der Markierungen kann es passieren, dass in einem Dokument Elemente aus verschiedenen DTD’s verwendet werden, bei dem die Verwendung gleicher Markierungen mit unterschiedlicher semantischer Bedeutung zu Konflikten führt. In XML lassen sich deshalb sog. Namensbereiche definieren. I.A. werden URL’s verwendet, die eine weltweite Einmaligkeit garantieren sollen. Definition eines Präfix, der jeder Markierung im Dokument vorangestellt wird: xmlns=" © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

XLink Ermöglicht das Beschreiben von Links in Form herkömmlicher Links in eine Richtung aber auch komplexere Link-Strukturen. Jedes Element kann mit einer Link-Funktionalität versehen werden, dies geschieht durch das Einfügen des Attributs xlink:type (simple oder extended). Arten: Simple Links Extended Links Danach können weitere Attribute folgen, die weitere Informationen zum Link bereithalten (xlink:href | show | actuate | role). © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

XPointer Adressierung von Zielstellen eines Links innerhalb eines XML-Dokuments Verweist auf beliebiges Element oder Dokument-Ausschnitt eines XML-Dokuments, ohne dass die Zielstelle selbst markiert wird (<> HTML) © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

XPath Ermöglicht Adressierung (Selektion) einzelner Knoten bzw. ganzer Bereiche Location Step: Navigation durch das Dokument über sog. Location Steps Es werden Informationen relativ zur aktuellen Position im Baum adressiert Die Bewegung erfolgt über Achsen (existieren unterschiedliche Arten) Location Path: Mehrere Location Steps (verknüpft durch „/“) bilden einen Location Path Grundlage für XPointer und XSLT © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

XML - Anwendung Überall wo neben korrekter Syntax auch eine semantische Beschreibung von Daten notwendig ist Web Services: […] WSDL is an XML document […] […] SOAP is a simple and lightweight XML-based mechanism […] […] UDDI […] service description information in XML […] © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Zur Einordnung:
 exemplarisch der - Conceptual Web Services Stack [Ausschnitt] © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

Simple Objects Access Protocol
SOAP und WSDL Simple Objects Access Protocol SOAP stellt einen einfachen und durchsichtigen Mechanismus zum Austausch von strukturierter und getypter Information zur Verfügung. Ziele: Einfachheit und Erweiterbarkeit Einsatz auf verteilten Systemen [auch durch Firewalls hindurch] Das Rad nicht neu zu erfinden, sondern aktuelle Standards [HTTP und XML] zu nutzen © 2001 Monika Mustermann, MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

SOAP und WSDL SOAP ist XML! Das Protokoll besteht aus 3 Teilen:
der Spezifikation für den Umschlag einem Satz von Kodier- und Ordnungsregeln [serialization] einer Konvention um RPC‘s und evtl. Antworten zu repräsentieren envelope namespace-identifier: serialization namespace-identifier: © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Das Nachrichtenmodell:
SOAP-Nachrichten sind kombinierte Übertragungen vom Sender zum Empfänger. Die Nachrichten verfolgen den sog. Message Path, d.h. sie können an jedem auf dem Weg liegenden Knotenpunkt verarbeitet werden. Empfang 1. Identifizieren aller Teile 2. Sicherstellen der Bestimmung und Unterstützung Verarbeitung 3. Falls nicht endgültiger Empfänger „alte“ Teile entfernen und weiterleiten © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Der Aufbau von SOAP:
Ist optional und kann die Nachricht um Funktionalität erweitern, die vorher von den kommunizierenden Anwendungen nicht abgestimmt wurde. © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Ein Beispiel: <SOAP-ENV:Envelope
xmlns:SOAP-ENV=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Header> [...] </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Der Header
stellt flexiblen Mechanismus zum Erweitern der Nachricht zur Verfügung z.B. für Authentifizierung oder Transaktionsmanagement besitzt u.a. 2 essentielle Attribute: Das actor-Attribut: identifiziert eine Zwischenstation, die ggfs. Teile der Nachricht verarbeitet Das mustUnderstand-Attribut: gibt an ob die Verarbeitung optional ist, damit ist ein vorhersagbares Verhalten erzwingbar © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Der Body entspricht im Grunde einem Headerelement mit einem mustUnderstand-Wert von 1 und dem engültigen Empfänger der Nachricht als actor. Stellt einen einfachen Mechanismus zum Austausch der eigentlich der Nachricht zugrundeliegenden Information zur Verfügung. Enthält u.a. ein Fault-Element, um Informationen über eventuell aufgetretene Fehler in einer SOAP-Nachricht zu übermitteln. © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Die Serialisierung von Daten (Encoding)
basiert auf einem einfachen Typensystem. Jeder Datentyp gehört entweder den einfachen Datentypen an, oder ist aus mehreren Datentypen konstruiert. [ zusammengesetzter Datentyp] Erfolgt in 2 Schritten: aus dem Datenmodell der Anwendung ein Schema konstruieren Generierung der eigentlichen XML-Datei aus diesem Schema und dem aktuellen Datenbestand Alle Werte werden durch den Inhalt von Elementen repräsentiert, wobei für jedes nicht-leere Element der Datentyp angegeben werden muss. © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Welche Datentypen gibt es? Built-In Datentypen:
- string - boolean - float - double - decimal -timeDuration - binary -uriReference ... Beispiel: <element name="nachname" type="string"/> <element name="alter" type="int"/> <element name="groesse" type="float"/> © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Welche Datentypen gibt es noch? - Aufzählungstypen
- Structs - Arrays <simpleType base="xsd:string"> <enumeration value="Rot"/> <enumeration value="Blau"/> <enumeration value="Gelb"/> </simpleType> <e:Buch> <autor>David Flanagan</autor> <titel>Java In A Nutshell</titel> <verlag>O Reilly</verlag> <preis>69.00</preis> </e:Buch> <primzahlen SOAP-ENC:arrayType="xsd:int[2]"> <zahl>3</zahl> <zahl>5</zahl> </primzahlen> © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL SOAP auf HTTP
Warum? Kopplung von SOAP mit der Stabilität und reichhaltigen Funktionalität von HTT-Protokoll. SOAP folgt von sich aus dem Request/Response-Nachrichtenmodell des HTTP. Falls eine Firewall den Server und die Clients trennen so ist es unwahrscheinlich, dass DCOM- oder CORBA-Pakete übermittelt werden, weil diese oft aus Sicherheitsgründen nur HTTP-Pakete durchlassen. © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL RPC‘s mit SOAP
Das Kapseln und Austauschen von RPCs in dem XML-Datenstrom war eines der Design-Ziele der Autoren der SOAP-Spezifikation. Der RPC wird als HTTP-Request übermittelt und das Ergebnis wird als Response geliefert. Benötigt werden - die URI des Zielobjektes - der Methodenname - evtl. vorhandene Parameter der Methode © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

a SOAP und WSDL RPC‘s mit SOAP: Ein Beispiel Anfrage: Antwort:
<SOAP-ENV:Body> <M:HoleLetztenKurs xmlns:M="MeineURI"> <Aktie>SUN</Aktie> </M:HoleLetztenKurs> </SOAP-ENV:Body> Antwort: <SOAP-ENV:Body> <M:HoleLetztenKursResponse xmlns:M="MeineURI"> <Kurs>107.0</Kurs> </M:HoleLetztenKursResponse> a © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL SOAP und Sicherheit:
SOAP ist von sich aus kein sicheres Protokoll, im Grunde genommen sämtliche Daten im Klartext übermittelt werden. Um die Sicherheit müssen sich daher die zugrundeliegenden Übertragungsprotokolle oder die kommunizierenden Anwendungen kümmern. Wie wird es also nun sicher? Zum Beispiel durch Einsatz von sicheren Verbindungen: HTTPS oder durch Zwischenschalten von Verschlüsselungsstationen. © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Woher weiss der Service-Requestor nun welches Format die message verwenden soll? Diese Frage wird nun mit WSDL beantwortet. Die Servicebeschreibung ist der Schlüssel die WebService-Architektur loszulösen und gleichzeitig senkt es rapide die Quantität des gemeinsamen Verstehens beider Teilnehmer. Wie auch schon bei IDL erreicht man eine vollständige Sprachen- und Plattformunabhängigkeit!  geringere Fehleranfälligkeit  Automatisierung möglich © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Web Services Description Language
Die WebServices werden als eine Menge von Endpunkten beschrieben, die untereinander Nachrichten austauschen. WSDL ist abermals XML! Die abstrakte Definition ist streng getrennt von der konkreten Netzwerkaustattung und oder den verwendeten Protokollen. Damit wird eine Wiederverwendung der akstrakten Definitionen erreicht! © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Interface Definition Implementation Definition
gibt eine Menge von abstrakten Operationen an die, die von diesem Endpunkt unterstützt werden gibt Transportinformationen für einen PortType an Interface Definition gibt Netzwerkadresse eines Endpunktes an Ein Service ist die Menge zusammengehörender Ports. Implementation Definition © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Wie ist nun eine solche WSDL-Datei aufgebaut?
<definitions name=“Beispiel“ targetNamespace=" ...> <types> ... </types> <message name=“Anfrage"> </message> <portType name=“BspPortType"> <operation name=“Frage” <input message=wsdlns:”Anfrage”/> </operation> </portType> <binding name=“BspBinding" type="wsdlns:BspPortType"> <soap:binding style="document“ ...> ... </binding> <service name=“BspService"> <port name=“BspPort" binding="wsdlns:BspBinding"> <soap:address location=" </port> </service> </definitions> © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

SOAP und WSDL Die komplette WebServices – Beschreibung basiert also
auf einer solchen WSDL Definition. Das heißt der Anfragende weiss nun, wie man den Service in Anspruch nimmt und mit ihm interagiert. Er kann nun weitere Informationen anfragen: „Welches Geschäft bietet diesen Service an? Was ist das genau für ein Service und welche Produkte sind damit verbunden? UDDI stellt nun einen Mechanismus bereit, um die Beschreibung der WebServices zu beherbergen... © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg

UDDI Gliederung Geschichte Techniken Beispiel
UDDI Gliederung Geschichte Techniken Beispiel Zusammenfassung und Ausblick © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Was ist UDDI Selbst Web Service Gruppe von Registraturen im Web
HTTP, FTP, SOAP WSDL UDDI Service Description Service Discovery and Publikation WSFL Service Flow Network XML-Based Messaging Was ist UDDI Selbst Web Service Gruppe von Registraturen im Web © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Wofür steht UDDI Universal Description , Discovery and Integration
Wofür steht UDDI Universal Description , Discovery and Integration Unternehmen soll Möglichkeit gegeben werden: Sich selbst und Produkte und Dienstleistungen zu beschreiben Andere Unternehmen zu finden Sich mit anderen Unternehmen zu vernetzen © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Geschichte Namhafte Gründungsväter Ziel – eine gemeinsame Lösung, d.h
Geschichte Namhafte Gründungsväter Ziel – eine gemeinsame Lösung, d.h Einheitliches Angebot Jeder kann handeln Nach 6 Monaten und 50 Meetings kam am erste Spezifikation von UDDI © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Publizieren Wer gefunden werden will, muss sich zu erkennen geben
Publizieren Wer gefunden werden will, muss sich zu erkennen geben White Pages Yellow Pages Green Pages © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Publizieren Wer gefunden werden will, muss sich zu erkennen geben White Pages - Unternehmensname - textuelle Beschreibung (verschiedene Sprachen) - Kontaktinformationen (Adresse, Telefonnummer) Yellow Pages Green Pages © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Publizieren Wer gefunden werden will, muss sich zu erkennen geben White Pages Kategorie des Unternehmens Industriezweig (nach NAICS) Produkt/ Service (nach UN/SPSC) Geografische Einordnung Yellow Pages Green Pages © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Publizieren Wer gefunden werden will, muss sich zu erkennen geben White Pages Technische Informationen Servicebeschreibung Verwendete Plattform Verwendete Anwendungen Yellow Pages Green Pages © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Publizieren Wer gefunden werden will, muss sich zu erkennen geben White Pages Eingabe erfolgt über Internet oder geeignete Werkzeuge, die die UDDI API unter-stützen Yellow Pages Green Pages © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Techniken Service Type Registration
Techniken Green Pages White Pages Yellow Pages Softwarefirmen, Programmierer, Standardisierungs- gremien Service Type Registration © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Ort Viele Server Prinzip des „registered once, published everywhere“ durch täglichen Abgleich der Server untereinander Einsatz an folgenden privaten Orten möglich Internal Enterprise Application UDDI node Portal UDDI node Partner Catalog UDDI node E-Marketplace UDDI node © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Datentypen Repräsentation durch 4 Datentypen 12.11.2018
© 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

BusinessEntity 12.11.2018 <type content = "elementOnly">
<element name = "businessEntity"> <type content = "elementOnly"> <annotation> <appInfo> Primary Data type: Describes an instance of a business or business unit. </appInfo> </annotation> <group order = "seq"> <element ref = "discoveryURLs" minOccurs = "0" maxOccurs = "1"/> <element ref = "name"/> <element ref = "description" minOccurs = "0" maxOccurs = "*"/> <element ref = "contacts" minOccurs = "0" maxOccurs = "1"/> <element ref = "businessServices" minOccurs = "0" maxOccurs = "1"/> <element ref = "identifierBag" minOccurs = "0" maxOccurs = "1"/> <element ref = "categoryBag" minOccurs = "0" maxOccurs = "1"/> </group> <attribute name = "businessKey" minOccurs = "1" type = "string"/> <attribute name = "operator" type = "string"/> <attribute name = "authorizedName" type = "string"/> </type> </element> © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

BusinessService 12.11.2018 <element name = "businessService">
<type content = "elementOnly"> <annotation> <appInfo> Primary Data type: Describes a logical service type in business terms. </appInfo> </annotation> <group order = "seq"> <element ref = "name"/> <element ref = "description" minOccurs = "0" maxOccurs = "*"/> <element ref = "bindingTemplates"/> <element ref = "categoryBag" minOccurs = "0" maxOccurs = "1"/> </group> <attribute name = "serviceKey" minOccurs = "1" type = "string"/> <attribute name = "businessKey" type = "string"/> </type> </element> © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

BindingTemplate 12.11.2018 <element name = "bindingTemplate">
<type content = "elementOnly"> <annotation> <appInfo> Primary Data type: Describes an instance of a web service in technical terms. </appInfo> </annotation> <group order = "seq"> <element ref = "description" minOccurs = "0" maxOccurs = "*"/> <group order = "choice"> <element ref = "accessPoint" minOccurs = "0" maxOccurs = "1"/> <element ref = "hostingRedirector" minOccurs = "0" maxOccurs = "1"/> </group> <element ref = "tModelInstanceDetails"/> <attribute name = "bindingKey" minOccurs = "1" type = "string"/> <attribute name = "serviceKey" type = "string"/> </type> </element> © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

tModel 12.11.2018 <element name = "tModel">
<type content = "elementOnly"> <annotation> <appInfo> This structure defines a metadata about a technology, specification or namespace qualified list (e.g. taxonomy, organizaton, etc.) </appInfo> </annotation> <group order = "seq"> <element ref = "name"/> <element ref = "description" minOccurs = "0" maxOccurs = "*"/> <element ref = "overviewDoc" minOccurs = "0" maxOccurs = "1"/> <element ref = "identifierBag" minOccurs = "0" maxOccurs = "1"/> <element ref = "categoryBag" minOccurs = "0" maxOccurs = "1"/> </group> <attribute name = "tModelKey" minOccurs = "1" type = "string"/> <attribute name = "operator" type = "string"/> <attribute name = "authorizedName" type = "string"/> </type> </element> © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Warum soll man sich registrieren?
Warum soll man sich registrieren? Kostenlos Billig Vereinigung von Marktgrössen gibt Sicherheit Neue Kunden Kosten senken Weiterentwicklungen von UDDI – Roadmap © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Zusammenfassung Web Services XML Soap, WSDL UDDI
Zusammenfassung Web Services XML Soap, WSDL UDDI Ausblick der Gartner Analysten „2002 – Web Services will capture substantial attention“ „By 2003, approximately 80 percent of all platform vendors will sopport Web services architectures, which will represent the next generation of platform middleware.“ „2004 – Web Services will dominate deployment of new application“ © 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg © 2001 Monika Mustermann, MLU Halle-Wittenberg

Thomas Faust, Andreas Linke, Steffen Schäfer

Ähnliche Präsentationen

Präsentation zum Thema: "Thomas Faust, Andreas Linke, Steffen Schäfer"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Thomas Faust, Andreas Linke, Steffen Schäfer

Ähnliche Präsentationen

Präsentation zum Thema: "Thomas Faust, Andreas Linke, Steffen Schäfer"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback