SlideShare a Scribd company logo
Introduction to Web Services
Held as part of the lecture series on
Web Engineering at Vienna University of Technology
May 2015
Philipp Liegl
ecosio GmbH
Wiedner Hauptstr. 52, 1040 Vienna, Austria

phone: +43 (1) 996 2106-20, fax: +43 (1) 996 2106-99

philipp.liegl@ecosio.com, www.ecosio.com, @ecosioHQ
Web Engineering
Web Services
Outline of today’s talk
▪ Introduction to Service-Oriented Computing
▪ SOAP
▪ WSDL
▪ UDDI
▪ Java API for XML Web Services (JAX-WS)
▪ RESTful Web Services
▪ Java API for RESTful Web Services (JAX-RS)
3
Introduction to Service-Oriented Computing
4
Context of Web Services: Distributed Information Systems
▪ Layers of an information system
▪ Presentation layer
▪ Communication interface to external entities
▪ Graphical user interface for human users 

or non graphical user interface for 

other programs
▪ Application logic layer
▪ Implements operations requested by clients

through the presentation layer
▪ Resource management layer
▪ Deals with different data sources of an

information system
▪ Distributed systems are split up into parts
▪ Run simultaneously on multiple computers
▪ Communicate over a network
presentation layer
application logic
layer
resource
management layer
client
TUWIENWEInformationSystem
Machine to machine communication
Getting applications to talk to each other
presentation layer
application logic
layer
resource
management layer
client
TUWIENWEInformationSystem
application logic
layer
resource
management layer
Anotherinformationsystem
client
presentation layer
application logic
layer
5
Introduction to Service Oriented Computing
6
Tag Cloud
Introduction to Service-Oriented Computing
7
Heterogeneity as the main obstacle for seamless communication of distributed information systems
Windows Server 2008 UNIX System
Flight information and
booking application
(programmed in C)
Travel information and
booking application
(programmed in Java)
Travel agency "The agency" Airline "The airline"
seamless
interaction?
• Mismatch in operating system, language, platform, etc.
• Service-oriented computing is an emergent paradigm that helps to overcome
these mismatches
• Example: Yield management in the airline industry requires close system
interaction in order to retrieve the most current prices
Introduction to Service-Oriented Computing
8
Application integration using services
Windows Server 2008 UNIX System
Flight booking application
(programmed in C)
Flight information
application
(programmed in Java)
Travel agency "The agency" Airline "The airline"
• Service vs. Web Service
• Services are business functions which an enterprise offers to its business
partners
• A possible implementation of Services are Web Services
• However, other concepts may also be used to implement a Service, e.g.,
ebXML, document-centric approaches using EDI messages, etc.
Service
Service
Request
Response
What is a “service”?
9
“a logical representation of a repeatable activity, that has a specific outcome”
“a service is a type of API, usually over HTTP”
You may have an API, but not expose it to anybody external.
“a service is a proxy of your internal logic, which is exposed to the outside
world”
Think of the analogy of “views” in database systems.
Introduction to Service-Oriented Computing
10
Important terms in service-oriented computing
• (Web) Services are self-contained modules that can be described, published,
located, orchestrated, and programmed using XML-based technologies over a
network
• Service providers are organizations that provide the service implementations,
supply their service descriptions, and provide related technical and business
support
• Service clients are end-users and organizations that use some service
• Service aggregators are organizations that consolidate multiple services into a
new, single orchestrated service offering that is commonly known as business
process.
• A service-oriented architecture (SOA) is a logical way of designing a software
system to provide services to either end-user applications or to other services
distributed in a network, via published and discoverable interfaces.
Introduction to Service-Oriented Computing
11
Characteristics of Web Services (WS)
• WS semantically encapsulate discrete functionality
• A Web Service is a self contained software module that performs a single task (e.g.
weather forecast by passing the zip-code as parameter)
• WS share a contract
• In order to allow interaction of services, a formal contract must be established, that
defines the exact terms of an information exchange between a service client and a
service provider
• WS abstract underlying program logic
• A service exposes a certain functionality to a client. How that functionality is achieved
(e.g., which program language is used, or which database is used) remains invisible to
the caller
• WS are loosely coupled software modules
• A service interface is defined in a neutral manner, independent of the underlying
platform, operating system, or programming language
• Due to their neutral interfaces, services are not hard-wired. Thus, a service may be easily
exchanged by another service, without much implementation effort
• WS are reusable
• A service may be reused by multiple applications
Introduction to Service-Oriented Computing
12
Characteristics of Web Services II (WS)
• WS can be dynamically found and included in applications
• A WS provides programmable access. Thus, a WS may be embedded in a
remotely located application, i.e., a service may be composed.
• Unlike Web Sites, Web Services are not targeted at human users
• They are called by and exchange data with other software modules and
applications.
• WS are described in terms of a standard description language
• Web Service Description Language (WSDL) and Web Application Description
Language (WADL) describe functional service characteristics
• Functional requirements: Requirements of the functionality which must be provided
(Functions, Data, Behavior, etc.)
• Non-functional requirements: Requirements of the circumstances under which the
functionality must be provided (e.g., reliability, performance, etc.)
• WS are distributed over the Internet
• WS make use of existing ubiquitous transport Internet protocols like HTTP
• By relying on the same well-understood transport mechanism as Web Content,
Web Services may leverage existing infrastructures and may cross corporate
firewalls.
Introduction to Service Oriented Computing
13
Functional vs. Non-Functional Service Characteristics
• Functional Service Characteristics
• Detail the operational characteristics that define the overall behavior of the
service
• How the service is invoked
• The location where it is invoked
• Syntax of exchanged messages, etc.
• Typically a question of the system design
• Non-Functional Service Characteristics
• Concentrate on service quality attributes
• Service metering and cost
• Performance metrics such as response time
• Security attributes, authorization, authentication, transactional integrity,
scalability, etc.
• Typically a question of the system architecture
Introduction to Service Oriented Computing
14
Tight versus loose coupling
Tight coupling Loose coupling
Physical coupling Direct physical link required Physical intermediary
Communication style Synchronous Asynchronous
Interaction pattern
OO-style navigation of
complex object trees
Data-Centric, Self-Contained
messages
Control of process logic
Central control of process
logic
Distributed logic components
Underlying platforms Homogeneous Heterogeneous
Service discovery and
binding
Statically bound services Dynamically bound services
Platform dependencies
Strong OS and programming
language dependency
OS- and programming language
independent
• Coupling refers to the degree to which software components depend upon each
other.
SOA
Introduction to Service-Oriented Computing
15
Web Services
▪ Types of Web Services
▪ SOAP/WSDL based
▪ Service interface is exposed through WSDL documents
▪ Message exchange using SOAP
▪ Client code may be generated from WSDL description
▪ Representational State Transfer (REST)
▪ Easy way to communicate with Web Services
▪ Resources are identified by URIs and their state is manipulated through HTTP
operations GET, POST, PUT, DELETE
▪ Rather a set of architectural principles, than a standard
Introduction to Service-Oriented Computing
Characterizing Web Services - Integration scenarios
▪ Within an organization
▪ Between business partners
16
CompanySupplier Customer
Goods/Services Goods/Services
Messages Messages
Legacy
application
ERP
application
Service
Service
Messages
Service
Service
Service
Service
Introduction to Service-Oriented Computing
Why Web Services?
▪ Interoperable
▪ connection of heterogeneous systems
▪ usage of common standards
▪ Economical
▪ no installation and tight integration
▪ recycling of components
▪ Automatic
▪ no human intervention necessary
▪ Accessible
▪ access to legacy systems
▪ access to internal applications
▪ Available
▪ on any device, every time, anywhere
▪ Goals
▪ solve integration problem
▪ complete automated infrastructure for, e.g., e-commerce
17
Introduction to Service-Oriented Computing
18
Service Oriented Architectures
▪ Service oriented architectures are an abstract pattern that applies to a
wide variety of Web services
▪ SOA is a loosely-coupled architecture designed to meet the business
needs of an organization
▪ SOA represent business functions as shared, reusable services
▪ SOA defines an architecture which usually consists of the following roles
and the contracts between those roles:
Service
Service
Requestor
Service
Provider
PublishFind
Bind
Introduction to Service-Oriented Computing
Operations in a Web Service Architecture
▪ Publish
▪ A service description needs to be published such that
▪ the service requestor can find it
▪ it is accessible
▪ Find
▪ The service requestor retrieves the service description
▪ directly
▪ by querying a service registry
▪ Bind
▪ The service requestor invokes or instantiates the interaction with the
service by using binding details in the service description to locate, contact,
and invoke the service.
19
Introduction to Service-Oriented Computing
Roles in a Web Service Architecture
business perspective technical perspective
service provider owner of the service
platform that hosts the
service
service requestor
business that requires
certain functionality
application that invokes or
interacts with the service
service registry
searchable registry of service descriptions
where service providers publish their service
descriptions
20
Introduction to Service-Oriented Computing
21
Layers in a SOA
Business domain
Business processes
Business services
Infrastructure 

services
Component-based

service realizations
Operational systems
Distribution
Purchasing
Order 

management Inventory
ERP Legacy ApplicationsCRM Databases
Introduction to Service-Oriented Computing
Web Service Technology Stack
22
HTTP, JMS, SMTP
XML
SOAP
WSDL
UDDI
WS-Reliability
Orchestration – BPEL4WS
Choreography – CDL4WS
WS-Security
Transactions
Coordination
Context
Management
Business
processes
Quality of
Service
Message
Transport
Description
Discovery
Introduction to Service-Oriented Computing
23
Standards in use
Service
Service
Requestor
Service
Provider
PublishFind
Bind
UDDI
WSDLWSDL
SOAP
Note, that finding and publishing a service is also realized using SOAP calls.
Introduction to Service-Oriented Computing
Standards of interest
▪ SOAP (by W3C)
▪ Originally from “Simple Object Access Protocol“
▪ Message exchange format
▪ WSDL (by W3C)
▪ “Web Service Description Language“
▪ Standard to describe what is exchanged between Web Service Provider
and Web Service Requestor
▪ UDDI (by OASIS)
▪ “Universal Description Discovery and Integration“
▪ Basis for a directory service
24
SOAP
25
Motivation
• Conventional distributed object communication protocols such as Java/
RMI had a symmetric requirement
• both ends of the communication link had to be implemented under the
same distributed object model
• e.g., in case of Java RMI, both ends must be implemented in Java, which
does the marshalling (transform Java object into the exchange format) and
unmarshalling (transform exchange format back to Java object) of objects
Client
program
Server

program
RMI
registry
Java Java
RMI RMI
SOAP
What is SOAP?
▪ SOAP once stood for 'Simple Object Access Protocol', but this acronym was
dropped with Version 1.2 of the standard
▪ SOAP is a protocol for exchanging structured information in a decentralized,
distributed environment and defines:
▪ an envelope that defines a framework for describing what is in a message and how
to process it
▪ a set of encoding rules for expressing instances of application-defined data types
▪ conventions for representing remote procedure calls and responses
▪ XML-based W3C Specification
▪ For inter-application communication
▪ SOAP describes how a message is formatted, but not how it is delivered
▪ A SOAP message must be embedded in a transport-level protocol
▪ Typically HTTP is used, however, SMTP, FTP and others may also be used
26
SOAP
27
Web Services communication and messaging network
SOAP is a network application protocol that is used to transfer messages
between service instances, described by WSDL interfaces.
TCP/IP stack
Transfer protocol (e.g., HTTP)
SOAP messages
WSDL interface WSDL interface
Web Service Web Service
SOAP
28
The two fundamental Web Service message exchange patterns
Sender
Sender Receiver
Receiver
Request message
Response message
Request message
SOAP
SOAP
SOAP
29
Structure of a SOAP message
▪ A SOAP envelope consists of an optional header and a
mandatory body
▪ All elements of a SOAP envelope are defined using
XML Schema
▪ Header contains information on how the message is to
be processed, e.g., routing and delivery, authentication
or authorization, transaction contexts, etc.
▪ The body element is mandatory and carries the
message payload
▪ The content of the header and the body element are
application defined and not part of the SOAP
standard
* . *
* *0
* *0 .
.
. * 10
SOAP
30
Example of a SOAP header with two header blocks
<?xml version="1.0" encoding="UTF-8"?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
…
<env:Header>

<tx:transaction-id 

xmlns:tx="http://www.transaction.com/transaction" 

env:mustUnderstand="true">
512
</tx:transaction-id>

<notary:token xmlns:notary="http://www.notary.com/token"
env:mustUnderstand="true">
RKEIK-DKEKW-DKIEL-DKKLK-WIEFK
</notary:token>

</env:Header>
…
</env:Envelope>
SOAP
Example SOAP Message
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<n:alertcontrol xmlns:n="http://example.org/alertcontrol">
<n:priority>1</n:priority>
<n:expires>2010-06-22T14:00:00-05:00</n:expires>
</n:alertcontrol>
</env:Header>
<env:Body>
<m:alert xmlns:m="http://example.org/alert">
<m:msg>Pick up Mary at school at 2pm</m:msg>
</m:alert>
</env:Body>
</env:Envelope>
(http://www.w3.org/TR/2007/REC-soap12-part1-20070427/)
Envelope
Header
Body
31
SOAP
32
SOAP nodes
▪ SOAP provides a distributed processing model using SOAP nodes
▪ A node may
▪ transmit a SOAP message
▪ receive a SOAP message
▪ process a SOAP message
▪ relay a SOAP message
▪ Use cases for SOAP nodes:
▪ Crossing trust domains
▪ Ensuring scalability
▪ Providing value-added services along the message path
Example for a SOAP
message path:
Initial
SOAP
sender
SOAP
inter-
mediary
SOAP
inter-
mediary
SOAP
receiver
SOAP
message
SOAP
message
SOAP
message
SOAP
The SOAP communication model supports four different styles
▪ 2 communication styles
▪ remote procedure calls (RPC)
▪ contains a procedure call
▪ document exchange
▪ contains only the actual message
▪ 2 encoding styles
▪ encoded
▪ data type encoded in message
▪ literal
▪ refers to XML Schema
33
Four potential styles:
- RPC/Literal
- Document/Literal
- RPC/Encoded
- Document/Encoded
Only two are relevant according to
the WS-I Basic Profile 1.0:
- document/literal
- RPC/literal
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
SOAP
SOAP body
▪ Carries the actual message payload
▪ Challenge to be solved in service oriented architectures
▪ Which format to chose for a specific payload?
34
SOAP
35
Excursus: RPC-style Web Services
• An RPC-style Web Service appears as a remote object to the client application
• Clients express their request as a method call with a set of parameters
• Messages are automatically serialized/deserialized back to the respective
objects
• Thus, RPC services are rather tightly coupled
Price for a
given product
Online price
response
Web service 

definitions
Application
program
Database
SOAP
36
Example of RPC-style SOAP message
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:m="http://www.supply.com/prices">
<env:Header>
<tx:Transaction-id xmlns:t="http://www.transaction.com/id"
env:mustUnderstand="true">
512
</tx:Transaction-id>
</env:Header>
<env:Body>
<m:GetProductPrice>
<product-id>4893248</product-id>
</m:GetProductPrice>
</env:Body>
</env:Envelope>
hard wired method name
SOAP
37
Excursus: Document-style Web Services
• Document-style Web Services are message driven
• The client invokes the service by sending a document (e.g., Quote Request)
rather than a discrete set of parameters (cf. RPC-style)
• The Web Service may (= synchronously) or may not (= asynchronously) return a
response message (e.g., Quote)
• In an asynchronous case the client can continue computation, without waiting for
an immediate response
Request for
quote
Quote
document
Database
Receive
Check
Send
Quote
Request
Quote
Web service 

definitions
Application program
SOAP
38
Example of document-style SOAP message
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<tx:Transaction-id xmlns:t="http://www.transaction.com/id"
env:mustUnderstand="true">
512
</tx:Transaction-id>
</env:Header>
<env:Body>
<p:PurchaseOrder orderDate="2010-05-06" xmlns:p="http://www.supply.com/order">
<p:from>
<p:accountNumber>239dsd</p:accountNumber>
</p:from>
<p:to>
<p:accountNumber>23540234</p:accountNumber>
</p:to>
<p:products> … </p:products>
</p:PurchaseOrder>
</env:Body>
</env:Envelope>
SOAP
39
Error handling
• SOAP uses the env:Fault element to communicate faults to the
originator of the faulty message or another SOAP node
• An env:Fault element has two mandatory sub-elements:
• env:Code
• env:Reason
• env:Detail (optional, for application specific information)
• In case an error occurred, a SOAP message with an env:Fault
element in the env:body is returned to the originator
SOAP
40
SOAP & HTTP
Send HTTP POST
with SOAP
message
Receive request
Decode request
message
Do something
Encode response
message
Send response
Receive HTTP
response with
SOAP response
Client Service listener ApplicationService proxy
Receive function call
Return value
SOAP
41
Summary: Advantages
• Simplicity
• Based on XML, highly structured, easy to parse
• Portability
• no dependency on the underlying platform
• Firewall-friendly due to HTTP
• Use of open standards
• Interoperability
• Because SOAP is based on XML and HTTP it is possibly the most widely
interoperable protocol to date
• Universal acceptance
• Resilience to changes
• Even if new versions of the specification are introduced, SOAP nodes may
provide backward compatibility
• However, if the service changes, the service clients must change as well!
SOAP
42
Summary: Disadvantages
• SOAP + XML over HTTP does not have a high-performance
• However, this is a trade-off compared to its interoperability features
• SOAP is stateless (as is HTTP)
• A requesting application must reintroduce itself to other applications when
more connections are required
• SOAP serializes by value and does not support serialization by
reference
• Multiple copies of an object will occur over time, containing state
information that is not synchronized with other dislocated copies of the
same object
43
• Start Java program “ArithmeticService”
• Access it under http://localhost:8080/arithmeticservice?wsdl
• Use SOAP-UI (http://www.soapui.org/) to access the service
https://github.com/pliegl/we2015
SOAP
Demo
WSDL
What is WSDL?
▪ Web Service Description Language
▪ XML-based specification schema for describing the public interface of a
Web Service
▪ WSDL serves as a contract between a service provider and a client,
invoking the service
▪ WSDL describes
▪ what a service does; i.e., the operations the service provides
▪ where it resides; i.e., details of the protocol specific address (URL)
▪ how to invoke it, i.e., details of the data formats and protocols necessary to
access the service's operations
44
WSDL
45
The two main parts of WSDL
• Service interface definition (abstract part)
• describes the general Web service interface structure
• the operations supported by the service
• the operation parameters
• and abstract data types
• Service implementation part (concrete part)
• binds the interface
• to a concrete network address
• to a specific protocol
• and to concrete data structures
• a Web service client may bind to such an implementation and invoke the
service
WSDL
46
WSDL specification
types
messages
operations
port types
bindings
services
and ports
WSDL specification
abstract part
concrete part
<definitions>


<types>

data type definitions

</types>



<message>

definition of the data being communicated

</message>



<portType>

<operation>
set of operations
</operation>

</portType>



<binding>

protocol and data format specification

</binding>

<service>
location of the service
</service>


</definitions>
WSDL
WSDL Elements I
▪ <definitions>: WSDL root element
▪ <types>: Container for data type definitions used by the Web Service
▪ Option A: Define a local XML Schema for parameter data types
▪ Option B: Reference one or more existing external XML Schemas
▪ Option C: Combination of Option A and Option B
▪ <message>: Definition of the messages, used by the Web Service. The
type of a message is defined in <types>
▪ <portType>: Logical grouping of abstract <operations> which are
supported by one or more endpoints
▪ <operation>: Operation signatures and I/O messages, defined in
<message>. Consists of <input>, <output> and <fault> messages
47
WSDL
WSDL Elements II
▪ <binding>: Define the message format and the protocol details for each
port type
▪ <soap:binding>: Defines the SOAP style (RPC or document) and the SOAP
protocol to use (usually HTTP)
▪ <operation>: Defines each of the concrete operations, which the
referenced port type exposes. For each operation the corresponding SOAP
action is defined. Furthermore, it is defined how the input and output is
encoded (literal or encoded). Default is literal.
▪ <service>: Defines the <port>s supported by the Web Service.
▪ <port>: Refers to an existing <binding> and via the <binding> to a
<portType>
▪ <soap:address>: Defines the location, where the service may be accessed.
(i.e., the URL)
48
WSDL
49
Conceptual overview
• operation
• operation
• operation
Interface
• operation
• operation
• operation
Interface
Resource
end point 1 end point 4 end point 5 end point 6
Messages
binding 1 binding 2 binding 3 binding 4 binding 5 binding 6
<portType>
<operation>
<binding>
<port>
<service>
<binding>
end point 2 end point 3
<portType>
<operation>
WSDL
Example (1/5)
▪ Assume we want to provide the following functions via a Web Service
public class MyWebService {
public String greet( String name ) {

return "Hello " + name + "!";

}

public int addInt(int n1, int n2 ) {

return n1+n2;
}
}
▪ Then we obtain the following WSDL-document:
50
WSDL
Example (2/5)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<definitions targetNamespace="http://endpoint.myws/" name="MyWebServiceService"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://endpoint.myws/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://
schemas.xmlsoap.org/wsdl/soap/">
<types/>
<message name="addIntRequest">
<part name="n1" type="xsd:int"/>
<part name="n2" type="xsd:int"/>
</message>
<message name="addIntResponse">
<part name="sum" type="xsd:int"/>
</message>
<message name="greetRequest">
<part name="arg0 " type="xsd:string"/>
</message>
<message name="greetResponse">
<part name="return" type="xsd:string"/>
</message>
51
WSDL
Example (3/5)
<portType name="MyWebService">
<operation name="addInt" parameterOrder="n1 n2">
<input message="tns:addIntRequest"/>
<output message="tns:addIntResponse"/>
</operation>
<operation name="greet" parameterOrder="arg0">
<input message="tns:greetRequest"/>
<output message="tns:greetResponse"/>
</operation>
</portType>
52
Name of the portType
WSDL
Example (4/5)
<binding name="MyWebServicePortBinding"
type="tns:MyWebService">
<soap:binding
transport=http://schemas.xmlsoap.org/soap/http
style="rpc"/>
<operation name="addInt">
<soap:operation soapAction="http://localhost:8080/addInteger"/>
<input>
<soap:body use="literal"
namespace="http://endpoint.myws/"/>
</input>
<output>
<soap:body use="literal"
namespace="http://endpoint.myws/"/>
</output>
</operation>
<operation name="greet">
…
</operation>
</binding>
53
Arbitrary name Points to the port type for the
binding
May be used to identify a
certain SOAP Request
WSDL
Example (4/5)
<binding name="MyWebServicePortBinding"
type="tns:MyWebService">
<soap:binding
transport=http://schemas.xmlsoap.org/soap/http
style="rpc"/>
<operation name="addInt">
<soap:operation soapAction="http://localhost:8080/addInteger"/>
<input>
<soap:body use="literal"
namespace="http://endpoint.myws/"/>
</input>
<output>
<soap:body use="literal"
namespace="http://endpoint.myws/"/>
</output>
</operation>
<operation name="greet">
…
</operation>
</binding>
54
Document:
• content of <soap:Body> is specified by XML Schema defined in the
<wsdl:type> section.
• Does not need to follow specific SOAP conventions - the message is
sent as one "document" in the <soap:Body> element.
• No additional formatting rules have to be considered. Document style
is the default choice.
RPC:
• The structure of an RPC style <soap:Body> element needs to comply
with the rules specified in detail in Section 7 of the SOAP 1.1
specification.
• According to these rules, <soap:Body> may contain only one element
that is named after the operation, and all parameters must be
represented as sub-elements of this wrapper element.
WSDL
Example (5/5)
<service name="MyWebServiceService">
<port name="MyWebServicePort"
binding="tns:MyWebServicePortBinding">
<soap:address location="http://localhost:8080"/>
</port>
</service>
</definitions>
55
WSDL
56
Messaging Patterns
Sender
Receiver
Sender
Receiver
Sender
Receiver
Sender
Receiver
One-way messaging
SOAP request message
Notification messaging
SOAP request message
Solicit/response messaging
SOAP request message
SOAP response message
Request/response messaging
SOAP request message
SOAP response message
1:
2:
3:
4:
WSDL
57
1: One way messaging
• The service endpoint receives a message, but does not send a response
• The <operation> element is declared with a single <input> element, but no
<output> element
• Like a “fire and forget” mechanism
• A one-way-operation is typically thought of as asynchronous messaging
<!– portType element describing the abstract interface of a Web Service -->
<wsdl:portType name="SubmitPurchaseOrderPortType">
<wsdl:operation name="SubmitPurchaseOrder">
<wsdl:input name="order" message="tns:SubmitPurchaseOrderMessage">
</wsdl:input>
</wsdl:operation>
</wsdl:portType>
Sender
Receiver
One-way messaging
SOAP message
WSDL
58
2: Request/Response messaging
• The service endpoint receives a message and returns a message in response
• If an <operation> element is declared with a single <input> element
followed by a single <output> element, it defines a request/response
operation
<!– portType element describing the abstract interface of a Web Service -->
<wsdl:portType name="SubmitPurchaseOrderPortType">
<wsdl:operation name="SubmitPurchaseOrder">
<wsdl:input name="order" message="tns:SubmitPurchaseOrderMessage"/>
<wsdl:output name="orderResponse" message="tns:PurchaseOrderResponseMsg"/>
</wsdl:operation>
</wsdl:portType>
Sender
Receiver
Request/response messaging
SOAP request
SOAP response
WSDL
59
3: Notification messaging
• An operation in which the service endpoint sends a message to the client, but
does not expect to receive a response is called a notification operation
• This type of operation is used if services need to notify clients of events
• A Web Service using the notification messaging pattern follows the push model of
distributed computing (the client has registered with the Web service to receive
messages about an event)
• Is the opposite of the one-way messaging pattern
• The <operation> element contains an <output> tag, but no <input> message
definitions
<!– portType element describing the abstract interface of a Web Service -->
<wsdl:portType name="FloodWarningPortType">
<wsdl:operation name="FloodWarning">
<wsdl:output message="tns:FloodWarningMsg"/>
</wsdl:operation>
</wsdl:portType>
Sender
Receiver
Notification messaging
SOAP notification
WSDL
60
4: Solicit/response messaging
• An operation in which the service endpoint sends a message and expects to
receive an answer-message in response
• Is the opposite of the request/response messaging pattern
• Is similar to notification messaging, except that the client is expected to respond
to the Web Service
• As with notification messaging, clients of the solicit/response Web services must
subscribe to the service in order to receive messages
• In the <operation> element first an <output> tag and then an <input>
tag is declared
<!– portType element describing the abstract interface of a Web Service -->
<wsdl:portType name="AnythingNewInYourBusinessPortType">
<wsdl:operation name="AnythingNew">
<wsdl:output message="tns:AnyThingNewRequest"/>
<wsdl:input message="tns:MyNewsResponse"/>
</wsdl:operation>
</wsdl:portType>
Sender
Receiver
Solicit/response messaging
SOAP request message
SOAP answer message
WSDL
61
Demo „Arithmetic Service“
UDDI
What is UDDI?
▪ Universal Description Discovery and Integration
▪ UDDI defines a scheme for publishing and finding Web services of
business entities
▪ “Yellow Pages for Web Services”
▪ Thought as standard for one XML-directory for Web services
▪ Three main pillars of a UDDI registry
▪ “white pages”: address, contact, and known identifiers
▪ “yellow pages”: industrial classification
▪ “green pages”: meta information on services (reference to service
description in WSDL)
▪ In 2005 IBM, Microsoft, and SAP closed their existing UDDI registries
62
UDDI
63
Reasons why UDDI never gained momentum
• Discovery model of UDDI is very limited
• No complex queries on potential services possible
• Annotation mechanism for service definitions is limited
• Pure technical focus (service definitions)
• No integration of product data offered by a company
• Missing B2B reference processes
• Lack of quality and validity of entries
• Approach too generic (world-wide)
• Too many “fun-entries”
Although the public success of UDDI is very limited, UDDI may still leverage
benefits in an intra-organizational context.
Java API for XML Web Services (JAX-WS)
Overview
▪ Java Specification Request 224: Java API for XML-Based Web Services
(JAX-WS): https://www.jcp.org/en/jsr/detail?id=224
▪ Web Services with JAX-WS are POJOs, enriched with annotations:
▪ @WebService
▪ @SOAPBinding
▪ @WebMethod
▪ @WebParam
▪ @WebResult
▪ @OneWay
▪ XML processing using JAX-B (Java Architecture for XML Binding)
▪ Marshalling: Java Object ‣ XML instance
▪ Unmarshalling: XML Instance ‣ Java Object
▪ Java provides a simple mini server
64
Java API for XML Web Services (JAX-WS)
65
Application development approaches
• The WSDL to Java approach (contract first)
• Defines the WSDL first
• Use of tools such as wsimport to generate portable web service artifacts
• Should be used for complex Web Service projects where multiple
stakeholders and partners are involved.
• The Java to WSDL approach (contract last)
• Create a Service Endpoint Interface (SEI) as Java source files
• Use the source files as inputs to generate the WSDL and other required
portable artifacts (using wsgen)
• May be used for smaller Web Service projects with a limited set of
requirements
Java API for XML Web Services (JAX-WS)
66
wsimport 101
• Use the WSDL of an existing Service to generate a Java Web Service
Client
d path to the .class files
keep flag indicating that the source files shall be kept
s path for the source files
p Java package for the generated classes
wsimport –d path/to/binaries –keep –s path/to/source –p
my.java.package http://www.urltoservice.com?wsdl
Java API for XML Web Services (JAX-WS)
An Example
67
import javax.jws.WebMethod;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
@WebService(name="ArithmeticService")
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class ArithmeticService {
@WebMethod(operationName="addFunction")
@WebResult(name = "sum")
public int add(int addend_a, int addend_b) {
return addend_a + addend_b;
}
@WebMethod(operationName="subtractFunction")
@WebResult(name = "difference")
public int subtract(int minuend, int subtrahend) {
return minuend - subtrahend;
}
}
Java API for XML Web Services (JAX-WS)
Deploying the Example
68
import javax.xml.ws.Endpoint;
public class RunService {
public static void main (String [] args) {
Endpoint endpoint = Endpoint.publish("http://localhost:8080/
arithmeticservice", new 

ArithmeticService());
}
}
Analyze the generated WSDL by opening



http://localhost:8080/arithmeticservice?wsdl
Further WS-Standards
69
▪ WS-Notification
▪ WS-Transfer
▪ WS-PolicyAssertions
▪ WS-Resource Framework
▪ WS-Security
▪ WS-SecureConversation
▪ WS-Policy
▪ WS-Trust
▪ WS-Federation
▪ WS-Privacy
▪ WS-Test
▪ WS-Eventing
▪ WS-MakeConnection
▪ …
WS-* standard wrap up
• WS-death star
• Lots of different WS-* specifications have been 

developed

• Hard to cope with these standards, even with

a software stack at hand
• While useful on an enterprise level, the WS-* approach is an over-
engineering for smaller, more lightweight projects
• Alternative approaches using HTTP with plain XML or JSON are on the
rise
70
RESTful Web Services
71
Introduction
• Acronym for REpresentational State Transfer
• Based on the dissertation of Dr. Fielding http://www.ics.uci.edu/~fielding/
pubs/dissertation/top.htm
• Defines a set of architectural principles
• Centered around the concept of resources and the manipulation of a
resource’s state
• Basic design principles
• REST server provides access to resources
• REST client manipulates the resources using HTTP methods
• Statelessness (I did not say stateless applications!)
• Directory-like structure of URIs for addressing resources
• Transfer of XML or JSON data in order to alter the state of resources
RESTful Web Services
72
Use of HTTP methods
• Through HTTP methods resources may be accessed, modified,
created, deleted
• GET (retrieve a resource)
• PUT (change the state of a resource, i.e., update a resource)
• POST (create a new resource)
• DELETE (remove a resource)
• Example: Rename user Alice to Bob
PUT /users/Alice HTTP/1.1
Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<id>4711</id>
<name>Bob</name>
</user>
RESTful Web Services
73
Stateless 1/2
• Consider the following stateful design for accessing users in chunks of
10 record sets
Web
Service
Client
GET /users/getNext?sessionID=432
<response>
<user id="1">User 1</user>
<user id="2">User 2</user>
….
</response>
currentChunk = 

getCurrentChunkForUser(432);
updateChunk(currentChunk,432);
return currentChunk;
• Server must hold current state and client/server must use session
mechanism in order to allow correct correlation to current state
• Bad for clustered environments (session data synchronization across cluster)
• Session overhead can become an issue (memory consumption)
• java.io.NotSerializableException issues (in case of bad session design)
RESTful Web Services
74
Stateless 2/2
• Consider the following stateless design for accessing users in chunks
of 10 record sets
Web
Service
Client
GET /users/chunk=4
<response chunk="4" nextChunk="">
<user id="1">User 1</user>
<user id="2">User 2</user>
….
</response>
getChunk(4)
• Responsibility for state management is entirely on the client's side
• The server's response must allow the client to maintain the state, i.e.,
the response must contain information necessary for state management
(see above)
RESTful Web Services
75
Directory-like structure of URIs
• URIs are used to address resources (in order to change their state)
• In the context of RESTful Services URIs might be considered as self-
documenting interfaces
• A resulting URI structure might be
• http://www.mycompany.com/users
• http://www.mycompany.com/users/internal
• http://www.mycompany.com/users/internal/34
• http://www.mycompany.com/users/external
• http://www.mycompany.com/users/external/432
• http://www.mycompany.com/users/external/premium
• http://www.mycompany.com/users/external/regular
RESTful Web Services
76
Transfer of XML or JSON data
• Resource representation reflects the current state of a resource
• What values are currently stored for an entry x at the time the client accesses
the resource
• E.g., 'request user xyz' returns the current state of the resource 

user xyz at time t
• Client applications should be able to request the content in the format which
best fits their needs
• Use of MIME-Types in the HTTP Accept Header
• e.g., application/json, application/xml, application/xhtml+xml
• Also known as "content negotiation"
• JSON (JavaScript Object Notation)
• Lightweight data interchange format
• Easy for humans to read and write and easy for machines to parse and
generate
• Further information: http://www.json.org/
RESTful Web Services
77
JSON example: person object
{
"name" : "John Doe",
"age" : 43,
"address" : {
"street" : "Favoritenstraße 9-11",
"city" : "Vienna",
"state": "AT"
},
"phoneNumbers" : [
{
"type" : "business",
"number" : "+43 58801 18800"
},
{
"type" : "mobile",
"number" : "+43 664 18800188"
}
]
}
Address object
Array
JAX-RS - Java API for RESTful Web Services

Building you own RESTful Services
78
▪ Java Specification Request 339: The Java API for RESTful Web
Services: https://jcp.org/en/jsr/detail?id=339
▪ Sample implementation: Java Jersey: https://jersey.java.net/
▪ Web Services with JAX-WS are POJOs, enriched with annotations:
▪ @Path
▪ @GET, @PUT, @POST, @DELETE,…
▪ @Produces
▪ @Consumes
▪ …
@Path("/users/{username}")
public class UserResource {
@GET
@Produces("text/xml")
public String getUser(@PathParam("username") String userName) {
...
}
}
JAX-RS - Java API for RESTful Web Services

HEAD and OPTION Request
79
▪ HTTP HEAD: invokes the implemented GET method (if present), but
does not return the response entity
▪ HTTP OPTION:
▪ sets the allow response header to the HTTP methods, supported by
the resource
▪ in addition the description of the RESTful Web Service using WADL
(Web Application Description Language) is returned
<application xmlns="http://research.sun.com/wadl/2006/10">
<doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 1.8" />
<resources base="http://localhost:8080/we-restful-service/rest/">
<resource path="students">
<method id="getStudentsXML" name="GET">
<response>
<representation mediaType="application/xml" />
</response>
</method>
<method id="getStudentsJSON" name="GET">
<response>
<representation mediaType="application/json" />
</response>
</method> …
RESTful Web Services
80
Demo
• Accessing SAP’s repositories on GitHub
• e.g., https://api.github.com/users/SAP/repos
• Accessing sample student application
• see https://github.com/pliegl/we2015 for further details
Resource POST

create
GET

read
PUT
update
DELETE
delete
/students Create a new
student
List all students Bulk update a
set of students
Delete all
students
/student/1 Error Show student
with register
number 1
If exists update
student with
register number
1
If not error
Delete student
with register
number 1
http://localhost:8080/we-restful-service/rest/students
Summary
▪ Web services support interoperable machine-to-machine interaction
▪ Web services may be part of Web applications, but do not have a GUI
themselves
▪ Web services are used for integration purposes
▪ 3 core standards for Web services
▪ SOAP
▪ WSDL
▪ UDDI
▪ RESTful services are another powerful architectural style for realizing
machine-to-machine interaction
81
Interesting Literature & Tools
82
• Michael Papazoglou, Web Services: Principles and
Technology, Prentice Hall, 2008
• recommended - this presentation is mostly based on
this book
• Martin Kalin, Java Web Services, O'Reilly, 2009
• Java-specific perspective on Web Services
• Eben Hewitt, Java SOA Cookbook, O'Reilly, 2009
• Java-specific perspective on SOA – 

covers additional concepts such as 

service orchestration, etc. as well
• www.soapui.org/
• Useful for Web Service testing
Interesting Literature & Tools – RESTful Web Services
83
• Leonard Richardson and Sam Ruby, RESTful Web
Services, O'Reilly, 2007
• Brian Mulloy, Web API Design – Crafting interfaces
that developers love, apigee
• https://pages.apigee.com/rs/apigee/images/api-
design-ebook-2012-03.pdf
• Cesare Pautasso and Erik Wilde, Tutorial Design
Principles, Patterns and Emerging Technologies for
RESTful Web Services
• http://dret.net/netdret/docs/rest-icwe2010/
• Google Chrome Advanced REST client
• https://chrome.google.com/webstore/detail/
advanced-rest-client/
hgmloofddffdnphfgcellkdfbfbjeloo

More Related Content

What's hot

What is REST API? REST API Concepts and Examples | Edureka
What is REST API? REST API Concepts and Examples | EdurekaWhat is REST API? REST API Concepts and Examples | Edureka
What is REST API? REST API Concepts and Examples | Edureka
Edureka!
 
Spring boot Introduction
Spring boot IntroductionSpring boot Introduction
Spring boot Introduction
Jeevesh Pandey
 
servlet in java
servlet in javaservlet in java
servlet in java
sowfi
 
What is an API?
What is an API?What is an API?
What is an API?
Muhammad Zuhdi
 
Kotlin for Android Development
Kotlin for Android DevelopmentKotlin for Android Development
Kotlin for Android Development
Speck&Tech
 
Spring boot introduction
Spring boot introductionSpring boot introduction
Spring boot introduction
Rasheed Waraich
 
RAML
RAMLRAML
Java Servlets
Java ServletsJava Servlets
Java Servlets
BG Java EE Course
 
Java servlets
Java servletsJava servlets
Java servlets
lopjuan
 
Introduction to REST - API
Introduction to REST - APIIntroduction to REST - API
Introduction to REST - API
Chetan Gadodia
 
Simple object access protocol(soap )
Simple object access protocol(soap )Simple object access protocol(soap )
Simple object access protocol(soap )
balamurugan.k Kalibalamurugan
 
Servlets
ServletsServlets
Intro to web services
Intro to web servicesIntro to web services
Intro to web services
Neil Ghosh
 
Java 8 features
Java 8 featuresJava 8 features
Java 8 features
NexThoughts Technologies
 
introduction about REST API
introduction about REST APIintroduction about REST API
introduction about REST API
AmilaSilva13
 
Introduction to Spring Boot
Introduction to Spring BootIntroduction to Spring Boot
Introduction to Spring Boot
Purbarun Chakrabarti
 
Login and Registration form using oop in php
Login and Registration form using oop in phpLogin and Registration form using oop in php
Login and Registration form using oop in php
herat university
 
Deep Dive into Kubernetes - Part 1
Deep Dive into Kubernetes - Part 1Deep Dive into Kubernetes - Part 1
Deep Dive into Kubernetes - Part 1
Imesh Gunaratne
 
Solid principles
Solid principlesSolid principles
Solid principles
Declan Whelan
 
Rest api standards and best practices
Rest api standards and best practicesRest api standards and best practices
Rest api standards and best practices
Ankita Mahajan
 

What's hot (20)

What is REST API? REST API Concepts and Examples | Edureka
What is REST API? REST API Concepts and Examples | EdurekaWhat is REST API? REST API Concepts and Examples | Edureka
What is REST API? REST API Concepts and Examples | Edureka
 
Spring boot Introduction
Spring boot IntroductionSpring boot Introduction
Spring boot Introduction
 
servlet in java
servlet in javaservlet in java
servlet in java
 
What is an API?
What is an API?What is an API?
What is an API?
 
Kotlin for Android Development
Kotlin for Android DevelopmentKotlin for Android Development
Kotlin for Android Development
 
Spring boot introduction
Spring boot introductionSpring boot introduction
Spring boot introduction
 
RAML
RAMLRAML
RAML
 
Java Servlets
Java ServletsJava Servlets
Java Servlets
 
Java servlets
Java servletsJava servlets
Java servlets
 
Introduction to REST - API
Introduction to REST - APIIntroduction to REST - API
Introduction to REST - API
 
Simple object access protocol(soap )
Simple object access protocol(soap )Simple object access protocol(soap )
Simple object access protocol(soap )
 
Servlets
ServletsServlets
Servlets
 
Intro to web services
Intro to web servicesIntro to web services
Intro to web services
 
Java 8 features
Java 8 featuresJava 8 features
Java 8 features
 
introduction about REST API
introduction about REST APIintroduction about REST API
introduction about REST API
 
Introduction to Spring Boot
Introduction to Spring BootIntroduction to Spring Boot
Introduction to Spring Boot
 
Login and Registration form using oop in php
Login and Registration form using oop in phpLogin and Registration form using oop in php
Login and Registration form using oop in php
 
Deep Dive into Kubernetes - Part 1
Deep Dive into Kubernetes - Part 1Deep Dive into Kubernetes - Part 1
Deep Dive into Kubernetes - Part 1
 
Solid principles
Solid principlesSolid principles
Solid principles
 
Rest api standards and best practices
Rest api standards and best practicesRest api standards and best practices
Rest api standards and best practices
 

Viewers also liked

RESTful Web Services
RESTful Web ServicesRESTful Web Services
RESTful Web Services
Christopher Bartling
 
Soap vs rest
Soap vs restSoap vs rest
Soap vs rest
Antonio Severien
 
SOAP-based Web Services
SOAP-based Web ServicesSOAP-based Web Services
SOAP-based Web Services
Katrien Verbert
 
Introduction to Service Oriented Architectures, SOAP/WSDL Web Services and RE...
Introduction to Service Oriented Architectures, SOAP/WSDL Web Services and RE...Introduction to Service Oriented Architectures, SOAP/WSDL Web Services and RE...
Introduction to Service Oriented Architectures, SOAP/WSDL Web Services and RE...
ecosio GmbH
 
Webservices
WebservicesWebservices
Webservices
Gerard Sylvester
 
Web Services Tutorial
Web Services TutorialWeb Services Tutorial
Web Services Tutorial
Lorna Mitchell
 
Web Services
Web ServicesWeb Services
Web Services
Katrien Verbert
 
Web Services (SOAP, WSDL, UDDI)
Web Services (SOAP, WSDL, UDDI)Web Services (SOAP, WSDL, UDDI)
Web Services (SOAP, WSDL, UDDI)
Peter R. Egli
 
Jax ws
Jax wsJax ws
Jax ws
F K
 
Дорога к микросервисной архитектуре
Дорога к микросервисной архитектуреДорога к микросервисной архитектуре
Дорога к микросервисной архитектуре
CodeFest
 
Panduan microsoft exel 2007
Panduan microsoft exel 2007Panduan microsoft exel 2007
Panduan microsoft exel 2007
Adre Ridwan
 
myPorfolio
myPorfoliomyPorfolio
myPorfolio
Huy Trong Le
 
FPT Arena Multimedia - My Hill Website project
FPT Arena Multimedia - My Hill Website projectFPT Arena Multimedia - My Hill Website project
FPT Arena Multimedia - My Hill Website project
Lan Thien
 
Web services wsdl
Web services wsdlWeb services wsdl
Web services wsdl
princeirfancivil
 
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESB
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESBАрхитектура масштабируемых приложений. Микросервисы, CQRS, ESB
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESB
Pavel Treshnikov
 
Web services uddi
Web services uddiWeb services uddi
Web services uddi
Rajkattamuri
 
Web services
Web servicesWeb services
Web services
Peter R. Egli
 
Микросервисные архитектуры и немного жизненного опыта
Микросервисные архитектуры и немного жизненного опытаМикросервисные архитектуры и немного жизненного опыта
Микросервисные архитектуры и немного жизненного опыта
Elena Grahovac
 
JAX-RS 2.0: RESTful Web Services
JAX-RS 2.0: RESTful Web ServicesJAX-RS 2.0: RESTful Web Services
JAX-RS 2.0: RESTful Web Services
Arun Gupta
 
04 Архитектура информационных систем. Архитектурные модели и стили
04 Архитектура информационных систем. Архитектурные модели и стили04 Архитектура информационных систем. Архитектурные модели и стили
04 Архитектура информационных систем. Архитектурные модели и стили
Edward Galiaskarov
 

Viewers also liked (20)

RESTful Web Services
RESTful Web ServicesRESTful Web Services
RESTful Web Services
 
Soap vs rest
Soap vs restSoap vs rest
Soap vs rest
 
SOAP-based Web Services
SOAP-based Web ServicesSOAP-based Web Services
SOAP-based Web Services
 
Introduction to Service Oriented Architectures, SOAP/WSDL Web Services and RE...
Introduction to Service Oriented Architectures, SOAP/WSDL Web Services and RE...Introduction to Service Oriented Architectures, SOAP/WSDL Web Services and RE...
Introduction to Service Oriented Architectures, SOAP/WSDL Web Services and RE...
 
Webservices
WebservicesWebservices
Webservices
 
Web Services Tutorial
Web Services TutorialWeb Services Tutorial
Web Services Tutorial
 
Web Services
Web ServicesWeb Services
Web Services
 
Web Services (SOAP, WSDL, UDDI)
Web Services (SOAP, WSDL, UDDI)Web Services (SOAP, WSDL, UDDI)
Web Services (SOAP, WSDL, UDDI)
 
Jax ws
Jax wsJax ws
Jax ws
 
Дорога к микросервисной архитектуре
Дорога к микросервисной архитектуреДорога к микросервисной архитектуре
Дорога к микросервисной архитектуре
 
Panduan microsoft exel 2007
Panduan microsoft exel 2007Panduan microsoft exel 2007
Panduan microsoft exel 2007
 
myPorfolio
myPorfoliomyPorfolio
myPorfolio
 
FPT Arena Multimedia - My Hill Website project
FPT Arena Multimedia - My Hill Website projectFPT Arena Multimedia - My Hill Website project
FPT Arena Multimedia - My Hill Website project
 
Web services wsdl
Web services wsdlWeb services wsdl
Web services wsdl
 
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESB
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESBАрхитектура масштабируемых приложений. Микросервисы, CQRS, ESB
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESB
 
Web services uddi
Web services uddiWeb services uddi
Web services uddi
 
Web services
Web servicesWeb services
Web services
 
Микросервисные архитектуры и немного жизненного опыта
Микросервисные архитектуры и немного жизненного опытаМикросервисные архитектуры и немного жизненного опыта
Микросервисные архитектуры и немного жизненного опыта
 
JAX-RS 2.0: RESTful Web Services
JAX-RS 2.0: RESTful Web ServicesJAX-RS 2.0: RESTful Web Services
JAX-RS 2.0: RESTful Web Services
 
04 Архитектура информационных систем. Архитектурные модели и стили
04 Архитектура информационных систем. Архитектурные модели и стили04 Архитектура информационных систем. Архитектурные модели и стили
04 Архитектура информационных систем. Архитектурные модели и стили
 

Similar to Introduction to SOAP/WSDL Web Services and RESTful Web Services

Java Web Services [1/5]: Introduction to Web Services
Java Web Services [1/5]: Introduction to Web ServicesJava Web Services [1/5]: Introduction to Web Services
Java Web Services [1/5]: Introduction to Web Services
IMC Institute
 
Week2 cloud computing week2
Week2 cloud computing week2Week2 cloud computing week2
Week2 cloud computing week2
Ankit Gupta
 
Web services
Web servicesWeb services
Web services
Divya Tiwari
 
nptl cc video.pptx
nptl cc video.pptxnptl cc video.pptx
nptl cc video.pptx
MunmunSaha7
 
Service Oriented Architecture
Service Oriented ArchitectureService Oriented Architecture
Service Oriented Architecture
Mohamed Zaytoun
 
Web Services Foundation Technologies
Web Services Foundation TechnologiesWeb Services Foundation Technologies
Web Services Foundation Technologies
Pankaj Saharan
 
Cloud description
Cloud descriptionCloud description
Cloud description
thanuambika
 
Unit-5_2 PPT on Distributed Web based System.pdf
Unit-5_2 PPT on Distributed Web based System.pdfUnit-5_2 PPT on Distributed Web based System.pdf
Unit-5_2 PPT on Distributed Web based System.pdf
rameshwarchintamani
 
Introduction to Web Services
Introduction to Web ServicesIntroduction to Web Services
Introduction to Web Services
Thanachart Numnonda
 
CS-802 Act-1.ppt
CS-802 Act-1.pptCS-802 Act-1.ppt
CS-802 Act-1.ppt
AnushkaChauhan68
 
Integration with dynamics ax 2012
Integration with dynamics ax 2012Integration with dynamics ax 2012
Integration with dynamics ax 2012
Ali Raza Zaidi
 
SOA - Unit 1 - Introduction to SOA with Web Services
SOA - Unit   1 - Introduction to SOA with Web ServicesSOA - Unit   1 - Introduction to SOA with Web Services
SOA - Unit 1 - Introduction to SOA with Web Services
hamsa nandhini
 
Web service implementation
Web service implementationWeb service implementation
Web service implementation
Yatindra Sahu
 
Ch19
Ch19Ch19
introduction-to-cloud-computing
introduction-to-cloud-computingintroduction-to-cloud-computing
introduction-to-cloud-computing
ssuserc27607
 
Lecture 1 - Introduction to Cloud Computing.pptx
Lecture 1 - Introduction to Cloud Computing.pptxLecture 1 - Introduction to Cloud Computing.pptx
Lecture 1 - Introduction to Cloud Computing.pptx
HuyLc16
 
4582349.ppt
4582349.ppt4582349.ppt
4582349.ppt
ahmad21315
 
Moran wsmx
Moran wsmxMoran wsmx
Moran wsmx
nishant kumar
 
Tutorial Webservices
Tutorial WebservicesTutorial Webservices
Tutorial Webservices
Fabian Lopez
 
Chapter_1_-_Introduction_to_Cloud_Computing.pptx
Chapter_1_-_Introduction_to_Cloud_Computing.pptxChapter_1_-_Introduction_to_Cloud_Computing.pptx
Chapter_1_-_Introduction_to_Cloud_Computing.pptx
SushmithaNatraj1
 

Similar to Introduction to SOAP/WSDL Web Services and RESTful Web Services (20)

Java Web Services [1/5]: Introduction to Web Services
Java Web Services [1/5]: Introduction to Web ServicesJava Web Services [1/5]: Introduction to Web Services
Java Web Services [1/5]: Introduction to Web Services
 
Week2 cloud computing week2
Week2 cloud computing week2Week2 cloud computing week2
Week2 cloud computing week2
 
Web services
Web servicesWeb services
Web services
 
nptl cc video.pptx
nptl cc video.pptxnptl cc video.pptx
nptl cc video.pptx
 
Service Oriented Architecture
Service Oriented ArchitectureService Oriented Architecture
Service Oriented Architecture
 
Web Services Foundation Technologies
Web Services Foundation TechnologiesWeb Services Foundation Technologies
Web Services Foundation Technologies
 
Cloud description
Cloud descriptionCloud description
Cloud description
 
Unit-5_2 PPT on Distributed Web based System.pdf
Unit-5_2 PPT on Distributed Web based System.pdfUnit-5_2 PPT on Distributed Web based System.pdf
Unit-5_2 PPT on Distributed Web based System.pdf
 
Introduction to Web Services
Introduction to Web ServicesIntroduction to Web Services
Introduction to Web Services
 
CS-802 Act-1.ppt
CS-802 Act-1.pptCS-802 Act-1.ppt
CS-802 Act-1.ppt
 
Integration with dynamics ax 2012
Integration with dynamics ax 2012Integration with dynamics ax 2012
Integration with dynamics ax 2012
 
SOA - Unit 1 - Introduction to SOA with Web Services
SOA - Unit   1 - Introduction to SOA with Web ServicesSOA - Unit   1 - Introduction to SOA with Web Services
SOA - Unit 1 - Introduction to SOA with Web Services
 
Web service implementation
Web service implementationWeb service implementation
Web service implementation
 
Ch19
Ch19Ch19
Ch19
 
introduction-to-cloud-computing
introduction-to-cloud-computingintroduction-to-cloud-computing
introduction-to-cloud-computing
 
Lecture 1 - Introduction to Cloud Computing.pptx
Lecture 1 - Introduction to Cloud Computing.pptxLecture 1 - Introduction to Cloud Computing.pptx
Lecture 1 - Introduction to Cloud Computing.pptx
 
4582349.ppt
4582349.ppt4582349.ppt
4582349.ppt
 
Moran wsmx
Moran wsmxMoran wsmx
Moran wsmx
 
Tutorial Webservices
Tutorial WebservicesTutorial Webservices
Tutorial Webservices
 
Chapter_1_-_Introduction_to_Cloud_Computing.pptx
Chapter_1_-_Introduction_to_Cloud_Computing.pptxChapter_1_-_Introduction_to_Cloud_Computing.pptx
Chapter_1_-_Introduction_to_Cloud_Computing.pptx
 

Recently uploaded

DASH, presented by Elly Tawhai at PacNOG 33
DASH, presented by Elly Tawhai at PacNOG 33DASH, presented by Elly Tawhai at PacNOG 33
DASH, presented by Elly Tawhai at PacNOG 33
APNIC
 
University of California, Riverside diploma
University of California, Riverside diplomaUniversity of California, Riverside diploma
University of California, Riverside diploma
eufdev
 
Best CSS Animation Libraries for Web Developers
Best CSS Animation Libraries for Web DevelopersBest CSS Animation Libraries for Web Developers
Best CSS Animation Libraries for Web Developers
Shrestha Raaz
 
Female Service Girls Call Delhi 9873940964 Provide Best And Top Girl Service ...
Female Service Girls Call Delhi 9873940964 Provide Best And Top Girl Service ...Female Service Girls Call Delhi 9873940964 Provide Best And Top Girl Service ...
Female Service Girls Call Delhi 9873940964 Provide Best And Top Girl Service ...
elbertablack
 
Chennai Girls Call ServiCe X00XXX00XX Tanisha Best High Class Chennai Available
Chennai Girls Call ServiCe X00XXX00XX Tanisha Best High Class Chennai AvailableChennai Girls Call ServiCe X00XXX00XX Tanisha Best High Class Chennai Available
Chennai Girls Call ServiCe X00XXX00XX Tanisha Best High Class Chennai Available
shamrisumri
 
Open Source TCP or Netflow Log Server Using Graylog
Open Source TCP or Netflow Log Server Using GraylogOpen Source TCP or Netflow Log Server Using Graylog
Open Source TCP or Netflow Log Server Using Graylog
Bangladesh Network Operators Group
 
Girls Call Shimla 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Shimla 000XX00000 Provide Best And Top Girl Service And No1 in CityGirls Call Shimla 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Shimla 000XX00000 Provide Best And Top Girl Service And No1 in City
dilbaagsingh0898
 
Software Defined Networking, Concepts and Practical Implementations
Software Defined Networking, Concepts and Practical ImplementationsSoftware Defined Networking, Concepts and Practical Implementations
Software Defined Networking, Concepts and Practical Implementations
Bangladesh Network Operators Group
 
High Profile Girls Call ServiCe Chennai XX00XXX00X Tanisha Best High Class Ch...
High Profile Girls Call ServiCe Chennai XX00XXX00X Tanisha Best High Class Ch...High Profile Girls Call ServiCe Chennai XX00XXX00X Tanisha Best High Class Ch...
High Profile Girls Call ServiCe Chennai XX00XXX00X Tanisha Best High Class Ch...
shamrisumri
 
Use of Ontologies in Chemical Kinetic Database CHEMCONNECT
Use of Ontologies in Chemical Kinetic Database CHEMCONNECTUse of Ontologies in Chemical Kinetic Database CHEMCONNECT
Use of Ontologies in Chemical Kinetic Database CHEMCONNECT
Edward Blurock
 
How-to-Diagnose-Hard-Drives-by-DFL-DDP-2024.pdf
How-to-Diagnose-Hard-Drives-by-DFL-DDP-2024.pdfHow-to-Diagnose-Hard-Drives-by-DFL-DDP-2024.pdf
How-to-Diagnose-Hard-Drives-by-DFL-DDP-2024.pdf
Dolphin Data Lab
 
Digital ethnography of the Polish darknet drug trade community
Digital ethnography of the Polish darknet drug trade communityDigital ethnography of the Polish darknet drug trade community
Digital ethnography of the Polish darknet drug trade community
Piotr Siuda
 
Girls Call Mahipalpur 000XX00000 Provide Best And Top Girl Service And No1 in...
Girls Call Mahipalpur 000XX00000 Provide Best And Top Girl Service And No1 in...Girls Call Mahipalpur 000XX00000 Provide Best And Top Girl Service And No1 in...
Girls Call Mahipalpur 000XX00000 Provide Best And Top Girl Service And No1 in...
mahigarg2024#G05
 
Ontology for the semantic enhancement, database definition and management and...
Ontology for the semantic enhancement, database definition and management and...Ontology for the semantic enhancement, database definition and management and...
Ontology for the semantic enhancement, database definition and management and...
Edward Blurock
 
Rent remote desktop server mangohost .net
Rent remote desktop server mangohost .netRent remote desktop server mangohost .net
Rent remote desktop server mangohost .net
pdfsubmission50
 
Study of international anticancer research trends.pdf
Study of international anticancer research trends.pdfStudy of international anticancer research trends.pdf
Study of international anticancer research trends.pdf
Preston University
 
@Girls @Call Chennai 🛬 XXXXXXXXXX 🛬 available 24*7 cash payment book now pay ...
@Girls @Call Chennai 🛬 XXXXXXXXXX 🛬 available 24*7 cash payment book now pay ...@Girls @Call Chennai 🛬 XXXXXXXXXX 🛬 available 24*7 cash payment book now pay ...
@Girls @Call Chennai 🛬 XXXXXXXXXX 🛬 available 24*7 cash payment book now pay ...
shamrisumri
 
My President is bulletproof t shirts hoodie
My President is bulletproof t shirts hoodieMy President is bulletproof t shirts hoodie
My President is bulletproof t shirts hoodie
exgf28
 
Dewanstudio Project Portfolio 2023 show case
Dewanstudio Project Portfolio 2023 show caseDewanstudio Project Portfolio 2023 show case
Dewanstudio Project Portfolio 2023 show case
DEWANSTUDIO.COM
 
IPv6 Deployment Planning and Security Considerations
IPv6 Deployment Planning and Security ConsiderationsIPv6 Deployment Planning and Security Considerations
IPv6 Deployment Planning and Security Considerations
Bangladesh Network Operators Group
 

Recently uploaded (20)

DASH, presented by Elly Tawhai at PacNOG 33
DASH, presented by Elly Tawhai at PacNOG 33DASH, presented by Elly Tawhai at PacNOG 33
DASH, presented by Elly Tawhai at PacNOG 33
 
University of California, Riverside diploma
University of California, Riverside diplomaUniversity of California, Riverside diploma
University of California, Riverside diploma
 
Best CSS Animation Libraries for Web Developers
Best CSS Animation Libraries for Web DevelopersBest CSS Animation Libraries for Web Developers
Best CSS Animation Libraries for Web Developers
 
Female Service Girls Call Delhi 9873940964 Provide Best And Top Girl Service ...
Female Service Girls Call Delhi 9873940964 Provide Best And Top Girl Service ...Female Service Girls Call Delhi 9873940964 Provide Best And Top Girl Service ...
Female Service Girls Call Delhi 9873940964 Provide Best And Top Girl Service ...
 
Chennai Girls Call ServiCe X00XXX00XX Tanisha Best High Class Chennai Available
Chennai Girls Call ServiCe X00XXX00XX Tanisha Best High Class Chennai AvailableChennai Girls Call ServiCe X00XXX00XX Tanisha Best High Class Chennai Available
Chennai Girls Call ServiCe X00XXX00XX Tanisha Best High Class Chennai Available
 
Open Source TCP or Netflow Log Server Using Graylog
Open Source TCP or Netflow Log Server Using GraylogOpen Source TCP or Netflow Log Server Using Graylog
Open Source TCP or Netflow Log Server Using Graylog
 
Girls Call Shimla 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Shimla 000XX00000 Provide Best And Top Girl Service And No1 in CityGirls Call Shimla 000XX00000 Provide Best And Top Girl Service And No1 in City
Girls Call Shimla 000XX00000 Provide Best And Top Girl Service And No1 in City
 
Software Defined Networking, Concepts and Practical Implementations
Software Defined Networking, Concepts and Practical ImplementationsSoftware Defined Networking, Concepts and Practical Implementations
Software Defined Networking, Concepts and Practical Implementations
 
High Profile Girls Call ServiCe Chennai XX00XXX00X Tanisha Best High Class Ch...
High Profile Girls Call ServiCe Chennai XX00XXX00X Tanisha Best High Class Ch...High Profile Girls Call ServiCe Chennai XX00XXX00X Tanisha Best High Class Ch...
High Profile Girls Call ServiCe Chennai XX00XXX00X Tanisha Best High Class Ch...
 
Use of Ontologies in Chemical Kinetic Database CHEMCONNECT
Use of Ontologies in Chemical Kinetic Database CHEMCONNECTUse of Ontologies in Chemical Kinetic Database CHEMCONNECT
Use of Ontologies in Chemical Kinetic Database CHEMCONNECT
 
How-to-Diagnose-Hard-Drives-by-DFL-DDP-2024.pdf
How-to-Diagnose-Hard-Drives-by-DFL-DDP-2024.pdfHow-to-Diagnose-Hard-Drives-by-DFL-DDP-2024.pdf
How-to-Diagnose-Hard-Drives-by-DFL-DDP-2024.pdf
 
Digital ethnography of the Polish darknet drug trade community
Digital ethnography of the Polish darknet drug trade communityDigital ethnography of the Polish darknet drug trade community
Digital ethnography of the Polish darknet drug trade community
 
Girls Call Mahipalpur 000XX00000 Provide Best And Top Girl Service And No1 in...
Girls Call Mahipalpur 000XX00000 Provide Best And Top Girl Service And No1 in...Girls Call Mahipalpur 000XX00000 Provide Best And Top Girl Service And No1 in...
Girls Call Mahipalpur 000XX00000 Provide Best And Top Girl Service And No1 in...
 
Ontology for the semantic enhancement, database definition and management and...
Ontology for the semantic enhancement, database definition and management and...Ontology for the semantic enhancement, database definition and management and...
Ontology for the semantic enhancement, database definition and management and...
 
Rent remote desktop server mangohost .net
Rent remote desktop server mangohost .netRent remote desktop server mangohost .net
Rent remote desktop server mangohost .net
 
Study of international anticancer research trends.pdf
Study of international anticancer research trends.pdfStudy of international anticancer research trends.pdf
Study of international anticancer research trends.pdf
 
@Girls @Call Chennai 🛬 XXXXXXXXXX 🛬 available 24*7 cash payment book now pay ...
@Girls @Call Chennai 🛬 XXXXXXXXXX 🛬 available 24*7 cash payment book now pay ...@Girls @Call Chennai 🛬 XXXXXXXXXX 🛬 available 24*7 cash payment book now pay ...
@Girls @Call Chennai 🛬 XXXXXXXXXX 🛬 available 24*7 cash payment book now pay ...
 
My President is bulletproof t shirts hoodie
My President is bulletproof t shirts hoodieMy President is bulletproof t shirts hoodie
My President is bulletproof t shirts hoodie
 
Dewanstudio Project Portfolio 2023 show case
Dewanstudio Project Portfolio 2023 show caseDewanstudio Project Portfolio 2023 show case
Dewanstudio Project Portfolio 2023 show case
 
IPv6 Deployment Planning and Security Considerations
IPv6 Deployment Planning and Security ConsiderationsIPv6 Deployment Planning and Security Considerations
IPv6 Deployment Planning and Security Considerations
 

Introduction to SOAP/WSDL Web Services and RESTful Web Services

  • 1. Introduction to Web Services Held as part of the lecture series on Web Engineering at Vienna University of Technology May 2015
  • 2. Philipp Liegl ecosio GmbH Wiedner Hauptstr. 52, 1040 Vienna, Austria
 phone: +43 (1) 996 2106-20, fax: +43 (1) 996 2106-99
 philipp.liegl@ecosio.com, www.ecosio.com, @ecosioHQ Web Engineering Web Services
  • 3. Outline of today’s talk ▪ Introduction to Service-Oriented Computing ▪ SOAP ▪ WSDL ▪ UDDI ▪ Java API for XML Web Services (JAX-WS) ▪ RESTful Web Services ▪ Java API for RESTful Web Services (JAX-RS) 3
  • 4. Introduction to Service-Oriented Computing 4 Context of Web Services: Distributed Information Systems ▪ Layers of an information system ▪ Presentation layer ▪ Communication interface to external entities ▪ Graphical user interface for human users 
 or non graphical user interface for 
 other programs ▪ Application logic layer ▪ Implements operations requested by clients
 through the presentation layer ▪ Resource management layer ▪ Deals with different data sources of an
 information system ▪ Distributed systems are split up into parts ▪ Run simultaneously on multiple computers ▪ Communicate over a network presentation layer application logic layer resource management layer client TUWIENWEInformationSystem
  • 5. Machine to machine communication Getting applications to talk to each other presentation layer application logic layer resource management layer client TUWIENWEInformationSystem application logic layer resource management layer Anotherinformationsystem client presentation layer application logic layer 5
  • 6. Introduction to Service Oriented Computing 6 Tag Cloud
  • 7. Introduction to Service-Oriented Computing 7 Heterogeneity as the main obstacle for seamless communication of distributed information systems Windows Server 2008 UNIX System Flight information and booking application (programmed in C) Travel information and booking application (programmed in Java) Travel agency "The agency" Airline "The airline" seamless interaction? • Mismatch in operating system, language, platform, etc. • Service-oriented computing is an emergent paradigm that helps to overcome these mismatches • Example: Yield management in the airline industry requires close system interaction in order to retrieve the most current prices
  • 8. Introduction to Service-Oriented Computing 8 Application integration using services Windows Server 2008 UNIX System Flight booking application (programmed in C) Flight information application (programmed in Java) Travel agency "The agency" Airline "The airline" • Service vs. Web Service • Services are business functions which an enterprise offers to its business partners • A possible implementation of Services are Web Services • However, other concepts may also be used to implement a Service, e.g., ebXML, document-centric approaches using EDI messages, etc. Service Service Request Response
  • 9. What is a “service”? 9 “a logical representation of a repeatable activity, that has a specific outcome” “a service is a type of API, usually over HTTP” You may have an API, but not expose it to anybody external. “a service is a proxy of your internal logic, which is exposed to the outside world” Think of the analogy of “views” in database systems.
  • 10. Introduction to Service-Oriented Computing 10 Important terms in service-oriented computing • (Web) Services are self-contained modules that can be described, published, located, orchestrated, and programmed using XML-based technologies over a network • Service providers are organizations that provide the service implementations, supply their service descriptions, and provide related technical and business support • Service clients are end-users and organizations that use some service • Service aggregators are organizations that consolidate multiple services into a new, single orchestrated service offering that is commonly known as business process. • A service-oriented architecture (SOA) is a logical way of designing a software system to provide services to either end-user applications or to other services distributed in a network, via published and discoverable interfaces.
  • 11. Introduction to Service-Oriented Computing 11 Characteristics of Web Services (WS) • WS semantically encapsulate discrete functionality • A Web Service is a self contained software module that performs a single task (e.g. weather forecast by passing the zip-code as parameter) • WS share a contract • In order to allow interaction of services, a formal contract must be established, that defines the exact terms of an information exchange between a service client and a service provider • WS abstract underlying program logic • A service exposes a certain functionality to a client. How that functionality is achieved (e.g., which program language is used, or which database is used) remains invisible to the caller • WS are loosely coupled software modules • A service interface is defined in a neutral manner, independent of the underlying platform, operating system, or programming language • Due to their neutral interfaces, services are not hard-wired. Thus, a service may be easily exchanged by another service, without much implementation effort • WS are reusable • A service may be reused by multiple applications
  • 12. Introduction to Service-Oriented Computing 12 Characteristics of Web Services II (WS) • WS can be dynamically found and included in applications • A WS provides programmable access. Thus, a WS may be embedded in a remotely located application, i.e., a service may be composed. • Unlike Web Sites, Web Services are not targeted at human users • They are called by and exchange data with other software modules and applications. • WS are described in terms of a standard description language • Web Service Description Language (WSDL) and Web Application Description Language (WADL) describe functional service characteristics • Functional requirements: Requirements of the functionality which must be provided (Functions, Data, Behavior, etc.) • Non-functional requirements: Requirements of the circumstances under which the functionality must be provided (e.g., reliability, performance, etc.) • WS are distributed over the Internet • WS make use of existing ubiquitous transport Internet protocols like HTTP • By relying on the same well-understood transport mechanism as Web Content, Web Services may leverage existing infrastructures and may cross corporate firewalls.
  • 13. Introduction to Service Oriented Computing 13 Functional vs. Non-Functional Service Characteristics • Functional Service Characteristics • Detail the operational characteristics that define the overall behavior of the service • How the service is invoked • The location where it is invoked • Syntax of exchanged messages, etc. • Typically a question of the system design • Non-Functional Service Characteristics • Concentrate on service quality attributes • Service metering and cost • Performance metrics such as response time • Security attributes, authorization, authentication, transactional integrity, scalability, etc. • Typically a question of the system architecture
  • 14. Introduction to Service Oriented Computing 14 Tight versus loose coupling Tight coupling Loose coupling Physical coupling Direct physical link required Physical intermediary Communication style Synchronous Asynchronous Interaction pattern OO-style navigation of complex object trees Data-Centric, Self-Contained messages Control of process logic Central control of process logic Distributed logic components Underlying platforms Homogeneous Heterogeneous Service discovery and binding Statically bound services Dynamically bound services Platform dependencies Strong OS and programming language dependency OS- and programming language independent • Coupling refers to the degree to which software components depend upon each other. SOA
  • 15. Introduction to Service-Oriented Computing 15 Web Services ▪ Types of Web Services ▪ SOAP/WSDL based ▪ Service interface is exposed through WSDL documents ▪ Message exchange using SOAP ▪ Client code may be generated from WSDL description ▪ Representational State Transfer (REST) ▪ Easy way to communicate with Web Services ▪ Resources are identified by URIs and their state is manipulated through HTTP operations GET, POST, PUT, DELETE ▪ Rather a set of architectural principles, than a standard
  • 16. Introduction to Service-Oriented Computing Characterizing Web Services - Integration scenarios ▪ Within an organization ▪ Between business partners 16 CompanySupplier Customer Goods/Services Goods/Services Messages Messages Legacy application ERP application Service Service Messages Service Service Service Service
  • 17. Introduction to Service-Oriented Computing Why Web Services? ▪ Interoperable ▪ connection of heterogeneous systems ▪ usage of common standards ▪ Economical ▪ no installation and tight integration ▪ recycling of components ▪ Automatic ▪ no human intervention necessary ▪ Accessible ▪ access to legacy systems ▪ access to internal applications ▪ Available ▪ on any device, every time, anywhere ▪ Goals ▪ solve integration problem ▪ complete automated infrastructure for, e.g., e-commerce 17
  • 18. Introduction to Service-Oriented Computing 18 Service Oriented Architectures ▪ Service oriented architectures are an abstract pattern that applies to a wide variety of Web services ▪ SOA is a loosely-coupled architecture designed to meet the business needs of an organization ▪ SOA represent business functions as shared, reusable services ▪ SOA defines an architecture which usually consists of the following roles and the contracts between those roles: Service Service Requestor Service Provider PublishFind Bind
  • 19. Introduction to Service-Oriented Computing Operations in a Web Service Architecture ▪ Publish ▪ A service description needs to be published such that ▪ the service requestor can find it ▪ it is accessible ▪ Find ▪ The service requestor retrieves the service description ▪ directly ▪ by querying a service registry ▪ Bind ▪ The service requestor invokes or instantiates the interaction with the service by using binding details in the service description to locate, contact, and invoke the service. 19
  • 20. Introduction to Service-Oriented Computing Roles in a Web Service Architecture business perspective technical perspective service provider owner of the service platform that hosts the service service requestor business that requires certain functionality application that invokes or interacts with the service service registry searchable registry of service descriptions where service providers publish their service descriptions 20
  • 21. Introduction to Service-Oriented Computing 21 Layers in a SOA Business domain Business processes Business services Infrastructure 
 services Component-based
 service realizations Operational systems Distribution Purchasing Order 
 management Inventory ERP Legacy ApplicationsCRM Databases
  • 22. Introduction to Service-Oriented Computing Web Service Technology Stack 22 HTTP, JMS, SMTP XML SOAP WSDL UDDI WS-Reliability Orchestration – BPEL4WS Choreography – CDL4WS WS-Security Transactions Coordination Context Management Business processes Quality of Service Message Transport Description Discovery
  • 23. Introduction to Service-Oriented Computing 23 Standards in use Service Service Requestor Service Provider PublishFind Bind UDDI WSDLWSDL SOAP Note, that finding and publishing a service is also realized using SOAP calls.
  • 24. Introduction to Service-Oriented Computing Standards of interest ▪ SOAP (by W3C) ▪ Originally from “Simple Object Access Protocol“ ▪ Message exchange format ▪ WSDL (by W3C) ▪ “Web Service Description Language“ ▪ Standard to describe what is exchanged between Web Service Provider and Web Service Requestor ▪ UDDI (by OASIS) ▪ “Universal Description Discovery and Integration“ ▪ Basis for a directory service 24
  • 25. SOAP 25 Motivation • Conventional distributed object communication protocols such as Java/ RMI had a symmetric requirement • both ends of the communication link had to be implemented under the same distributed object model • e.g., in case of Java RMI, both ends must be implemented in Java, which does the marshalling (transform Java object into the exchange format) and unmarshalling (transform exchange format back to Java object) of objects Client program Server
 program RMI registry Java Java RMI RMI
  • 26. SOAP What is SOAP? ▪ SOAP once stood for 'Simple Object Access Protocol', but this acronym was dropped with Version 1.2 of the standard ▪ SOAP is a protocol for exchanging structured information in a decentralized, distributed environment and defines: ▪ an envelope that defines a framework for describing what is in a message and how to process it ▪ a set of encoding rules for expressing instances of application-defined data types ▪ conventions for representing remote procedure calls and responses ▪ XML-based W3C Specification ▪ For inter-application communication ▪ SOAP describes how a message is formatted, but not how it is delivered ▪ A SOAP message must be embedded in a transport-level protocol ▪ Typically HTTP is used, however, SMTP, FTP and others may also be used 26
  • 27. SOAP 27 Web Services communication and messaging network SOAP is a network application protocol that is used to transfer messages between service instances, described by WSDL interfaces. TCP/IP stack Transfer protocol (e.g., HTTP) SOAP messages WSDL interface WSDL interface Web Service Web Service
  • 28. SOAP 28 The two fundamental Web Service message exchange patterns Sender Sender Receiver Receiver Request message Response message Request message SOAP SOAP
  • 29. SOAP 29 Structure of a SOAP message ▪ A SOAP envelope consists of an optional header and a mandatory body ▪ All elements of a SOAP envelope are defined using XML Schema ▪ Header contains information on how the message is to be processed, e.g., routing and delivery, authentication or authorization, transaction contexts, etc. ▪ The body element is mandatory and carries the message payload ▪ The content of the header and the body element are application defined and not part of the SOAP standard * . * * *0 * *0 . . . * 10
  • 30. SOAP 30 Example of a SOAP header with two header blocks <?xml version="1.0" encoding="UTF-8"?>
 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> … <env:Header>
 <tx:transaction-id 
 xmlns:tx="http://www.transaction.com/transaction" 
 env:mustUnderstand="true"> 512 </tx:transaction-id>
 <notary:token xmlns:notary="http://www.notary.com/token" env:mustUnderstand="true"> RKEIK-DKEKW-DKIEL-DKKLK-WIEFK </notary:token>
 </env:Header> … </env:Envelope>
  • 31. SOAP Example SOAP Message <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2010-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pick up Mary at school at 2pm</m:msg> </m:alert> </env:Body> </env:Envelope> (http://www.w3.org/TR/2007/REC-soap12-part1-20070427/) Envelope Header Body 31
  • 32. SOAP 32 SOAP nodes ▪ SOAP provides a distributed processing model using SOAP nodes ▪ A node may ▪ transmit a SOAP message ▪ receive a SOAP message ▪ process a SOAP message ▪ relay a SOAP message ▪ Use cases for SOAP nodes: ▪ Crossing trust domains ▪ Ensuring scalability ▪ Providing value-added services along the message path Example for a SOAP message path: Initial SOAP sender SOAP inter- mediary SOAP inter- mediary SOAP receiver SOAP message SOAP message SOAP message
  • 33. SOAP The SOAP communication model supports four different styles ▪ 2 communication styles ▪ remote procedure calls (RPC) ▪ contains a procedure call ▪ document exchange ▪ contains only the actual message ▪ 2 encoding styles ▪ encoded ▪ data type encoded in message ▪ literal ▪ refers to XML Schema 33 Four potential styles: - RPC/Literal - Document/Literal - RPC/Encoded - Document/Encoded Only two are relevant according to the WS-I Basic Profile 1.0: - document/literal - RPC/literal http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
  • 34. SOAP SOAP body ▪ Carries the actual message payload ▪ Challenge to be solved in service oriented architectures ▪ Which format to chose for a specific payload? 34
  • 35. SOAP 35 Excursus: RPC-style Web Services • An RPC-style Web Service appears as a remote object to the client application • Clients express their request as a method call with a set of parameters • Messages are automatically serialized/deserialized back to the respective objects • Thus, RPC services are rather tightly coupled Price for a given product Online price response Web service 
 definitions Application program Database
  • 36. SOAP 36 Example of RPC-style SOAP message <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.supply.com/prices"> <env:Header> <tx:Transaction-id xmlns:t="http://www.transaction.com/id" env:mustUnderstand="true"> 512 </tx:Transaction-id> </env:Header> <env:Body> <m:GetProductPrice> <product-id>4893248</product-id> </m:GetProductPrice> </env:Body> </env:Envelope> hard wired method name
  • 37. SOAP 37 Excursus: Document-style Web Services • Document-style Web Services are message driven • The client invokes the service by sending a document (e.g., Quote Request) rather than a discrete set of parameters (cf. RPC-style) • The Web Service may (= synchronously) or may not (= asynchronously) return a response message (e.g., Quote) • In an asynchronous case the client can continue computation, without waiting for an immediate response Request for quote Quote document Database Receive Check Send Quote Request Quote Web service 
 definitions Application program
  • 38. SOAP 38 Example of document-style SOAP message <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <tx:Transaction-id xmlns:t="http://www.transaction.com/id" env:mustUnderstand="true"> 512 </tx:Transaction-id> </env:Header> <env:Body> <p:PurchaseOrder orderDate="2010-05-06" xmlns:p="http://www.supply.com/order"> <p:from> <p:accountNumber>239dsd</p:accountNumber> </p:from> <p:to> <p:accountNumber>23540234</p:accountNumber> </p:to> <p:products> … </p:products> </p:PurchaseOrder> </env:Body> </env:Envelope>
  • 39. SOAP 39 Error handling • SOAP uses the env:Fault element to communicate faults to the originator of the faulty message or another SOAP node • An env:Fault element has two mandatory sub-elements: • env:Code • env:Reason • env:Detail (optional, for application specific information) • In case an error occurred, a SOAP message with an env:Fault element in the env:body is returned to the originator
  • 40. SOAP 40 SOAP & HTTP Send HTTP POST with SOAP message Receive request Decode request message Do something Encode response message Send response Receive HTTP response with SOAP response Client Service listener ApplicationService proxy Receive function call Return value
  • 41. SOAP 41 Summary: Advantages • Simplicity • Based on XML, highly structured, easy to parse • Portability • no dependency on the underlying platform • Firewall-friendly due to HTTP • Use of open standards • Interoperability • Because SOAP is based on XML and HTTP it is possibly the most widely interoperable protocol to date • Universal acceptance • Resilience to changes • Even if new versions of the specification are introduced, SOAP nodes may provide backward compatibility • However, if the service changes, the service clients must change as well!
  • 42. SOAP 42 Summary: Disadvantages • SOAP + XML over HTTP does not have a high-performance • However, this is a trade-off compared to its interoperability features • SOAP is stateless (as is HTTP) • A requesting application must reintroduce itself to other applications when more connections are required • SOAP serializes by value and does not support serialization by reference • Multiple copies of an object will occur over time, containing state information that is not synchronized with other dislocated copies of the same object
  • 43. 43 • Start Java program “ArithmeticService” • Access it under http://localhost:8080/arithmeticservice?wsdl • Use SOAP-UI (http://www.soapui.org/) to access the service https://github.com/pliegl/we2015 SOAP Demo
  • 44. WSDL What is WSDL? ▪ Web Service Description Language ▪ XML-based specification schema for describing the public interface of a Web Service ▪ WSDL serves as a contract between a service provider and a client, invoking the service ▪ WSDL describes ▪ what a service does; i.e., the operations the service provides ▪ where it resides; i.e., details of the protocol specific address (URL) ▪ how to invoke it, i.e., details of the data formats and protocols necessary to access the service's operations 44
  • 45. WSDL 45 The two main parts of WSDL • Service interface definition (abstract part) • describes the general Web service interface structure • the operations supported by the service • the operation parameters • and abstract data types • Service implementation part (concrete part) • binds the interface • to a concrete network address • to a specific protocol • and to concrete data structures • a Web service client may bind to such an implementation and invoke the service
  • 46. WSDL 46 WSDL specification types messages operations port types bindings services and ports WSDL specification abstract part concrete part <definitions> 
 <types>
 data type definitions
 </types>
 
 <message>
 definition of the data being communicated
 </message>
 
 <portType>
 <operation> set of operations </operation>
 </portType>
 
 <binding>
 protocol and data format specification
 </binding>
 <service> location of the service </service> 
 </definitions>
  • 47. WSDL WSDL Elements I ▪ <definitions>: WSDL root element ▪ <types>: Container for data type definitions used by the Web Service ▪ Option A: Define a local XML Schema for parameter data types ▪ Option B: Reference one or more existing external XML Schemas ▪ Option C: Combination of Option A and Option B ▪ <message>: Definition of the messages, used by the Web Service. The type of a message is defined in <types> ▪ <portType>: Logical grouping of abstract <operations> which are supported by one or more endpoints ▪ <operation>: Operation signatures and I/O messages, defined in <message>. Consists of <input>, <output> and <fault> messages 47
  • 48. WSDL WSDL Elements II ▪ <binding>: Define the message format and the protocol details for each port type ▪ <soap:binding>: Defines the SOAP style (RPC or document) and the SOAP protocol to use (usually HTTP) ▪ <operation>: Defines each of the concrete operations, which the referenced port type exposes. For each operation the corresponding SOAP action is defined. Furthermore, it is defined how the input and output is encoded (literal or encoded). Default is literal. ▪ <service>: Defines the <port>s supported by the Web Service. ▪ <port>: Refers to an existing <binding> and via the <binding> to a <portType> ▪ <soap:address>: Defines the location, where the service may be accessed. (i.e., the URL) 48
  • 49. WSDL 49 Conceptual overview • operation • operation • operation Interface • operation • operation • operation Interface Resource end point 1 end point 4 end point 5 end point 6 Messages binding 1 binding 2 binding 3 binding 4 binding 5 binding 6 <portType> <operation> <binding> <port> <service> <binding> end point 2 end point 3 <portType> <operation>
  • 50. WSDL Example (1/5) ▪ Assume we want to provide the following functions via a Web Service public class MyWebService { public String greet( String name ) {
 return "Hello " + name + "!";
 }
 public int addInt(int n1, int n2 ) {
 return n1+n2; } } ▪ Then we obtain the following WSDL-document: 50
  • 51. WSDL Example (2/5) <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <definitions targetNamespace="http://endpoint.myws/" name="MyWebServiceService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://endpoint.myws/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http:// schemas.xmlsoap.org/wsdl/soap/"> <types/> <message name="addIntRequest"> <part name="n1" type="xsd:int"/> <part name="n2" type="xsd:int"/> </message> <message name="addIntResponse"> <part name="sum" type="xsd:int"/> </message> <message name="greetRequest"> <part name="arg0 " type="xsd:string"/> </message> <message name="greetResponse"> <part name="return" type="xsd:string"/> </message> 51
  • 52. WSDL Example (3/5) <portType name="MyWebService"> <operation name="addInt" parameterOrder="n1 n2"> <input message="tns:addIntRequest"/> <output message="tns:addIntResponse"/> </operation> <operation name="greet" parameterOrder="arg0"> <input message="tns:greetRequest"/> <output message="tns:greetResponse"/> </operation> </portType> 52 Name of the portType
  • 53. WSDL Example (4/5) <binding name="MyWebServicePortBinding" type="tns:MyWebService"> <soap:binding transport=http://schemas.xmlsoap.org/soap/http style="rpc"/> <operation name="addInt"> <soap:operation soapAction="http://localhost:8080/addInteger"/> <input> <soap:body use="literal" namespace="http://endpoint.myws/"/> </input> <output> <soap:body use="literal" namespace="http://endpoint.myws/"/> </output> </operation> <operation name="greet"> … </operation> </binding> 53 Arbitrary name Points to the port type for the binding May be used to identify a certain SOAP Request
  • 54. WSDL Example (4/5) <binding name="MyWebServicePortBinding" type="tns:MyWebService"> <soap:binding transport=http://schemas.xmlsoap.org/soap/http style="rpc"/> <operation name="addInt"> <soap:operation soapAction="http://localhost:8080/addInteger"/> <input> <soap:body use="literal" namespace="http://endpoint.myws/"/> </input> <output> <soap:body use="literal" namespace="http://endpoint.myws/"/> </output> </operation> <operation name="greet"> … </operation> </binding> 54 Document: • content of <soap:Body> is specified by XML Schema defined in the <wsdl:type> section. • Does not need to follow specific SOAP conventions - the message is sent as one "document" in the <soap:Body> element. • No additional formatting rules have to be considered. Document style is the default choice. RPC: • The structure of an RPC style <soap:Body> element needs to comply with the rules specified in detail in Section 7 of the SOAP 1.1 specification. • According to these rules, <soap:Body> may contain only one element that is named after the operation, and all parameters must be represented as sub-elements of this wrapper element.
  • 55. WSDL Example (5/5) <service name="MyWebServiceService"> <port name="MyWebServicePort" binding="tns:MyWebServicePortBinding"> <soap:address location="http://localhost:8080"/> </port> </service> </definitions> 55
  • 56. WSDL 56 Messaging Patterns Sender Receiver Sender Receiver Sender Receiver Sender Receiver One-way messaging SOAP request message Notification messaging SOAP request message Solicit/response messaging SOAP request message SOAP response message Request/response messaging SOAP request message SOAP response message 1: 2: 3: 4:
  • 57. WSDL 57 1: One way messaging • The service endpoint receives a message, but does not send a response • The <operation> element is declared with a single <input> element, but no <output> element • Like a “fire and forget” mechanism • A one-way-operation is typically thought of as asynchronous messaging <!– portType element describing the abstract interface of a Web Service --> <wsdl:portType name="SubmitPurchaseOrderPortType"> <wsdl:operation name="SubmitPurchaseOrder"> <wsdl:input name="order" message="tns:SubmitPurchaseOrderMessage"> </wsdl:input> </wsdl:operation> </wsdl:portType> Sender Receiver One-way messaging SOAP message
  • 58. WSDL 58 2: Request/Response messaging • The service endpoint receives a message and returns a message in response • If an <operation> element is declared with a single <input> element followed by a single <output> element, it defines a request/response operation <!– portType element describing the abstract interface of a Web Service --> <wsdl:portType name="SubmitPurchaseOrderPortType"> <wsdl:operation name="SubmitPurchaseOrder"> <wsdl:input name="order" message="tns:SubmitPurchaseOrderMessage"/> <wsdl:output name="orderResponse" message="tns:PurchaseOrderResponseMsg"/> </wsdl:operation> </wsdl:portType> Sender Receiver Request/response messaging SOAP request SOAP response
  • 59. WSDL 59 3: Notification messaging • An operation in which the service endpoint sends a message to the client, but does not expect to receive a response is called a notification operation • This type of operation is used if services need to notify clients of events • A Web Service using the notification messaging pattern follows the push model of distributed computing (the client has registered with the Web service to receive messages about an event) • Is the opposite of the one-way messaging pattern • The <operation> element contains an <output> tag, but no <input> message definitions <!– portType element describing the abstract interface of a Web Service --> <wsdl:portType name="FloodWarningPortType"> <wsdl:operation name="FloodWarning"> <wsdl:output message="tns:FloodWarningMsg"/> </wsdl:operation> </wsdl:portType> Sender Receiver Notification messaging SOAP notification
  • 60. WSDL 60 4: Solicit/response messaging • An operation in which the service endpoint sends a message and expects to receive an answer-message in response • Is the opposite of the request/response messaging pattern • Is similar to notification messaging, except that the client is expected to respond to the Web Service • As with notification messaging, clients of the solicit/response Web services must subscribe to the service in order to receive messages • In the <operation> element first an <output> tag and then an <input> tag is declared <!– portType element describing the abstract interface of a Web Service --> <wsdl:portType name="AnythingNewInYourBusinessPortType"> <wsdl:operation name="AnythingNew"> <wsdl:output message="tns:AnyThingNewRequest"/> <wsdl:input message="tns:MyNewsResponse"/> </wsdl:operation> </wsdl:portType> Sender Receiver Solicit/response messaging SOAP request message SOAP answer message
  • 62. UDDI What is UDDI? ▪ Universal Description Discovery and Integration ▪ UDDI defines a scheme for publishing and finding Web services of business entities ▪ “Yellow Pages for Web Services” ▪ Thought as standard for one XML-directory for Web services ▪ Three main pillars of a UDDI registry ▪ “white pages”: address, contact, and known identifiers ▪ “yellow pages”: industrial classification ▪ “green pages”: meta information on services (reference to service description in WSDL) ▪ In 2005 IBM, Microsoft, and SAP closed their existing UDDI registries 62
  • 63. UDDI 63 Reasons why UDDI never gained momentum • Discovery model of UDDI is very limited • No complex queries on potential services possible • Annotation mechanism for service definitions is limited • Pure technical focus (service definitions) • No integration of product data offered by a company • Missing B2B reference processes • Lack of quality and validity of entries • Approach too generic (world-wide) • Too many “fun-entries” Although the public success of UDDI is very limited, UDDI may still leverage benefits in an intra-organizational context.
  • 64. Java API for XML Web Services (JAX-WS) Overview ▪ Java Specification Request 224: Java API for XML-Based Web Services (JAX-WS): https://www.jcp.org/en/jsr/detail?id=224 ▪ Web Services with JAX-WS are POJOs, enriched with annotations: ▪ @WebService ▪ @SOAPBinding ▪ @WebMethod ▪ @WebParam ▪ @WebResult ▪ @OneWay ▪ XML processing using JAX-B (Java Architecture for XML Binding) ▪ Marshalling: Java Object ‣ XML instance ▪ Unmarshalling: XML Instance ‣ Java Object ▪ Java provides a simple mini server 64
  • 65. Java API for XML Web Services (JAX-WS) 65 Application development approaches • The WSDL to Java approach (contract first) • Defines the WSDL first • Use of tools such as wsimport to generate portable web service artifacts • Should be used for complex Web Service projects where multiple stakeholders and partners are involved. • The Java to WSDL approach (contract last) • Create a Service Endpoint Interface (SEI) as Java source files • Use the source files as inputs to generate the WSDL and other required portable artifacts (using wsgen) • May be used for smaller Web Service projects with a limited set of requirements
  • 66. Java API for XML Web Services (JAX-WS) 66 wsimport 101 • Use the WSDL of an existing Service to generate a Java Web Service Client d path to the .class files keep flag indicating that the source files shall be kept s path for the source files p Java package for the generated classes wsimport –d path/to/binaries –keep –s path/to/source –p my.java.package http://www.urltoservice.com?wsdl
  • 67. Java API for XML Web Services (JAX-WS) An Example 67 import javax.jws.WebMethod; import javax.jws.WebResult; import javax.jws.WebService; import javax.jws.soap.SOAPBinding; @WebService(name="ArithmeticService") @SOAPBinding(style = SOAPBinding.Style.RPC) public class ArithmeticService { @WebMethod(operationName="addFunction") @WebResult(name = "sum") public int add(int addend_a, int addend_b) { return addend_a + addend_b; } @WebMethod(operationName="subtractFunction") @WebResult(name = "difference") public int subtract(int minuend, int subtrahend) { return minuend - subtrahend; } }
  • 68. Java API for XML Web Services (JAX-WS) Deploying the Example 68 import javax.xml.ws.Endpoint; public class RunService { public static void main (String [] args) { Endpoint endpoint = Endpoint.publish("http://localhost:8080/ arithmeticservice", new 
 ArithmeticService()); } } Analyze the generated WSDL by opening
 
 http://localhost:8080/arithmeticservice?wsdl
  • 69. Further WS-Standards 69 ▪ WS-Notification ▪ WS-Transfer ▪ WS-PolicyAssertions ▪ WS-Resource Framework ▪ WS-Security ▪ WS-SecureConversation ▪ WS-Policy ▪ WS-Trust ▪ WS-Federation ▪ WS-Privacy ▪ WS-Test ▪ WS-Eventing ▪ WS-MakeConnection ▪ …
  • 70. WS-* standard wrap up • WS-death star • Lots of different WS-* specifications have been 
 developed
 • Hard to cope with these standards, even with
 a software stack at hand • While useful on an enterprise level, the WS-* approach is an over- engineering for smaller, more lightweight projects • Alternative approaches using HTTP with plain XML or JSON are on the rise 70
  • 71. RESTful Web Services 71 Introduction • Acronym for REpresentational State Transfer • Based on the dissertation of Dr. Fielding http://www.ics.uci.edu/~fielding/ pubs/dissertation/top.htm • Defines a set of architectural principles • Centered around the concept of resources and the manipulation of a resource’s state • Basic design principles • REST server provides access to resources • REST client manipulates the resources using HTTP methods • Statelessness (I did not say stateless applications!) • Directory-like structure of URIs for addressing resources • Transfer of XML or JSON data in order to alter the state of resources
  • 72. RESTful Web Services 72 Use of HTTP methods • Through HTTP methods resources may be accessed, modified, created, deleted • GET (retrieve a resource) • PUT (change the state of a resource, i.e., update a resource) • POST (create a new resource) • DELETE (remove a resource) • Example: Rename user Alice to Bob PUT /users/Alice HTTP/1.1 Host: myserver Content-Type: application/xml <?xml version="1.0"?> <user> <id>4711</id> <name>Bob</name> </user>
  • 73. RESTful Web Services 73 Stateless 1/2 • Consider the following stateful design for accessing users in chunks of 10 record sets Web Service Client GET /users/getNext?sessionID=432 <response> <user id="1">User 1</user> <user id="2">User 2</user> …. </response> currentChunk = 
 getCurrentChunkForUser(432); updateChunk(currentChunk,432); return currentChunk; • Server must hold current state and client/server must use session mechanism in order to allow correct correlation to current state • Bad for clustered environments (session data synchronization across cluster) • Session overhead can become an issue (memory consumption) • java.io.NotSerializableException issues (in case of bad session design)
  • 74. RESTful Web Services 74 Stateless 2/2 • Consider the following stateless design for accessing users in chunks of 10 record sets Web Service Client GET /users/chunk=4 <response chunk="4" nextChunk=""> <user id="1">User 1</user> <user id="2">User 2</user> …. </response> getChunk(4) • Responsibility for state management is entirely on the client's side • The server's response must allow the client to maintain the state, i.e., the response must contain information necessary for state management (see above)
  • 75. RESTful Web Services 75 Directory-like structure of URIs • URIs are used to address resources (in order to change their state) • In the context of RESTful Services URIs might be considered as self- documenting interfaces • A resulting URI structure might be • http://www.mycompany.com/users • http://www.mycompany.com/users/internal • http://www.mycompany.com/users/internal/34 • http://www.mycompany.com/users/external • http://www.mycompany.com/users/external/432 • http://www.mycompany.com/users/external/premium • http://www.mycompany.com/users/external/regular
  • 76. RESTful Web Services 76 Transfer of XML or JSON data • Resource representation reflects the current state of a resource • What values are currently stored for an entry x at the time the client accesses the resource • E.g., 'request user xyz' returns the current state of the resource 
 user xyz at time t • Client applications should be able to request the content in the format which best fits their needs • Use of MIME-Types in the HTTP Accept Header • e.g., application/json, application/xml, application/xhtml+xml • Also known as "content negotiation" • JSON (JavaScript Object Notation) • Lightweight data interchange format • Easy for humans to read and write and easy for machines to parse and generate • Further information: http://www.json.org/
  • 77. RESTful Web Services 77 JSON example: person object { "name" : "John Doe", "age" : 43, "address" : { "street" : "Favoritenstraße 9-11", "city" : "Vienna", "state": "AT" }, "phoneNumbers" : [ { "type" : "business", "number" : "+43 58801 18800" }, { "type" : "mobile", "number" : "+43 664 18800188" } ] } Address object Array
  • 78. JAX-RS - Java API for RESTful Web Services
 Building you own RESTful Services 78 ▪ Java Specification Request 339: The Java API for RESTful Web Services: https://jcp.org/en/jsr/detail?id=339 ▪ Sample implementation: Java Jersey: https://jersey.java.net/ ▪ Web Services with JAX-WS are POJOs, enriched with annotations: ▪ @Path ▪ @GET, @PUT, @POST, @DELETE,… ▪ @Produces ▪ @Consumes ▪ … @Path("/users/{username}") public class UserResource { @GET @Produces("text/xml") public String getUser(@PathParam("username") String userName) { ... } }
  • 79. JAX-RS - Java API for RESTful Web Services
 HEAD and OPTION Request 79 ▪ HTTP HEAD: invokes the implemented GET method (if present), but does not return the response entity ▪ HTTP OPTION: ▪ sets the allow response header to the HTTP methods, supported by the resource ▪ in addition the description of the RESTful Web Service using WADL (Web Application Description Language) is returned <application xmlns="http://research.sun.com/wadl/2006/10"> <doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 1.8" /> <resources base="http://localhost:8080/we-restful-service/rest/"> <resource path="students"> <method id="getStudentsXML" name="GET"> <response> <representation mediaType="application/xml" /> </response> </method> <method id="getStudentsJSON" name="GET"> <response> <representation mediaType="application/json" /> </response> </method> …
  • 80. RESTful Web Services 80 Demo • Accessing SAP’s repositories on GitHub • e.g., https://api.github.com/users/SAP/repos • Accessing sample student application • see https://github.com/pliegl/we2015 for further details Resource POST
 create GET
 read PUT update DELETE delete /students Create a new student List all students Bulk update a set of students Delete all students /student/1 Error Show student with register number 1 If exists update student with register number 1 If not error Delete student with register number 1 http://localhost:8080/we-restful-service/rest/students
  • 81. Summary ▪ Web services support interoperable machine-to-machine interaction ▪ Web services may be part of Web applications, but do not have a GUI themselves ▪ Web services are used for integration purposes ▪ 3 core standards for Web services ▪ SOAP ▪ WSDL ▪ UDDI ▪ RESTful services are another powerful architectural style for realizing machine-to-machine interaction 81
  • 82. Interesting Literature & Tools 82 • Michael Papazoglou, Web Services: Principles and Technology, Prentice Hall, 2008 • recommended - this presentation is mostly based on this book • Martin Kalin, Java Web Services, O'Reilly, 2009 • Java-specific perspective on Web Services • Eben Hewitt, Java SOA Cookbook, O'Reilly, 2009 • Java-specific perspective on SOA – 
 covers additional concepts such as 
 service orchestration, etc. as well • www.soapui.org/ • Useful for Web Service testing
  • 83. Interesting Literature & Tools – RESTful Web Services 83 • Leonard Richardson and Sam Ruby, RESTful Web Services, O'Reilly, 2007 • Brian Mulloy, Web API Design – Crafting interfaces that developers love, apigee • https://pages.apigee.com/rs/apigee/images/api- design-ebook-2012-03.pdf • Cesare Pautasso and Erik Wilde, Tutorial Design Principles, Patterns and Emerging Technologies for RESTful Web Services • http://dret.net/netdret/docs/rest-icwe2010/ • Google Chrome Advanced REST client • https://chrome.google.com/webstore/detail/ advanced-rest-client/ hgmloofddffdnphfgcellkdfbfbjeloo