Vorlesung - IVS Arbeitsgruppe Softwaretechnik Abschnitt 3.1.3 Grundlegende Web Service Technologien Seite 1
- Übersicht UDDI WSDL Requester SOAP over HTTP Provider Seite 2
- Übersicht A web service is a piece of business logic, located somewhere on the Internet, that is accessible through standard-based Internet protocols such as HTTP or SMTP. Using a web service could be as simple as logging into a site or as complex as facilitating a multi-organization business negotiation. Quelle: Chappell, A.; Jewell, T.: Java, O Reilly- Verlag Seite 3
- Übersicht Seite 4
- Übersicht Seite 5
- Übersicht SOAP: Das Simple Object Access Protocol dient dem Verpacken von Informationen bezüglich der Kommunikation verschiedenen Dienstanbieter im Web. Es stellt gewissermaßen eine objektbasierte Verbindungsform her, ist allerdings sehr einfach aufgebaut und frei verfügbar. (vgl. CORBA IIOP) WSDL: Die Web Service Definition Language dient der unmittelbaren Beschreibung/Spezifikation des eigentlichen Web-Services. Sie nutzt die durch SOAP gekapselten Dienstkomponenten und stellt ebenso die Verbindung zur darüber liegenden Schicht her. (vgl. CORBA IDL) UDDI: Die Universal Description, Discovery and Intergation Komponente nimmt die Registrierung eines Webservices vor und beinhaltet die einzelnen Dienstbeschreibungen für den Kunden. Diese sind in drei Bereiche unterteilt: den White-, Yellow- and Green-Pages. Seite 6
extensible Markup Language extensible Markup Language (XML) Esperanto der IT Welt Auszeichnung und Strukturierung von Daten mittels so genannter Tags XML stellt unter anderem die Basis für SOAP und WSDL dar <?xml version="1.0"?> <brief> <adresse typ = an > <name>harry Mustermann</name> <strasse>musterstrasse</strasse> <nummer>1b</nummer> <postleitzahl>12345</postleitzahl> <ort>musterhausen</ort> </adresse> <adresse typ = von > <name>klaus Gustav</name> <strasse>dorfstrasse</strasse> <nummer>33</nummer> <postleitzahl>54321</postleitzahl> <ort>michelbinge</ort> </adresse> <brieftext> Lieber Harry, wie geht es dir... etc. </brieftext> </brief> Seite 7
extensible Markup Language XML ist Teilmenge von SGML (Standard Generalized Markup Language) HTML kann mittels XML definiert werden DTD für HTML www.w3c.org/tr/rec-html40/strict.dtd Trennung von Struktur und Inhalt Möglichkeit Selbstbeschreibender Dokumentenstrukturen Möglichkeit einer Validierung von XML-Dokumenten Leichte Erweiterbarkeit durch die Definition neuer Tags Geschachtelte Tags zur Beschreibung strukturierter Daten Seite 8
Wohlgeformtes XML: extensible Markup Language XML Dokumente bestehen aus Prolog und Elementen Im Prolog steht die XML-Declaration (XML-Version) Jedes öffnende Tag muss explizit geschlossen werden z.b. Zeilenvorschub: <BR></BR> oder <BR/> Attribute müssen in Anführungszeichen gesetzt werden < (<) und & (&) dürfen im Text nicht vorkommen Standardattribute müssen vom Typ CDATA (Characater Data) sein Seite 9
DTD Document Type Definition - definiert die Grammatik der Dokumente Element Declaration <!ELEMENT Elementname (Inhaltsbeschreibung)> Case sensitiv? (optionales Element), + (mind. einmal), * (beliebig häufig) Elemente müssen immer mit Buchstaben oder Unterstrich beginnen Attribute Declaration extensible Markup Language <!ATTLIST Elementname Attributdefinition> Attributdefinition bestehen aus: Attributname Attributtyp (implizit als CDATA, ID oder explizit als (Wert1 Wert2 ) Defaulttyp weitere Bestandteile: Kommentare, Processing Instructions, Seite 10
<? xml version= 1.0?> <!DOCTYPE email SYSTEM mail.dtd > <mail> <empfaenger>schmiete@ivs.cs.uni-magdeburg.de</empfaenger> <absender>dumke@ivs.cs.uni-magdeburg.de</absender> <betreff>vorlesung </betreff> <nachricht>prüfungstermin im Februar</nachricht> </mail> extensible Markup Language Seite 11
<!--mail DTD V.2--> <!ELEMENT mail extensible Markup Language (empfaenger, absender, betreff, nachricht, termin*)> <!ELEMENT empfaenger (#PCDATA)> <!ELEMENT absender (#PCDATA)> <!ELEMENT betreff (#PCDATA)> <!ELEMENT nachricht (#PCDATA)> <!ELEMENT termin (#PCDATA)> Seite 12
XML Schema Language XS Definition einfacher und komplexer Datentypen Schema ist selbst XML-Dokument d.h. validierbar Einfache Datentypen: extensible Markup Language xs:integer, xs:decimal, xs:boolean, xs:string Komplexe Datentypen: xs:complextype, xs:sequence, xs:group, Verwendung von Facets Einschränken von Wertebereichen Seite 13
extensible Markup Language <? xml version= 1.0?> <xs:schema xmlns:xs= http//www.w3.org/2001/xmlschema > <xs:element name= mail > <xs:complextype> <xs:sequence> <xs:element name= empfaenger type= xs:string > <xs:element name= absender type= xs:string > <xs:element name= betreff type= xs:string > <xs:element name= nachricht type= xs:string > <xs:element name= termin type= xs:integer > </xs:sequence> </xs:complextype> </xs:element></xs:schema> Seite 14
extensible Markup Language DOM Document Object Model Plattform- und sprachunabhängiges API Erlaubt externen Programmen dynam. Zugriff auf XML-Dokumente Zugriff/Änderung auf Inhalte, Struktur und Layout SAX Single API for XML Plattform- und sprachunabhängiges API Erzeugt beim Parsen Events zur Steuerung externer Programme Seite 15
extensible Markup Language Seite 16
extensible Markup Language Seite 17
extensible Markup Language Electronic Data Interchange EDI Datenaustausch zwischen IT-Systemen zunehmend XML-basiert Primäre Verwaltung und Standardisierung durch die OASIS (600 Mitglieder) xcbl XML Common Business Library CommerceOne Spezifikation für das Order Management Beschreibt nicht nur die benötigten Dokumente, es werden ebenfalls Inhalte und deren Semantik festgelegt ebxml electronic Business (ergänzt WS-Protokolle) - Framework Komplette Spezifikation, Dokumentation und Ausführung elektronischen Handels Seite 18
Simple Object Access Protocol Initiative von Canon, Microsoft, IBM und SUN Datentransport mittels XML im Internet Verwendung von HTTP, SMTP oder auch FTP RPC-orientierte Arbeitsweise (via HTTP) Remote Procedure Call Zwei-Wege Kommunikation DOC-orientierte Arbeitsweise (via SMTP oder FTP) Versendung von Dokumenten Ein-Weg Kommunikation Seite 19
Simple Object Access Protocol Dokumentenorientierte Interaktion: clientseitig: SAOP envelope (SOAP body (Bestelldokument (Produktangaben))) serverseitig: SAOP envelope (SOAP body (Bestätigungsdokument (Orderinformationen))) RPC-orientierte Interaktion: clientseitig: SAOP envelope (SOAP body (bestellmethode (Produktparameter))) serverseitig: SAOP envelope (SOAP body (bestellantwort (Rückgabewerte))) Seite 20
Simple Object Access Protocol Verwendung von einfachen Datentypen: Zahlen, Strings, Zeittypen, Arrays Ziel Kompatibilität mit möglichst vielen Systemen Bilden komplexerer Datentypen in darüber liegenden Schichten Seite 21
Simple Object Access Protocol <?xml version = 1.0?> <soap:envelope xmlns:soap= http://schemas.xmlsoap.org/soap/envelope/ > <soap:header> <!-- Optionale Headerinformationen kommen hier hin --> <To>Mike</To> <From>Andreas Schmietendorf</From> </soap:header> <soap:body> <!-- Die eigentliche Nachricht kommen hier hin --> Bitte schicke mir die noetigen Geschaeftsunterlagen </soap:body> </soap:envelope> Seite 22
Simple Object Access Protocol Header einer SOAP-Nachricht Header in SOAP nicht formalisiert Potentielle Aufgaben z.b.: Authentifizierung Sicherheitsinformationen Routing - Weiterleiten von Informationen Transaktionssteuerung Zahlungsmodalitäten Formalisierung durch aufsetzende Protokolle wie z.b. ebxml Seite 23
Simple Object Access Protocol <?xml version="1.0" encoding= utf-8?> <soap:envelope xmlns:soap= http://schemas.xmlsoap.org/soap/envelope > <soap:header> <Digest>B839D234A3F87</Digest> </soap:header> <soap:body> <StockReport> <Symbol>IBM</Symbol> <Prise>65.42</Prise> </StockReport> </soap:body> </soap:envelope> Seite 24
Simple Object Access Protocol <?xml version="1.0" encoding= utf-8?> <soap:envelope xmlns:soap= http://schemas.xmlsoap.org/soap/envelope > <soap:body> <Add> <x>1</x> <y>2</y> </Add> </soap:body> </soap:envelope> <?xml version="1.0" encoding= utf-8?> <soap:envelope xmlns:soap= http://schemas.xmlsoap.org/soap/envelope > <soap:body> <AddResult> <result>3</result> </AddResult> </soap:body> </soap:envelope> Seite 25
Implementation von SOAP-Verbindung clientseitig: Client-Implementation, Client-Stub (Service als lokaler Aufruf), SOAP-Engine (SOAP-Bereitstellung und Nachrichtenerstellung), HTTP-Engine (HTTP-Integration und Aufruf zum Server) serverseitig: Simple Object Access Protocol HTTP-Engine (Nachrichtenübernahme), SOAP-Router (Interpretation), Server-Stub (Service als lokale Prozedur), Service-Implementation. Seite 26
Vorteile SOAP Simple Object Access Protocol Programmiersprachenunabhängigkeit Transportprotokollunabhängigkeit Hoher Grad an Standardisierung Verwendung von bestehenden Industriestandards Technologieunabhängig Seite 27