Web Service

Foundations: WSDL
and SOAP
Web Services
Overview

Marlon Pierce
Indiana University
mpierce@cs.indiana.edu
 What Are Web Services?
Web services framework is an XML-based distributed services
system.
SOAP, WSDL, UDDI

WS-Interoperability

Intended to support machine-to-machine interactions over the

network using messages.
Basic ideas is to build a platform and programming language-
independent distributed invocation system out of existing Web
standards.
Most standards defined by W3C, Oasis (IP considerations)

Interoperability really works, as long as you can map XML message

to a programming language type, structure, class, etc.
We regularly use Java-C++ and Java-Perl communication
Very loosely defined, when compared to CORBA, etc.
Inherit both good and bad of the web
Scalable, simple, distributed

But no centralized management, not high performance, must be

tolerant of failures.
Basic Architectures:
Servlets/CGI and Web Services
Browser
Browser GUI
Client

HTTP GET/POST Web WSDL

Server
SOAP
WSDL
Web

WSDL
WSDL
Server Web
Server
SOAP
JDBC
JDBC

DB DB
 Explanation of Previous Slide
The diagram on the left represents a standard web
application.
Browsers converse with web servers using HTTP GET/POST
methods.
Servlets or CGI scripts process the parameters and take
action, like connect to a DB.
Examples: Google, Amazon
On the right, we have a Web services system.
Interactions may be either through the browser or through a
desktop client (Java Swing, Python, Windows, etc.)
Examples: Google, Amazon
Some Terminology
The diagram on the left is called a client/server system.
The diagram on the right is called a multi-tiered architecture.
SOAP: Simple Object Access Protocol
No longer an abbreviation in SOAP 1.2

XML Message format between client and service.

WSDL: Web Service Description Language.

Describes how the service is to be used

Compare (for example) to Java Interface.

Guideline for constructing SOAP messages.

WSDL is an XML language for writing Application Programmer

Interfaces (APIs).
Amazon and Google Experiment
with Web Services
Both Google and Amazon have conducted open experiments
with Web services.
Why? To allow partners to develop custom user interfaces and
applications that work Google and Amazon data and services.
You can download their APIs and try them.
http://www.google.com/apis/

http://www.amazon.com/webservices
More Examples of Web Services
Geographical Information Systems are perfect candidates for WS
The Open Geospatial Consortium defines several relevant standards
Geographic Markup Language (GML) exchanges info.
Web Feature Service works with abstract GML feature data.
Web Map Service creates maps (images)
Lots more at http://www.opengeospatial.org/specs/?page=specs
XMethods
Lots and lots of contributed examples, live demos
Try them
http://www.xmethods.com/
Lots more for bioinformatics.
Easiest way to find is to download Taverna from SourceForge.
Then check out http://communitygrids.blogspot.com for guidelines.
CICC is building many new one for chemical informatics.
Web Service Architectures
The following examples illustrate how Web services interact with
clients.
For us, a client is typically a JSP, servlet, or portlet that a user
accesses through browser.
You can also build other clients
Web service interoperability means that clients and services can

be in different programming languages (C/C++, python, java,

etc).
 Before Going On
In the next several slides well go into the details of WSDL and SOAP.
But in practice, you dont need to work directly with either.
Most tools that Im familiar with generate the WSDL for you from your class.
Similarly, SOAP messages are constructed by classes.
Generated client stubs will even hide SOAP classes behind a local faade that
looks like a local class but actually constructs SOAP calls to the remote server.
Many tools for developing services are available
Apache Axis 1.x and 2.x for Java and C++
Sun Web Services for Java
SOAP Lite for Perl
.NET tools from MS
gSOAP for C++

WSDL 1.1 Overview

Marlon Pierce
Community Grids Lab
Indiana University
mpierce@cs.indiana.edu
What Is WSDL?
Web Service Description Language
W3C specification
See http://www.w3.org/TR/wsdl for the official note for
WSDL 1.1.
WSDL 1.1 never became a full recommendation.
WSDL 2.0 working draft just completed its public call for
comments.
This slide set will review WSDL 1.1, which is still the
standard.
WSDL 2.0 should replace this soon.
 Why Use WSDL?
WSDL uses XML to describe interfaces
Programming language independent way to do this.
So you can use (for example) C++ programs to remotely invoke Java programs
and vice versa.
Consider Web browsers and Web servers:
All web browsers work pretty well with all web sites.
You dont care what kind of web server Amazon.com uses.
Amazon doesnt care if you use IE, Mozilla, Konqueror, Safari, etc.
You all speak HTTP.
WSDL (and SOAP) are a generalization of this.
Note I will describe WSDL from an Remote Procedure Call/Remote Method
Invocation point of view.
But WSDL and SOAP also support more a more message-centric point of view.
C.f. Java Messaging System.
This is probably the way of the future for Web Services.
A Very Simple Example: Echo
public class echoService implements echoServiceInterface{
public String echo(String msg) {
return msg;
}
public static void main(String[] args) {
new echoService().echo(hello);
}
}
The Echo Interface

/**
* All implementers of this interface must
* implement the echo() method.
*/
public interface echoServiceInterface {
public String echo(String toEcho);
}
Now Use Echo As A Remote
Service
We can take the previous
Java program and deploy C#
it in Tomcat as a service. Client
Clients can then invoke
the echo service. WSDL
WSDL tells them how to
do it. SOAP(Echo hello) hello
Clients dont need to
know anything about the
service implementation
or even language. WSDL
WSDL is the latest IDL
DCE and CORBA IDL Tomcat+
were two older examples. Axis+Echo
 What Does
echoServiceInterface Look
Like In WSDL?
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions targetNamespace="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo"
xmlns:intf="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types />
<wsdl:message name="echoResponse">
<wsdl:part name="echoReturn" type="xsd:string" />
</wsdl:message>
<wsdl:message name="echoRequest">
<wsdl:part name="in0" type="xsd:string" />
</wsdl:message>
<wsdl:portType name="Echo">
<wsdl:operation name="echo" parameterOrder="in0">
<wsdl:input message="impl:echoRequest" name="echoRequest" />
<wsdl:output message="impl:echoResponse" name="echoResponse" />
</wsdl:operation>
</wsdl:portType> Theres more
 What Does This Look Like In
WSDL, Continued?
<wsdl:binding name="EchoSoapBinding" type="impl:Echo">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="echo">
<wsdlsoap:operation soapAction="" />
<wsdl:input name="echoRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo" use="encoded" />
</wsdl:input>
<wsdl:output name="echoResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding
namespace="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo" use="encoded" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="EchoService">
<wsdl:port binding="impl:EchoSoapBinding" name="Echo">
<wsdlsoap:address location="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Dont strain your eyes. We will break this down

 Writing WSDL
Im sure you are impressed with the previous two
slides.
One could write WSDL by hand, but this is not the
usual way.
It was automatically generated by Apache Axis. Most
other Web service tools will do the same from your
service code.
We will go through the construction, though, for
understanding.
You should not think of WSDL (and SOAP) as
programming languages.
They are just assertions, or descriptions.
 WSDL Parts
Types
Used to define custom message types

Messages
Abstraction of request and response messages that my client
and service need to communicate.
PortTypes
Contains a set of operations.

Operations organize WSDL messages.

Operation->method name, portType->java interface

Bindings
Binds the portType to a specific protocol (typically SOAP over
http).
You can bind one portType to several different protocols by using
more than one port.
Services
Gives you one or more URLs for the service.

Go here to execute echo.

Echo Service WSDL,
Section by Section
 Namespaces
The WSDL document begins with several XML namespace
definitions.
Namespaces allow you to compose a single XML document from
several XML schemas.
Namespaces allow you to identify which schema an XML tag comes
from.
Avoids name conflicts.

See earlier XML lectures

As we will see, the Axis namespace generator went overboard.
Not all of these are used.
 Front Matters
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions
targetNamespace="http://grids.ucs.indiana.edu:8045/GCWS/services
/Echo"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo"
xmlns:intf="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

</wsdl:definitions>
WSDL Types

Use <types/> to declare local message

structures.
 What Does
echoServiceInterface Look
Like In WSDL?
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions >
<wsdl:types />
<wsdl:message name="echoResponse">
<wsdl:part name="echoReturn" type="xsd:string" />
</wsdl:message>
<wsdl:message name="echoRequest">
<wsdl:part name="in0" type="xsd:string" />
</wsdl:message>

</wsdl:definitions>
WSDL Types
WSDL messages dont need to declare types when just sending
XML Schema primitive objects.
EchoService just has string messages.
So no special types definitions are needed in our WSDL.

Strings are an XML schema built-in type.

Schema Built In Types
 When Would I Need A

Type?
Any time your Web Service needs to send data
formatted by anything other than XML Schema built-
in types, you must define the type in WSDL.
Example: Arrays are not built-in types!
Arrays of strings, ints, etc., must be defined in the WSDL
<type></type> structure.
Another example: JavaBeans (or C structs or any
data classes with get/set methods) can be serialized
to XML.
Pass as messages to the remote endpoint.
Support for this in implementations is variable.
AXIS has limited support because they use their own
serializers.
Sun has better support but it wont work with Axis.
How Does WSDL Encode String
Arrays?
Imagine that my echo service actually echoes
back an array of strings.
Arrays are not part of the built-in types, so I
will have to define them myself.
Luckily for us, SOAP defines arrays, so we
can import this definition.
Next slide shows what this looks like.
 String Array Example
<wsdl:types>
<schema
targetNamespace="http://grids.ucs.indiana.edu:8045/GCWS/service
s/EchoArray"
xmlns="http://www.w3.org/2001/XMLSchema">
<import
namespace="http://schemas.xmlsoap.org/soap/encoding/" />
<complexType name="ArrayOf_xsd_string">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType"
wsdl:arrayType="xsd:string[]" />
</restriction>
</complexContent>
</complexType>
<element name="ArrayOf_xsd_string" nillable="true"
type="impl:ArrayOf_xsd_string" />
</schema>
</wsdl:types>
WSDL String Array Types
WSDL <type/> is nothing more than an extensibility placeholder
in WSDL.
Technically, the WSDL schema specifies that <type> </type> can
contain a <sequence> of 0 or more <any> tags.
Look at the WSDL schema.

And note that the <any/> tag acts like wildcard.

You can insert any sort of xml here.
 Inserting a Type
Between <type></type>, we insert a <schema>.
Since arrays are defined in SOAP encoding rules, I next import the
appropriate schema.
I import the definition of the SOAP Array and extend it to a
String array.
Typically imports also have location attributes
This namespace is located here for download.
Next, insert our own local definition of a type called
ArrayOf_xsd_string.
This is a restricted extension of the SOAP Array complex type.
We only allow 1 dimensional string arrays
It is also nillableI am allowed to returna null value for
the string.
Handling Other XML Types
You can also express other message arguments as XML.
Examples: a purchase order, an SVG description of an image, a GML
description of a map.
In practice, these are handled by automatic Bean
serializers/deserializers.
Castor is an example: http://www.castor.org/
XMLBeans is another http://xml.apache.org/xmlbeans/
These are tools that make it easy to convert between XML and
JavaBeans.
By JavaBeans I mean objects that associate simple get/set methods
with all data.
Implementation dependent.
WSDL Messages
WSDL Messages

The message section specifies

communications that will go on between
endpoints.
Gives each message a name (to be used later for
reference).
Specifies the type of message
Can be primitive types, like strings
Can be defined types, as we saw previously.
 The echoServiceInterface
messages
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions>
<wsdl:types />
<wsdl:message name="echoResponse">
<wsdl:part name="echoReturn" type="xsd:string" />
</wsdl:message>
<wsdl:message name="echoRequest">
<wsdl:part name="in0" type="xsd:string" />
</wsdl:message>
<wsdl:portType name="Echo">
<wsdl:operation name="echo" parameterOrder="in0">
<wsdl:input message="impl:echoRequest" name="echoRequest" />
<wsdl:output message="impl:echoResponse"
name="echoResponse" />
</wsdl:operation>
</wsdl:portType>

</wsdl:definitions>
 Our Echo Messages
<wsdl:message name="echoResponse">
<wsdl:part name="echoReturn"
type="xsd:string" />
</wsdl:message>
<wsdl:message name="echoRequest">
<wsdl:part name="in0" type="xsd:string" />
</wsdl:message>
Echo Service Messages
Our echo service takes a string argument and returns a string
answer.
In WSDL, I first abstract these as messages.
Echo needs two messages.

Note we have not yet said message is the request and which is
the response.
That is the job of the portType operations, coming up.
Structure of a Message
WSDL <message> elements have name attributes and
one or more parts.
The message name should be unique for the

document.
<operation> elements will refer to messages by name.

I need one <part> for each piece of data I need to

send in that message.
Each <part> is given a name and specifies its type.
<part> types can point to <wsdl:type> definitions if

necessary.
Our service just needs xsd:strings, so no problem.
PortTypes and
Operations
 WSDL portTypes
WSDL messages are only abstract messages.
We bind them to operations within the portType.
The structure of the portType specifies (still
abstractly) how the messages are to be used.
Think of operations->java methods and portTypes-
>java interfaces.
 The echoServiceInterface
portType
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions>
<wsdl:types />
<wsdl:message name="echoResponse">
<wsdl:part name="echoReturn" type="xsd:string" />
</wsdl:message>
<wsdl:message name="echoRequest">
<wsdl:part name="in0" type="xsd:string" />
</wsdl:message>
<wsdl:portType name="Echo">
<wsdl:operation name="echo" parameterOrder="in0">
<wsdl:input message="impl:echoRequest" name="echoRequest" />
<wsdl:output message="impl:echoResponse"
name="echoResponse" />
</wsdl:operation>
</wsdl:portType>

</wsdl:definition>
 EchoService portType
<wsdl:portType name="Echo">
<wsdl:operation name="echo" parameterOrder="in0">
<wsdl:input
message="impl:echoRequest"
name="echoRequest" />
<wsdl:output
message="impl:echoResponse" name="echoResponse"
/>
</wsdl:operation>
</wsdl:portType>
 portType Message Patterns
PortTypes support four types of messaging:
One way: Client send a message to the service and doesnt want a

response.
<input> only.
Request-Response: Client sends a message and waits for a
response.
<input>, then <output>
Solicit-Response: Service sends a message to the client first, then
the client responds.
<output>, then <input>
Notification: <output> only.
These still are abstract. We must implement them using some
message protocol.
HTTP units of transmission are request and response, so mapping

Solicit-Response to HTTP will take some work.

portType for EchoService
The echo service has one method, echo.
It takes one string argument and returns one string.
In WSDL, the portType is Echo, the operation is echo.
The messages are organized into input and output.
Messages are placed here as appropriate.

That is, <input> takes the <echoRequest> message.

Parameter Order

This attribute of operation is used to specify

zero or more space-separated values.
The values give the order that the input
messages must be sent.
Echo is a bad example, since it only has one
input parameter, named in0.
WSDL Self-Referencing
The WSDL <input> and <output> tags need to point back to the
<message> definitions above:

<wsdl:message name="echoResponse">
<wsdl:part name="echoReturn" type="xsd:string" />
</wsdl:message>

<wsdl:portType name="Echo">
<wsdl:operation name="echo" parameterOrder="in0">

<wsdl:output message="impl:echoResponse"
name="echoResponse" />
</wsdl:operation>
</wsdl:portType>
The Picture So Far

Input Message
Input Message portType
Part has
Part I npu
t Operation

Input

Output Message
hasOutput
Ouput
Part
Part
Bindings
WSDL SOAP Bindings
In the previous slide, we specify several things:
We will use SOAP/HTTP

We will use RPC encoding style

Other choice is literal document style.

We specify the namespace associated with the Echo service
input and output messages.
All of this corresponds to SOAP message parts.
We will expand this in the next lecture.
 Binding Section of WSDL
<wsdl:definitions>

<wsdl:binding name="EchoSoapBinding" type="impl:Echo">

<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="echo">
<wsdlsoap:operation soapAction="" />
<wsdl:input name="echoRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo"
use="encoded" />
</wsdl:input>
<wsdl:output name="echoResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding
namespace="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo"
use="encoded" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="EchoService">
<wsdl:port binding="impl:EchoSoapBinding" name="Echo">
<wsdlsoap:address location="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Dont strain your eyes--we will zoom in.

So Far

We have defined abstract messages, which

have XML values.
Simple or custom-defined types.
We have grouped messages into operations
and operations into portTypes.
We are now ready to bind the portTypes to
specific protocols.
 The Binding for Echo
<wsdl:binding name="EchoSoapBinding" type="impl:Echo">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="echo">
<wsdl:input name="echoRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace=[echo service namespace URI]"
use="encoded" />
</wsdl:input>
<wsdl:output name="echoResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace=[echo service namespace URI]"
use="encoded" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding> The highlighted wsdlsoap: tags are
extensions for SOAP message binding
and not part of the WSDL schema.
Binding tags
Binding tags are meant to bind the parts of
portTypes to sections of specific protocols.
SOAP, HTTP GET/POST, and MIME are provided in the
WSDL specification.
Bindings refer back to portTypes by name, just as
operations point to messages.
They are mirror images of the portTypes.
Each part is extended by schema elements for a particular
binding protocol (i.e. SOAP).
In our WSDL bindings, we will have two messages
(input and output).
Each corresponds to SOAP body sections, described later.
Additionally, we specify that the body should be encoded.
That is, RPC encoded.
Alternatively, could also be literal (or document).
WSDL Internal References

portType binding

Operation Operation

Input Input

Ouput Output
Structure of the Binding
<binding> tags are really just placeholders.
They are meant to be extended at specific places by
wsdl protocol bindings.
These protocol binding rules are defined in supplemental
schemas.
The following box figure summarizes these things
Green boxes are part of WSDL
From the wsdl namespace, that is.
Red boxes are parts of the document from other schemas
From wsdlsoap namespace in the echo example.
Binding Structure

binding

Non-wsdl extension

operation

Non-wsdl extension

input output

Non-wsdl Non-wsdl
extension extension
A little more on encoding...
We specify SOAP encoding
SOAP is a message format and needs a transport
protocol, so we specify HTTP.
Operation styles may be either RPC or Document.
We use RPC.

SOAP Body elements will be used to actually convey

message payloads.
RPC requires encoded payloads.
Each value (echo strings) is wrapped in an element named
after the operation.
Useful RPC processing on the server side.
Documents are literal (unencoded)
Use to just send a payload of XML inside SOAP.
Binding Associations to
SOAPWSDL SOAP

Binding SOAP RPC

Operation SOAP Action

Input SOAP Body

Output SOAP Body

Binding Restrictions

Binding elements point by name to

portTypes.
WSDL allows more than one binding element
to point to the same port type.
Why?
Because a service may support multiple,
alternative protocol bindings.
What Does It Mean?
WSDL is not a programming language.
A service that exposes an WSDL interface is just telling a client what it
needs to do to communicate with the service.
Send me strings and I will return strings.
I expect SOAP messages that include the strings in the body.
I expect this body to be RPC encoded with the operation name so that I will
know which operation the body contents belong to.
I will return SOAP messages that include Strings in the body.
These will also be encoded so that you know what to do with them.
Ports and Services
 What Does This Look Like In
WSDL, Continued?
<wsdl:definitions>

<wsdl:binding>

</wsdl:binding>
<wsdl:service name="EchoService">
<wsdl:port binding="impl:EchoSoapBinding"
name="Echo">
<wsdlsoap:address
location="http://grids.ucs.indiana.edu:8045/GCWS/ser
vices/Echo" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Ports and Services

<wsdl:service name="EchoService">
<wsdl:port
binding="impl:EchoSoapBinding"
name="Echo">
<wsdlsoap:address
location=http://..../"/>
</wsdl:port>
</wsdl:service>
Port and Service Tags

The service element is a collection of ports.

Thats all it is for.
Ports are intended to point to actual Web
service locations
The location depends on the binding.
For SOAP bindings, this is a URL.
Ports and Services
A service can have more than one port.
Two ports can point back to the same binding
element.
Ports refer to bindings by name
This allows you to provide alternative service locations.
The figure on next slide conceptually depicts
associating two ports to a single binding.
The ports differ only in the URLs of their services.
Port Associations to Bindings
Binding Service

Operation
Port #1

URL #1
Input

Port #2
Output URL #2
Summary of WSDL
WSDL decouples remote service operations.
Types=custom message definitions.

Any data types not in the XML schema.

Message=name the messages that must be exchanged and their
data types, possibly defined by <type>.
PortTypes=service interfaces
Operations=remote method signatures.
Bindings=mappings of portType operations to real message
formats
Ports=locations (URLs) of real services.
SOAP Intro and
Message Formats
Marlon Pierce
Community Grids Lab
Indiana University
mpierce@cs.indiana.edu
SOAP Primary References
SOAP is defined by a number of links
http://www.w3.org/TR/soap/
See primarily the Primer and Messaging
Framework links.
The actual SOAP schema is available from
http://www.w3.org/2003/05/soap-envelope/
It is pretty small, as these things go.
SOAP and Web Services
Our previous lectures have Client
looked at WSDL
Defines the interfaces for WSDL
remote services.
Provides guidelines for
SOAP SOAP
constructing clients to the Request
service. Response
Tells the client how to
WSDL
communicate with the
service.
Service
The actual communications
are encoded with SOAP.
Transported by HTTP
Beyond Client-Server
SOAP assumes messages
have an originator, one or
Originator Recipient
more ultimate receivers, and
zero or more intermediaries.
The reason is to support
distributed message
processing.
Intermediary
Implementing this message
routing is out of scope for
SOAP.
Assume each node is a
Tomcat server or JMS Intermediary
broker.
That is, we can go beyond Intermediary
client-server messaging.
 SOAP in One Slide
SOAP is just a message format.
Must transport with HTTP, TCP, etc.
SOAP is independent of but can be connected
to WSDL.
SOAP provides rules for processing the
message as it passes through multiple steps.
SOAP payloads
SOAP carries arbitrary XML payloads as a body.
SOAP headers contain any additional information
These are encoded using optional conventions
Defining SOAP Messages

Given what you have learned about WSDL,

imagine it is your job to design the message
interchange layer.
What are the requirements?
Note SOAP actually predates WSDL, so this
is in reverse order.
 Web Service Messaging Infrastructure
Requirements?
Define a message format
Define a messaging XML schema
Allow the message to contain arbitrary XML from other schemas.
Keep It Simple and Extensible
Messages may require advanced features like security, reliability, conversational
state, etc.
KISS, so dont design these but do design a place where this sort of advanced
information can go.
Add these capabilities in further specifications: WS-Security, WS-ReliableMessaging, etc.
Tell the message originator is something goes wrong.
Define data encodings
That is, you need to tell the message recipient the types of each piece of data.
Define some RPC conventions that match WSDL
Your service will need to process the message, so you need to provide some
simple conventions for matching the message content to the WSDL service.
Decide how to transport the message.
Generalize it, since messages may pass through many entities.
Decide what to do about non-XML payloads (movies, images, arbitrary
documents).
SOAP Messaging
SOAP Basics
SOAP is often thought of as a protocol extension for
doing Remote Procedure Calls (RPC) over HTTP.
This is how it is often used.

This is not accurate: SOAP is an XML message

format for exchanging structured, typed data.
It may be used for RPC in client-server applications

May be used to send XML documents

Also suitable for messaging systems (like JMS) that

follow one-to-many (or publish-subscribe) models.

SOAP is not a transport protocol. You must attach
your message to a transport mechanism like HTTP.
What Does SOAP Look
Like?
The next two slides shows examples of SOAP
message from our Echo service.
Its just XML
First slide is an example message that might be
sent from a client to the echo service.
Second slide is an example response.
I have highlighted the actual message payload.
 SOAP Request

<?xml version=1.0 ?>

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:echo
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="http://.../axis/services/EchoService">
<in0 xsi:type="xsd:string">Hollow World</in0>
</ns1:echo>
</soapenv:Body>
</soapenv:Envelope>
 SOAP Response
<?xml version=1.0 ?>
<soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:echoResponse

soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/

xmlns:ns1="http://../axis/services/echoService">
<echoReturn xsi:type=String>
Hollow World
</echoReturn>
</ns1:echoResponse>
</soapenv:Body>
</soapenv:Envelope>
 SOAP Structure
SOAP structure is very Envelope
simple.
0 or 1 header elements

1 body element
Header
Envelop that wraps it all.

Body contains XML payload.

Headers are structured the
same way. Body
Can contain additional

payloads of metadata
Security information,
Message
quality of service, etc. Payload
SOAP Schema Notes
All of this is expressed formally <xs:complexType
in the SOAP schema. name="Envelope">
Which in turn derives from the <xs:sequence>
SOAP Infoset
<xs:element
XML on the right is taken ref="tns:Header"
directly from the SOAP minOccurs="0" />
schema. <xs:element ref="tns:Body"
This just encodes the minOccurs="1" />
previously stated rules. </xs:sequence>
Also, note that the SOAP <xs:anyAttribute
envelope can contain other namespace="##other"
attributes. processContents="lax" />
<anyAttribute> tag is the
wildcard </xs:complexType>
SOAP Envelop
The envelop is the root container of the SOAP message.
Things to put in the envelop:
Namespaces you will need.
http://schemas.xmlsoap.org/soap/envelope is required, so that the recipient
knows it has gotten a SOAP message.
Others as necessary
Encoding rules (optional)
Specific rules for deserializing the encoded SOAP data.
More later on this.
Header and body elements.
Headers are optional, body is mandatory.
Headers come first in the message, but we will look at the body first.
Brief Aside:WS-* is WS-
<any>
Well next look at the structure of the header and
body.
SOAP and many other web services use the <any>
tag for extensibility.
And they use lax processing assertions.
Allows for skipping over the SOAP payload.
Needed in distributed messaging environments
 Options on <xsd:any/>
The <xsd:any/> element takes the usual optional
maxOccurs, minOccurs attributes.
Allows a namespace attribute taking one of the values:
##any (the default),
##other (any namespace except the target
namespace),
List of namespace names, optionally including either
##targetNamespace or ##local.
Controls what elements the wildcard matches, according to
namespace.
It also allows a processContents attribute taking one of the
values strict, skip, lax (default strict), controlling the extent
to which the contents of the matched element are validated.
SOAP is lax.
Lax
If the item, or any items among its children if it's an
element information item, has a uniquely determined
declaration available, it must be valid with respect
to that definition.
That is, validate message payloads when you can,
don't worry when you can't.
SOAP Headers
SOAP Body elements contain the primary message contents.
Headers are really just extension points where you can
include elements from other namespaces.
i.e., headers can contain arbitrary XML.

Headers may be processed independently of the body.

Headers may optionally define encodingStyle.
Headers may optionally have a role attribute
Header entries may optionally have a mustUnderstand
attribute.
mustUnderstand=1 means the message recipient must

process the header element.

If mustUnderstand=0 or is missing, the header element is

optional.
Headers may also have a relay attribute.
Header Definition From SOAP
Schema
<xs:element name="Header" type="tns:Header" />
<xs:complexType name="Header">
<xs:annotation>
<xs:documentation>Elements replacing the wildcard MUST be
namespace qualified, but can be in the
targetNamespace</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
Example Uses of Headers
Security: WS-Security and SAML place additional security
information (like digital signatures and public keys) in the header.
Quality of Service: SOAP headers can be used if we want to
negotiate particular qualities of service such as reliable message
delivery and transactions.
Session State Support: Many services require several steps
and so will require maintenance of session state.
Equivalent to cookies in HTTP.

Put session identifier in the header.

Example Header from SOAP
Primer
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-
envelope">
<env:Header>
<m:reservation xmlns:m=http://my.example.com/"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d
</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00
</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>ke Jgvan yvind</n:name>
</n:passenger>
</env:Header>
Explanation of Header
Example
In general, we can import tags into the header from name
spaces outside of soap.
<reservation/>, <reference/>, <dataAndTime/>,<passenger/>

SOAP doesnt need to worry to much about these.

It is the nodes job to process these things.

In this particular case, we may imagine an ongoing

transaction for making an airline reservation.
Involves several steps and messages, so client must remind

the server of this state information when sending a message.

The actual header content all comes from other namespaces.

The role and mustUnderstand attributes are from SOAP.

Header Processing
SOAP messages are allowed to pass through many
intermediaries before reaching their destination.
Intermediary=some unspecified routing application.

Imagine SOAP messages being passed through many

distinct nodes.
The final destination processes the body of the
message.
Headers are allowed to be processed independently of
the body.
May be processed by intermediaries.

This allows an intermediary application to determine if

it can process the body, provide the required security,
session, or reliability requirements, etc.
Roles, Understanding, and
Relays
Yes Yes
must Process
Role? Understand Header

No No

Forward Yes No Remove

Relay?
Header Header
Header Roles
SOAP nodes may be assigned role designations.
SOAP headers then specify which role or roles
should process.
Standard SOAP roles:
None: SOAP nodes MUST NOT act in this role.
Next: Each SOAP intermediary and the ultimate SOAP
receiver MUST act in this role.
UltimateReceiver: The ultimate receiver MUST act in
this role.
In our example, all nodes must process the
header entries.
SOAP Body
Body entries are really just placeholders for XML
from some other namespace.
The body contains the XML message that you
are transmitting.
It may also define encodingStyle, just as the
envelop.
The message format is not specified by SOAP.
The <Body></Body> tag pairs are just a way to notify
the recipient that the actual XML message is contained
therein.
The recipient decides what to do with the message.
SOAP Body Element
Definition
<xs:element name="Body" type="tns:Body" />
<xs:complexType name="Body">
<xs:sequence>
<xs:any namespace="##any"
processContents="lax" minOccurs="0
maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute namespace="##other"
processContents="lax" />
</xs:complexType>
SOAP Body Example
<soapenv:Body>
<ns1:echo soapenv:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1=
"http://.../axis/services/EchoService">
<in0 xsi:type="xsd:string">Hollow
World</in0>
</ns1:echo>
</soapenv:Body.
Example SOAP Body Details
The <Body> tag is extended to include elements
defined in our Echo Service WSDL schema.
This particular style is called RPC.
Maps WSDL bindings to SOAP body elements.
Guidelines will be given in next lecture.
xsi-type is used to specify that the <in0> element
takes a string value.
This is data encoding
Data encoding rules will also be examined in next lectures.