Web Service Foundations: WSDL and SOAP

115  Download (0)

Full text

(1)

Web Service Foundations:

WSDL and SOAP

Marlon Pierce

(2)

What Are Web Services?

n Web services framework is an XML-based distributed services

system.

q SOAP, WSDL, UDDI

q WS-Interoperability

q Intended to support machine-to-machine interactions over the

network using messages.

n Basic ideas is to build a platform and programming

language-independent distributed invocation system out of existing Web

standards.

q Most standards defined by W3C, OASIS (IP considerations)

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

to a programming language type, structure, class, etc.

n We regularly use Java-C++ and Java-Perl communication

n Very loosely defined, when compared to CORBA, etc. n Inherit both good and bad of the web

q Scalable, simple, distributed

q But no centralized management, not high performance, client

(3)
(4)

Explanation of Previous Slide

n

The diagram on the left represents a standard web

application.

q

Browsers converse with web servers using HTTP

GET/POST methods.

q

Servlets or CGI scripts process the parameters and take

action, like connect to a DB.

n

On the right, we have a Web services system.

q

Separates visual from non-visual components

q

Interactions may be either through the browser or

(5)

Some Terminology

n

The diagram on the left is called a

client/server

system.

n

The diagram on the right is called a

multi-tiered

architecture.

n

SOAP

: Simple Object Access Protocol

q

No longer an abbreviation in SOAP 1.2

q

XML Message format between client and service.

n

WSDL

: Web Service Description Language.

q

Describes how the service is to be used

q

Compare (for example) to Java Interface.

q

Guideline for constructing SOAP messages.

q

WSDL is an XML language for writing

Application

(6)

More Examples of Web Services

n Geographical Information Systems are perfect candidates for WS

q The Open Geospatial Consortium defines several relevant standards n Geographic Markup Language (GML) exchanges info.

n Web Feature Service works with abstract GML feature data. n Web Map Service creates maps (images)

n Lots more at http://www.opengeospatial.org/specs/?page=specs

n XMethods

q Lots and lots of contributed examples, live demos q Try them

n http://www.xmethods.com/

n

Lots more

for bioinformatics.

q Easiest way to find is to download Taverna from SourceForge. q Then check out http://communitygrids.blogspot.com for

guidelines.

(7)

RDAHMM: GPS Time Series Segmentatio

Slide Courtesy of Robert Granat, JPL

n Complex data with subtle signals is difficult for humans to

analyze, leading to gaps in analysis

n HMM segmentation provides an automatic way to focus attention

on the most interesting parts of the time

GPS displacement (3D) length two years

Divided automatically by HMM into 7 classes.

Features:

•Dip due to aquifer drainage (days 120-250)

•Hector Mine

earthquake (day 626) •Noisy period at

(8)

Making RDAHMM into a Web Service

n

RDAHMM takes GPS (or

other) time-series data as

input, along with various

command line

parameters.

n

GPS data comes from

GRWS or other services.

q http://geoapp.ucsd.edu/scig

nDataPortal/grwsSummary.j sp

n

It creates 11 output files.

n

Results are

superimposed on the

input time series.

USAGE: GEMCodes/RDAHMM2/bin/rdahmm -data 'input observation sequence file'

[-L 'output model log likelihood file'] [-Q 'output optimal state sequence file'] [-pi 'output model initial state probability file'] [-A 'output model transition probability file'] [-B 'output model output distribution file'] [-minvalfile 'data minimum value file'] [-maxvalfile 'data maximum value file file'] [-rangefile 'data range file']

[-covarsweightsfile 'covariance component weightings file'] [-covgraphfile 'covariance graph connectivity file']

-T 'number of observations' -D 'dimension of observations' -N 'number of model states'

(9)

This is a portal client to a data mining service that I built. The web service

analyzes GPS signal data to look for modes.

Portal courtesy of NASA REASoN project.

GPS data comes from the Scripps GRWS Web Service. Instead of defining a data type for this file, we just pass around URLs. The RDAHMM service receives the URL as input.

The service returns output result files as URLs.

(10)

How Do You Design the RDAHMM

Service?

n

First, you need an engine to run RDAHMM.

q

I develop Java services, so I have found Apache Ant

very useful for wrapping binary executables, managing

command-lines, and interacting with the Unix shell.

q

You can embed Ant in other Java programs.

n

Second, you need an appropriate Web Service

container for your development environment.

q

I use Apache Axis (examples will use version 1.4).

n This runs in Apache Tomcat.

q

.NET, C/C++, Python, Ruby, Perl, etc all have Web

Service containers.

(11)

Writing the Service

n

Writing a Web Service is easy

q

Just write a Java program

n

In our case, the Java program must

q

Grab GPS data from GRWS service

n We pass this around using URLs.

q

Collect command line parameter values as input.

q

Run the code.

q

Send back a response as a Java Bean that

encapsulates URLs.

n Can either block or not-block, depending on how you want to

execute things.

(12)

Service Code Example

public RDAHMMResultsBean runNonblockingRDAHMM2(String siteCode,String resource, String contextGroup,

String contextId, String minMaxLatLon, String

beginDate, String endDate, numModelStates) throws Exception {

try {

String dataUrl=querySOPACGetURL(siteCode, resource, contextGroup, contextId, minMaxLatLon, beginDate, endDate);

return createRDAHMMBean( dataUrl,numModelStates); }

(13)

RDAHMMResultBean Code

public class RDAHMMResultsBean implements java.io.Serializable { private java.lang.String AUrl;

private java.lang.String BUrl; private java.lang.String LUrl; private java.lang.String QUrl; private java.lang.String inputUrl;

....

public RDAHMMResultsBean() { }

//Plus all of the getters and setters

public java.lang.String getInputUrl() { return inputUrl; }

public void setInputUrl(java.lang.String inputUrl) { this.inputUrl = inputUrl; } ...

}

n

Nothing special about

this code.

n

Note all the returned

values are actually

URLs.

n

AUrl, BUrl, LUrl, etc

are all URLs to files

generated by

RDAHMM.

(14)

Deploying an Axis 1 Service

n

Now that you have written the code, you

follow these steps to make it into a service.

n

Download Axis and install it into Tomcat.

q

That is, create a subdirectory of webapps and put

all the Axis jars in WEB-INF/lib/.

n

Create a service descriptor file,

service-config.wsdd and put this in WEB-INF/

q

Axis gives you tools to help.

n

Compile your code and put it in

(15)

Creating an Axis Client

n

Axis will inspect your newly deployed service and create a

WSDL file out of it.

q More on this in a minute.

n

WSDL is an XML API description.

q It tells clients how to invoke your service.

q Typically the service is invoked by sending a SOAP message, so

WSDL tells you how to construct SOAP.

n

Clients typically discover and download the WSDL (UDDI,

wget, whatever).

n

Axis has a tool called WSDL2Java that will convert the

WSDL into

client stubs

.

q Stubs give you local objects that invoke the remote service.

n

Clients can be anything

(16)

Some Notes on Axis 2

n

Axis 2 is a redesign of Axis 1 that has

q

Greater performance (using

StAX

XML parsers)

q

Extensiblity to support Web Service Quality of Service

add-ons.

q

Better support for Java-to-XML binding frameworks.

n

Allows you to send and receive more

complicated XML messages.

q

But I think you should avoid this.

n

See my notes:

q

(17)

Some Additional Notes

n

Typically, you

don’t

need to import any Axis

specific packages.

q

Exception: finding and loading a property file.

n

If you are familiar with JSP, servlets, or

similar things, you will notice that you also

don’t

q

Need to manage HTTP request, response, and

session variables.

n

This style of programming is similar to the

Inversion of Control Pattern (IOC).

(18)

What Have We Gained from This?

n

We have

decoupled

the RDAHMM client and the

service.

q

Now separated using well-defined interfaces.

q

One service can be used by multiple, independently

developed clients.

q

Services just do one thing really well. Application

“smarts” are in the client.

n

Multiple services can be linked together into

composite applications.

q

Workflow

q

See for example Taverna

n Google “Taverna SourceForge” to find it.

(19)

Some General Advice

n

Keep you services self-contained with simple interfaces.

q Core problem in distributed systems is scalability.

q Services, like mash-ups, are intended to be put to unexpected

uses.

q Complication is the enemy.

q Services are NOT Distributed Objects

n http://www.allthingsdistributed.com/historical/archives/000343.html

n

Use XML Simple Types and URLs for input and output

rather than attachments.

n

Collect your input/output into Java Beans, C structs, etc,

but don’t go overboard.

q Interoperability can suffer if your I/O types are too complicated.

n Java<-->C, Axis 1<-->Axis2

q JavaBeans/POJOs are used frequently in IOC systems like

Spring and Java Server Faces.

(20)

Web Service Extensions

n

Web Services communicate with SOAP, and SOAP is

designed to be extensible.

n

Examples of Extensions

q Addressing: describes how SOAP messages can be conveyed

across multiple hops.

q Security: how to authenticate clients and servers, how to

authorize usage, etc.

q Reliability/ReliableMessaging: provides guaranteed delivery

through acknowledgements

n

Most of these are defined by specifications published by

OASIS.

q For more discussion, see

http://grids.ucs.indiana.edu/ptliupages/presentations/GGF15Web Services/

q For a critique by Shrideep Pallickara, see

(21)

WSDL 1.1 Overview

Marlon Pierce

Community Grids Lab

Indiana University

(22)

What Is WSDL?

n

Web Service Description Language

q

W3C specification

q

See ht

tp://www.w3.org/TR/wsdl fo

r the official “note” for

WSDL 1.1.

q

WSDL 1.1 never became a full “recommendation”.

q

WSDL 2.0 working draft just completed it’s public call for

comments.

n

This slide set will review WSDL 1.1, which is still the

“standard”.

(23)

Why Use WSDL?

n

WSDL uses XML to describe interfaces

q Programming language independent way to do this.

q So you can use (for example) C++ programs to remotely invoke Java

programs and vice versa.

n

Consider Web browsers and Web servers:

q All web browsers work pretty well with all web sites.

q You don’t care what kind of web server Amazon.com uses.

q Amazon doesn’t care if you use IE, Mozilla, Konqueror, Safari, etc. q You all speak HTTP.

n

WSDL (and SOAP) are a generalization of this.

n

Note I will describe WSDL from an Remote Procedure

Call/Remote Method Invocation point of view.

q But WSDL and SOAP also support more a more message-centric

point of view.

(24)

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”); }

(25)

The Echo Interface

/**

* All implementers of this interface must

* implement the echo() method.

*/

(26)

Now Use Echo As A Remote Service

n

We can take the previous

Java program and deploy

it in Tomcat as a service.

n

Clients can then invoke

the echo service.

q

WSDL tells them how to

do it.

q

Clients don’t need to

know anything about the

service implementation

or even language.

n

WSDL is the latest IDL

q

DCE and CORBA IDL

were two older examples.

C#

Client

WSDL

Tomcat+ Axis+Ech o

WSDL

(27)

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>

(28)

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:servicename="EchoService">

<wsdl:portbinding="impl:EchoSoapBinding" name="Echo">

<wsdlsoap:address location="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo" /> </wsdl:port>

</wsdl:service> </wsdl:definitions>

(29)

Writing WSDL

n

I’m sure you are impressed with the previous two

slides.

n

One could write WSDL by hand, but this is not the

usual way.

n

It was automatically generated by Apache Axis. Most

other Web service tools will do the same from your

service code.

n

We will go through the construction, though, for

understanding.

n

You should not think of WSDL (and SOAP) as

programming languages.

(30)

WSDL Parts

n Types

q Used to define custom message types

n Messages

q Abstraction of request and response messages that my client and

service need to communicate.

n PortTypes

q Contains a set of operations.

q Operations organize WSDL messages.

q Operation->method name, portType->java interface

n Bindings

q Binds the portType to a specific protocol (typically SOAP over

http).

q You can bind one portType to several different protocols by using

more than one port.

n Services

(31)
(32)

Namespaces

q

The WSDL document begins with several XML namespace

definitions.

q

Namespaces allow you to compose a single XML document

from several XML schemas.

q

Namespaces allow you to identify which schema an XML tag

comes from.

q

Avoids name conflicts.

q

See earlier XML lectures

q

As we will see, the Axis namespace generator went

overboard.

(33)

Front Matters: Namespace Definitions

<?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"> …

(34)

WSDL Types

(35)

What Does echoServiceInterface Look

Like In WSDL?

<?xml version="1.0" encoding="UTF-8" ?>

<wsdl:definitions …>

<wsdl:types />

<w

sd

l:message name="echoResponse">

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

</wsdl:message>

<wsd

l:

message name="echoRequest">

<wsdl:part name="in0" type="xsd:string" />

</wsdl:message>

</wsdl:definitions>

(36)

WSDL Types

n

WSDL messages don’t need to declare

types when just sending XML Schema

primitive objects.

n

EchoService just has string messages.

q

So no special types definitions are

needed in our WSDL.

(37)
(38)

When Would I Need A Custom Type?

n

Any time your Web Service needs to send data

formatted by anything other than XML Schema

built-in types, you must defbuilt-ine the type built-in WSDL.

n

Example:

Arrays

are not built-in types!

q

Arrays of strings, ints, etc., must be defined in the WSDL

<type></type> structure.

n

Another example:

JavaBeans

(or C structs or any

data classes with get/set methods) can be serialized

to XML.

q

Pass as messages to the remote endpoint.

q

Support for this in implementations is variable.

n

AXIS has limited support because they use their own

serializers.

(39)

How Does WSDL Encode String

Arrays?

n

Imagine that my echo service actually echoes

back an array of strings.

n

Arrays are not part of the built-in types, so I

will have to define them myself.

n

Luckily for us, SOAP defines arrays, so we

can import this definition.

(40)

String Array Example

<wsdl:types> <schema

targetNamespace="http://.../GCWS/services/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>

Create a new data type,

(41)

WSDL String Array Types

n

WSDL

<type/>

is nothing more than an extensibility

placeholder in WSDL.

n

Technically, the WSDL schema specifies that

<type> </type>

can contain a

<sequence>

of 0 or

more

<any>

tags.

q

Look at the WSDL schema.

n

And note that the

<any/>

tag acts like wildcard.

q

You can insert any sort of xml here.

q

This is a common XML/Web Service trick.

n

Type allows us to strongly type messages

q

Compare: strong versus weak typing in

(42)

Inserting a Type

n

Between <type></type>, we insert a <schema>.

n

Since arrays are defined in SOAP encoding rules, I next

import

the appropriate schema.

q

I import the definition of the SOAP Array and extend it

to a String array.

q

Typically imports also have “location” attributes

n “This namespace is located here for download.”

n

Next, insert our own local definition of a type called

“ArrayOf_xsd_string”.

n

This is a restricted extension of the SOAP Array complex

type.

q

We only allow 1 dimensional string arrays

q

It is also nillable—I am allowed to returna “null” value

(43)

Handling Other XML Types

n

You can also express other message arguments

as XML.

q

Examples: a purchase order, an SVG description of an

image, a GML description of a map.

n

In practice, these are handled by automatic

Bean serializers/deserializers.

q

Castor is an example: htt

p://www.castor.org/

q

XMLB

eans is another http

://xml.apache.org/xmlbeans/

n

These

are tools that make it easy to convert

between XML and JavaBeans.

n

By “JavaBeans” I mean objects that associate

simple get/set methods with all data.

(44)
(45)

WSDL Messages

n

The “message” section specifies

communications that will go on

between endpoints.

q

Gives each message a name (to be

used later for reference).

q

Specifies the type of message

n

Can be primitive types, like strings

(46)

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>

(47)

Our Echo Messages

<wsdl:message name="

echoResponse

">

<wsdl:part name="

echoReturn

"

type="

xsd:string

" />

</wsdl:message>

<wsdl:message name="

echoRequest

">

(48)

Echo Service Messages

n

Our echo service takes a string argument

and returns a string answer.

n

In WSDL, I first abstract these as

messages.

q

Echo needs two messages: request and

response

n

Note we have not yet said message is the

request and which is the response.

q

That is the job of the

portType

(49)

Structure of a Message

n

WSDL

<message>

elements have name attributes

and one or more

parts

.

q

The message name should be unique for the

document.

q

<operation>

elements will refer to messages by

name.

n

I need one

<part>

for each piece of data I need to

send in that message.

n

Each

<part>

is given a name and specifies its type.

q

<part>

types can point to

<wsdl:type>

definitions if

necessary.

(50)
(51)

WSDL portTypes

n

WSDL messages are only abstract

messages.

q

We bind them to

operations

within the

portType

.

n

The structure of the

portType

specifies (still

abstractly) how the messages are to be

used.

q

Think of operations-->java methods and

(52)

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>

(53)

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

" />

(54)

portType Message Patterns

n PortTypes support four types of messaging:

q One way: Client send a message to the service and doesn’t want a

response.

n <input> only.

q Request-Response: Client sends a message and waits for a

response.

n <input>, then <output>

q Solicit-Response: Service sends a message to the client first, then

the client responds.

n <output>, then <input>

q Notification: <output> only.

n These still are abstract. We must implement them using some

message protocol.

q HTTP units of transmission are request and response, so mapping

(55)

portType for EchoService

n

The echo service has one method, echo.

n

It takes one string argument and returns one

string.

n

In WSDL, the portType is “Echo”, the operation

is “echo”.

n

The messages are organized into input and

output.

q

Messages are placed here as appropriate.

q

That is, <input> takes the <echoRequest>

(56)

Parameter Order

n

This attribute of operation is used to specify

zero or more space-separated values.

n

The values give the order that the input

messages must be sent.

n

Echo is a bad example, since it only has one

(57)

WSDL Self-Referencing

n 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>

(58)

The Picture So Far…

Part

Input Message

Part

Input Message

PartPart

Output Message

portType

Operation

Input

Ouput

hasInput

(59)
(60)

WSDL SOAP Bindings

n

In the previous slide, we specify several things:

q

We will use SOAP/HTTP

q

We will use RPC encoding style

n

Other choice is literal “document” style.

q

We specify the namespace associated with

the Echo service input and output messages.

n

All of this corresponds to SOAP message parts.

(61)

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>

(62)

So Far…

n

We have defined abstract messages, which

have XML values.

q

Simple or custom-defined types.

n

We have grouped messages into operations

and operations into portTypes.

n

We are now ready to

bind

the portTypes to

(63)

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>

(64)

Binding tags

n

Binding tags are meant to bind the parts of

portTypes to sections of specific protocols.

q

SOAP, HTTP GET/POST, and MIME are provided in the

WSDL specification.

n

Bindings refer back to portTypes by name, just as

operations point to messages.

q

They are mirror images of the portTypes.

q

Each part is extended by schema elements for a particular

binding protocol (i.e. SOAP).

n

In our WSDL bindings, we will have two messages

(input and output).

q

Each corresponds to SOAP body sections, described later.

q

Additionally, we specify that the body should be encoded.

n That is, RPC encoded.

(65)

WSDL Internal References

portType

Operation

Input

Ouput

binding

Operation

Input

(66)

Structure of the Binding

n

<binding> tags are really just placeholders.

n

They are meant to be extended at specific places by

wsdl protocol bindings.

q

These protocol binding rules are defined in supplemental

schemas.

n

The following box figure summarizes these things

q

Green boxes are part of WSDL

n From the wsdl namespace, that is.

q

Red boxes are parts of the document from other schemas

(67)

Binding Structure

binding

Non-wsdl extension operation

Non-wsdl extension

input output

Non-wsdl

(68)

A little more on encoding...

n

We specify SOAP encoding

n

SOAP is a message format and needs a transport

protocol, so we specify HTTP.

n

Operation styles may be either “RPC” or “Document”.

q

We use RPC.

n

SOAP Body elements will be used to actually convey

message payloads.

q

RPC requires “encoded” payloads.

n

Each value (echo strings) is wrapped in an element

named after the operation.

n

Useful RPC processing on the server side.

q

Documents are literal (unencoded)

(69)

Binding Associations to SOAP

Binding SOAP RPC

Operation

WSDL

SOAP

SOAP Action

Input

Output

SOAP Body

(70)

Binding Restrictions

n

Binding elements point by name to

portTypes.

n

WSDL allows more than one binding element

to point to the same port type.

q

Why?

q

Because a service may support multiple,

(71)

What Does It Mean?

n

WSDL is not a programming language.

n

A service that exposes an WSDL interface is just

telling a client what it needs to do to

communicate with the service.

q

Send me strings and I will return strings.

q

I expect SOAP messages that include the strings in

the body.

q

I expect this body to be RPC encoded with the

operation name so that I will know which operation the

body contents belong to.

q

I will return SOAP messages that include Strings in

the body.

q

These will also be encoded so that you know what to

(72)
(73)

What Does This Look Like In WSDL?

<wsdl:definitions>

<wsdl:binding>

</wsdl:binding>

<wsd

l:

service name="EchoService">

<wsd

l:

port binding="impl:EchoSoapBinding"

name="Echo">

<wsdlsoap:address

location="http://grids.ucs.indiana.edu:8045/GCWS/ser

vices/Echo" />

</wsdl:port>

</wsdl:service>

(74)

Ports and Services

<wsdl:service name="EchoService">

<

wsdl:port

binding="impl:EchoSoapBinding"

name="Echo">

<wsdlsoap:address

location=“http://..../"/>

</wsdl:port>

(75)

Port and Service Tags

n

The service element is a collection of

ports.

q

That’s all it is for.

n

Ports are intended to point to actual

Web service locations

(76)

Ports and Services

n

A service can have more than one port.

n

Two ports can point back to the same binding

element.

q

Ports refer to bindings by name

q

This allows you to provide alternative service

locations.

n

The figure on next slide conceptually depicts

associating two ports to a single binding.

(77)

Port Associations to Bindings

Binding Service

Operation

Port #1

Input

Output

URL #1

(78)

Summary of WSDL

n

WSDL decouples remote service operations.

q

Types=custom message definitions.

n

Any data types not in the XML schema.

q

Message=name the messages that must be

exchanged and their data types, possibly

defined by <type>.

q

PortTypes=service interfaces

n

Operations=remote method signatures.

q

Bindings=mappings of portType operations to

real message formats

(79)

SOAP Intro and Message

Formats

Marlon Pierce

Community Grids Lab

Indiana University

(80)

SOAP Primary References

n

SOAP is defined by a number of links

q

h

ttp://www.w3.org/TR/soap/

n

Se

e primarily the “Primer” and “Messaging

Framework” links.

n

The actual SOAP schema is available from

htt

p://www.w3.org/2003/05/soap-envelope/

(81)

SOAP and Web Services

n

Our previous lectures have

looked at WSDL

q

Defines the interfaces for

remote services.

q

Provides guidelines for

constructing clients to the

service.

q

Tells the client how to

communicate with the

service.

n

The actual communications

are encoded with SOAP.

q

Transported by HTTP

Client

Service

WSDL

WSDL

SOAP

(82)

Beyond Client-Server

n SOAP assumes messages

have an originator, one or more ultimate receivers, and zero or more intermediaries.

n The reason is to support

distributed message processing.

n Implementing this message

routing is out of scope for SOAP.

q Assume each node is a

Tomcat server or JMS broker.

n That is, we can go beyond

(83)

SOAP in One Slide

n

SOAP is just a message format.

q

Must transport with HTTP, TCP, etc.

n

SOAP is independent of but can be connected

to WSDL.

n

SOAP provides rules for processing the

message as it passes through multiple steps.

n

SOAP payloads

(84)

Defining SOAP Messages

n

Given what you have learned about WSDL,

imagine it is your job to design the message

interchange layer.

q

What are the requirements?

n

Note SOAP actually predates WSDL, so this

(85)

Web Service Messaging Infrastructure Requirements?

n Define a message format

q Define a messaging XML schema

q Allow the message to contain arbitrary XML from other schemas.

n Keep It Simple and Extensible

q Messages may require advanced features like security, reliability, conversational

state, etc.

q KISS, so don’t design these but do design a place where this sort of advanced information can go.

n Add these capabilities in further specifications: WS-Security, WS-ReliableMessaging, etc. n Tell the message originator is something goes wrong.

n Define data encodings

q That is, you need to tell the message recipient the types of each piece of data.

n Define some RPC conventions that match WSDL

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

n Decide how to transport the message.

q Generalize it, since messages may pass through many entities.

n Decide what to do about non-XML payloads (movies, images, arbitrary

(86)
(87)

SOAP Basics

n

SOAP is often thought of as a protocol extension for

doing

Remote Procedure Calls

(RPC) over HTTP.

q

This is how it is often used.

n

This is not accurate:

SOAP is an XML message

format

for exchanging structured, typed data.

q

It may be used for RPC in client-server applications

q

May be used to send XML documents

q

Also suitable for messaging systems (like JMS) that

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

n

SOAP is not a transport protocol

. You must attach

(88)

What Does SOAP Look Like?

n

The next two slides shows examples of SOAP

message from our Echo service.

q

It’s just XML

n

First slide is an example message that might be

sent from a client to the echo service.

n

Second slide is an example response.

(89)

<?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>

(90)

<?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>

(91)

SOAP Structure

n

SOAP structure is very

simple.

q

0 or 1 header elements

q

1 body element

q

Envelop that wraps it all.

n

Body contains XML

payload.

n

Headers are structured the

same way.

q

Can contain additional

payloads of “metadata”

q

Security information,

quality of service, etc.

Envelope

Body

Message

Payload

(92)

SOAP Schema Notes

n All of this is expressed formally

in the SOAP schema.

q Which in turn derives from the

SOAP Infoset

n XML on the right is taken

directly from the SOAP schema.

n This just encodes the

previously stated rules.

n Also, note that the SOAP

envelope can contain other attributes.

q <anyAttribute> tag is the

wildcard

<xs:complexType

name="Envelope"> <xs:sequence>

<xs:element ref="tns:Header" minOccurs="0" />

<xs:element ref="tns:Body" minOccurs="1" />

</xs:sequence> <xs:anyAttribute

(93)

SOAP Envelop

n

The envelop is the root container of the SOAP

message.

n

Things to put in the envelop:

q

Namespaces you will need.

n http://schemas.xmlsoap.org/soap/envelope is required, so

that the recipient knows it has gotten a SOAP message.

n Others as necessary

q

Encoding rules (optional)

n Specific rules for deserializing the encoded SOAP data. n More later on this.

n

Header and body elements.

q

Headers are optional, body is mandatory.

q

Headers come first in the message, but we will look at

(94)

Options on

<xsd:any/>

n

The

<xsd:any/>

element takes the usual optional

maxOccurs

,

minOccurs

attributes.

n

Allows a

namespace

attribute taking one of the values:

q

##any

(the default),

q

##other

(any namespace except the target

namespace),

q

List of namespace names, optionally including either

##targetNamespace

or

##local

.

Controls what elements the wildcard matches, according to

namespace.

n

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.

(95)

Lax

n

“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.”

n

That is,

·

validate

·

message payloads when you can,

(96)

SOAP Headers

n SOAP Body elements contain the primary message contents. n Headers are really just extension points where you can

include elements from other namespaces.

q i.e., headers can contain arbitrary XML.

n Headers may be processed independently of the body. n Headers may optionally define encodingStyle.

n Headers may optionally have a “role” attribute

n Header entries may optionally have a “mustUnderstand

attribute.

q mustUnderstand=1 means the message recipient must

process the header element.

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

optional.

(97)

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>

(98)

Example Uses of Headers

n

Security

: WS-Security and SAML place

additional security information (like digital

signatures and public keys) in the header.

n

Quality of Service:

SOAP headers can be used

if we want to negotiate particular qualities of

service such as reliable message delivery and

transactions.

n

Session State Support:

Many services require

several steps and so will require maintenance of

session state.

q

Equivalent to cookies in HTTP.

(99)

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 Jógvan Øyvind</n:name> </n:passenger>

(100)

Explanation of Header Example

n In general, we can import tags into the header from name

spaces outside of soap.

q <reservation/>, <reference/>, <dataAndTime/>,<passenger/>

n SOAP doesn’t need to worry to much about these.

q It is the node’s job to process these things.

n In this particular case, we may imagine an ongoing

transaction for making an airline reservation.

q Involves several steps and messages, so client must remind

the server of this state information when sending a message.

q The actual header content all comes from other namespaces.

(101)

Header Processing

n

SOAP messages are allowed to pass through many

intermediaries before reaching their destination.

q

Intermediary=some unspecified routing application.

q

Imagine SOAP messages being passed through many

distinct nodes.

q

The final destination processes the body of the

message.

n

Headers are allowed to be processed independently of

the body.

q

May be processed by intermediaries.

n

This allows an intermediary application to determine if

(102)

Roles, Understanding, and Relays

Role

?

must Under

stand

Rela

y?

Forward

Header

No

Yes

Process

Header

Yes

No

Yes

No

Remove

(103)

Header Roles

n

SOAP nodes may be assigned role designations.

n

SOAP headers then specify which role or roles

should process.

n

Standard SOAP roles:

q

None

: SOAP nodes MUST NOT act in this role.

q

Next:

Each SOAP intermediary and the ultimate SOAP

receiver MUST act in this role.

q

UltimateReceiver:

The ultimate receiver MUST act in

this role.

n

In our example, all nodes must process the

(104)

SOAP Body

n

Body entries are really just placeholders for XML

from some other namespace.

n

The body contains the XML message that you

are transmitting.

n

It may also define encodingStyle, just as the

envelop.

n

The message format is not specified by SOAP.

q

The <Body></Body> tag pairs are just a way to notify

the recipient that the actual XML message is contained

therein.

(105)

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

" />

(106)

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>

(107)

Example SOAP Body Details

n

The <Body> tag is extended to include elements

defined in our Echo Service WSDL schema.

n

This particular style is called RPC.

q

Maps WSDL bindings to SOAP body elements.

q

Guidelines will be given in next lecture.

n

xsi-type is used to specify that the <in0> element

takes a string value.

q

This is data encoding

(108)

A Broader View of Web

Services

(109)

Representational State Transfer (REST)

q

The term REST was proposed by Roy Fielding

q Dissertation is available from

http://roy.gbiv.com/pubs/dissertation/top.htm

q Fielding is the first author of the HTTP 1.1 Spec, IETF RFC 2616)

q

The primary concept of REST is statelessness (or

idempotence).

q All invocations of the same method should give identical

responses.

q

Note REST does not have to transfer HTML

q One could build other client server applications on top of this. q Famous example: WebDAV (actually predates Fielding’s

dissertation).

q Modern examples: Atom and RSS feeds emit XML data that can

be easily parsed and used in applications.

q Commonly used in mash-ups. See Yahoo’s Pipes examples. q That is, RSS and Atom XML don’t have to be immediately

(110)

<?xml version='1.0' encoding='UTF-8'?>' <feed xmlns='http://www.w3.org/2005/Atom'

xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/'> <id>tag:blogger.com,1999:blog-19457310</id>

<updated>2007-03-30T14:10:58.184-07:00</updated>

<title type='text'>Marlon Pierce's Community Grids Lab Blog</title> <link rel='alternate' type='text/html'

href='http://communitygrids.blogspot.com/index.html'></link> <link rel='next' type='application/atom+xml'

href='http://communitygrids.blogspot.com/feeds/posts/default?start-index=26&amp;max-results=25'></link>

<link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml'

href='http://communitygrids.blogspot.com/feeds/posts/default'></link> <link rel='self' type='application/atom+xml'

href='http://communitygrids.blogspot.com/feeds/posts/default'></link> <author><name>Marlon Pierce</name></author> <generator version='7.00' uri='http://www2.blogger.com'>Blogger</generator> <openSearch:totalResults>76</openSearch:totalResults><openSearch:startInd ex>1</openSearch:startIndex> <entry><id>tag:blogger.com,1999:blog-19457310.post-4399342799160789059</id> <published>2007-03-29T18:24:00.000-07:00</published> <updated>2007-03-30T14:10:58.271-07:00</updated> <title type='text'>db4o Java Bean Database</title> <content type='html'>The db4o &lt;a

href="http://www.db4o.com/"&gt;http://www.db4o.com/&lt;/a&gt; project makes a very simple,

light-weight object database. It's free, too. Maybe too free, as they use GPL. But see comment below. Obviously this sort

of thing is great if you do a lot of POJO development (say, with JSF) and need some persistent storage.&lt;br /&gt;&lt;br /&gt;The downloadable

(111)

Atom and RSS Services?

q

Sure, why not? You can convey a lot of information

in a news feed.

q

Good for sequential science data

q

Seismic events

q

Recently docked drug-like molecules in on-going

simulations.

q

Also it is easy to build HTTP GET query interfaces.

q

Useful for conveying metadata about projects

q

http:/

/www.chembiogrid.org/wsrss/wsdlrss/getFeed lists

available Web services, which are frequently updated.

q

Useful tools:

q

Atomsphere

Java libraries

(112)

REST Vs. SOAP?

n

Actually, I think it is really REST versus WSDL.

n

REST applies the

same

API to all applications:

q

PUT, GET, POST, DELETE

q

These operations are applied to URLs

q

The actual URLs can point to XML files.

n XML could be SOAP, ATOM, RSS, ...

q

Clients and services may do additional processing of

the transmitted XML that is not in the API’s scope.

n

WSDL and XML-RPC define custom APIs

(113)

Realistic REST

q

From my experience, REST’s stateless

philosophy is generally a good idea, even if you

design and build SOAP+WSDL Web Services.

q

Some useful principals:

q

Make each service completely self-contained. The

WSDL should define everything you need to invoke

the service.

q

Use URLs as return values. This is especially useful

for scientific services that use input and output files.

q It’s much easier and more maintainable to use URLs to

transfer files that your service needs or generates.

q

Don’t use stateful communication protocols. Park

(114)

This is a portal client to a data mining service that I built. The web service

analyzes GPS signal data to look for modes.

Portal courtesy of NASA REASoN project.

GPS data comes from the Scripps GRWS Web Service. Instead of defining a data type for this file, we just pass around URLs. The RDAHMM service receives the URL as input.

The service returns output result files as URLs.

(115)

Apache S3 REST

n

Amazon’s Simple Storage Service (S3) provides a simple

for-fee online storage service.

n

Files are uploaded and downloaded using HTTP PUT and

GET operations.

n

Shared symmetric session keys are used to generate

unique, un-guessable URLs for files that can be

reproduced by the client without having to contact the

service.

n

It is all amazingly simple.

n

See docs at

q http://docs.amazonwebservices.com/AmazonS3/

n

See my notes at

q

Figure

Updating...

References