This document provides an introduction to web services. It defines services and web services, compares web services to other technologies, and outlines the main web services specifications and implementation approaches. Specifically, it discusses SOAP, WSDL, UDDI, RESTful services, and how web services use XML messaging over HTTP to enable interoperability across platforms. The document also presents examples of how web services can be used for application integration and B2B integration.

1. Introduction to Web Services
Assoc.Prof.Dr. Thanachart Numnonda
September 2010
www.imcinstitute.com

2. Agenda
 What is Service?
 What/Why Web Services?
 Comparing Web Services with Other Technologies
 Web Services Specifications:
 Web Services Implementation
2

3. What is Service?
3

4. Service : Definition [W3C]
A service is an abstract resource that represents a
capability of performing tasks that represents a
coherent functionality from the point of view of
provider entities and requester entities.
To be used, a service must be realized by a concrete
provider agent.
4

5. Service Concepts
• Service is a resource and has an owner,
• Service is provided by a person or an organization.
• Service must be realized by a (software) provider
agent.
• Service performs one or more tasks.
• Service is used by a requester agent.
• Example: a service for updating software
5

6. Characteristics of Service

7. Characteristics of Service

8. What is Web Service?
8

9. Web Service : Definition [Wikipedia]
 Web services are typically application programming
interfaces (API) or web APIs that are accessed via
HTTP and executed on a remote system hosting the
requested services.
 Web services tend to fall into one of two camps: Big
Web Services and RESTful Web Services.
9

10. Web Service : Definition [W3C]
 a software system designed to support interoperable
machine-to-machine interaction over a network.
 It has an interface described in a machine-
processable format (WSDL).
 Other systems interact with the web service in a
manner prescribed by its description using SOAP
messages, typically conveyed using HTTP
with an XML serialization in conjunction with other
Web standards..
 There are two major classes of web services, REST-
compliant Web services and arbitrary Web services. 10

11. Big Web Services
 Big Web Services use Extensible Markup Language (XML)
messages that follow the SOAP standard and have been
popular with traditional enterprise.
 There is often a machine-readable description of the
operations offered by the service written in WSDL.
 WSDL is not a requirement of a SOAP endpoint, but it is a
prerequisite for automated client-side code generation in
many Java and .NET SOAP frameworks
11

12. RESTful Web Services
 Representational State Transfer (REST) services do not
require XML, SOAP, or WSDL service-API definitions.
 The primary purpose of the service is to manipulate XML
representations of Web resources using a uniform set of
stateless operations.
 is typically a defined set of HTTP request messages along
with a definition of the structure of response messages,
usually expressed in an XML or JavaScript Object Notation
(JSON) format.
12

13. Web Services : Styles of use
 The three most common styles of use are
– Remote Procedure Calls (RPC)
– Service-oriented architecture (SOA)
– Representational state transfer (REST)
13

14. RPC Web services
 present a distributed function (or method) call interface.
Typically, the basic unit of RPC Web services is the WSDL
operation.
 Not being loosely coupled, because it was often
implemented by mapping services directly to language-
specific functions or method calls.
 Other approaches: CORBA, DCOM, RMI.
14

15. Service-oriented architecture
 Web services can also be used to implement an architecture
according to SOA concepts, where the basic unit of
communication is a message.
 referred to as message-oriented services.
 loose coupling because the focus is on the "contract" that
WSDL provides.
 use Enterprise Service Buses which combine message-
oriented processing and Web Services to create an Event-
driven SOA.
15

16. Representational state transfer
 REST attempts to describe architectures which use HTTP by
constraining the interface to a set of well-known, standard
operations (like GET, POST, PUT, DELETE ).
 An architecture based on REST can use WSDL to describe
SOAP messaging over HTTP or can be created without using
SOAP at all..
16

17. Web Services : Demo
17

18. Web Services Conceptual Model
18

19. Web Services : Components
 A web service includes three basic components:
– a mechanism to find and register interest in a
service
– a definition of the service’s input and output
parameters
– a transport mechanism to access a service
 Web services also include other technologies that can be
used to provide additional features such as security,
transaction processing and others.
19

20. Web Services : Process
 A service provider publishes a service to an external registry.
 A client (a service consumer) looks up for a service in the
registry.
 The registry returns information about the service:
 The client binds to the underlying service
 The client calls and accesses the service.
20

21. Comparing Web Services
with other technologies
21

22. Web Service is not a new technology!
• Web services do not introduce new functionality.
• Similar functionality is provided by:
– Sun RMI
– Microsoft DCOM
– Enterprise Java Beans
– etc.
22

23. How Web Services differ from Others?
• Supported by all major software vendors; so fulfills
the promise of universal interoperability
• Operations of Web Services are based on the
exchanged of XML format
• Web Services use normal HTTP transport protocols
so message can pass through a fireware.
• Web Services utilize standard Internet protocols
such as HTTP, SMTP, FTP
23

24. Comparison: Standards
• The main difference with past Distributed
Computing Environments is adopted standards and
implementations:
– a standard lookup service – UDDI
– a standard definition mechanism – WSDL
– a standard way for two parties to communicate –
SOAP
• The foundation technology for all three (and more)
is XML.
24

25. Traditional Communication
• Systems must be tightly bound
• Data must be transferred in such a way that two
systems agree beforehand on the format
• Various “network normal forms” were created to
decide how bytes, integers, etc. were to be encoded
for transfer.
25

26. XML-Based Communication
• Common, well-defined data and representation
• Well-defined set of validity and well-formedness
rules
• Web service communication relies on XML syntax
to write messages.
26

27. Web Services : Disadvantage
• Web services may suffer from poor performance
compared to other distributed computing
approaches such as RMI, CORBA, or DCOM.
• Web services standards features such as
transactions are currently nonexistent or still in
their infancy compared to more mature distributed
computing open standards such as CORBA.
27

28. Web Services Properties
 self-contained – no additional software is required for WS:
– client-side: a programming language with XML/HTML client
support
– server-side: a web server and a SOAP server are needed
 loosely coupled – client and server only knows about messages -
a simple coordination level that allows for more flexible re-
configuration.
 web-enabled – WS are published, located and invoked across
the web, using established lightweight Internet standards.
 language-independent and interoperable – client and server
may be implemented in different environments and different
languages.

29. Web Services Properties (cont.)
 composable –WS can be aggregated using workflow techniques
to perform higher-level business functions.
 dynamically bound – with UDDI and WSDL, the discovery and
binding of web services can be automated.
 programmatic access –the web services approach does not
provide a graphical user interface but operates at the command
level.
 wrap existing applications – stand-alone applications can easily
be integrated by implementing a web service as an interface.

30. 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
30

31. 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

32. WS Usage : Application Integration
• Legacy systems can be wrapped as web services and made
available for integration with other systems.
• Applications exposed as web services are accessible by
other applications running on different hardware platforms
and written in different languages.
32

33. WS Usage : B2B Integration
• Business-to-business (B2B) partner integration over the
Internet.
• B2B integrates business systems of two or more companies
to support cross-enterprise business processes, e.g. supply
chain management.
33

34. Web Service Specifications
34

35. Web Services Architecture Stacks
35

36. Communications Layer
• Web Services are essentially transport-neutral.
• A web service message can be transported using
HTTP or HTTPS, as well as more specialized
transport mechanisms, such as e.g. JMS.
• Web services insulate the designer from most of the
details and implications of the message transport
layer.
36

37. Messaging Layer
• SOAP = Simple Object Access Protocol
• A protocol to exchange structured information in a
distributed environment.
• SOAP extensions:
– WS-ReliableMessaging - a standard for web services
messaging to guarantee the receipt of messages for
WS requestors and providers
– WS-Transactions - a series of standards related to
WS invocations in transactions (atomicity,
consistency, isolation and durability semantics)
37

38. Descriptions Layer
• WSDL = Web Services Description Language
• A language that allows a service provider to specify
the functional
• characteristic of its web services.
• WSDL extensions:
– WS-Policy - augment WSDL with non-functional
constraints on WS
– WS-ResourceProperties – describes how to define
and access properties of resources through WS
38

39. Processes Layer: Discovery
• Discovery - locating a machine-processable
description of a web service that may have been
previously unknown and that meets certain criteria.
• UDDI = Universal Description, Discovery and
Integration
• UDDI defines a way to store and retrieve
information about web services.
39

40. WS Interoperability
• Web Services tackle the set of problems related to
loosely coupled, dynamically configured
heterogeneous distributed computing.
• WS Specifications:
– A series of smaller, purpose-focused specifications
dealing with narrow problems (security, transactions,
etc.) in isolation.
– Each WS specification is designed to be composed
with the others.
– WS designers determines which specifications their
system needs and implement them accordingly.
40

41. WS-I Organization
• Web Services Interoperability organization (WS-I,
http://www.ws-i.org/):
– WS-I is to standardize combinations of WS
specifications that can be used to increase the level of
interoperability between web services.
– WS-I promotes the Basic Profile – implementation
guidelines for how non-proprietary WS
specifications, such as SOAP, WSDL, UDDI, should
be used together for best interoperability.
41

42. Web Services and Standards
42

43. Web Service Implementation
43

44. Web Services : Design methodologies
• Web services can be implemented in two ways:
– the bottom up method first writes the implementing
class in a programming language, and then uses a
WSDL generating tool to expose its methods as a
web service. This is often the simpler approach.
– the top down method first writes the WSDL
document and then uses a code generating tool to
produce the class skeleton, which later completed.
44

45. J2EE 1.4 Simple Web Service
 Simplest way is to use JSE(JAX-RPC Service Endpoint)
– Expose Java classes directly as web services
– Can use SOAP Endpoints based on Servlet
Containers, e.g. Apache Axis
– E.g. JSE with SOAP over HTTP
SOAP SOAP Service
Over HTTP Handler
Servlet Container
JAX-RPC Service Endpoint with SOAP Over HTTP
45

46. EJB Web Services (JSR 109)
 J2EE 1.4 Allows JAX-RPC (JSR 101) Web Services using Stateless
Session Beans.
 JAX-RPC hides the complexity of SOAP messages from the developer.
 J2EE web services can be invoked by any web service client, and any
J2EE web service client can invoke any web service.
Web Browser,
Applets HTTP
and optionally JSPs
Session Beans
Java Bean and Servlets
Entity Beans DB
Components RMI
Message Driven
or IIOP
Beans
Application Clients
(Java)
SOAP
SOAP Handler
Application Clients
(Java/Non Java)
Client Tier Business Tier
Web Tier
Web Services in J2EE Server
EIS Tier
46

47. Java EE 5 Web Service : JAX-WS
 Plainold Java Object (POJO) can be easily
exposed as web service.
 Annotation driven
 Data binding through JAXB
 Server Independent
47

48. JAX-WS : Servlet Endpoint
48

49. Java Web Services Framework
 Application Server : Most have web services
functionality
– WS-I required by Java EE5 spec.
– GlassFish
– etc.
 Apache Axis
49

50. 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
 Web Services and Java, Elsa Estevez, Tomasz
Janowski and Gabriel Oteniya, UNU-IIST, Macau
50

51. Thank you
thananum@gmail.com
www.facebook.com/imcinstitute
www.imcinstitute.com
51