WSDL, UDDI, SOAP, REST: SOA Acronym Soup

Matthew J. Dovey Oxford University

WebService Soup: The confusion WS-Addressing WSDL WS-Security WS-Eventing WS-N XACML REST WS-I SOAP SOA WS-Events SAML BPEL UDDI WSRF

Firstly

What is a WebService?
 

Goal is interoperability between enterprises Were getting there but it hasnt been an uneventful journey!

REST


Representational State Transfer SRU, OpenSearch etc. are NOT REST WebServices


But rather REST-like in that they use XML and HTTP but RESTnot the underlying philosophy of REST

Underlying philosophy of mapping HTTP verbs to the Create/Retrieve/Update/Delete philosophy of APIs



Discussed in a PhD thesis by Roy Fielding

True REST


URLs are nouns, not verbs The basic API (verbs) is C.R.U.D
Create  Retrieve  Update  Delete


(HTTP POST) (HTTP GET) [no side effects] (HTTP PUT) (HTTP DELETE)

SRU REST style

Noun: http://www.server/database/myResultSet
Verbs: Search create result set
POST /database/myResultSet HTTP/1.1 ContentContent-Type: text/xml; charset=utf-8 charset=utf<query>title = fish</query>

Sort update result set

PUT /database/myResultSet HTTP/1.1 ContentContent-Type: text/xml; charset=utf-8 charset=utf<sortBy>author</sortBy>

Retrieve retrieve result set

GET /database/myResultSet HTTP/1.1 ContentContent-Type: text/xml; charset=utf-8 charset=utf<recordSet><startRecord>1</startRecord><endRecord>10</endRecord></recordSet>

Finish delete result set

DELETE /database/myResultSet HTTP/1.1 ContentContent-Type: text/xml; charset=utf-8 charset=utf-

SOAP


Originally Simple Object Access Protocol but now SOAP stands for SOAP!


(Called XP for XML Protocol for a while)

Originates from doing Remote Procedural Calls over XML and HTTP Microsoft initiated but moved to W3C Originally a number of competitors


 

XMLXML-RPC etc

Remote Procedural Style

myVar = foo(hello world, 6)

String foo(String s, Integer i) { return result; }

Remote Procedural Style

myVar = foo(hello world, 6)

LAN

String foo(String s, Integer i) { return result; }

Remote Procedural Style

myVar = foo(hello world, 6)

Internet

String foo(String s, Integer i) { return result; }

More SOAP
<SOAP:Envelope xmlns:SOAP=..."> <SOAP:Header> </SOAP:Header> <SOAP:Body> <SRW:searchRetrieveRequest xmlns:SRW=..."> <SRW:version>1.1</SRW:version> <SRW:query>(dc.author exact "jones" and dc.title >= "smith")</SRW:query> <SRW:startRecord>1</SRW:startRecord> <SRW:maximumRecords>10</SRW:maximumRecords> <SRW:recordSchema>info:.../mods</SRW:recordsSchema> </SRW:searchRetrieveRequest> </SOAP:Body> </SOAP:Envelope>

SOAP Components


SOAP:Header
 

Not well used, but designed for messaging and relaying purposes e.g. telling proxies to rewrite sru:baseUrl

SOAP:Body


XML payload

SOAP:Faults


Error conditions

WSDL 1.1


Web Service Description Language



Describes the SOAP Messages

Components


Types
 

XML representations of the types (typically XML Schema language) e.g. searchRetrieveRequestType XML messages built from types passed from client to server and server to client e.g. searchRetrieveRequest, searchRetrieveResponse Which messages are sent in which direction, and what the response is e.g. searchRetrieveRequest is sent client to server, and a searchRetrieveResponse sent back How to encode (e.g. SOAP document/literal) How to transport (e.g. HTTP, SMTP) Endpoint e.g. http://voyager.loc.gov:7090/

Messages
 

portTypes
 

Bindings
 

Services
 

Invisible WSDL
String foo(String s, Integer i) {}
WSDL Document

myVar = foo(hello world, 6)

Not so invisible WSDL



WSDL not well defined/described



The original spec uses definition by example

Early WSDL tools highly incompatible

 

Different interpretations e.g. when to use xsd:import; when to use wsdl:import

Not so bad today (if using the major toolkits)

Early SOAP/WSDL Toolkits Issues



SOAP Encoding 1


rpc versus document



RPC Style: String foo(String s, Integer i) Document Style Class foo {

String s; Integer I;

} String foobar(foo);

SOAP Encoding 2 SOAP versus Literal styles



Literal just as plain XML

<stuff>hello</stuff> <numbers"> <item>10</item> <item>20</item> <item>30</item> <item>40</item> <item>50</item> </numbers>

SOAP use particular SOAP defined XML constructs for arrays etc.
<stuff xsi:type=xsd:string>hello</stuff> <numbers xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:integer[5]"> xsi:type="SOAPSOAP<item>10</item> <item>20</item> <item>30</item> <item>40</item> <item>50</item> </numbers>

And it gets worse

Literal:
<Distance> <p1> <x>10</x> <y>20</y> </p1> <p2> <x>10</x> <y>20</y> </p2> <Distance>

SOAP Encoding:
<Distance> <p1 HREF="#id1"/> <p2 HREF="#id1"/> </Distance> <Point id="id1"> <x>10</x> <y>20</y> </Point>

XML Schema


Officially any XML Schema construct is valid in WSDL In practice

e.g. for a long time Java tools were defined by JAXJAXRPC which defined a subset of valid XML Schema  e.g. in early stages of SRU the following caused headaches:



xsd:positiveInteger, xsd:nonNegativeInteger etc.

XML Schema funnies sequences and choice

<sequence>
<element name=foo type=string /> <element name=bar type=string />

</sequence> Often generates String foo; String bar; <choice>

<element name=foo type=string /> <element name=bar type=string />

</choice> Also generates String foo; String bar; (Although will raise an exception if both are non-null at serialization) non-

Consider
<choice> <element name=foo type=string /> <sequence> <element name=foo type=string /> <element name=bar type=string /> </sequence> </choice>

Early Axis (until 2005!) generated String foo; String foo; String bar;

XML Schema funnies: Extension of all groups

<complexType=type1> <complexContent> <all> <element name=foo type=string /> <element name=bar type=string /> <all> </complexContent> </complexType> <complexType=type2> <complexContent> <extension base=type2"> <all> <element name=foo1 type=string /> <element name=bar2 type=string /> <all> </extension> </complexContent> </complexType> Passes most XML parsers but is invalid!

XML Schema funnies: Qualified Dublin Core case

Health warning complex XML Schema follows!!!
<xs:complexType name="SimpleLiteral"> <xs:complexContent mixed="true"> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any processContents="lax" minOccurs="0" maxOccurs="0"/> </xs:sequence> <xs:attribute ref="xml:lang" use="optional"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="W3CDTF"> <xs:simpleContent> <xs:restriction base="dc:SimpleLiteral"> <xs:simpleType> <xs:union memberTypes="xs:gYear xs:gYearMonth xs:date xs:dateTime"/> </xs:simpleType> </xs:restriction> </xs:simpleContent> </xs:complexType> Valid but will not get past many parsers

Enter WS-I WS

Web Service Interoperability profile



Key components: SOAP, WSDL, UDDI

Defines a set of rules for interoperable WebServices

e.g. use SOAP document/literal style  Rules for wsdl:import versus xsd:import  Still defines any XML Schema as valid etc.


Compliant toolsets much better at interoperating today

UDDI (the oft forgotten third part of WS-I) WS  

Universal Description, Discovery and Integration (of WebServices) Provides a model of organisations and webservices Provides a WebService API for interacting with registries of WebServices
    

publishing, searching, retrieving, replicating, subscribing

  

Template based searching (still issues to be resolved) Not well used outside of enterprise due to out of band contractual negotiations needed for inter-enterprise web services interPoor open source implementations for version 3.0

And the rest

      

WSDL 2.0 WSWS-Addressing: indirection via server EPR (End Point References) WS- WSWS-N, WS-Events, WS-Evening: Notification publish/subscribe WSBPEL: WebService Workflow/Choreography WSRF: Representing resources through WebServices WSWS-Security: SAML, XACML, etc. for encryption, signing/validation and credential delegation ebXMLebXML-BP, OWL-S, Semantic Framework etc. for OWLpolicy/contractural negotiations


etc

Compatibility declines as you go further up the stack



Straying from WS-I can be dangerous WS-

And finally retro-fitting retro

Service Oriented Architecture Reference Model



Attempting to retro fit a definition onto SOA

Service Oriented Architecture Blueprints



Attempting to retro fit a methodology

Last word


Interoperability of WebServices have been a difficult road For more complex tasks (security, messaging, asynchronous etc.) there is still some difficulties ahead But we do have interoperability at the basic level and it is getting better