Web Service Foundations WSDL and SOAP

Document Sample
Web Service Foundations WSDL and SOAP Powered By Docstoc
					Web Service Foundations:

   Marlon Pierce
   Community Grids Lab, Indiana University
    What Are Web Services?
   Web services framework is an XML-based distributed services

     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
     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, client
       applications must be tolerant of failures.
Servlets/CGI Compared to Web Services

    Browser                                             GUI

           HTTP GET/POST    Web                        WSDL

     Server                                  Web

      DB                                     DB
    Explanation of Previous Slide
   The diagram on the left represents a standard web
       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.
   On the right, we have a Web services system.
       Separates visual from non-visual components
       Interactions may be either through the browser or
        through a desktop client (Java Swing, Python, Windows,
Some Terminology
   The diagram on the left is called a client/server system.
   The diagram on the right is called a multi-tiered
   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).
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
   CICC is building many new one for chemical informatics.
    RDAHMM: GPS Time Series Segmentation
    Slide Courtesy of Robert Granat, JPL
                                                    GPS displacement (3D)
                                                    length two years.

                                                    Divided automatically
                                                    by HMM into 7 classes.

                                                    • Dip due to aquifer
                                                      drainage (days 120-
                                                    • Hector Mine
                                                      earthquake (day 626)
                                                    • Noisy period at
                                                      end of time series

     Complex data with subtle signals is difficult for humans to
      analyze, leading to gaps in analysis
     HMM segmentation provides an automatic way to focus attention
      on the most interesting parts of the time
Making RDAHMM into a Web Service
                                      USAGE: GEMCodes/RDAHMM2/bin/rdahmm -data
   RDAHMM takes GPS (or                   'input observation sequence file'
    other) time-series data as          [-L 'output model log likelihood file']
                                        [-Q 'output optimal state sequence file']
    input, along with various           [-pi 'output model initial state probability file']
    command line                        [-A 'output model transition probability file']
                                        [-B 'output model output distribution file']
    parameters.                         [-minvalfile 'data minimum value file']
                                        [-maxvalfile 'data maximum value file file']
   GPS data comes from                 [-rangefile 'data range file']
    GRWS or other services.             [-covarsweightsfile 'covariance component weightings
       http://geoapp.ucsd.edu/scig     [-covgraphfile 'covariance graph connectivity file']
        nDataPortal/grwsSummary.j       -T 'number of observations'
        sp                              -D 'dimension of observations'
                                        -N 'number of model states'
   It creates 11 output files.         -output_type 'type of HMM output distribution {gauss}'
                                        [-init_type 'type of HMM parameter initialization
   Results are                            {random}']

    superimposed on the               .....
    input time series.
 This is a portal
 client to a data                         The service returns output result
 mining service                           files as URLs.
 that I built.
 The web
 analyzes GPS
 signal data to
 look for modes.

 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

                                            The lesson: don’t go overboard
                                            with XML message definitions.
Portal courtesy of NASA REASoN project.
                                            You will regret it. Use URLs and
                                            keep your SOAP/WSDL simple.
How Do You Design the RDAHMM
   First, you need an engine to run RDAHMM.
       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.
       You can embed Ant in other Java programs.
   Second, you need an appropriate Web Service
    container for your development environment.
       I use Apache Axis (examples will use version 1.4).
           This runs in Apache Tomcat.
       .NET, C/C++, Python, Ruby, Perl, etc all have Web
        Service containers.
           Ex: gSOAP for C/C++ from FSU, ZSI for Python
Writing the Service
   Writing a Web Service is easy
       Just write a Java program
   In our case, the Java program must
       Grab GPS data from GRWS service
           We pass this around using URLs.
       Collect command line parameter values as input.
       Run the code.
       Send back a response as a Java Bean that
        encapsulates URLs.
           Can either block or not-block, depending on how you want to
            execute things.
   This is a mixture of REST and XML-RPC styles.
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,
  minMaxLatLon, beginDate,
         return createRDAHMMBean( dataUrl,numModelStates);
  catch (Exception ex) {...}
   RDAHMMResultBean Code
   public class RDAHMMResultsBean
       implements java.io.Serializable {                      Nothing special about
     private java.lang.String AUrl;                            this code.
     private java.lang.String BUrl;
     private java.lang.String LUrl;                           Note all the returned
     private java.lang.String QUrl;                            values are actually
     private java.lang.String inputUrl;
      ....                                                     URLs.
     public RDAHMMResultsBean() {
                                                              AUrl, BUrl, LUrl, etc
     //Plus all of the getters and setters                     are all URLs to files
     public java.lang.String getInputUrl() {
       return inputUrl; }
                                                               generated by
     public void setInputUrl(java.lang.String                  RDAHMM.
       inputUrl) { this.inputUrl = inputUrl; }

Deploying an Axis 1 Service
   Now that you have written the code, you
    follow these steps to make it into a service.
   Download Axis and install it into Tomcat.
       That is, create a subdirectory of webapps and put
        all the Axis jars in WEB-INF/lib/.
   Create a service descriptor file, service-
    config.wsdd and put this in WEB-INF/
       Axis gives you tools to help.
   Compile your code and put it in WEB-
    INF/classes or WEB-INF/lib (if jarred).
Creating an Axis Client
   Axis will inspect your newly deployed service and create a
    WSDL file out of it.
       More on this in a minute.
   WSDL is an XML API description.
       It tells clients how to invoke your service.
       Typically the service is invoked by sending a SOAP message, so
        WSDL tells you how to construct SOAP.
   Clients typically discover and download the WSDL (UDDI,
    wget, whatever).
   Axis has a tool called WSDL2Java that will convert the
    WSDL into client stubs.
       Stubs give you local objects that invoke the remote service.
   Clients can be anything
       JSP pages, Java Portlets, PHP clients, Swing or SWT GUIs, etc.
Some Notes on Axis 2
   Axis 2 is a redesign of Axis 1 that has
       Greater performance (using StAX XML parsers)
       Extensiblity to support Web Service Quality of Service
       Better support for Java-to-XML binding frameworks.
   Allows you to send and receive more
    complicated XML messages.
       But I think you should avoid this.
   See my notes:
       http://communitygrids.blogspot.com/2007/02/some-
Some Additional Notes
   Typically, you don’t need to import any Axis
    specific packages.
       Exception: finding and loading a property file.
   If you are familiar with JSP, servlets, or
    similar things, you will notice that you also
       Need to manage HTTP request, response, and
        session variables.
   This style of programming is similar to the
    Inversion of Control Pattern (IOC).
       Very useful when dealing with Java Beans.
What Have We Gained from This?
   We have decoupled the RDAHMM client and the
       Now separated using well-defined interfaces.
       One service can be used by multiple, independently
        developed clients.
       Services just do one thing really well. Application
        “smarts” are in the client.
   Multiple services can be linked together into
    composite applications.
       Workflow
       See for example Taverna
           Google “Taverna SourceForge” to find it.
       Others: Kepler, XBaya (from IU)
Some General Advice
   Keep you services self-contained with simple interfaces.
       Core problem in distributed systems is scalability.
       Services, like mash-ups, are intended to be put to unexpected
       Complication is the enemy.
       Services are NOT Distributed Objects
           http://www.allthingsdistributed.com/historical/archives/000343.html
   Use XML Simple Types and URLs for input and output
    rather than attachments.
   Collect your input/output into Java Beans, C structs, etc,
    but don’t go overboard.
       Interoperability can suffer if your I/O types are too complicated.
           Java<-->C, Axis 1<-->Axis2
       JavaBeans/POJOs are used frequently in IOC systems like
        Spring and Java Server Faces.
       Db4o is a really nice JavaBean database.
Web Service Extensions
   Web Services communicate with SOAP, and SOAP is
    designed to be extensible.
   Examples of Extensions
       Addressing: describes how SOAP messages can be conveyed
        across multiple hops.
       Security: how to authenticate clients and servers, how to
        authorize usage, etc.
       Reliability/ReliableMessaging: provides guaranteed delivery
        through acknowledgements
   Most of these are defined by specifications published by
       For more discussion, see
       For a critique by Shrideep Pallickara, see
WSDL 1.1 Overview

   Marlon Pierce
   Community Grids Lab
   Indiana University
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 it’s public call for
   This slide set will review WSDL 1.1, which is still the
       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.
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                             Client
    it in Tomcat as a service.                      WSDL
   Clients can then invoke
    the echo service.
                                   SOAP(Echo “hello”)            “hello”
       WSDL tells them how to
        do it.
       Clients don’t need to
        know anything about the                     WSDL
        service implementation
        or even language.                           Tomcat+
   WSDL is the latest IDL                         Axis+Echo
       DCE and CORBA IDL
        were two older examples.
    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"
 <wsdl:types />
<wsdl:message name="echoResponse">
   <wsdl:part name="echoReturn" type="xsd:string" />
   <wsdl:message name="echoRequest">
   <wsdl:part name="in0" type="xsd:string" />
<wsdl:portType name="Echo">
   <wsdl:operation name="echo" parameterOrder="in0">
          <wsdl:input message="impl:echoRequest" name="echoRequest" />
          <wsdl:output message="impl:echoResponse" name="echoResponse" />
                                                    There’s more…
      What Does This Look Like In WSDL,
<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: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:service name="EchoService">
    <wsdl:port binding="impl:EchoSoapBinding" name="Echo">
              <wsdlsoap:address location="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo" />

                                         Don’t strain your eyes. We will break this down
    Writing WSDL
   I’m sure you are impressed with the previous two
   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
   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
     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
 The WSDL document begins with several XML namespace
 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
   Not all of these are used.
    Front Matters: Namespace Definitions
<?xml version="1.0" encoding="UTF-8" ?>
WSDL Types

   Use <types/> to declare local message
  What Does echoServiceInterface Look
  Like In WSDL?
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions …>
 <wsdl:types />
                                It’s empty...
<wsdl:message name="echoResponse">
  <wsdl:part name="echoReturn" type="xsd:string" />
  <wsdl:message name="echoRequest">
  <wsdl:part name="in0" type="xsd:string" />
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 Custom 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
         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
        namespace="http://schemas.xmlsoap.org/soap/encoding/" />
     <complexType name="ArrayOf_xsd_string">
        <complexContent>                           Create a new data
          <restriction base="soapenc:Array">
            <attribute ref="soapenc:arrayType"
                  wsdl:arrayType="xsd:string[]" /> that is a restricted
                                                   extension of the
                                                   general SOAP array
     <element name="ArrayOf_xsd_string" nillable="true"
        type="impl:ArrayOf_xsd_string" />
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.
     This is a common XML/Web Service trick.

   Type allows us to strongly type messages
       Compare: strong versus weak typing in
        programming languages
    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
   This is a restricted extension of the SOAP Array complex
     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
The echoServiceInterface messages
<?xml version="1.0" encoding="UTF-8" ?>
 <wsdl:types />
<wsdl:message name="echoResponse">
   <wsdl:part name="echoReturn" type="xsd:string" />
<wsdl:message name="echoRequest">
   <wsdl:part name="in0" type="xsd:string" />
<wsdl:portType name="Echo">
   <wsdl:operation name="echo" parameterOrder="in0">
        <wsdl:input message="impl:echoRequest" name="echoRequest" />
        <wsdl:output message="impl:echoResponse" name="echoResponse"
  Our Echo Messages
<wsdl:message name="echoResponse">
  <wsdl:part name="echoReturn"
     type="xsd:string" />
<wsdl:message name="echoRequest">
  <wsdl:part name="in0" type="xsd:string" />
Echo Service Messages
   Our echo service takes a string argument
    and returns a string answer.
   In WSDL, I first abstract these as
     Echo needs two messages: request and
   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
     <operation> elements will refer to messages by
   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
     Our service just needs xsd:strings, so no problem.
PortTypes and Operations
    WSDL portTypes
   WSDL messages are only abstract
       We bind them to operations within the portType.
   The structure of the portType specifies (still
    abstractly) how the messages are to be
       Think of operations-->java methods and
        portTypes-->java interfaces.
 The echoServiceInterface portType
<?xml version="1.0" encoding="UTF-8" ?>
 <wsdl:types />
<wsdl:message name="echoResponse">
   <wsdl:part name="echoReturn" type="xsd:string" />
   <wsdl:message name="echoRequest">
   <wsdl:part name="in0" type="xsd:string" />
<wsdl:portType name="Echo">
   <wsdl:operation name="echo" parameterOrder="in0">
        <wsdl:input message="impl:echoRequest" name="echoRequest" />
        <wsdl:output message="impl:echoResponse"
   name="echoResponse" />
   EchoService portType
<wsdl:portType name="Echo">
  <wsdl:operation name="echo" parameterOrder="in0">
      name="echoRequest" />
      name="echoResponse" />
        portType Message Patterns
   PortTypes support four types of messaging:
     One way: Client send a message to the service and doesn’t want a
           <input> only.
       Request-Response: Client sends a message and waits for a
           <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
   In WSDL, the portType is “Echo”, the operation
    is “echo”.
   The messages are organized into input and
     Messages are placed here as appropriate.

     That is, <input> takes the <echoRequest>
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:portType name="Echo">
    <wsdl:operation name="echo" parameterOrder="in0">
           <wsdl:output message="impl:echoResponse"
           name="echoResponse" />
The Picture So Far…

 Input Message
  Input Message       portType
      Part            Operation


 Output Message
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: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">
                            use="encoded" />
              <wsdl:output name="echoResponse">
              use="encoded" />
<wsdl:service name="EchoService">
    <wsdl:port binding="impl:EchoSoapBinding" name="Echo">
              <wsdlsoap:address location="http://grids.ucs.indiana.edu:8045/GCWS/services/Echo" />

                                                 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
<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">
          namespace=“[echo service namespace URI]"
          use="encoded" />
    <wsdl:output name="echoResponse">
      <wsdlsoap:body         encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          namespace=“[echo service namespace URI]"
          use="encoded" />
</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
   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


    Non-wsdl extension


       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 SOAP
       WSDL                 SOAP

  Binding             SOAP RPC

    Operation           SOAP Action

            Input         SOAP Body

        Output            SOAP Body
Binding Restrictions

   Binding elements point by name to
   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?
<wsdl:service name="EchoService">
  <wsdl:port binding="impl:EchoSoapBinding"
  vices/Echo" />
Ports and Services
<wsdl:service name="EchoService">
Port and Service Tags
   The service element is a collection of
       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
       Ports refer to bindings by name
       This allows you to provide alternative service
   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

                           Port #1

                                  URL #1

                           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
    Marlon Pierce
    Community Grids Lab
    Indiana University
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
       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            Response
     Tells the client how to
       communicate with the                    WSDL
   The actual communications              Service
    are encoded with SOAP.
     Transported by HTTP
Beyond Client-Server
   SOAP assumes messages
    have an originator, one or
    more ultimate receivers, and   Originator                  Recipient
    zero or more intermediaries.
   The reason is to support
    distributed message
   Implementing this message                        Intermediary
    routing is out of scope for
       Assume each node is a
        Tomcat server or JMS
   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 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 (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

<?xml version=‘1.0’ ?>
      <in0 xsi:type="xsd:string">Hollow World</in0>
  SOAP Response
<?xml version=‘1.0’ ?>
     <echoReturn xsi:type=“String“>
       Hollow World
    SOAP Structure
   SOAP structure is very         Envelope
     0 or 1 header elements

     1 body element                Header
     Envelop that wraps it all.

   Body contains XML
   Headers are structured the      Body
    same way.
     Can contain additional
       payloads of “metadata”      Message
     Security information,        Payload
       quality of service, etc.
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
   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.
        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
       List of namespace names, optionally including either
        ##targetNamespace or ##local.
    Controls what elements the wildcard matches, according to
   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.

   “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”
     mustUnderstand=1 means the message recipient must
       process the header element.
     If mustUnderstand=0 or is missing, the header element is
   Headers may also have a “relay” attribute.
Header Definition From SOAP Schema
<xs:element name="Header" type="tns:Header" />
 <xs:complexType name="Header">
     <xs:documentation>Elements replacing the wildcard MUST be
        namespace qualified, but can be in the
        <xs:any namespace="##any" processContents="lax"
        minOccurs="0" maxOccurs="unbounded" />
   <xs:anyAttribute namespace="##other" processContents="lax" />
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
   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-
   <m:reservation xmlns:m=“http://my.example.com/"
   envelope/role/next" env:mustUnderstand="true">
   <n:passenger xmlns:n=“…"
   envelope/role/next" env:mustUnderstand="true">
        <n:name>Åke Jógvan Øyvind</n:name>
Explanation of Header Example

   In general, we can import tags into the header from name
    spaces outside of soap.
     <reservation/>, <reference/>, <dataAndTime/>,<passenger/>

   SOAP doesn’t need to worry to much about these.
     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
   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
  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.
   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
   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
       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:any namespace="##any"
        processContents="lax" minOccurs="0“
        maxOccurs="unbounded" />
    <xs:anyAttribute namespace="##other"
      processContents="lax" />
SOAP Body Example
 <ns1:echo soapenv:encodingStyle=
      <in0 xsi:type="xsd:string">Hollow
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.
A Broader View of Web

   Beyond WSDL, SOAP, and the OASIS
Representational State Transfer (REST)
   The term REST was proposed by Roy Fielding
       Dissertation is available from
       Fielding is the first author of the HTTP 1.1 Spec, IETF RFC 2616)
   The primary concept of REST is statelessness (or
       All invocations of the same method should give identical
   Note REST does not have to transfer HTML
       One could build other client server applications on top of this.
       Famous example: WebDAV (actually predates Fielding’s
       Modern examples: Atom and RSS feeds emit XML data that can
        be easily parsed and used in applications.
       Commonly used in mash-ups. See Yahoo’s Pipes examples.
       That is, RSS and Atom XML don’t have to be immediately
        rendered for presentations.
<?xml version='1.0' encoding='UTF-8'?>'
<feed xmlns='http://www.w3.org/2005/Atom'
<title type='text'>Marlon Pierce's Community Grids Lab Blog</title>
<link rel='alternate' type='text/html'
<link rel='next' type='application/atom+xml'
<link rel='http://schemas.google.com/g/2005#feed'
<link rel='self' type='application/atom+xml'
<author><name>Marlon Pierce</name></author>
<generator version='7.00'
<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
documentation is pretty good, as is this article:
Atom and RSS Services?
   Sure, why not? You can convey a lot of information
    in a news feed.
   Good for sequential science data
       Seismic events
       Recently docked drug-like molecules in on-going
   Also it is easy to build HTTP GET query interfaces.
   Useful for conveying metadata about projects
       http://www.chembiogrid.org/wsrss/wsdlrss/getFeed lists
        available Web services, which are frequently updated.
   Useful tools:
       Atomsphere Java libraries
       SimplePie RSS libraries for PHP
   Actually, I think it is really REST versus WSDL.
   REST applies the same API to all applications:
       These operations are applied to URLs
       The actual URLs can point to XML files.
           XML could be SOAP, ATOM, RSS, ...
       Clients and services may do additional processing of
        the transmitted XML that is not in the API’s scope.
   WSDL and XML-RPC define custom APIs
    specific to the application.
Realistic REST
   From my experience, REST’s stateless
    philosophy is generally a good idea, even if you
    design and build SOAP+WSDL Web Services.
   Some useful principals:
       Make each service completely self-contained. The
        WSDL should define everything you need to invoke
        the service.
       Use URLs as return values. This is especially useful
        for scientific services that use input and output files.
           It’s much easier and more maintainable to use URLs to
            transfer files that your service needs or generates.
       Don’t use stateful communication protocols. Park
        state information in a URL or in a WS-Context service.
 This is a portal
 client to a data                         The service returns output result
 mining service                           files as URLs.
 that I built.
 The web
 analyzes GPS
 signal data to
 look for modes.

 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

                                            The lesson: don’t go overboard
                                            with XML message definitions.
Portal courtesy of NASA REASoN project.
                                            You will regret it. Use URLs and
                                            keep your SOAP/WSDL simple.
Apache S3 REST
   Amazon’s Simple Storage Service (S3) provides a simple
    for-fee online storage service.
   Files are uploaded and downloaded using HTTP PUT and
    GET operations.
   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.
   It is all amazingly simple.
   See docs at
       http://docs.amazonwebservices.com/AmazonS3/
   See my notes at
       http://communitygrids.blogspot.com/2007/02/notes-on-amazon-