1 / 48

Verlesung “Informationssysteme: Neuere Konzepte”

Verlesung “Informationssysteme: Neuere Konzepte”. Web Services. Michael Klein kleinm@ipd.uni-karlsruhe.de http://www.michaelklein.net/nki. Übungsblätter. Zunächst: Besprechung der 3 Übungsblätter. Verlesung “Informationssysteme: Neuere Konzepte”. Web Services. Michael Klein

arden-carney
Download Presentation

Verlesung “Informationssysteme: Neuere Konzepte”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Verlesung“Informationssysteme: Neuere Konzepte” Web Services Michael Klein kleinm@ipd.uni-karlsruhe.de http://www.michaelklein.net/nki

  2. Übungsblätter • Zunächst: • Besprechung der 3 Übungsblätter

  3. Verlesung“Informationssysteme: Neuere Konzepte” Web Services Michael Klein kleinm@ipd.uni-karlsruhe.de http://www.michaelklein.net/nki (Folien teilweise auf englisch)

  4. Szenario (1) Telefongesellschaft Telefon- anschluss? Auftrag

  5. Szenario (2) Anschluss verfügbar? nein ja Geschäftsprozess Reservierung der Nummer ja Auftrag Eintrag? Eintrag Telefonbuch Telefongesellschaft nein ok Einkauf Endgeräte Versand Endgeräte Prob Entschuldigungs-schreiben Einzug Anschlussgebühren

  6. Funktionalität A Dienstorientierte Architektur Geschäftsprozess • Nutzung von Funktionalitätexterner Entitäten über Dienste Funktionalität A‘ Funktionalität B‘ Dienst- geber 3 Dienst- geber 5 Funktionalität A Dienst- geber 1 Funktionalität A Dienst- geber 2  Funktionalität kann evtl. kostengünstig ausgelagert werden.

  7. Service Oriented Computing • Network not as collection of documents but as a collection of functionality • Applications and business processes use functionality of other entities • especially interesting: • in mobile networks with limited capabilities • in the internet: large companies, many services  outsourcing • Integration of distributed functionality across organizational and network boundaries

  8. Characteristics of SOC Characteristics • Functionality is hidden behind an interface • Offered functionality is publicly described • Service = public functionality that can be published, discovered, and executed across the network(client-server paradigm)

  9. 8. invoke 10. transfer results 6. select 7. configure 2. publish 4. search For General Process: the „Service Triangle“ 9. execute Requestor (Client) Provider (Server) 3. describe request 1. describe offer 5. match Repository

  10. ? Which provider is appropriate? (matching) How to invoke it? (binding, configuration) Service Desc Service Desc Service Desc Service Desc Service Desc Service Provider Service Provider Service Provider Service Provider Service Provider Service Description Language Service Requests Service Requests

  11. Web Services WSDL, SOAP, UDDI

  12. What is a Web Service? Web Service = • service that Accessible through the internet • consumes and produces xml documents • is uniquely identified by an uri • Based on three main technologies • WSDL: Web Service Description Language • SOAP: Simple Object Access Protocoll • UDDI: Universal Description, Discovery and Integration Web Service xml xml

  13. 8. invoke 10. transfer results 6. select 7. configure 2. publish 4. search For Task of the Technologies 9. execute Requestor (Client) Provider (Server) SOAP 3. describe request 1. describe offer WSDL WSDL 5. match Repository UDDI • automatic prematching based on categories • manual matching and selecting • static binding

  14. WSDL, SOAP, and UDDI • WSDL • to describe the functionality of a service • helps to find an appropriate service • helps to invoke a found service correctly • UDDI • directory service • is itself a service • helps to get an overview of the services in the repository • only helpful in case of very many services • SOAP • communication protocol between service requestor and provider • helps to transfer simple (atomic) and complex (composite) data  All based on XML

  15. Web Service Stack Communication Description Discovery SOAP Semantics XML WSDL Extensions UDDI HTTP WSDL XML TCP/IP XML • Task:provide a standard, flexible way to discover where a Web service is located . • Task: provide a standard, flexible way to describe what and how a Web service does what it does. • Task: provide a standard, flexible communications channel

  16. WSDL Building Blocks

  17. History of WSDL NASSL SDL/SCL … 2000: Microsoft, IBM and Ariba jointly issue WSDL 1.0 2001: A dozen companies submit WSDL 1.1 as W3C Note 2002: W3C publishes WSDL 1.2 as Working Draft 2003: WSDL is separated into three parts: core, messages, bindings 2004: WSDL 2.0 (mainly renamings)

  18. WSDL 1.2 Components as UML Diagram service = publicly callable functionality ABSTRACT message = collection of information that can be exchanged via network CONCRETE operation = function that processes an input message and returns an output message

  19. Types • defines important datatypes • primitive types from XML schema • complex types buildable via <complexType>-Tag <types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> <element name="TradePrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types>

  20. Messages • combines types to abstract messages • smallest interchangeable units • unidirectional • built up from parts <message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePriceRequest"/> </message> <message name="GetLastTradePriceOutput"> <part name="body" element="xsd1:TradePrice"/> </message>

  21. Operation and PortType • Operation is abstract functionality that • receives an input messages • processes it • send set an output and fault messages • PortType groups operations to interfaces <portType name= "StockQuotePortType"> <operation name = "GetLastTradePrice"> <input message = "tns:GetLastTradePriceInput"/> <output message = "tns:GetLastTradePriceOutput"/> </operation></portType>

  22. Operation Types • One-way operationsinput only • Request-Responseinput, then output(default) • Solicit-Responseoutput, then input • Notificationoutput only client server client server client server client server

  23. Binding • Connects abstract PortTypes with concrete Ports • Defines concrete message syntax • Defines concrete communication protocol details • Most important protocol: SOAP • Simpler protocols like HTTP GET/POST possible <binding name="StockQuoteBinding„ type="tns:StockQuotePortType"> <soap:binding style= "document" transport= "http://schemas.xmlsoap.org/soap/http"/> <operation name= "GetLastTradePrice"> <soap:operation soapAction=“http://example.com/GetLastTradePrice"/> <input> <soap:body use= "literal"/> </input> <output> <soap:body use= "literal"/> </output> </operation> </soap:binding></binding>

  24. Port and Service • Port specifies a concrete address of a binding • Service is a collection of such ports <service name="StockQuoteService"> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/> </port></service>

  25. Components of WSDL 1.2 – Summary ABSTRACT CONCRETE

  26. Renamings in WSDL 2.0 WSDL 2.0 WSDL 1.2 Port Endpoint PortType Interface Message no special tag. Directly defined by xs:element and xs:complexType Part no special tag. Directly defined by xs:sequence and xs:element

  27. Example for Changes in WSDL 2.0 <types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema“ targetNamespace="http://…/schemas/resSvc.xsd“> <xs:element name="checkAvailability“ type="tCheckAvailability"/> <xs:complexType name="tCheckAvailability"> <xs:sequence> <xs:element name="checkInDate" type="xs:date"/> <xs:element name="checkOutDate" type="xs:date"/> <xs:element name="roomType" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:element name="checkAvailabilityResponse" type="xs:double"/> <xs:element name="invalidDataError" type="xs:string"/> </xs:schema> </types> Message Part

  28. WSDL Discovery

  29. Matching • Task: • Given a service description for a requested service r and a service description of an offered service o. Question: Is o suitable to fulfill r’s needs? To what degree? • Idea: • Matcher compares o and r and calculates matching value in [0,1] • 0.0: o is not suitable at all • 1.0: o is perfectly suitable • intermediate values: o is suitable to the given degree

  30. Matching WSDL Descriptions – Approaches (1) Keyword based Search • Request r is set of keywords. •  Matching value is only a hint •  Manual postprocessing and selection necessary (2) Type based Matchers • Check whether input message of request „provides more“ information than input message of offer • Check whether output message of request „wants less“ information than output message of offer • „wants less“ • each type in the request has to appear in the offer • types of the offer have to be a subtype of the desired types in the request

  31. Type based Matcher • For each or_i in r: Is there a oo_j in o with oo_j subtypeof or_i • For each io_i in o: Is there a ir_j in r with ir_j subtypeof io_i Request r Offer o ir_1 io_1 or_1 oo_1 Service Service … … … … ir_n io_k or_m oo_l

  32. Problems with WSDL Matching • Problems • Not really new. Already in CORBA, DCOM, EJB, ebXML, …  No advantage to pure interface description • Semantics not clearFunctionality has to be guessed from flow of information  What does a service, that requests a String and outputs an Integer?  automatic selection difficult • Strict message compatibilityIf messages between provider and requestor do not match, the service cannot be used Message oriented service description incomingmessages outgoingmessages Service

  33. WSDL Tools and Extensions

  34. Tools for WSDL • Integration in Programming Languages • Microsoft .NET • Sun: Java Web Service Development Pack • XML Processing, SOAP Binding, XML Registry… • Web Services Toolkit (WSTK) von IBM • Plugins for Eclipse (WSDL Viewer, WSDL Validator, …) • SOAP for Perl • NuSOAP – SOAP Toolkit for PHP • … • Tools / Server Components for WSDL • Axis (SOAP Server) • IBM’s Websphere • Graphical WSDL editors like CapeClear • WSDL generators (“right-click on method”) • WSDL validators • …

  35. WSDL in Practice – Early Adopters • amazon.com • “Amazon E-Commerce Service” • Everything but really buy: • ItemLookup, ItemSearch, SimilarityLookup • CartAdd, CartClear, CartCreate, CartGet, CartModify • Service requestors need to registers first • Intended usage: including Amazon in own web sites • ebay.com • “eBay SOAP API” • Offer Items, Place Bids, Search for articles… • google.com

  36. WS-*: Language Extension for WSDL • WS-PolicyFor including non-functional requirements/assertions in WSDL descriptions • WS-Resource Framework (WSRF)For describing resources and states on the service provider. • WS-Security (WSS)For securing the usage of web services • WS-CoordinationFor enhancing WSDL descriptions by protocols to coordinate the actions of several participants. Example: WS-AtomicTransaction

  37. Web Service Composition – BPEL4WS subprovider 1 • BPEL4WS = Business Process Execution Language for Web Services • Specification of the Orchestration, i.e. the coordination between main service and its subservice providers. • Developed by Microsoft (“XLANG”) and IBM (“WSFL”) service requestor service provider subprovider 2 subprovider 3 BPEL4WS WSDL

  38. Evaluation of WSDL Advantages • Easy to understand • Widely accepted • Rich tool support • good integration in programming languages • many extensions • important early adopters • upcoming standard for description Disadvantages • Low semantics • primitive matchers • not usable for automatic service selection • designed for static service binding

  39. Ausblick:Semantic Web Services

  40. Funktionalität A Dienstorientierte Architektur Geschäftsprozess • Nutzung von Funktionalitätexterner Entitäten über Dienste • Dynamische Dienstbindung Funktionalität A‘ Funktionalität B‘ Dienst- geber 3 Dienst- geber 5 Funktionalität A Dienst- geber 1 Funktionalität A Dienst- geber 2

  41. Dynamic Service Binding • Dynamic Service Binding • Advantages • robust • context-aware • network independent • Most important task: automation •  Complete process should be automatic • Important: • Semantic Service Description Language

  42. Ansätze • ALLGEMEIN:Von syntaktischer zu semantischer Dienstbeschreibung • Einigung auf ein gemeinsames Vokabular Ontologie • Nicht mehr Drucker/Printer/prt/lpt1, sondern „PRINTER“ • Zusätzlich Beschreibung der Zustandsänderung durch den Dienst • Welcher Zustand muss vor Dienstausführung gelten? • Welcher Zustand gilt nach erfolgreicher Dienstausführung? • Getrennte Anfrage- und Angebotsbeschreibungen • Anfrager kann Präferenzen in die Anfrage integrieren • Was muss, was soll, was darf, was könnte etc.

  43. Gemeinsames Vokabular Grundsätzlicher Ansatz: Rechnerverständlichkeit benötigt gemeinsames Vokabular  Einsatz von Ontologien Location Schema Room within Building Instanzen room2.14:Room room335:Room within geb50.34:Building

  44. 2. Getrennt Nachrichten-/ Zustandsbasierte Dienstbeschreibung (z.B. OWL-S) Dienst Zustände vor Dienstausführung Zustände nach Dienstausführung 3. Rein Zustandsorientierte Dienstbeschreibung (z.B. DSD) Dienst konfigurierbare Zustände vor Dienstausführung konfigurierbare Zustände nach Dienstausführung Typen von Dienstbeschreibungen eingehende Nachrichten 1.Rein nachrichtenbasierteDienstbeschreibung (z.B. WSDL) abgehende Nachrichten Dienst Zustand Information

  45. Vorteile • Vorteile eines gemeinsamen Vokabulars: • Keine unterschiedliche Benennung des gleichen Sachverhalts •  Beschreibung ist eindeutig •  Computer kann Vergleich selbstständig durchführen • Allerdings auch Einigungsaufwand • Vorteile von rein zustandsorientierten Beschreibungen: • Keine explizite Beschreibung von Nachrichten •  Einfluss der ausgetauschten Information auf Zustände klar definiert •  Dienst können passen, obwohl Informationsfluss unterschiedlich

  46. ZUSAMMENFASSUNG

  47. Zusammenfassung UDDI Dienstorientierte Architektur Web Service SOAP message-operation-port-service WSDL Semantische Dienstbeschreibung Vergleich von WSDL-Beschreibungen abstrakte vs. konkrete Dienstbeschreibung Dienstverzeichnis rein zustandsorientierte Dienstbeschreibung Dynamische Dienstbindung BPEL4WS

  48. Thank you for your attention!

More Related