# Presentation: 926203

## WSDL, UDDI, SOAP, REST: SOA Acronym Soup

- Matthew J. Dovey
- Oxford University

## WebService Soup: The confusion

- REST

- SOAP

- WSDL

- UDDI

- WS-Addressing

- WSRF

- SOA

- WS-N

- WS-Events

- WS-Eventing

- BPEL

- WS-Security

- SAML

- XACML

- WS-I

## Firstly...

- What is a WebService?
- Goal is interoperability ***between enterprises***
- We’re getting there but it hasn’t 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 not 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     (HTTP POST)
- Retrieve  (HTTP GET) *[no side effects]*
- Update    (HTTP PUT)
- Delete     (HTTP DELETE)

## SRU – REST style

- Noun: http://www.server/database/myResultSet
- Verbs:
- Search – create result set
- POST /database/myResultSet HTTP/1.1
- Content-Type: text/xml; charset=utf-8
- <query>title = fish</query>
- Sort – update result set
- PUT /database/myResultSet HTTP/1.1
- Content-Type: text/xml; charset=utf-8
- <sortBy>author</sortBy>
- Retrieve – retrieve result set
- GET /database/myResultSet HTTP/1.1
- Content-Type: text/xml; charset=utf-8
- <recordSet><startRecord>1</startRecord><endRecord>10</endRecord></recordSet>
- Finish – delete result set
- DELETE /database/myResultSet HTTP/1.1
- Content-Type: text/xml; charset=utf-8

## 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
- XML-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)
- String foo(String s, Integer i) {
- ...
- 	return result;
- }

- LAN

## Remote Procedural Style

- ...
- myVar = foo(“hello world”, 6)
- String foo(String s, Integer i) {
- ...
- 	return result;
- }

- Internet

## 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
- Messages
- XML messages built from types passed from client to server and server to client
- e.g. searchRetrieveRequest, searchRetrieveResponse
- portTypes
- 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
- Bindings
- How to encode (e.g. SOAP document/literal)
- How to transport (e.g. HTTP, SMTP)
- Services
- Endpoint
- e.g. http://voyager.loc.gov:7090/

## Invisible WSDL

- String foo(String s, Integer i)
- {...}
- ...
- myVar = foo(“hello world”, 6)
- ...

-   WSDL Document

## 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]">  <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 JAX-RPC 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)

## 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	

- 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)

- 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
- Poor open source implementations for version 3.0

## And the rest

- WSDL 2.0
- WS-Addressing: indirection via server EPR (End Point References)
- WS-N, WS-Events, WS-Evening: Notification publish/subscribe
- BPEL: WebService Workflow/Choreography
- WSRF: Representing resources through WebServices
- WS-Security: SAML, XACML, etc. for encryption, signing/validation and credential delegation
- ebXML-BP, OWL-S, Semantic Framework etc. for policy/contractural negotiations
- etc...
- Compatibility declines as you go further up the stack...
- Straying from WS-I can be dangerous

## And finally retro-fitting

- 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