Web services - content

• What are web services?
• Web services description language (WSDL)
• Simple Object Access Protocol (SOAP)
• Session management
• Security
• Universal Description, Discovery and Integration (UDDI)

Web services

• Web services are one of the hot new topics, about to "revolutionise the web"
• There are many definitions of Web services
  • A web service is a server application that can be invoked using the HTTP protocol by SOAP calls
  • A Web service is anything that uses the Web (HTTP) protocol
  • A Web service is an B2B internet application
  • A Web service is anything that uses the internet
• We mean the first definition

Web services

• From the WWW Consortium:
  A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols
• Web services allow applications and agents to browse the Web on behalf of users
• Instead of a user navigating HTML screens, an agent can connect to services on the Web and interact with them directly without the distraction of presentation elements
• SOAP/WSDL/UDDI are the technologies behind Web services

Scope of tutorial

• Realistically, Web services are just the same old middleware story under a new guise
• Cover enough background on middleware to see where Web services fit in
• Deal with Web services at the technical levels of WSDL, SOAP and UDDI
• Discuss language bindings and programming environments
• Talk about both good and bad sides of Web services
• You should leave with enough knowledge of how to implement a Web service, and their weaknesses and strengths

Gartner software state

Gartner regularly publishes a graph on the state of software. The latest (at August 2002) is

Web Service Structure

Web Service Components

• WSDL (Web Services Description Language) is the metalanguage used to describe a Web service. It corresponds to the IDL (Interface Definition Language) of other RPC systems
• SOAP (Simple Object Access Protocol) is the wire format for remote method calls and their replies. It corresponds to the XDR level of Sun's RPC
• UDDI (Universal Description, Discovery and Integration) is the resource registration and lookup mechanism. It corresponds to the Naming Services of CORBA, RMI

Example Web Services

The site XMethods (www.xmethods.com) is an open site for registering Web services. It includes

• Zip code to geographical coordinates
• Car rental quotes
• Nasdaq stock exchange quotes
• California weather service
• Access Amazon.com using SOAP
• Slashdot news feed
• Note: well over half of the "services" on this site are not Web services at all, but things like ordinary HTML Web pages

Web Service Environmental Support

Web services are basically RPC across port 80. They require the following environmental support

• An HTTP server configured to pass Web service requests to a CGI script/servlet/JSP/ASP/...
• A user agent that is not a browser to prepare Web method requests and understand responses
• The user agent may make use of a browser for handling HTTP requests from the user side
• Firewall access to allow arbitrary content to pass on port 80 (exploit a security hole!)

Web Service Standards Requirements

• Web services use XML extensively, and use XML DTD's and Schema
• XML-defined standard data types are used
• XML generators and parsers are required (places requirements on PDAs)

Ordinary Procedure Call

• The imperative languages use the procedure as a means of structuring the language. The language will have conditionals, loops and procedure calls.
• When a procedure is called, it usually makes use of the stack, pushing parameters onto the stack and reserving space for local variables

Remote Procedure Call

Web Services Remote Procedure Call

Components of RPC

An RPC system consists of the following pieces

• A set of data types that can be sent as parameters and received as results
• A representation of these data types on the wire
• A message format for sending procedure name and parameters and getting procedure reply
• A means of representing the procedures and their signatures (parameters and result types) in a form independent of implementation - this will be used to generate two implementations, one on the client side, the other on the server. This acts as a specification of a remote procedure call
• A mechanism for automatically generating a client stub
• A mechanism for automatically generating a server stub
• A way of linking the server-side implementation of the procedure to the server stub so that the stub can call it
• Address of the service
• Locating the service

Web Services and Standardisation

Missing parts

• Security - HTTPS can be used, but this is external rather than a Web service mechanism
• Session management
• Transactions and general flow control

These are coming (?), but aren't here yet

WSDL

Role of Specification Languages

• A specification is an implementation-free description of a service
• A specification should be understandable by all implementors
• A specification may be of syntax only, or include some semantics
• Syntax is easy: Sun RPC, CORBA IDL, Java interfaces
• Semantics is hard
  • Meaning is impossible (e.g. Z, pre/post)
  • Environment is possible (e.g. where it runs)

Simple Service

• A service to convert millimetres to inches and vice versa may be described informally as

  
        Converter service:
            float inchToMM(float)
            float mmToInch(float)
        

• The description includes no semantics
• It includes no environment

CORBA

A CORBA IDL specification would look like

    interface Converter {
        float inchToMM(in float value);
        float mmToInch(in float value);
    };

Java RMI

A Java RMI specification would look like

    public interface Converter implements Remote {
        public float inchToMM(float value)
                     throws RemoteException;
        public float mmToInch(float value)
                     throws RemoteException;
    }

WSDL

The WSDL specification looks like

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:tns="urn:Converter" targetNamespace="urn:Converter" name="ConverterService">
    <message name="inchToMMRequest">
        <part name="param1" type="xsd:float"/>
    </message>
    <message name="inchToMMResponse">
        <part name="return" type="xsd:float"/>
    </message>
    <message name="mmToInchRequest">
        <part name="param1" type="xsd:float"/>
    </message>
    <message name="mmToInchResponse">
        <part name="return" type="xsd:float"/>
    </message>
    <message name="java_rmi_RemoteException">
        <part type="xsd:string" name="java_rmi_RemoteException"/>
    </message>
    <message name="com_iona_xmlbus_webservices_ejbserver_ConversionException">
        <part type="xsd:string" name="com_iona_xmlbus_webservices_ejbserver_ConversionException"/>
    </message>
    <portType name="ConverterPortType">
        <operation name="inchToMM">
            <input message="tns:inchToMMRequest" name="inchToMM"/>
            <output message="tns:inchToMMResponse" name="inchToMMResponse"/>
            <fault message="tns:java_rmi_RemoteException" name="java_rmi_RemoteException"/>
        </operation>
        <operation name="mmToInch">
            <input message="tns:mmToInchRequest" name="mmToInch"/>
            <output message="tns:mmToInchResponse" name="mmToInchResponse"/>
            <fault message="tns:java_rmi_RemoteException" name="java_rmi_RemoteException"/>
            <fault
                message="tns:com_iona_xmlbus_webservices_ejbserver_ConversionException" name="com_iona_xmlbus_webservices_ejbserver_ConversionException"/>
        </operation>
    </portType>
    <binding name="ConverterBinding" type="tns:ConverterPortType">
        <soap:binding transport="http://schemas.xmlsoap.org/soap/http/" style="rpc"/>
        <operation name="inchToMM">
            <soap:operation soapAction="" style="rpc"/>
            <input name="inchToMM">
                <soap:body use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </input>
            <output name="inchToMMResponse">
                <soap:body use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </output>
            <fault name="java_rmi_RemoteException">
                <soap:fault name="java_rmi_RemoteException"
                    use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </fault>
        </operation>
        <operation name="mmToInch">
            <soap:operation soapAction="" style="rpc"/>
            <input name="mmToInch">
                <soap:body use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </input>
            <output name="mmToInchResponse">
                <soap:body use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </output>
            <fault name="java_rmi_RemoteException">
                <soap:fault name="java_rmi_RemoteException"
                    use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </fault>
            <fault name="com_iona_xmlbus_webservices_ejbserver_ConversionException">
                <soap:fault
                    name="com_iona_xmlbus_webservices_ejbserver_ConversionException"
                    use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </fault>
        </operation>
    </binding>
    <service name="Converter">
        <port name="ConverterPort" binding="tns:ConverterBinding">
            <soap:address location="http://www.xmlbus.com:9010/ionasoap/servlet/Converter"/>
        </port>
    </service>
</definitions>

Components of WSDL Specification

Data types

• XML data types are okay
• Add extra data types here

Messages

• inchToMMRequest
• inchToMMResponse
• java_rmi_RemoteException
• ...

Ports

• inchToMM(inchToMMRequest, inchToMMResponse, java_rmi_RemoteException)
• ...

Bindings

• 
        ConverterBinding
        operation: inchToMM/rpc
                   "inchToMM"
                   "inchToMMResponse"
                   "java_rmi_RemoteException"
        

• ...

Service

      name: Converter
      

      address: http://...
      ...
      

WSDL Specification Revisited

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:tns="urn:Converter" targetNamespace="urn:Converter" name="ConverterService">

    <message name="inchToMMRequest">
        <part name="param1" type="xsd:float"/>
    </message>
    <message name="inchToMMResponse">
        <part name="return" type="xsd:float"/>
    </message>
    <message name="mmToInchRequest">
        <part name="param1" type="xsd:float"/>
    </message>
    <message name="mmToInchResponse">
        <part name="return" type="xsd:float"/>
    </message>
    <message name="java_rmi_RemoteException">
        <part type="xsd:string" name="java_rmi_RemoteException"/>
    </message>
    <message name="com_iona_xmlbus_webservices_ejbserver_ConversionException">
        <part type="xsd:string" name="com_iona_xmlbus_webservices_ejbserver_ConversionException"/>
    </message>

    <portType name="ConverterPortType">
        <operation name="inchToMM">
            <input message="tns:inchToMMRequest" name="inchToMM"/>
            <output message="tns:inchToMMResponse" name="inchToMMResponse"/>
            <fault message="tns:java_rmi_RemoteException" name="java_rmi_RemoteException"/>
        </operation>
        <operation name="mmToInch">
            <input message="tns:mmToInchRequest" name="mmToInch"/>
            <output message="tns:mmToInchResponse" name="mmToInchResponse"/>
            <fault message="tns:java_rmi_RemoteException" name="java_rmi_RemoteException"/>
            <fault
                message="tns:com_iona_xmlbus_webservices_ejbserver_ConversionException" name="com_iona_xmlbus_webservices_ejbserver_ConversionException"/>
        </operation>
    </portType>

    <binding name="ConverterBinding" type="tns:ConverterPortType">
        <soap:binding transport="http://schemas.xmlsoap.org/soap/http/" style="rpc"/>
        <operation name="inchToMM">
            <soap:operation soapAction="" style="rpc"/>
            <input name="inchToMM">
                <soap:body use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </input>
            <output name="inchToMMResponse">
                <soap:body use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </output>
            <fault name="java_rmi_RemoteException">
                <soap:fault name="java_rmi_RemoteException"
                    use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </fault>
        </operation>
        <operation name="mmToInch">
            <soap:operation soapAction="" style="rpc"/>
            <input name="mmToInch">
                <soap:body use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </input>
            <output name="mmToInchResponse">
                <soap:body use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </output>
            <fault name="java_rmi_RemoteException">
                <soap:fault name="java_rmi_RemoteException"
                    use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </fault>
            <fault name="com_iona_xmlbus_webservices_ejbserver_ConversionException">
                <soap:fault
                    name="com_iona_xmlbus_webservices_ejbserver_ConversionException"
                    use="encoded" namespace="urn:Converter" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
            </fault>
        </operation>
    </binding>

    <service name="Converter">
        <port name="ConverterPort" binding="tns:ConverterBinding">
            <soap:address location="http://www.xmlbus.com:9010/ionasoap/servlet/Converter"/>
        </port>
    </service>

</definitions>

WSDL Versions

• WSDL version 1.2 is undergoing finalisation by the W3C
• It cleans up WSDL v1.1, and is incompatable with it (e.g. more namespace use, elimination of operator overloading)
• But that doesn't matter, since no-one will ever write the stuff...

Role of WSDL in Web Services

• Implement a service using your favourite programming language (Java, C#, VB, ...)
• Reverse engineer this to a WSDL spec using a tool supplied by your Web Service vendor
• Forward engineer this to your next favourite language

Apache Axis WSDL Tools

• Axis is available from www.apache.org, and builds on the IBM Web Services Toolkit (WSTK)
• If a web service is available from Axis, then you can download a WSDL description to a browser by calling the web service URL with "?WSDL" appended. It may not show up as anything readable: the browser will fail to interpret most of the tags, but it can be saved to a file
• In the WSTK 3.2 you can either give a Java interface and generate a WSDL interface, or a Java class (earlier versions would not accept an interface)
• e.g

  
        interface ConverterInterface {
            float inchToMM(float value);
  	  float mmToInch(float value);
        };
        

• Then run a WSDL generator

  
        AXIS_LIB=/usr/local/axis-1_1/lib # change this for your lib dir
        for i in $AXIS_LIB/*.jar
        do
            CP=$CP:$i
        done
        java -cp "$CP" org.apache.axis.wsdl.Java2WSDL \
            -o ConverterInterface.apache.wsdl \
            -l http://localhost/wstk/services/ConverterInterface \
             ConverterInterface
        

• A Java interface can be created from a WSDL spec by

  
        java -cp $WSTK_CP org.apache.axis.wsdl.WSDL2Java \
             ConverterInterface.ibm.wsdl
        

• Stub and tie generation will be dealt with later

There and Back Again

• Java -> WSDL -> Java may give a different result to what you started from
• Original

  
      interface ConverterInterface {
          float inchToMM(float value);
          float mmToInch(float value);
  };
        

• Round trip

  
      package DefaultNamespace;
  
      public interface Converter extends java.rmi.Remote {
          public float inchToMM(float in0) throws java.rmi.RemoteException;
          public float mmToInch(float in0) throws java.rmi.RemoteException;
      }
        

Conclusion

• WSDL is a totally obscure specification language
• It would be extremely difficuly to generate a correct WSDL document by hand
• The reverse of good s/w engineering principles is followed: write the code and then reverse-engineer the specification
• The implementations of WSDL vary in quality

SOAP

What SOAP Claims to be

• SOAP is "Simple Object Access Protocol"
• It is "a lightweight protocol for exchange of information in a decentralized, distributed environment"
• "It is an XML based protocol..."

What SOAP is

• Basically, SOAP/WSDL/UDDI is the latest in RPC technologies
• It is the first open standard RPC supported by Microsoft, and was originally developed by Microsoft, IBM and Artima
• It is now part of the W3C standards track
• Version 1.2 is under finalisation by W3C
• SOAP consists of
  • A description of allowable data types
  • A message format
  • A binding to HTTP transport, and (non-normative) examples of other bindings (e.g. email)

What SOAP isn't

• It isn't object oriented - it is procedural
• It isn't simple - it requires an understanding of XML, including XML namespaces
• It isn't lightweight - it needs XML generators/parsers on client and server sides, and just sending a one-byte character of payload can use 1000 bytes of message
• It isn't complete as an RPC system (e.g. no standardisation of language bindings)

XML Descriptions

• XML currently uses two systems for describing XML documents
• XML DTDs (Document Type Definitions) are good for describing document structure
• XML Schema are good for describing data types
• Both may be needed

XML DTDs

XML DTDs (Document Type Definitions) are good for describing document structure e.g.

• A book consists of a preface followed by one or more chapters followed by an index
• A chapter is made up of one or more sections
• A section consists of text
• The DTD for this is

  
        <!ELEMENT book (preface?, chapter+, index)>
        <!ELEMENT chapter (section+)>
        <!ELEMENT section (#PCDATA)>
        

XML Schema

• Schema are good for data type descriptions
• For example, if you want to have the data

        <age> 45 </age>
        <height> 5.9 </height>
        <color> blue </color>
        

• then you would describe the data type using the schema

        <element name="age" type="positiveInteger"/>
        <element name="height" type="float"/>
        <element name="color">
          <simpleType base="xsd:string">
            <enumeration value="green">
            <enumeration value="blue">
          </simpleType>
        </element>
        

• XML Schema also describes how to make lists and unions of other data types. e.g. for a list

        <simpleType name='sizes'>
            <list itemType='decimal'/>
        <simpleType>
        

  with example data

        <cerealSizes xsi:type='sizes'> 8 10.5 12 </cerealSizes>
        

XML Schema Standard Data Types

SOAP Messages

SOAP messages are either

• a request for a service
• a response from a service

Java mapping of data types

Most XML standard data type are represented by a Java data type

Some types can't be represented since they don't exist in Java, such as unsigned int. If a type can be "nillable" (that is, have a nil value) and it would be a Java primitive type, then it is wrapped in a Java class such as Integer.

SOAP Request

A SOAP request consists of

• The envelope which defines the various namespaces used by the rest of the message
• The header is optional, and can carry authentication, payments, etc
• The body carries the payload of the message. For RPC it contains
  • the method/procedure name
  • the arguments

SOAP Response

A SOAP response is just like a request, except the body contains the result.

SOAP Message Structure

<?xml version="1.0" ?>
 <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
   <env:Header>
     <p:oneBlock xmlns:p="http://example.com" env:actor="http://example.com/Log">
     ::::
     </p:oneBlock>
     <q:anotherBlock xmlns:q="http://example.com"
           env:actor="http://www.w3.org/2001/12/soap-envelope/actor/next">
     ::::
     </q:anotherBlock>
     <r:aThirdBlock xmlns:r="http://example.com">
     ::::
     </r:aThirdBlock>
   </env:Header>
   <env:Body >
     ::::
   </env:Body>
 </env:Envelope>

SOAP Header Blocks

• SOAP headers are optional, and are designed to allow for expansion
• A header can specify an actor which is a SOAP processing node along the message route e.g. next or a URL
• When a site matches the header it takes corresponding action
• Actions could be e.g.
  • Log the entry
  • Discard the message if crossing a firewall (?)
• The "anonymous" role (no actor specified) is the target of the message

SOAP Body for RPC Request

• When used for RPC, the body of a request contains a "struct" which is a method and its arguments

• 
  <?xml version='1.0' ?>
  <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
   <env:Body>
      <m:reserveAndCharge 
          env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
               xmlns:m="http://travelcompany.example.org/" >
        <n:name xmlns:n="http://mycompany.example.com/employees">
             John Q. Public
        </n:name>
        <o:creditCard xmlns:o="http://mycompany.example.com/financial">
             <o:number>123456789099999</o:number>
             <o:expiration>2005-02</o:expiration>
        </o:creditCard>
      </m:reserveAndCharge>
    </env:Body>
  </env:Envelope>
        

SOAP Body for RPC Response

• When used for RPC, the body of a response contains a "struct" which is the return
• The struct label is <Request>Response

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
  <env:Body>
       <m:reserveAndChargeResponse
             env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
             xmlns:m="http://travelcompany.example.org/" >
           <m:confirmation>
               <reference>FT35ZBQ</reference>
               <viewAt>
               http://travelcompany.example.org/reservations?code=FT35ZBQ
               </viewAt>
           </m:confirmation>
       </m:reserveAndChargeResponse>
   </env:Body>
</env:Envelope>
      

SOAP HTTP Binding

• SOAP 1.2 only defines HTTP as transport protocol
• Other protocols (email, Java Messaging, etc) are left unspecified
• Notable points
  • POST (not GET) is supported
  • The document type is application/soap
  • Errors are signalled using HTTP 500 "Internal Server Error"

SOAP HTTP Request

POST /Charging HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Body>
    <m:reserveAndCharge>
        ::::::
    </m:reserveAndCharge>
  </env:Body>
</env:Envelope>
      

SOAP HTTP Response

HTTP/1.1 200 OK
Content-Type: application/soap; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Body>
    <m:reserveAndChargeResponse>
        ::::::
    </m:reserveAndCharge>
 </env:Body>
</env:Envelope>
      

Calling SOAP Methods

Roll Your Own

• A client that knows the format of a SOAP request and response can just make an HTTP request and handle the response using the syntax of that service
• A general purpose client is given by Bob DuCharme
• Pseudocode is

  
        read the SOAP request from a file
        open HTTP connection to web service
        POST request to service
        read response
        write response to stdout
        

Perl SOAP::Lite

• The Perl SOAP::Lite module is available from http://guide.soaplite.com
• Given the service "spec"

  
        Service host: www.soaplite.com 
        Service name: Demo
        Methods:
            String hi()
            String bye()
        

• A Perl server is

  
        use SOAP::Transport::HTTP;
  
        SOAP::Transport::HTTP::CGI
          -> dispatch_to('Demo')
          -> handle;
  
        package Demo;
  
        sub hi {
          return 'hello world';
        }
  
        sub bye {
          return 'goodbye, world';
        }
        

  Make this available as e.g. CGI script hibye.cgi
• A Perl client is

  
        use SOAP::Lite;
  
        print SOAP::Lite
          -> uri('http://www.soaplite.com/Demo')  # Demo service
          -> proxy('http://services.soaplite.com/hibye.cgi') # script for service
          -> hi()
          -> result;
        

Apache Axis Server

• Apache Axis 1.1 is the Apache SOAP server
• It runs as a servlet within e.g. Jakarta Tomcat
• The Axis servlet is responsible for dispatching calls to the Web service
• Install Axis in a Tomcat servlet directory such as .../jakarta-tomcat/webapps/axis
• Copy the Java implementation source code with jws extension to the toplevel of the Axis directory e.g. .../jakarta-tomcat/webapps/axis/Converter.jws
• Access the service URL by e.g. http://localhost:8088/axis/Converter.jws
• The Axis servlet is responsible for generating WSDL, ties, and linking the service implementation

Apache Axis service and Perl client

• The file Converter.jws would contain

  
  public class Converter implements java.rmi.Remote {
      public float inchToMM(float float_1) throws
           java.rmi.RemoteException {
  
          float _retVal = float_1 * 2.54;
          return _retVal;
      }
      public float mmToInch(float float_1) throws
           java.rmi.RemoteException {
  
          float _retVal = float_1 / 2.54;
          return _retVal;
      }
  }
  

• This is stored in $TOMCAT_HOME/webapps/axis/Converter.jws
• Perl client to Java Converter Web service

  
  #!/usr/bin/perl
  
  use SOAP::Lite;
  
  print SOAP::Lite
      -> uri('http://localhost/Converter')  # Converter service
      -> proxy('http://localhost:8088/axis/Converter.jws') # Axis service
      -> inchToMM(1.0)
      -> result;
        

Apache Axis Client - do it yourself

• The basic classes to interact with a service are Service and Call
• These assume you know
  • the location of the service (the endpoint address)
  • the operation (the method you are calling)
  • the parameters to the call (an array handed to Call.invoke()

    import org.apache.axis.client.Call;
    import org.apache.axis.client.Service;
    import javax.xml.namespace.QName;
   
    public class TestClient {
      public static void main(String [] args) {
          try {
              String endpoint =
                       "http://nagoya.apache.org:5049/axis/services/echo";
  
             Service  service = new Service();
             Call     call    = (Call) service.createCall();
  
             call.setTargetEndpointAddress( new java.net.URL(endpoint) );
             call.setOperationName(new QName("http://soapinterop.org/", "echoString"));
             String ret = (String) call.invoke( new Object[] { "Hello!" } );
  
             System.out.println("Sent 'Hello!', got '" + ret + "'");
         } catch (Exception e) {
             System.err.println(e.toString());
         }
     }
   }

Apache Axis client using WSDL

• WSDL2Java generates client-side stubs
• For the ConverterInterface service, it generates
  • ConverterInterface.java - the Java interface you use
  • ConverterInterfaceServiceLocator.java - finds the service and returns a ConverterInterfaceService.java
  • ConverterInterfaceService.java - has a method to get the client HOPP
  • ConverterInterfaceSoapBindingStub.java - an implementation of the interface which is the client part of the HOPP

public class Tester
{
    public static void main(String [] args) throws Exception {
        // Make a service
        ConverterInterfaceService service = new ConverterInterfaceServiceLocator();
 
        // Now use the service to get a stub which implements the SDI.
        ConverterInterface port = service.getConverterInterface();
 
        // Make the actual call
        float mm = port.inchToMM(1.0);
    }
}

Browser access to Web services

• To access a web service from a browser, another client-server layer is required
• A Perl script to act as this additional middle server/client is

  
  #!/usr/bin/perl 
  
  use CGI;
  use SOAP::Lite;
  
  $query = new CGI;
  
  # get CGI query params
  $mm = $query->param('mm');
  
  $inch = SOAP::Lite
      -> uri('http://localhost/Converter')  # Demo service
      -> proxy('http://localhost/cgi-bin/converter.pl') # script for service
      -> mmToInch($mm)
      -> result;
  
  print $query->header();
  print $query->start_html(-title=>'Converter result');
  
  print "<p>
  $mm millimetres is $inch inches
  </p>
  </body> </html>";
  

• With Web page

  
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Draft//EN">
  <html> <head>
  <title>Converter Client</title>
  </head>
  
  <body>
  <h1>Converter Client</h1>
  
  <form action="http://localhost/cgi-bin/converter-bridge.pl" method="post">
  Millimetres
  <input type="text" width="10" name="mm">
  <input type=submit value="mm To Inch">
  </form>
  </html>
        

Conclusion

• There are implementations of Web services from many languages: Java, Perl, Python, Ada, tcl, etc
• Some are close to unusable
• Some are very easy to use
• The Apache Axis and Perl-Lite are notably easy. Probably Microsoft is easy too
• Web services are intended for programs, not people. To supply a human-oriented front end means an extra client-server step

Session management

HTTP and sessions

• IP is connectionless
• TCP is built above IP and includes session management i.e. a connection is established and is used for synchronous bi-directional communication. The connection identifies the session
• HTTP is built above TCP and is sessionless: logically each HTTP GET establishes a separate TCP session, and subsequent GET's have no logical link to the previous TCP session
• Optimisations in HTTP 1.1 allow multiple sessionless HTTP conections to share a TCP connection

Cookies and other hacks

• To build a shopping cart, a session is needed
• Hacks on top of HTML/HTTP are used
  • Cookies
  • URL rewriting
  • Hidden form fields

Sessions and SOAP

• SOAP uses the HTTP transport layer, and adds no session control: SOAP is sessionless
• None of the HTML/HTTP hacks are available
• If you want sessions, build session support yourself

What is involved

• The client and server need to maintain a shared identifier
• SOAP can only support this by an extra parameter to each method call
• The client and server will need to build session information keyed to this session identifier
• Timeouts will be needed to handle clients or servers going away

Conclusion

• Sessionless HTTP was fine while only static pages were delivered
• Mechanisms for HTML sessions are hacks that do not translate into Web services
• The W3 Consortium mantra that "HTTP is the universal protocol" means that you have to redo all the work done for TCP that was discarded by HTTP

Security

General

• Security is not an afterthought
• But for Web services, it is
• Security involves
  • Identification
  • Authentication - proof of identity
  • Authorisation - privileges belonging to identity
  • Integrity - data is not tampered with
  • Confidentiality - data is not exposed to others
  • Delegation and administration
  • Recording
  • Monitoring
• SOAP ignores all of these

XML Encryption

• The XML Working Group is looking at things like signatures and encryption
• Encryption of XML documents can be done at
  • the entire document
  • An entire tag such as <CreditCardInfo>
  • The tag content of its contained tags
  • The tag content of its character data

Breaking the SOAP specifications

• There is no concept of encryption in SOAP itself
• Encrypting any SOAP element breaks the SOAP specification. This rules out encrypting
  • An entire tag such as <CreditCardInfo>
  • The tag content of its contained tags
• The only binding mandated by the W3C is of SOAP to HTTP
• Encrypting an entire document breaks this binding
• All that is left is the encryption of character data (e.g. credit card number): at which point you lose the data-typing of SOAP - and expose a point of attack

Conclusion

• Security is not an afterthought
• But for Web services, it is

UDDI

UDDI (Universal Description, Discovery and Integration)

• UDDI is intended to be the ultimate directory for online businesses
• A business can register itself with a UDDI registry giving info such as
  • business description (name, short description, contacts, categories, urls, etc)
  • business service (description, categories, pointers to info)
  • binding template: information about a service entry point and implementation specifications
  • tModel: service types (categories, pointers to interface definitions, etc)
• A UDDI registry can be searched for businesses, services or service types

Registry Entry

UDDI and WSDL

• UDDI is often called a respository for WSDL documents
• UDDI is not tied to WSDL
• UDDI separates specification (tModel) from implementation (binding template)
• WSDL puts both specification and binding in the same document
• UDDI "best practice" recommends that WSDL documents should be in two parts, with binding "including" specification

Public/private Registries

• IBM, Microsoft, SAP, ... run public registries (uddi.ibm.com, uddi.microsoft.com, ...)
• These synchronise, so all registries contain the same info
• These could hold fantastic amounts of information - all the world's yellow pages, plus extra service information
• Private registries can be run within LANs, between cooperating groups of industries, etc

Private Registries

• IBM supply a private registry
• Sun JWSP contains a Registry Service in $JWSP_HOME/samples/registry-server

Access to Registries

• A client can search a registry
• A client can publish/delete information to a registry
• A variety of APIs exist

Perl client

• The SOAP::Lite package also includes UDDI::Lite
• This is not well documented yet
• Example client

  
        use UDDI::Lite +autodispatch =>
            proxy => 'http://uddi.microsoft.com/inquire',
        ;
  
        my $list = find_business(name => 'xmethods');
        my $bis = $list->businessInfos;
        for ($bis->businessInfo) {
            my $s = $_->serviceInfos->serviceInfo;
            print $s->name, ' ', $s->businesskey, "\n";
        }
        

Java Client

• The JAXR specification gives Java classes to access UDDI registries
• IBM's UDDI4J also does this
• These are too complex to give here

Summary

• Web services are a new version of RPC, heavily reliant on XML
• They have all the standard disadvantages of RPC
  • Location dependence
  • Slow
  • Prone to network errors
  • Prone to security attacks
• In addition, they have their own disadvantages
  • Verbose transport protocol
  • Heavy processing on client and server
  • Ludicrously centralised services in UDDI
• Web services have learnt none of the lessons from e.g. Service Location Protocol, Jini, mobile agents
• Some very talented engineers have hidden the complexity e.g. M/S .NET, Perl::Lite, Axis
• Many important aspects of distributed systems (implemented in e.g. CORBA) have not been addressed yet
  • Security
  • Transactions
• Web services have been touted as (one of) the next major advance on the Web (along with the Semantic Web, etc)
• Gartner put them near the top of the hype cycle
• Sigh...

References

• Roger Costello's Xfront Schema tutorial http://www.xfront.com/xml-schema.html
• Bob DuCharme "A general-purpose Java SOAP client" http://www-106.ibm.com/developerworks/xml/library/x-soapcl/
• Graham Glass Hello world, Web service-style , http://www-106.ibm.com/developerworks/webservices/library/ws-peer2/
• Graham Glass How SOAP works , http://www-106.ibm.com/developerworks/webservices/library/ws-peer3/
• Graham Glass Web Services Description Language (WSDL) , http://www-106.ibm.com/developerworks/webservices/library/ws-peer4/
• SOAP 1.2 Protocol, http://www.w3.org/TR/soap12
• WSDL 1.0 Specification, http://http://www.ibm.com/developerworks/web/library/w-wsdl.html
• UDDI home page http://www.uddi.org
• Web Services Tooolkit http://alphaworks.ibm.com/tech/webservicestoolkit