Quick overview of Web Services - SOAP and RESTful

1. Java Training Overview
Web Services

2. Introduction
• Who am I?
– Worked for TSB for 13+ years as FNA
– October 2012 moved to ITSO
– TSB and ITSO was kind enough to send me to San
Antonio with Sean, Vicky and Tony

3. What we will be covering
•
•
•
•
Web services architecture
Web services definitions and terms
How Web Services work
Overview and examples of SOAP and RESTful
Web Services

4. What we won’t be covering
• Java programming
• How to functional test Web Services

5. What are Web Services?
“A piece of software that provides some useful
functionality by a programmatic interface that is
available via the standard protocols of the Internet.”

6. What are Web Services?
•
•
•
•
Application components
Use open protocols
Self-contained and self-describing
Can be discovered using Universal Description
Discovery and Integration (UDDI)
• Can be used by other applications
• Allows data exchange between different applications
and different platforms

7. Web Services Platform
•
•
•
•
•
•
Lots of confusion
2 general types of Web Services – SOAP and REST
SOAP is a protocol, REST is an architecture style
Can have many overlaps
Usually over HTTP
Usually uses XML (or JSON)

8. How do Web Services work?
CGI
Web
Application
Browser
HTML
Web
Service
Client
(Phone
App)
Web
Service
Web
Service
Web Service
Provider
Database

9. SOAP

10. SOAP…
•
•
•
•
•
•
•
•
•
Stands for Simple Object Access Protocol
Is a communication protocol
Is a format for sending messages
Is designed to communicate via the Internet
Is platform and language independent
Is based on XML
Is simple and extensible
Allows you to get around firewalls
Is a W3C standard

11. SOAP building blocks
A SOAP message is an ordinary XML document
containing the following elements:
• An Envelope element that identifies the XML
document as a SOAP message
• A Header element that contains header information
• A Body element that contains call and response
information
• A Fault element containing errors and status
information

12. SOAP syntax rules
• A SOAP message MUST be encoded using XML
• A SOAP message MUST use the SOAP Envelope
namespace
• A SOAP message MUST use the SOAP Encoding
namespace
• A SOAP message must NOT contain a DTD reference
• A SOAP message must NOT contain XML Processing
Instructions
• SOAP request could be an HTTP POST or HTTP GET

13. Example: A SOAP Request
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>

14. Example: A SOAP Response
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>

15. WSDL
WSDL is an XML-based language for locating and
describing Web services.
• WSDL stands for Web Services Description Language
• WSDL is based on XML
• WSDL is used to describe Web services
• WSDL is used to locate Web services
• WSDL is a W3C standard

16. WSDL document structure
The main structure of a WSDL document looks like this:
<definitions>
<types>
data type definitions........
</types>
<message>
definition of the data being communicated....
</message>
<portType>
set of operations......
</portType>
<binding>
protocol and data format specification....
</binding>
</definitions>
A WSDL document can also contain other elements, like extension elements, and a service element that makes it
possible to group together the definitions of several web services in one single WSDL document.

17. Example: WSDL document
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>

18. UDDI
UDDI is a directory service where companies can
register and search for Web services.
• UDDI stands for Universal Description, Discovery
and Integration
• UDDI is a directory for storing information about
web services
• UDDI is a directory of web service interfaces
described by WSDL
• UDDI communicates via SOAP
• UDDI is built into the Microsoft .NET platform

19. REST

20. REST
•
•
•
•
•
•
•
•
XML
HTTP
URIs
Soap has a single front door, REST has URIs
Resource based, each with it's own URI
Requests are GETs and responses are XML
No request body, no SOAP envelope
SOAP only does GET and POST, REST does GET, POST,
PUT, DELETE (and others)

21. Key component of a REST architecture
• Resources, which are identified by logical URLs.
Both state and functionality are represented using resources.
– The logical URLs imply that the resources are universally
addressable by other parts of the system.
– Resources are the key element of a true RESTful design,
as opposed to "methods" or "services" used in RPC and
SOAP Web Services, respectively. You do not issue a
"getProductName" and then a "getProductPrice" RPC calls
in REST; rather, you view the product data as a resource -and this resource should contain all the required
information (or links to it).

22. Key component of a REST architecture
• A web of resources, meaning that a single resource should
not be overwhelmingly large and contain too fine-grained
details. Whenever relevant, a resource should contain links to
additional information -- just as in web pages.
• The system has a client-server, but of course one
component's server can be another component's client.
• There is no connection state; interaction is stateless (although
the servers and resources can of course be stateful). Each new
request should carry all the information required to complete
it, and must not rely on previous interactions with the same
client.

23. Key component of a REST architecture
• Resources should be cachable whenever possible (with an
expiration date/time). The protocol must allow the server to
explicitly specify which resources may be cached, and for how
long.
– Since HTTP is universally used as the REST protocol, the
HTTP cache-control headers are used for this purpose.
– Clients must respect the server's cache specification for
each resource.
• Proxy servers can be used as part of the architecture, to
improve performance and scalability. Any standard HTTP
proxy can be used.

24. REST: Request Example
• REST Request is often just a URL
http://www.acme.com/phonebook/UserDetails?firstName=John&lastName=Doe
or
http://www.acme.com/phonebook/UserDetails/firstName/John/lastName/Doe
• While REST services might use XML in
their responses (as one way of organizing structured
data), REST requests rarely use XML.

25. REST: Response Example
• Response is usually XML or JSON
<person>
<firstName>John</firstName>
<lastName>Doe</lastName>
<age>25</age>
<address>
<streetAddress>21 2nd Street</streetAddress>
<city>New York</city>
<state>NY</state>
<postalCode>10021</postalCode>
</address>
<phoneNumbers>
<phoneNumber type="home">212 555-1234</phoneNumber>
<phoneNumber type="fax">646 555-4567</phoneNumber>
</phoneNumbers>
</person>

26. That, in a nutshell, is it

27. What we covered
•
•
•
•
Web services architecture
Web services definitions and terms
How Web Services work
Overview and examples of SOAP and RESTful
Web Services

28. Questions?