Inhalt • Veränderung im World Wide Web SOAP, die Sprache der Web Services • Was sind Web Services? • WSDL (web service description language) für die Beschreibung von Web Services UDDI als ein universelles Verzeichnis von Web Services Szenarien für den Einsatz von Web Services Entwickeln von Web Services mit Microsoft .NET Framework und VS.NET

Einseitige Nutzung des WWW Keine Trennung von Inhalt und Layout Statische und nicht standardisierte Darstellung (statisches HTML) Hauptsächlich grafische Orientierung B2B-Datenaustausch scheitert oft an unterschiedlichen Formaten und Prozessen

Nachteile bisheriger Lösungsansätze: komplexe Kommunikation (Objekte) verbindungsorientiert (viele Pakete werden ausgetauscht, um die Sitzung zu starten/aufrechtzuerhalten) plattformabhängig proprietäre Sicherheitseinstellungen Methoden untereinander inkompatibel (CORBA, RMI etc.) Arbeitet nicht über Domänen- oder Firewallgrenzen hinweg

Software-Wiederverwendung Ursprünglich lokal in Bibliotheken (.dll) Später Komponentenarchitektur z.B. Java-Beans) COM(+)-Komponenten CCM bei CORBA Heute vorwiegend Frameworks Wunschdenken: Dynamische Einbindung von entfernten Komponenten, Zugriff über URL

Warum ein neues Protokoll? Einheitliches Protokoll auf Client und Server-Seite Kein Ballast oder überflüssige Spezialisierung Nur dieselbe Plattform kann miteinander „sprechen“ (COM mit COM, EJB mit EJB, ORB mit ORB) Unterschiedliche Syntax für Methodenaufrufe

SOAP - Idee HTTP-POST/GET als Transportprotokoll, weil transparent und standardisiert Umgehung von Firewalls HTTP-Content: XML Arbeitet zusammen mit: Jedem Betriebssystem Jeder Programmiersprache Jeder Plattform (…für die eine SOAP-Implementierung existiert) Apache Axis SOAP Server Apache SOAP 2.2 Server WhiteMesa 2.7 SOAP Server IONA XMLBus SOAP::Lite EasySOAP++ 4S4C Microsoft ASP.NET Web Services

Kommunikation mit SOAP SOAP-Nachrichten sind entweder Anfragen oder Antworten Nachricht (SOAP Envelope) ist unterteilt in SOAP Header und SOAP Body Anfragen enthalten das angesprochene Ziel sowie die in- in/out-Parameter. Antworten umfassen entweder das Resultat einer Anfrage oder einen Fehlercode (bzw. Exception Stack) Prinzipiell jedes standardisierte Kommunikationsprotokoll verwendbar

SOAP - technisch

SOAP - technisch

SOAP request POST /soap HTTP/1.0 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: 516 SOAPAction: "" <?xml version=’1.0’ encoding=’UTF-8’?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:getRate xmlns:ns1="urn:xmethods-CurrencyExchange" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <country1 xsi:type="xsd:string">USA</country1> <country2 xsi:type="xsd:string">germany</country2> </ns1:getRate> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

SOAP response HTTP/1.1 200 OK Date: Sun, 11 Nov 2001 16:40:48 GMT Content-Type: text/xml Server: Electric/1.0 Connection: Keep-Alive Content-Length: 492 <?xml version=’1.0’ encoding=’UTF-8’?> <soap:Envelope xmlns:soap=’http://schemas.xmlsoap.org/soap/envelope/’ xmlns:xsi=’http://www.w3.org/1999/XMLSchema-instance’ xmlns:xsd=’http://www.w3.org/1999/XMLSchema’ xmlns:soapenc=’http://schemas.xmlsoap.org/soap/encoding/’ soap:encodingStyle=’http://schemas.xmlsoap.org/soap/encoding/’> <soap:Body> <n:getRateResponse xmlns:n=’urn:xmethods-CurrencyExchange’> <Result xsi:type=’xsd:float’>2.1858</Result> </n:getRateResponse> </soap:Body> </soap:Envelope>

SOAP fault message HTTP/1.1 500 Internal Server Error Date: Sun, 11 Nov 2001 16:49:19 GMT Content-Type: text/xml Server: Electric/1.0 Connection: Keep-Alive Content-Length: 515 <?xml version=’1.0’ encoding=’UTF-8’?> <soap:Envelope xmlns:soap=’http://schemas.xmlsoap.org/soap/envelope/’ xmlns:xsi=’http://www.w3.org/1999/XMLSchema-instance’ xmlns:xsd=’http://www.w3.org/1999/XMLSchema’ xmlns:soapenc=’http://schemas.xmlsoap.org/soap/encoding/’ soap:encodingStyle=’http://schemas.xmlsoap.org/soap/encoding/’> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>no service found with address urn:xmethods-CurrencyExchange2</faultstring> </soap:Fault> </soap:Body> </soap:Envelope>

Benutzung von SOAP Serialisierung/Deserialisierung der Objekte wird durch SOAP-Implementierung übernommen Spezielle Serialisierer/ Deserialisierer für komplexere, selbstdefinierte Objekttypen Für Web Service und Client nötige Beschreibung der SOAP-Nachrichten durch WSDL

Was ist ein Web Service? Ein Web Service ist eine Anwendung, die ihre Methoden über eine Schnittstelle nach außen zur Verfügung stellt Server-Logik wird gekapselt Die öffentlichen Methoden eines Web Service werden vom Client aufgerufen, als wären sie Teil des Programms

Web Services für Entwickler Web Service als dynamisch angesprochener Baustein (Infrastruktur oder Business-Logik-Komponente) einer Anwendung Komponenten müssen nicht mehr lokal erreichbar sein Keine Installation Web Services können in unterschiedlichen Programmiersprachen implementiert sein , wenn es SOAP-Implementierungen für diese Sprache gibt

Web Services für Entwickler Interoperabilität zwischen Programmiersprachen und Plattformen Basis einer Vielzahl von B2x-Applikationen Herausforderungen für den Entwickler: Programmiermodell Verständnis für Protokolle und Serialisierung Auffinden von Services

Web Services und Objektorientierung Kein zugrunde liegendes Objektmodell auf Implementierungsebene (wie bei CORBA oder COM) SOAP ist verbindungslos Client hat keinerlei Anhaltspunkt, ob er bei zwei Aufrufen dasselbe Objekt erreicht WebService kann verschiedene Clients ohne Zusatzaufwand nicht auseinanderhalten Web Service eher wie ein Modul

Beschreibung eines Web Service Der Benutzer eines Web Service muss wissen • Welche Methoden werden angeboten? • Welche Parameter erwarten die Methoden (einschl. der Datentypen)? • Welche Werte liefern sie zurück? > WSDL: Web Service Description Language WSDL wird von IBM und Microsoft forciert und vielen anderen unterstützt Interoperables XML-Format

WSDL: Web Service Description Language WSDL enthält den Syntax des Service die Bindung an ein bestimmtes Netzprotokoll die Festlegung des Übertragungsformats die Zuordnung zu bestimmten Internetadressen (URIs) WSDL-Datei Auf Web Server: nötig zum „Anmelden“ des Web Service, damit Anfragen korrekt weitergeleitet werden Auf Client: nötig, um zu wissen wie der Web Service angesprochen/benutzt wird dynamische Einbindung neuer Services möglich

UDDI - Universal Description, Discovery, and Integration Verzeichnis in der Form eines Internet-Branchenbuches Listet Firmen-Informationen und öffentliche Web Services inkl. WSDL-Datei

Geschäfte mit Web Services Infrastrukturdienste (Benutzerauthentifizierung, Backup usw.) nahtlos aus externen Quellen Konzentration auf Business-Komponenten statt Infrastruktur Remote-Administration und Überwachung Verbindung interner und externer Dienste Interoperabilität deutlich verbessert durch allgemein akzeptierte Standards wie SOAP, WSDL, UDDI Entsprechende Entwicklungsumgebungen erhöhen die Produktivität, vermindern die Time-to-Market

Risiken und Probleme Standards noch in der Diskussion Herstellerunabhängigkeit derzeit nicht gewährleistet Sicherheit und Authentifizierung ungeklärt Höhere Dienste wie Multimedia nicht gesichert Lizenzierung und Abrechnung bei ASP-Ansatz unklar Technologie sehr neu und unreif, aber große Akzeptanz bei allen „Global Players“ der IT-Branche (IBM, Microsoft, Sun, HP, etc.) Abhängigkeit von der Verfügbarkeit der Services in den Architekturen

Anwendungsmöglichkeiten Software als Service: Application Service Providing (ASP) wird durch Web Services deutlich vereinfacht (Billing etc. noch unklar) Integration in Unternehmensanwendungen Geschäftsprozesse webtauglich machen, im Hause und beim Kunden Konsistente Datenverarbeitung mit XML Integration/Zusammenführung von „Informationsinseln“ mit Web Services Kunden Online-Shop Zulieferer Kundendienst Verkauf

Web Services in C# Überblick Webdienst-Namespaces Namespace Bedeutung System.WebServices alle erforderlichen Typen zur Erstellung eines WebServices System.WebServices.Description Kommunikation mit WSDL System.WebServices.Discovery Programmgesteuerte Festellung eines WebServices über DISCO-Dateien System.WebServices.Protocols Typen, die die Leistungsprotokolle HTTP GET, http POST und SOAP darstellen

Web Services in C# Praxis-Teil Präsentation „Erstellung eines einfachen WebServices in Visual Studio.Net“

Web Services in C# benutzerdefinierte Typen werden in eine XML-Darstellung überführt -> Serialisierung Kennzeichnung mit XmlIncludeAttribute Bsp. using System.Xml.Serialization; [XMLInclude(typeof(Kunde))] public class Kunde { … }

Web Services in C# Praxis-Teil Präsentation „Remote-Client mit Proxy in Visual Studio.Net“

Remote Client - Wetterabfrage Beschreibungsseite des GET_Weather Webservices Auflistung aller Web-Methoden

Remote Client - Wetterabfrage Der Remote-Client stellt eine Verbindung zum GET_Weather-WebService her. Aufruf: List_Countries() Es wird eine Länderliste zurückgeliefert.

Remote Client - Wetterabfrage Aufruf: Search_StationByCountry(..)

Remote Client - Wetterabfrage Eine Liste der passenden Meßstationen wird zurückgegeben. Nun wird durch den Aufruf: Get_WeatherReport(…) eine detailierter Wetterreport an den Client zurückgegeben.

Remote Client - Wetterabfrage Ein kompletter Programmdurchlauf

Aufgabe Die 7. Übungsaufgabe enthält bereits einen WebService-Teil. Sonst: Realisieren Sie unter Zuhilfenahme des ausgehändigten Tutorials eine Client-Anwendung, welche auf einen eigenen WebService zugreift und Grundrechenoperationen (+,-,*,/) ausführt.

Quellen / Literatur Literatur: - „C# und die .NET-Plattform“ von Andrew Troelsen - Webservice- Programmierung mit SOAP. von James Snell, u. a. Interessante Seiten: - http://www.codeproject.com - http://www.xmethods.net GET_Weather-Webservice: - http://www11.brinkster.com/bgx/webservices/GET_Weather.asmx