Web Service Foundations: WSDL and SOAP Web Services Overview Marlon Pierce Indiana University [email protected] What Are Web Services? Web services framework is an XML-based distributed services system.
Download ReportTranscript Web Service Foundations: WSDL and SOAP Web Services Overview Marlon Pierce Indiana University [email protected] What Are Web Services? Web services framework is an XML-based distributed services system.
Web Service Foundations: WSDL and SOAP
Web Services Overview
Marlon Pierce Indiana University [email protected]
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 network using messages.
interactions over the 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 HTTP GET/POST Web Server JDBC DB Browser Web Server WSDL SOAP Web Server JDBC GUI Client WSDL SOAP 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 we’ll go into the details of WSDL and SOAP.
But in practice, you don’t need to work directly with either .
Most tools that I’m 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 “façade” 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 [email protected]
What Is WSDL?
Web Service Description Language W3C specification See http://www.w3.org/TR/wsdl WSDL 1.1.
for the official “note” for WSDL 1.1 never became a full “recommendation”.
WSDL 2.0 working draft just completed it’s 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 don’t care what kind of web server Amazon.com uses.
Amazon doesn’t 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 it in Tomcat as a service.
Clients can then invoke the echo service.
WSDL tells them how to do it.
Clients don’t need to know anything about the service implementation or even language.
WSDL is the latest IDL DCE and CORBA IDL were two older examples.
SOAP(Echo “hello”) C# Client WSDL WSDL Tomcat+ Axis+Echo “hello”
What Does echoServiceInterface Look Like In WSDL?
There’s more…
What Does This Look Like In WSDL, Continued?
Don’t strain your eyes. We will break this down
Writing WSDL
I’m 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
WSDL Types
Use
What Does echoServiceInterface Look Like In WSDL?
WSDL Types
WSDL messages don’t 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
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 won’t 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 String Array Types
WSDL
Technically, the WSDL schema specifies that
Look at the WSDL schema.
And note that the
You can insert any sort of xml here.
Inserting a Type
Between
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 nillable —I 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
Our Echo Messages
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
parts
.
The message name should be unique for the document.
I need one
Each
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
EchoService portType
portType Message Patterns
PortTypes support four types of messaging: One way: Client send a message to the service and doesn’t want a response.
only.
Request-Response: Client sends a message and waits for a response. , then
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, takes the
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 and
The Picture So Far…
Output Message portType Operation Input Ouput
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
Don’t 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
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 Operation Input Ouput binding Operation Input Output
Structure of the Binding
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 Non-wsdl extension output Non-wsdl 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 SOAP
WSDL SOAP SOAP RPC Binding Operation SOAP Action SOAP Body Input SOAP Body Output
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?
Ports and Services
Port and Service Tags
The service element is a collection of ports.
That’s 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
Service Binding Operation Port #1 URL #1 Input Output Port #2 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
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 [email protected]
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 looked at WSDL Defines the interfaces for remote services.
Provides guidelines for constructing clients to the service.
Tells the client how to communicate with the service.
The actual communications are encoded with SOAP.
Transported by HTTP Client WSDL SOAP Request WSDL Service SOAP Response
Beyond Client-Server
SOAP assumes messages have an
originator
, one or more
ultimate receivers
, and zero or more
intermediaries
.
The reason is to support distributed message processing.
Implementing this message routing is out of scope for SOAP.
Assume each node is a Tomcat server or JMS broker.
That is, we can go beyond client-server messaging.
Originator Intermediary Recipient Intermediary Intermediary
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 don’t 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
documents).
(movies, images, arbitrary
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.
It’s 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
SOAP Response
SOAP Structure
SOAP structure is very simple.
0 or 1 header elements 1 body element Envelop that wraps it all.
Body contains XML payload.
Headers are structured the same way.
Can contain additional payloads of “metadata” Security information, quality of service, etc.
Envelope Header Body Message Payload
SOAP Schema Notes
All of this is expressed formally in the SOAP schema.
Which in turn derives from the SOAP Infoset XML on the right is taken directly from the SOAP schema.
This just encodes the previously stated rules.
Also, note that the SOAP envelope can contain other attributes.
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
knows it has gotten a SOAP message.
Others as necessary is required, so that the recipient 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-
We’ll next look at the structure of the header and body.
SOAP and many other web services use the
And they use “lax” processing assertions.
Allows for skipping over the SOAP payload.
Needed in distributed messaging environments
Options on
The
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
·
to that definition.” with respect 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
include elements from other namespaces.
where you can 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
Elements replacing the wildcard MUST be namespace qualified, but can be in the targetNamespace
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
Explanation of Header Example
In general, we can import tags into the header from name spaces outside of soap.
It is the node’s 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
Role?
Yes must Understand Yes Process Header No No Forward Header Yes Relay?
No Remove 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
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
unbounded " />
SOAP Body Example
Example SOAP Body Details
The
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
This is data encoding Data encoding rules will also be examined in next lectures.