This document provides an introduction and overview of web services. It begins by defining what a service is from both a business and technical perspective. It then discusses what web services are, how they differ from traditional client-server models, and their key characteristics. The document outlines some common web service specifications including SOAP, WSDL, and UDDI. It provides examples of how these specifications work together to enable web services. Finally, it discusses trends in web services adoption and some myths surrounding web services.

1. Topic 2
Introduction to Web Service
Dr.Thanachart Numnonda
Sun Microsystems (Thailand)
Asst.Prof.Thanisa Kruawaisayawan
KMITL

2. Agenda
 What is Service?
 What/Why Web Services?
 Web Services Specifications:
 Web Services Demo
2

3. What is Service?
3

4. What is Service?
 Primary goal of a service is to represent a “natural”
step of business functionality
 Technically, a service is a software component
 a service is an interface for (multiple) messages that
return information and/or change the state of an
associate entity (backend)
 The operations defines in the interface carry out
business functions
 Service is available across a network.
4

5. Services in SOA
• SOA is focused on business process
• Services can be implemented by any technology on
any platform (NOT only web services)
• In fact, SOA has been around for quite a while
• Other service components
– EJB (Enterprise Java Bean), COM+, .NET Enterprise
services, CCM (CORBA Component Models)
5

6. Characteristics of Service
6

7. Characteristics of Service (cont.)
7

8. Types of Services
• Entity Service
– Represent one or more business entity
– Features CRUD operations
• Functional Service
– Is a technology oriented service
– Perform a given function; eg: sending mail, deposit
• Process Service
– Represents a series of related tasks
– Can be represented as an orchestration invoked by ESB;
eg: loan process
8

9. What/Why Web Service?
9

10. What is Web Service?
 A Web service is a software module that has a URL
or an Internet address so they can be called upon to
perform a operation via the Internet.
 One Web service makes a request of another Web
service to perform its task or tasks and pass back an
answer creating a highly distributed system.
 using XML based messages via internet-based
protocols
 Web Services are latest distributed technology
10

11. Web Services Conceptual Model
11

12. Web Services Conceptual Model (cont.)
12

13. Web Services Conceptual Model (cont.)
13

14. Web Services Conceptual Model (cont.)
14

15. Characteristics of Web Services

XML based everywhere

Message-based

Programming language independent

Could be dynamically located

Could be dynamically assembled or aggregated

Accessed over the internet

Loosely coupled

Based on industry standards
15

16. How Web Services differ from Others?
• Supported by all major software vendors; so fulfills
the promose of universal interoperability
• Operations of Web Services are based on the
exchanged of XML format
• Web Services utilize standard Internet protocols such
as HTTP, SMTP, FTP
16

17. Distributed Computing Evolution
Servers Servers
Clients PDA Cell
Internet
Phone
Client-Server(C/S)
silos
Clients Workstation Server
Web-based computing
Kiosk Laptop
Web Services/Peer-to-Peer
17

18. Traditional C/S vs. Web Services
Traditional C/S Web Service

Within enterprise 
Between enterprises

Tied to a set of 
Program language
programming languages independent

Procedural 
Message-driven

Usually bound to a 
Easily bound to different
particular transport transports

Tightly-coupled 
Loosely-coupled

Efficient processing 
Relatively not efficient
(space/time) processing

19. Web Application vs. Web Services
Web Application Web Service

User-to-program 
Program-to-program
interaction interaction

Static integration of 
Possibility of dynamic
components integration of

Monolithic service components (in the
future)

Possibility of service
aggregation (in the
future)

20. Why Web Services?
Web Services:

Are platform neutral

Are accessible in a standard way

Are accessible in an interoperable
way

Use simple and ubiquitous
plumbing

Are relatively cheap

Simplify enterprise integration
20

21. Why Web Services are a Hot Topic:
 Interoperable – Connect across heterogeneous networks using
ubiquitous web-based standards
 Economical – Recycle components, no installation and tight
integration of software
 Automatic – No human intervention required even for highly
complex transactions
 Accessible – Legacy assets & internal apps are exposed and
accessible on the web
 Available – Services on any device, anywhere, anytime
 Scalable – No limits on scope of applications and amount of
heterogeneous applications

22. Web Services Usage Example
Distributor
XML
XML
Manufacturing
Supplier Internet Facility
XML
XML
Logistics
“Growing need for a standard lightweight infrastructure
for data exchange in e-business applications.”
22

23. Myth: Web Services is a New Concept

Web services is distributed computing all over
again – only now it is based on the web
Distributed Computing via
Concept CORBA /Java Basic Web Services
Interface Description CORBA IDL, Java interface WSDL
RPC support ORBs, Idl2java compilers, rmic SOAP
Service Registry CORBA naming service, JNDI UDDI
Messaging support CORBA Event/Notification service, JMS WS-Reliable Messaging?
Transaction support CORBA Transaction service, JTS WS-AtomicTransaction ?
Secuity support CORBA Security service, Java security WS-Security ?

24. Other Popular Myths Surrounding Web Services

Web services require only SOAP, WSDL, UDDI:
− We need more high-level semantics

Web services are based on the RPC paradigm:
− Document-driven model would be more popular
communication model

Web services must be based on HTTP:
− Other transports such as SMTP can be also used
24

25. Myths about Web Services

Web Services cure cancer: Not for a very very long
time!

Web Services are something completely new: Not
True!

You have to write Web Services from scratch: Not
True!

Java Platform does not support web services: Not
True!
25

26. State of Web Services

Technology/Standards are still evolving
− SOAP, WSDL, UDDI are not enough

Business web services is the next big thing, but more
works are needed in
− Quality of Service, management
− Security, transaction, state and user context
− Work flow, Identity management,
− Provisioning, Accounting

Will be adopted in phases
26

27. Web Services Adoption Phases
 1st phase (in the past)
 Concerted deployment internally within an organization
mainly for interoperability
 SOAP over HTTP/S
 2nd phase (current state)
 Selective and non-aggregate deployment with trusted
outside business partners
 Private registry deployment
 3rd phase (1 to 2 years)
 Wider, more dynamic and aggregate deployment with
outside business partners
 Public registry deployment

28. Web Services Adoption Phases (cont.)
 1st Phase – Simple Web Services (Past)

Consumer-focused, stateless, SOAP over HTTP/S
 2nd Phase – EAI Web Services (Now)

Deployed within organization boundaries to enable internal
integration
 3rd Phase – Business Web Services (1-2 Year)

Deployed on extranets to enable business transactions with
trading partners, suppliers, and customers, ebXML & UBL

29. Trends Towards Service Orientation

Evolution of EAI to web service standards

XML RPC => Asynchronous XML Messaging

Towards de-centralization

Componentized services
− Composable and composite services
− Data encapsulated within component
− Data ownership follows component ownership

Brokered web services

Flexible relationships => Adaptive businesses 29

30. Web Service Specifications?
30

31. Web Services : Fundamental Specifiations
 Service Invocation => SOAP
 Service Description => WSDL
 Service Registration (Publication) and Discovery
=> UDDI
 SOAP, WSDL and UDDI are XML based

32. XML
32

33. XML Schema
• XML is the lingua franca of SOA, used for message
payloads
• XML Schema provides data definition in XML
format
• XML Schemas are not object-oriented , are intended
to capture a data model
33

34. Example: Book.xsd
34

35. SOAP
35

36. SOAP

Simple Object Access Protocol

Wire protocol similar to
− IIOP for CORBA
− JRMP for RMI

XML is used for data encoding
− “text” based protocol vs. “binary” protocol

Supports XML-based RPC
36

37. What SOAP is Not

Not a component model
− So it will not replace objects and components, i.e. EJB,
JavaBeans

Not a programming language
− So it will not replace Java

Not a solution for all
− So it will not replace other distributed computing
technologies such as RMI
37

38. What does SOAP Define?

Message Envelope

Encoding Rules

RPC Convention

Binding with underlying protocols
38

39. SOAP Message Format
SOAP Message SOAP Envelope
SOAP Header
Primary MIME part
(text/xml) Header Entry
Header Entry
Attachment
SOAP Body
Attachment
Body Entry
Body Entry
Attachment
39

40. SOAP Message Envelope

Encoding information

Header
− Optional
− Could contain context knowledge

Security

Transaction

Body
− RPC methods and parameters
− Contains application data
40

41. SOAP Encoding
• Rules of expressing application-defined data types in
XML
• Based on W3C XML Schema
• Simple values
– Built-in types from XML Schema, Part 2 (simple types,
enumerations, arrays of bytes)
• Compound values
– Structs, arrays, complex types
41

42. SOAP RPC Request Example
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="…"
SOAP-ENV:encodingStyle="…">
<SOAP-ENV:Header>
<!-- Optional context information -->
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m=“some_URI">
<tickerSymbol>SUNW</tickerSymbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
42

43. SOAP RPC Response Example
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="…"
SOAP-ENV:encodingStyle="…">
<SOAP-ENV:Header>
<!-- Optional context information -->
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m=“some_URI">
<price>30.5</price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
43

44. SOAP RPC

Information needed for a method call:
− The URI of the target object
<SOAP-ENV:Body>
<m:GetLastTradePrice
xmlns:m=“http://stocks.com/StockQuotes">
<tickerSymbol>SUNW</tickerSymbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
44

45. SOAP RPC (cont.)

Information needed for a method call:
− The URI of the target object
− Method name
<SOAP-ENV:Body>
<m:GetLastTradePrice
xmlns:m=“http://stocks.com/StockQuotes">
<tickerSymbol>SUNW</tickerSymbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
45

46. SOAP RPC (cont.)

Information needed for a method call:
− The URI of the target object
− Method name
− Parameters
<SOAP-ENV:Body>
<m:GetLastTradePrice
xmlns:m=“http://stocks.com/StockQuotes">
<tickerSymbol>SUNW</tickerSymbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
46

47. WSDL
47

48. What is WSDL?
• XML language for describing web services
• Web service is described as
– A set of communication endpoints (ports)
• Endpoint is made of two parts
– Abstract definitions of operations and messages
– Concrete binding to networking protocol (and corresponding
endpoint address) and message format
• Why this separation?
– Enhance reusability (as we will see in UDDI reference to
WSDL document)
48

49. Why WSDL?
• Enables automation of communication details between
communicating partners
– Machines can read WSDL
– Machines can invoke a service defined in WSDL
• Discoverable through registry
• Arbitration
– 3rd party can verify if communication conforms to WSDL
49

50. WSDL Document Example

Simple service providing stock quotes

A single operation called GetLastTradePrice

Deployed using SOAP 1.1 over HTTP

Request takes a ticker symbol of type string

Response returns price as a float
50

51. WSDL Elements

Types

Message

Operation

Port Type

Binding

Port

Service
51

52. WSDL Elements (cont.)

Types
− Data type definitions
− Used to describe exchanged messages
− Uses W3C XML Schema as canonical type system
52

53. WSDL Example: Types
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/”>
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name=”tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
53

54. WSDL Elements

Messages
− Abstract, typed definitions of data being exchanged

Operations
− Abstract description of an action
− Refers to an input and/or output messages

Port type
− Collection of operations
− Abstract definition of a service
54

55. Example:
Messages, Operation, Port type
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
<!-- More operations -->
</portType>
55

56. WSDL Elements

Binding
− Concrete protocol and data format for a particular Port type
− Protocol example: SOAP 1.1 over HTTP or SOAP 1.1 over
SMTP

Port
− Defines a single communication endpoint
− Endpoint address for binding
− URL for HTTP, email address for SMTP

Service
− Aggregate set of related ports
56

57. Example: Binding, Port, Service
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation
soapAction="http://example.com/GetLastTradePrice"/>
<input> <soap:body use="literal" />
</input>
<output> <soap:body use="literal" />
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
57

58. UDDI
58

59. UDDI (Universal Description,
Discovery and Integration)

“White pages”
– address, contact, and known identifiers

“Yellow pages”
– industrial categorizations

Industry: NAICS (Industry codes - US Govt.)

Product/Services: UN/SPSC (ECMA)

Location: Geographical taxonomy

“Green pages”
– technical information about services
59

60. Additional WS Specifications
• WS-Security: Address transport of security context
• WS-Coordination: Framework for achieving
coordination between partners
• WS Transaction Specifications: Standard for creating
distributed transaction involving multiple Web
Services
– WS-AtomicTransaction
– WS-BusinessActivity
• WS-Realiable Messaging: Standards for reliable
delivery of messages between partners
60

61. Additional WS Specifications (cont.)
• WS-Addressing: Defines end point communication
• WS-Inspection: Specification uses for dynamic
discovery of service documents
• WS Policy: Specifics the policy of a web service
provider
• WS-Eventing: Defines event sources and consumers
in the event model.
61

62. Web Services and Standards
62

63. RESTful Web Services
• REST => REpresentational State Transfer
• Resources (nouns) ->Identified by a URI, For example:
• http://www.parts-depot.com/parts
• Methods (verbs) to manipulate the nouns
– Create, Read, Update, Delete
• Representation is how you view the State
– data and state transferred between client and server
– XML, JSON...
• Use verbs to exchange application state and representation
63

64. Characteristics of REST
• RESTful services are stateless
– Each request from client to server must contain all the
information necessary to understand the request
• RESTful services have a uniform interface
– GET, POST, PUT, and DELETE.
• REST-based architectures are built from resources
(pieces of information) that are uniquely identified by
URIs
– In a RESTful purchasing system, each purchase order has a
unique URI

65. REST vs “Traditional” Web Services
• “Traditional” web service
– Few URIs (nouns), many custom methods (verbs)
• musicPort.getRecordings(“beatles”)
– Uses HTTP as transport for SOAP messages
• RESTful web service
– Many resources (nouns), few fixed methods(verbs)
• GET /music/artists/beatles/recordings
– HTTP is the protocol

66. SOAP Service and REST Resource
• SOAP based web services is about services SOA
– Stock quote service
quoteService.purchas e(“sunw”, 2000, 6.0f);
• Resource-Oriented Architecture (ROA)
– Stock quote resource
– Resources are manipulated by exchanging representations
– Eg. purchasing stock
• Manipulate my portfolio resource
• Handle a POST in a stock resource that I own
• POST /mystocks/sunw
From http://www.prescod.net/rest/mistakes/

67. Web Services : Demo
67

68. Public Web Services
• Web Service X (http://www.webservicex.net)
• StrikeIron.com
• Xmethods.com
• FedEx.com
• Amazon Web Service
• Google
68

69. soapUI
• Open source tool for web service testing
• Iinspecting, invoking, monitoring,
simulating/mocking and functional/load
/compliance/surveillance testing
• REST/WADL and SOAP/WSDL-based Web
Services over HTTP.
• www.soupui.org
69

70. soapUI
70

71. Resources
 Some contents are borrowed from the presentation
slides of Sang Shin, Java™ Technology Evangelist,
Sun Microsystems, Inc.
 Business Process Execution Language for Web
Services, Matjaz B. Juric
 Java SOA Cookbook, Eben Hewitt
 SOA in Practice, Nicolai M. Josuttis
71

72. Thank you
thanachart.numnonda@sun.com
twitter.com/thanachart
www.facebook.com/thanachart
72