Aufbau Integrierter Gliederung Informationssysteme · Aufbau Integrierter Informationssysteme...

Aufbau IntegrierterInformationssysteme

Integration durch Einsatz von XML und WebServices

Thomas Faust, Andreas Linke, Steffen Schäfer

Martin-Luther-Universität Halle-Wittenberg

Hauptseminar - Halle - 05.02.2002

© 2002 Thomas Faust, Andreas Linke, Steffen Schäfer; MLU Halle-Wittenberg 2

Gliederung

• Grundlagen Web Services

• XML

• SOAP & WSDL

• UDDI

• Ausblick & Zusammenfassung


Web Services (1)

• Programm-zu-Programm Kommunikationsmodell

• Selbstbeschreibende, in sich geschlossene und modulareAnwendungen

• Integration von Anwendungen

• Kombinierbar mit anderen Web Services zu Produkten oderProzessen


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


Web Services Modell

ServiceRequestor

ServiceRegistry

ServiceProvider

WSDL, UDDIWSDL, UDDI

Rollen• Service Registry• Service Requestor• Service Provider

Service

ServiceDescription

ServiceDescription

Werkzeuge• Service Description• Service

Find Publish

Bind

Tätigkeiten• Publish• Find• Bind


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> )


<?xml version="1.0" encoding="ISO-8859-1„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 denUSA gedruckt werden darf...</text><gruss>J.J.</gruss></brief>

<!–- the end -->

XML - Komponenten

XML - Dokument

Namespace

XSLXSLT

DTDXML - Schema

XLink XPointerXPath


XML – Aufbau eines Dokuments

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><!DOCTYPE brief SYSTEM "brief.dtd">

<brief><anrede geschlecht="f" sozial="du">Nora</anrede><text>habe gerade den Ulysses beendet. Mal sehen, wannder in den USA gedruckt werden darf...</text><gruss>J.J.</gruss></brief>

<!–- the end -->

Prolog

Elemente

Epilog

brief.xml


brief.xml (1)

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><!DOCTYPE brief SYSTEM "brief.dtd">

Prolog

DTD‘s - Document Type DefinitionVerarbeitungsanweisungen

<!–- the end -->Epilog

weitere Verarbeitungsanweisungen und Kommentare


brief.xml (2)

<brief><anrede geschlecht="f" sozial="du">Nora</anrede><text>habe gerade den Ulysses beendet. Mal sehen, wannder in den USA gedruckt werden darf...</text><gruss>J.J.</gruss></brief>

Elemente

Markierungen

Element bezeichnet den eingeschlossenen Inhalt der Markierungen

Jedes Element kann Attribute enthalten, hinter dem Element-Namenwerden dazu Name-Wert-Paare geschrieben

Wurzel-Element


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 automatischsicherzustellen


DTD -Document Type Definition (2)

<!ELEMENT brief ( anrede, text, gruss ) >

<!ELEMENT anrede ( #PCDATA ) ><!ELEMENT text ( #PCDATA ) ><!ELEMENT gruss ( #PCDATA ) >

<!ATTLIST anredegeschlecht ( f | m ) #REQUIREDsozial (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


XML Schema

• XML-basierte Sprache (XML-Schemata sind XML-Dokumente)

• Konstrukte zur Spezifikation von Struktur, Inhalt und Semantikvon XML-Dokumenten, insbesondere Datentypen

• Definition eigener Datentypen möglich

• Einige Datentypen sind fest vorgegeben, z.B. date fürDatumsangaben


Konformität

• Beim Überprüfen auf Korrektheit eines Dokumentes sieht dieXML-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 odereinem XML-Schema entspricht:– Dokument ist wohlgeformt– Es ist eine existierende DTD definiert, die verfügbar ist– Das Dokument entspricht den aufgestellten Regeln


Ausgabe vonXML – Dokumenten (1)

• Die Darstellung von XML-Dokumenten wird mit sog. Stylesheetsdefiniert:– 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


Ausgabe vonXML – Dokumenten (2)

<?xml version="1.0" encoding="ISO-8859-1„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 denUSA gedruckt werden darf...</text><gruss>J.J.</gruss></brief>

<!–- the end -->

XML - Dokument

DTDXML - Schema

XSLXSLT


brief.xsl<?xml version="1.0" encoding="ISO-8859-1"?><xsl:stylesheet version="1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"xmlns="http://www.w3.org/TR/REC-html40">

<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 test="@sozial='du'">

<xsl:text>Liebe</xsl:text><xsl:if test="@geschlecht='m'"><xsl:text>r</xsl:text>

</xsl:if><xsl:text> </xsl:text>

</xsl:when><xsl:when test="@sozial='sie'">

...<xsl:apply-templates/><xsl:text>,</xsl:text></p>

</xsl:template>

</xsl:stylesheet>brief.xsl

bri

ef.x

ml

bri

ef.h

tml


Namespaces

• Durch die freie Wahl der Markierungen kann es passieren, dassin einem Dokument Elemente aus verschiedenen DTD’sverwendet werden, bei dem die Verwendung gleicher

Markierungen mit unterschiedlicher semantischer Bedeutung zuKonflikten 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 Dokumentvorangestellt wird:xmlns="http://www.w3.org/TR/REC-html40"


XLink

• Ermöglicht das Beschreiben von Links in Form herkömmlicherLinks in eine Richtung aber auch komplexere Link-Strukturen.

• Jedes Element kann mit einer Link-Funktionalität versehenwerden, dies geschieht durch das Einfügen des Attributsxlink:type (simple oder extended).

• Arten:– Simple Links– Extended Links

• Danach können weitere Attribute folgen, die weitereInformationen zum Link bereithalten (xlink:href | show | actuate| role).


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 markiertwird (< > HTML)


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


XML - Anwendung

• Überall wo neben korrekter Syntax auch eine semantischeBeschreibung 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 […]


&


SOAP und WSDL

Zur Einordnung:

à exemplarisch der - Conceptual Web Services Stack [Ausschnitt]

© 2001 Monika Mustermann, MLU Halle-Wittenberg 25

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] zunutzen


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: http://schemas.xmlsoap.com/soap/envelope

serialization namespace-identifier: http://schemas.xmlsoap.com/soap/encoding


SOAP und WSDL

Das Nachrichtenmodell:

SOAP-Nachrichten sind kombinierte Übertragungen vom Sender zumEmpfänger.

Die Nachrichten verfolgen den sog. Message Path, d.h. sie können anjedem auf dem Weg liegenden Knotenpunkt verarbeitet werden.

Empfang

1. Identifizieren aller Teile

2. Sicherstellen der Bestimmungund Unterstützung

3. Falls nicht endgültiger Empfänger„alte“ Teile entfernen und weiterleiten

Verarbeitung


SOAP und WSDL

Der Aufbau von SOAP:

Ist optional und kanndie Nachricht umFunktionalitäterweitern, die vorhervon denkommunizierendenAnwendungen nichtabgestimmt wurde.


<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/“SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header>[...]

</SOAP-ENV:Header>

<SOAP-ENV:Body>[...]

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

SOAP und WSDL

Ein Beispiel:


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 derNachricht verarbeitet

Das mustUnderstand-Attribut: gibt an ob die Verarbeitung optional ist,damit ist ein vorhersagbares Verhaltenerzwingbar

SOAP und WSDL


SOAP und WSDL

Der Body

entspricht im Grunde einem Headerelement mit einem mustUnderstand-Wertvon 1 und dem engültigen Empfänger der Nachricht als actor.

Stellt einen einfachen Mechanismus zum Austausch der eigentlich derNachricht zugrundeliegenden Information zur Verfügung.

Enthält u.a. ein Fault-Element, um Informationen über eventuell aufgetreteneFehler in einer SOAP-Nachricht zu übermitteln.


SOAP und WSDL

Die Serialisierung von Daten (Encoding)

basiert auf einem einfachen Typensystem.

Jeder Datentyp gehört entweder den einfachen Datentypen an, oder ist ausmehreren 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.


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"/>


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>


SOAP und WSDL

SOAP auf HTTP

Warum? Kopplung von SOAP mit der Stabilität und reichhaltigen Funktionalitätvon 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 ausSicherheitsgründen nur HTTP-Pakete durchlassen.


SOAP und WSDL

RPC‘s mit SOAP

Das Kapseln und Austauschen von RPCs in dem XML-Datenstrom wareines der Design-Ziele der Autoren der SOAP-Spezifikation.

Der RPC wird als HTTP-Request übermittelt und das Ergebnis wird alsResponse geliefert.

Benötigt werden- die URI des Zielobjektes- der Methodenname- evtl. vorhandene Parameter der Methode


SOAP und WSDL

RPC‘s mit SOAP: Ein Beispiel

Anfrage:

<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></SOAP-ENV:Body>


SOAP und WSDL

SOAP und Sicherheit:

SOAP ist von sich aus kein sicheres Protokoll, im Grunde genommensämtliche Daten im Klartext übermittelt werden.

Um die Sicherheit müssen sich daher die zugrundeliegendenÜbertragungsprotokolle oder die kommunizierenden Anwendungenkümmern.

Wie wird es also nun sicher?

Zum Beispiel durch Einsatz von sicheren Verbindungen: HTTPSoder durch Zwischenschalten von Verschlüsselungsstationen.


SOAP und WSDL

Woher weiss der Service-Requestor nun welches Format die messageverwenden soll?

Diese Frage wird nun mit WSDL beantwortet.

Die Servicebeschreibung ist der Schlüsseldie WebService-Architektur loszulösen undgleichzeitig senkt es rapide die Quantitätdes gemeinsamen Verstehens beiderTeilnehmer.

Wie auch schon bei IDL erreicht man einevollständige Sprachen- undPlattformunabhängigkeit!

à geringere Fehleranfälligkeità Automatisierung möglich


SOAP und WSDL

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 konkretenNetzwerkaustattung und oder den verwendeten Protokollen.

Damit wird eine Wiederverwendung der akstrakten Definitionen erreicht!

Web Services Description Language


SOAP und WSDL

gibt eine Menge von abstraktenOperationen an die, die von diesemEndpunkt unterstützt werden

gibt Transportinformationen für einenPortType an

gibt Netzwerkadresse einesEndpunktes an

Ein Service ist die Mengezusammengehörender Ports.

I nterface Definition

Implementation Definition


SOAP und WSDLWie ist nun eine solche WSDL-Datei aufgebaut?

<definitions name=“Beispiel“targetNamespace="http://tempuri.org/wsdl/"...>

<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="http://carlos:8080/FooSample/FooSample.asp"/></port>

</service>

</definitions>


SOAP und WSDL

Die komplette WebServices – Beschreibung basiert alsoauf einer solchen WSDL Definition.

Das heißt der Anfragende weiss nun, wie man den Servicein Anspruch nimmt und mit ihm interagiert.Er kann nun weitere Informationen anfragen:

„Welches Geschäft bietet diesen Service an? Was ist dasgenau für ein Service und welche Produkte sind damit verbunden?

UDDI stellt nun einen Mechanismus bereit, um die Beschreibungder WebServices zu beherbergen...


UDDI

Gliederung

• Geschichte

• Techniken

• Beispiel

• Zusammenfassung und Ausblick


Was ist UDDI

• Selbst Web Service

• Gruppe von Registraturen imWeb


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


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 30.09.2000 erste

Spezifikation von UDDI


Publizieren

Wer gefunden werden will, muss sich zu erkennen geben

White Pages

Yellow Pages

Green Pages


Publizieren


White Pages

Yellow Pages

Green Pages

- Unternehmensname- textuelle Beschreibung(verschiedene Sprachen)- Kontaktinformationen(Adresse, Telefonnummer)


Publizieren


White Pages

Yellow Pages

Green Pages

• Kategorie des Unternehmens

• Industriezweig (nach NAICS)

• Produkt/ Service (nachUN/SPSC)

• Geografische Einordnung


Publizieren


White Pages

Yellow Pages

Green Pages

• Technische Informationen

• Servicebeschreibung

• Verwendete Plattform

• Verwendete Anwendungen


Publizieren


White Pages

Yellow Pages

Green Pages

Eingabe erfolgt über Internetoder geeignete Werkzeuge,die die UDDI API unter-stützen


Techniken

Service TypeRegistration

Green Pages

White Pages

Yellow Pages

Softwarefirmen,Programmierer,Standardisierungs-gremien


Ort

• Viele Server

• Prinzip des „registered once, published everywhere“ durchtä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


Datentypen

Repräsentation durch 4 Datentypen


BusinessEntity

<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>


BusinessService

<element name = "businessService"><type content = "elementOnly">

<annotation><appInfo>

Primary Data type: Describes a logical service type in business terms.< /appInfo>


<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>


BindingTemplate

<element name = "bindingTemplate"><type content = "elementOnly">


Primary Data type: Describes an instance of a web service in technical terms.< /appInfo>


<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"/>

</group><attribute name = "bindingKey" minOccurs = "1" type = "string"/><attribute name = "serviceKey" type = "string"/>

</type></element>


tModel

<element name = " tModel"><type content = "elementOnly">


This structure defines a metadata about a technology, specificationor 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>


Beispiel


Beispiel (2)


Beispiel (3)


Beispiel (4)


Beispiel (5)


Beispiel (5)


Warum soll man sich registrieren?

• Kostenlos• Billig• Vereinigung von Marktgrössen gibt Sicherheit• Neue Kunden• Kosten senken

• Weiterentwicklungen von UDDI – Roadmap


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 sopportWeb services architectures, which will represent the next generation ofplatform middleware.“

• „2004 – Web Services will dominate deployment of new application“

Aufbau Integrierter Gliederung Informationssysteme · Aufbau Integrierter Informationssysteme...

Documents

Transcript of Aufbau Integrierter Gliederung Informationssysteme · Aufbau Integrierter Informationssysteme...