1. WEB SERVICES

2. LEARNING OUTCOMES
 At the end of this class, YOU should be able to : Describe the role of web services
 List component of web services
 List the specifications used to make web services platform independent

3. DISTRIBUTED COMPUTING ISSUE
 Software application written in various languages
 Running on multiple platform
 Data exchange problem
 Issue : To exchange data over the internet using similar manner to
inter process communication in a single computer.

4. WHAT IS A WEB SERVICE?
 Can be defined as : software functionality that can be invoked
through the internet using common protocols
 A remote component resides in remote web server
 Something like a remote function that can be called by a program through a
web server
 Accept parameters and produce results (service output)
 Service output often not HTML rather XML, text or other contents type
 Allow application developed using different languages to exchange
information

5. CONSTRAINED BY TECHNOLOGY

6. LEVERAGE HTTP

7. ROLE OF WEB SERVICE
 Expose a remote service or executable procedure to a client
application
 Service requestor
 Web services are designed to be platform independent
 No CPU, OS or programming language specific is required for web services
 Leverage existing technology
 Extensive use of HTTP and XML
 Interoperable across disparate programming language
 It is possible a client written in one programming language communicating
with server written in different language

8. WHERE WEB SERVICES ARE
USED?
 Within an enterprise (Enterprise Application Integration)
 Accelerate and reduce cost of integration
 Cost saving on infrastructure deployment and management
 Reduce skill requirements
 Improve reuse
 Between enterprises (E-business integration, B2B)
 Providing service to company’s customers
 Accessing services from company partners and suppliers
 Reduce standard barriers

9. WEB SERVICE CONTEXT
World Wide Web
Components
Web Service
Distributed Objects
Standards

10. WEB SERVICE
CONCEPTUAL ARCHITECTURE
Service
Registry
Find
Service
Requestor
Service
Description
Publish
Bind
Service
Provider
Servic
e
Service
Description

11. WEB SERVICES CORE XML
SPECIFICATION
 Web Services Definition Language (WSDL)
 Simple Object Access Protocol (SOAP)
 Universal Description, Discovery and Integration (UDDI)

12. WEB SERVICE
COMPONENT - ARCHITECTURE
MAPPING
Service
Service
Registry
Find
Description
In UDDI
Publish
Using
SOAP
Service
Requestor
Bind
In Your
Language
Service
Provider
Servic
e
Service
Description
In WSDL

13. RELATIONSHIP BETWEEN STANDARDS
Searching for a service (UDDI)
http://www.uudi.org
UDDI
Link to WSDL document
Web
Service
Contract Agreement (WSDL)
http://yourservice.com/?WSDL
Client
Web
Service
WSDL Web Service Contract
Communication (SOAP)
http://yourservice.com/svcA
XML/SOAP Body

14. INTERACTION BETWEEN WEB SERVER
AND CLIENT
UDDI Directory
Registered Web Service
Web Service Provider
white
1. Declare service to UDDI
yellow
Web
Server
WSDL
WSDL
Description
Description
Web
Servic
e
2. Client look for a
service in UDDI register
3. Download WSDL
service to generate
proxy or stub for the
web service
Web
Servic
e
WSDL
Description
Busines
s Object
Generated
Stub
Web Service Client
3. Client invoke web
service through proxy
sending/receiving SOAP
message
Application
Server
Busines
s Object
Busines
s Object
Busines
s Object
EAI &
Connector
yellow
Back
Office
and
Enterpris
e System

15. WEB SERVICE DEFINITION LANGUAGE
(WSDL)
 Web service need to be defined in order to be discovered by and
interfaced with other services and application
 WSDL : defined a web service and how to access them
 Define the location of the service
 The operations the service exposes
 Communicates using open protocols
 Can be discovered using UDDI

16. WSDL DOCUMENT STRUCTURE
 Abstract Part : describes
 The message it sends and
receives
 The operation associates a
message exchange pattern
with one or more message
 Concrete Part: specifies
WSDL Specification
Abstract Part
types
messages
operations
port types
 Transport and wire format
details for one or more
interfaces
 A port (end point) associates a
network address with a binding
 A service which groups
together end points that
implement a common interface
Concrete Part
bindings
services and ports

17. WSDL DOCUMENT STRUCTURE
<definitions>
<types>Define data types used by the web service</types>
<message>A group of related input/output </message>
<portType>
The operation performed by the web services
</portType>
<binding>
The element defines the message format and protocol
details for each port
</binding>
<service>Define operation expose by each port</service>
</definition>

18. <message>
 A group of related input and output messages
 <message> define parts and its associated type
<message name = “OrderMsg”>
<part name=“productName” type=“xs:string” />
<part name=“quantity” type=“xs:integer” />
</message>
<message name = “OrderResponseMsg”>
<part name=“orderId” type=“xs:integer” />
</message>

19. <portType>
 Elements that defines operations which are made up of messages
 The operation performed by the web services
 Comparable to a library in traditional programming
<portType name=“procurementPortType”>
<operation name=“orderGoods”>
<input message=“OrderMsg” />
<output message=“OrderResponseMsg” />
</operation>
</portType>

20. COMPARABLE TO TRADITIONAL
PROGRAMMING
 “procurementPortType” is comparable to function library
 “orderGoods” is comparable to a function with “OrderMsg” as
input parameter and “OrderResponseMsg” as return type

21. OPERATION TYPE
Type
Definition
One-way
The operation can receive a message but
will not return a response
The operation can receive a request and
will return a response
The operation can send a request and will
wait for a response
The operation can send a message but will
not wait for a response
Request-response
Solicit-response
Notification

22. REQUEST-RESPONSE
<message name = “OrderMsg”>
<part name=“productName” type=“xs:string” />
<part name=“quantity” type=“xs:integer” />
</message>
<message name = “OrderResponseMsg”>
<part name=“orderId” type=“xs:integer” />
</message>
<portType name=“procurementPortType”>
<operation name=“orderGoods”>
<input message=“OrderMsg” />
</operation>
</portType>

23. ONE WAY OPERATION
<message name = “OrderMsg”>
<part name=“productName” type=“xs:string” />
<part name=“quantity” type=“xs:integer” />
</message>
<portType name=“procurementPortType”>
<operation name=“orderGoods”>
<input message=“OrderMsg” />
<output message=“OrderResponseMsg” />
</operation>
</portType>

24. <binding>
 This element defines the message format and protocol details for
each port
 Attributes in <bindings>
 type : name of port type
 name : bindings name
 Sub Element of <bindings>

soap:binding
 style: “rpc” / “document”
 transport (Communication protocol: SOAP, Transport protocol : HTTP/SMTP)
 operation:
 Define operation that the port exposes
 Must specify how input and output encoded

25. <binding>
<binding name=“ProcurementSoapBinding” type=“tns:procurementPortType”>
<soap:binding style=“document”
transport=“http://schemas.xmlsoap.org/soap/http” />
<operation name=“orderGoods” >
<soap:operation soapAction=“http://example.com/orderGoods” />
<input>
<soap:body use=“literal” />
</input>
<output>
<soap:body use=“literal” />
</output>
</operation>
</binding>

26. <service>
 A service may have more than one end point, with each one
defined by its own port
 The port elements corresponds to a particular binding and
includes information on how to access it.
<service name=“ProcurementService”>
<port name=“ProcurementPort” binding=“tns:ProcurementSoapBinding”>
<soap:address location=“http://example.com/procurement” />
</port>
</service>

27. <?xml version="1.0"?>
<definitions name="Procurement"
targetNamespace="http://example.com/procurement/definitions"
xmlns:tns="http://example.com/procurement/definitions"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/" >
<message name="OrderMsg">
<part name="productName" type="xs:string"/>
<part name="quantity" type="xs:integer"/>
</message>
<binding name="ProcurementSoapBinding" type="tns:procurementPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="orderGoods">
<soap:operation soapAction="http://example.com/orderGoods"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="ProcurementService">
<port name="ProcurementPort" binding="tns:ProcurementSoapBinding">
<soap:address location="http://example.com/procurement"/>
</port>
</service>
</definitions>
messages
operation and
port type
concrete
part
binding
port and
service
Copyright Springer Verlag Berlin Heidelberg 2004
<portType name="procurementPortType">
<operation name="orderGoods">
<input message = "OrderMsg"/>
</operation>
</portType>
abstract
part

28. UNIVERSAL DESCRIPTION,
DISCOVERY AND INTEGRATION (UDDI)
 UDDI – platform independent framework to
 describe services,
 discover businesses,
 integrate business services by using the Internet
 Directory for storing information about web services
 Directory of web service interfaces described by WSDL
 Communicates via SOAP

29. SIMPLE OBJECT ACCESS PROTOCOL
(SOAP)
 SOAP is a protocol for accessing a Web Service
 Communication protocol
 For communication between applications
 Format for sending messages

30. WHY SOAP?
 RPC is used to communicate between objects like CORBA and
DCOM
 HTTP is not designed for this
 RPC represents a compatibility but with drawbacks.
 Security problem -firewalls and proxy servers will normally block this kind of
traffic
 SOAP is a better way to communicate between application using
HTTP
 HTTP is supported by all web browsers

31. SOAP DOCUMENT STRUCTURE
 Envelope
SOAP ENVELOPE
 element that identifies the XML
document as a SOAP message
 Header
 element that contains header
information
 Body
 element that contains call and
response information
 Fault
 element containing errors and
status information
Header
Body
Fault

32. SOAP DOCUMENT STRUCTURE
<?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:Header>
Contains application-specific information about the SOAP message
</soap:Header>
<soap:Body>
Contains the actual SOAP message
<soap:Fault>
Used to indicate error messages
</soap:Fault>
</soap:Body>
</soap:Envelope>

33. <soap:Envelope>
 Root element of a SOAP message
 Defines the XML document as a SOAP message
defines the Envelope as a
SOAP Envelope
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle=http://www.w3.org/2001/12/soapencoding >
•
</soap:Envelope>
•
•
Used to define the data types used
in the document
May appear on any SOAP element,
and applies to the element's contents
and all child elements
A SOAP message has no default
encoding

34. <soap:Header>
 Contains application-specific information (like authentication,
payment, etc) about the SOAP message
 Attributes of <soap:Header>
 mustUnderstand
 actor
 encodingStyle
defines how a recipient should process the
SOAP message

35. mustUnderstand
 Indicate whether a header entry is mandatory or optional for the
recipient to process
 Syntax = soap:mustUnderstand="0|1"
 1 : the SOAP server and the node that receives the message
containing the header block must be able to process it correctly or
issue an appropriate fault messsage
<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>

36. actor
 Used to address the Header element to a specific endpoint
<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:actor="http://www.w3schools.com/appml/">234
</m:Trans>
</soap:Header>

37. <soap:Body>
 Contains the actual SOAP message
requests the price of apples
<soap:Body>
applicationspecific
elements
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>

38. <soap:Body>
 Contains the actual SOAP message
<soap:Body>
applicationspecific
elements
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>

39. A RESPONSE COULD LOOK LIKE
<?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>
<m:GetPriceResponse
xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>

40. <soap:Fault>
 To indicate error messages
 Must appear as a child element of the Body element.
 A Fault element can only appear once in a SOAP message

41. <soap:Fault> SUB ELEMENTS
Sub Element
Description
<faultcode>
A code for identifying the fault
<faultstring>
A human readable explanation of the fault
<faultactor>
Information about who caused the fault to happen
<detail>
Holds application specific error information related to the Body
element

42. <soap:Fault>
<faultcode>SOAP-ENV:Client</faultcode>
<faultstring>Message does not have necessary info</faultstring>
<faultactor>http://gizmos.com/order</faultactor>
<detail>
<PO:order xmlns:PO="http://gizmos.com/orders/">
Quantity element does not have a value</PO:order>
<PO:confirmation xmlns:PO="http://gizmos.com/confirm">
Incomplete address: no zip code</PO:confirmation>
</detail>

43. <soap:Fault> CODES
Error
Description
VersionMismatch
Found an invalid namespace for the SOAP Envelope element
MustUnderstand
An immediate child element of the Header element, with the
mustUnderstand attribute set to "1", was not understood
The message was incorrectly formed or contained incorrect
information
There was a problem with the server so the message could not
proceed
Client
Server

44. BINDING SOAP WITH A TRANSFER
PROTOCOL
 SOAP binding describes how a SOAP message is carried in a transport
protocol (eg., HTTP, SMTP or FTP).
 For example, to bind SOAP to HTTP:
 A SOAP request is wrapped inside an HTTP POST
 The HTTP POST request species at least two HTTP headers:

Content-Type and

Content-Length.
 Content-Type: defines the MIME type for the SOAP message and the character encoding
(optional) used
 Content-Length: specifies the number of bytes in the body of the SOAP request or
response.
 Example
POST /stockquote HTTP/1.1
Content-Type: text/xml; charset=utf-8
Content-Length: 482

45. BINDING SOAP WITH A TRANSFER
PROTOCOL
Service Provider
HTTP Post Request
SOA
P
Engin
e
HTTP
Engin
e
HTTP Response
SOAP Envelope
SOAP Envelope
SOAP Header
SOAP Header
SOAP Body
SOAP Body
Method Request Name
Method Return
param1
Return param
param2
Service Requestor
SOA
P
Engin
e
HTTP
Engin
e

46. Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI“
<?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:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>
BINDING SOAP TO HTTP REQUEST
POST /StockQuote HTTP/1.1

47. Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<?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>
<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>
BINDING SOAP TO HTTP RESPONSE
HTTP/1.1 200 OK