2 12 th March Web Science th March Service Science th March Web Services (WSDL, SOAP, UDDI, XML)

Transcription

1 Where are we? # Date Title 1 5 th March Introduction 2 12 th March Web Science 3 19 th March Service Science Semantic Web Services Web Service Technologies Lecture IV 26 th March 2009 Dieter Fensel slides from Jacek Kopecký 4 26 th March Web Services (WSDL, SOAP, UDDI, XML) 5 2 nd April Web 2.0 and RESTful s 6 23 rd April WSMO 7 30 th April WSML 8 7 th May WSMX 9 14 th May OWL-S and others th May WSMO-Lite, MicroWSMO 11 4 th June SWS Use Cases th June seekda: the business point of view th June Mobile s 14 2 nd July Exam Preparation Copyright 2008 STI INNSBRUCK Overview Motivation Technical solutions SOAP protocol and related specs WSDL definition language Further selected specfications Motivation

2 5 Motivation: SOA Web Services Service-Oriented Architecture For large-scale distributed computing For interoperability within and among enterprises Business-oriented s Coarse- grained s Improves evolvability, manageability Needs a suitable set of technologies Technology for SOA Client-server messaging approach With predefined Message exchange patterns Independent of network protocols Application-specific s Similar to RPC, CORBA Most data in XML Descriptions in XML Schema 6 RPC vs. Web Services CORBA vs Web Services Remote Procedure Calls Aim to hide the network Distributed system looks like a local system Some calls happen to go over the network But network is important Latency, bandwidth Reliability connection, nodes RPC is harmful CORBA = Distributed Objects Encourages fine-grained design Much more advanced than RPC High barrier to entry Caused by binary protocols, high core complexity Initial big interoperability problems Due to the above, and incomplete specifications

3 9 Technical Solution: WS-* discover s registry publish descriptions SOAP client invoke (provider) 10 SOAP in Detail: Overview SOAP Messages née Simple Object Access Protocol In fact, simple messaging protocol Current version: W3C Message structure Processing model Protocol bindings XML Envelope Body Application payload Faults Headers Metadata, processing instructions May be marked as mandatory Possibly targeted at intermediaries

4 13 SOAP Message Example SOAP Message Envelope <soap:envelope namespaces > <soap:header> <wsa:messageid> unique ID </wsa:messageid> <wsa:replyto> endpoint </wsa:replyto> </soap:header> Body <soap:body> <bank:balancerequest> data </bank:balancerequest> </soap:body> Header </soap:envelope> 14 SOAP Processing Model SOAP Mandatory Headers Processing a message 1. Selecting headers targeted at me The current intermediary or ultimate receiver 2. Checking for understanding Do I understand all that is targeted at me and marked as mandatory? 3. Processing everything in some order mustunderstand="true" The recipient must understand them Implies agreement to act in accordance to the spec Non-mandatory headers can be ignored This mechanism enables gracious evolution If a new feature can be ignored, its introduction won't harm older nodes If a new feature must be understood, its introduction will be discovered early by older nodes, without unexpected behavior

5 17 SOAP Protocol Bindings SOAP HTTP Binding Transporting the message over a network Addressing What an endpoint address looks like Serialization How to put the XML message in on- the- wire bits and bytes Connection How to send the bits to the endpoint Addressing: URIs Serialization: HTTP message body Media type application/soap+xml Connection: TCP Possibly Web-friendly SOAP 1.1 only used HTTP POST 18 SOAP MEPs SOAP Summary Message Exchange Patterns Request-Response Input message followed by output or SOAP-Response Request without SOAP (e.g. HTTP GET) SOAP output or Still pretty simple even if the name doesn t say so any more Extremely extensible HTTP binding for easy communication The value of SOAP: XML and Processing Model

6 21 Attachments WS-Addressing XML is nice, but not binary XOP: XML-binary Optimized Packaging Binary data in XML logically in the tree On serialization, it is outside, raw, efficient MIME multipart message MTOM: XOP for SOAP Message Transfer Optimization Mechanism Extends SOAP HTTP binding Simple routing protocol Endpoint References for addressing With parameters or metadata in addition to the address Message headers for routing & correlation Many headers use endpoint references 22 WSA Msg Info Headers To let the middleware deliver the message From, ReplyTo, FaultTo channels back MessageID, RelatesTo simple correlation Action semantics implied by the message <S:Header> <wsa:messageid> unique ID </wsa:messageid> <wsa:replyto> endpoint </wsa:replyto> <wsa:to> address </wsa:to> <wsa:action> URI </wsa:action> </S:Header> Web Service Description Language WSDL

7 25 WSDL in Detail: Overview Web Service Description Language Interface Definition Language (IDL) for Web Services Current version: W3C Version 1.1 still in widespread use Interface reusable, abstract Operations with MEPs Binding reusable, concrete Service implements an Endpoints use bindings 26 endpoint endpoint

8 29 binding endpoint endpoint 30 endpoint binding

9 33 message msg msg ref ref ref msg ref msg ref ref message msg msg ref ref ref msg ref msg ref ref types 34 message msg msg ref ref ref msg ref msg ref ref types element declaration type definition message msg msg ref ref ref msg ref msg ref ref types element declaration type definition

10 37 WSDL Interface Design of application Possibly extending other s Operations Message exchange pattern (MEP) Input/output messages, s Referencing XML elements defined in types Faults Used and reused by s WSDL Interface Example < name= Banking > < name= transfer pattern= > <input element= Transfer /> <output element= Balance /> <out ref= InvalidBankAccount /> <out ref= InsufficientFunds /> </> < name= balance safe= true pattern= > <input element= BalanceRequest /> <output element= Balance /> <out ref= InvalidBankAccount /> </> < name= InvalidBankAccount element= InvalidAccountInfo /> < name= InsufficientFunds element= InsufficentFundsInfo /> </> 38 WSDL Predefined MEPs WSDL Invocation MEPs core Invocation: In- In- only out Out- only Out- in Messaging: Robust in- only In- optional- out Robust out- only Out- optional- in additional, not formal standard In-only: a single input message No s In-out: a single input message, a single output message A may replace output message Out-only and Out-in mirror images of the above

11 41 WSDL Messaging MEPs WSDL Binding Robust in-only: a single input message May trigger a In-optional-out: a single input message, possibly an output message Either message may trigger a Robust out-only, Out-optional-in mirrored Networking details necessary for accessing the Copies structure SOAP and HTTP bindings provided 42 WSDL Bindings WSDL Service SOAP binding: XML message in SOAP envelope Transport using a SOAP protocol binding (HTTP) HTTP binding: Web- friendly XML message in payload, or as parameters in the URI A logical node of the application One Multiple alternate endpoints Endpoints may have different bindings E.g. SOAP over HTTP for a public endpoint, and SOAP over JMS for the intranet

12 45 WSDL Service Example WSDL Summary < <endpoint <endpoint </> name= HypoTirol = Banking > name= visible binding= HTTP address= /> name= tls binding= SecureHTTP address= /> Concrete Abstract and reusable Interface Network binding WSDL does not imply implementation CORBA IDL requires objects Exchange of XML business documents Extensible in many ways 46 UDDI And More WS-* Specifications Universal Description, Discovery and Integration A Web registry API specification Business- oriented publication, discovery (initially limited search capabilities) Itself has Web Useful for intranet registries A failed public

13 49 UDDI Structure WS Policy Business entity Organization information, contact Business Service A group of related s Binding Template Information on how to access the tmodel (technical model) Any kind of specification, e.g. WSDL Also for classification, categorization Non-functional metadata Security, Quality of, Privacy, Transactionality policies Policy a set of alternatives (OR) Auth tokens: Kerberos OR X509 Alternative a set of assertions (AND) Auth token AND secure channel Assertions come from 3 rd parties 50 WS Policy Example The Rest of the Specs <wsp:policy> <wsp:exactlyone> <wsse:securitytoken> <wsse:tokentype>wsse:kerberosv5tgt </wsse:tokentype> </wsse:securitytoken> <wsse:securitytoken> <wsse:tokentype>wsse:x509v3 </wsse:tokentype> </wsse:securitytoken> </wsp:exactlyone> </wsp:policy> Security: authentication, encryption Reliable messaging Get the message there or tell me Transactions: ACID, Compensating BPEL4WS: Scripting Web Services Interoperability: WS-I Basic Profile and still more

14 53 Specification Origins Ad-hoc industry alliances Usually including Microsoft, IBM Standardization bodies W3C (Web- oriented), OASIS (industrial) Only when an initial specification is mature Standardization takes time, requires consensus/compromise Illustration by Example 54 Virtual Travel Agency Blue Hotel WSDL (1) <?xml version="1.0" encoding="utf-8"?> <description xmlns=" targetnamespace= " xmlns:tns= " xmlns:bhns= " xmlns:wsoap= " xmlns:soap=" xmlns:wsdlx= " <documentation> This document describes the Blue Hotel Web. </documentation>

15 57 Blue Hotel WSDL (2) Blue Hotel WSDL (3) <types> <xs:schema xmlns:xs=" targetnamespace=" xmlns=" <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="tcheckavailabilityresponse"/> <xs:complextype name="tcheckavailabilityresponse"> <xs:sequence> <xs:element name="roomtype" type="xs:string"/> <xs:element name="ratetype" type="xs:string"/> <xs:element name="rate" type="xs:double"/> </xs:sequence> </xs:complextype> <xs:element name="invaliddataerror" type="xs:string"/> </xs:schema> </types> < name = "BlueServiceInterface" > < name = "invaliddatafault" element = "bhns:invaliddataerror"/> < name="opcheckavailability" pattern=" style=" wsdlx:safe = "true"> <input messagelabel="in" element="bhns:checkavailability" /> <output messagelabel="out" element="bhns:checkavailabilityresponse" /> <out ref="tns:invaliddatafault" messagelabel="out"/> </> </> 58 Blue Hotel WSDL (4) Blue Hotel UDDI Binding Template <binding name="blueservicesoapbinding" ="tns:blueserviceinterface" wsoap:protocol= " type=" < ref="tns:invaliddatafault" wsoap:code="soap:sender"/> < ref="tns:opcheckavailability" wsoap:mep= " </binding> < name="blueservice" ="tns:blueserviceinterface"> <endpoint name="reservationendpoint" binding="tns:blueservicesoapbinding" address=" </> </description> <bindingtemplate bindingkey= "uuid:36f1b765-bdb d e5a2a" Key= "uuid:40e6d5a8-3e16-4f01-99da a40"> <description xml:lang="en"> SOAP binding for Blue Hotel </description> <accesspoint URLType="http"> </accesspoint> <tmodelinstancedetails> <tmodelinstanceinfo tmodelkey= "uuid:ae1b645f-cf2f-491f-811a f5904"/> </tmodelinstancedetails> </bindingtemplate>

16 61 Blue Hotel UDDI tmodel <tmodel tmodelkey= "uddi:we1b6q5f-cf2f-491f-811a f5904" operator=" authorizedname="george Blue"> <name>bluehotelinterface Port Type</name> <description> An for the Blue Hotel </description> <overviewdoc><overviewurl> BlueHotelService.wsdl </overviewurl></overviewdoc> </tmodel> Blue Hotel SOAP Request POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope soap:encodingstyle= " xmlns:soap=" <soap:body xmlns:bhns= " <bhns:checkavailability> <bhns:checkindate> </bhns:checkindate> <bhns:checkoutdate> </bhns:checkoutdate> <bhns:roomtype>single</bhns:roomtype> </bhns:checkavailability> </soap:body> </soap:envelope> 62 Blue Hotel SOAP Response HTTP/ OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope soap:encodingstyle= " xmlns:soap=" <soap:body xmlns:bhns= " <bhns:checkavailabilityresponse> <bhns:roomtype>single</bhns:roomtype> <bhns:ratetype>discount</bhns:ratetype> <bhns:rate>150.50</bhns:rate> </bhns:checkavailabilityresponse> </soap:body> </soap:envelope> Conclusions

17 65 Web Services Summary Further Developments Technology for - oriented systems Core: protocol + IDL (SOAP + WSDL) Many extension specifications Messaging paradigm Sometimes RPC Biggest benefit: XML Vendor-neutral, platform-independent Interoperable Easy to begin and play with But hidden in the frameworks Unless you're a developer of the framework Semantic Web Services Automating the use of Web s Using semantic technologies RESTful s Real Web s Integrated with the Web 66 References Next Lecture SOAP: WSDL: XOP: MTOM: WS-Addressing: WS-Policy: UDDI: OASIS: W3C: Wikipedia: # Date Title 1 5 th March Introduction 2 12 th March Web Science 3 19 th March Service Science 4 26 th March Web Services (WSDL. SOAP, UDDI, XML) 5 2 nd April Web 2.0 and RESTful s 6 23 rd April WSMO 7 30 th April WSML 8 7 th May WSMX 9 14 th May OWL-S and others th May WSMO-Lite, MicroWSMO 11 4 th June SWS Use Cases th June seekda: the business point of view th June Mobile s 14 2 nd July Exam Preparation

18 Questions? 69