Web Services - the good, the bad and the (extremely) ugly
Jan Newmarch
Monash University, Australia

Web services

• The Web initially was a means of accessing linked documents
• With the advent of Forms, interaction between user and HTTP server became possible
• Web services intend to replace the user with a user-agent program, interacting with a service that is not concerned with UI issues
• 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 service components

• Web services are made of three components
  • SOAP - simple object access protocol
  • WSDL - web services description language
  • UDDI - universal description, discovery and integration
• SOAP is the "wire" format for remote method calls, their parameters and replies
• WSDL is the metalanguage used to describe a web service. It corresponds to the interface definition language of other middleware systems
• UDDI is the resource registration and lookup mechanism. It corresponds to the naming services of CORBA and RMI
• While there are many possibilities for service invocation, the WWW Consortium has only standardised SOAP over HTTP

Advanced WS Protocol Stack

From The Web Services Protocol Stack

Web service supporters

• Web services are supported by a large number of commercial companies including Microsoft, IBM and belatedly Sun
• There are several standards organisations which look after various bits of the Web Services stack, including the World Wide Web Consortium
• Web services are doing well on the Gartner Hype Cycle
  

WSDL

• The purpose of a service specification language is to convey information about the service that is independent of any implementation
• Syntax based specification languages are usually simple enough that anyone with minimal skill can write a specification
• Semantics based specification languages are normally phenomenally hard to read and write
• WSDL is a syntax-based language, using an XML DTD

Service example

• A service might be specified informally as

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

• Using the CORBA IDL this becomes

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

• Using Java RMI it would be

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

WSDL version of example

<?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"/&
gt;
    </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 structure

A WSDL document has the structure

• Data types
• Messages e.g. inchToMMRequest (OSI layer 4 - transport)
• Ports e.g.
  inchToMM(in inchToMMRequest, out inchToMMResponse fault java_rmi_RemoteException (OSI layer 7 - application)
• Bindings e.g.

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

  (OSI layer 4 - transport)
• Service e.g.

  
        name: Converter
        address: http://...
        ...
        

  (OSI layer 5 - session)

Critique of WSDL

• WSDL is far too complex, and mixes up different layers of the OSI stack
• Data types and ports are necessary for specification.
• Messages and bindings are not, as they are are part of the transport layer
• Service location is vital, but it is part of the session layer
• The recommended way to write a WSDL spec is to not do so - reverse engineer one from an implementation. I fail first year students who behave like this!
• WSDL contains no concept of state, an important property for many applications

Implications and recommendations

• WSDL leads to very poor software engineering, which will lead to broken, unreliable systems
• WSDL needs to be simplified to be a service specification language only (see alternatives such as [long list elided], UBF, etc)
• Parts which are generated automatically by all the different WSDL generators should be part of the protocol specifications, not left to individual implementations
• WSDL should be extended to include state (see grid service extensions)

SOAP

• SOAP is claimed to be "Simple Object Access Protocol"
• SOAP does not deal with objects, only with components at best
• There is no notion of state, so they are not even good components
• SOAP is not simple: it requires XML parsers and generators
• SOAP is not lightweight - sending verbose XML documents consumes bandwidth
• SOAP parameters and return results are by value. There is no reference mechanism
• SOAP claims to follow web protocols - all of which use the URL as a reference. SOAP cannot support this

REST

• Representational State Transfer, invented by Roy Fielding, chief architect of HTTP 1.1
• REST principles
  • Every resource is addressable with a uniform address scheme
  • Uniform addressing scheme - the URL
  • Small number of operations
  • Simple
  • Semantic difference between GET and POST
  • Returned result is always the representation of a document
• SOAP:
  • There are no addressable endpoints, only the service location
  • No operations, or an indefinite number
  • Layered over HTTP, more complex
  • POST only, semantics blurred
  • Returned result is one of three types (simple data, a complex datatype or a url) but never the address of an object (unlike CORBA, Java RMI, etc)

SOAP vs REST

SOAP:

POST url HTTP/1.1
HOST: ...
CONTENT-LENGTH: ...
CONTENT-TYPE: ...
SOAP-ACTION: ...

<Envelope>
  <Body>
    <CUSTOMERS>
    </CUSTOMERS>
  </Body>
</Envelope>

HTTP/1.0 200
CONTENT-TYPE: text/xml
CONTENT-LENGTH: ..
<?xml version="1.0"?>
<Envelope>
  <Body>
    <CUSTOMERS>
      <CUSTOMER>
        <ID>11</ID>
        <FIRSTNAME>Julia</FIRSTNAME>
        ...
      </CUSTOMER>
      ...
    </CUSTOMERS>
  </Body>
</Envelope>

REST:

GET http://host/CUSTOMERS

<resources xmlns:xlink="http://www.w3.org/1999/xlink">
  <resource xlink:href="http://host/CUSTOMER/0/">0 </resource>
  <resource xlink:href="http://host/CUSTOMER/1/">1 </resource>
  <resource xlink:href="http://host/CUSTOMER/2/">2 </resource>
  <resource xlink:href="http://host/CUSTOMER/3/">3 </resource>
</resources>

Efficiency

Experiments conducted in a UPnP system, replacing SOAP with REST:

Time to make 1000 queries (secs)

Query request size (bytes)

Size of parsers (bytes)

SOAP accomodating REST

Web services now claim to have resolved any issues about using REST, so that it is a "dead" issue From SOAP 1.2. section 6.4 "SOAP Web Method Feature":

Underlying protocols designed for use on the World Wide Web provide for manipulation of resources using a small set of Web methods such as GET, PUT, POST, and DELETE. These methods are formally defined in the HTTP specification [RFC 2616], but other underlying protocols might also support them. Bindings to HTTP or such other protocols SHOULD use the SOAP Web Method feature to give applications control over the Web methods to be used when sending a SOAP message. Bindings supporting this feature SHOULD use the appropriate embodiment of that method if provided by the underlying protocol; for example, the HTTP binding provided with this specification represents the "GET" Web method as an HTTP GET request, and the "POST" method as an HTTP POST request (see 7. SOAP HTTP Binding). Bindings supporting this feature SHOULD provide to the receiving node indication of the Web method used for transmission. The SOAP Web Method feature MAY be implemented by bindings to underlying transports that have no preferred embodiment of particular Web methods (e.g. do not distinguish GET from POST). Such bindings SHOULD provide to the receiving node indication of the Web method used for transmission, but need take no other action in support of the feature.

Implications and recommendations

• SOAP cannot support the reference semantics of CORBA, RMI, DCOM, etc - all of which it claims to be superior to
• SOAP needs to support URLs - as urged by the REST community, or have a two-level naming scheme - as used in Grid Services. WS-Resources are not a solution
• SOAP is too heavyweight for small devices - REST principles can help here
• SOAP needs to be compressed, but this loses its advantage as a text protocol - no real solution (apart from starting again)
• Roy Fielding: SOAP doesn't just suck, it was deliberately designed to suck

UDDI

• UDDI was designed as the "directory for everything"
• It contains
  • white pages
  • yellow pages
  • service pages
• UDDI is intended for a small number of replicated servers supporting world-wide directories
• UDDI will operate on the same scale as DNS, but without the same performance tweaks
• UDDI was "borrowed" for web services. There is a mismatch in purpose
• A Web Service can have its WSDL stored, but only as a component called the tname
• You can search for organisations with a tname of WSDL, but you can't search for a particular WSDL document
• "best practice" for UDDI recommends that the session-layer component of WSDL be omitted, since it doesn't belong

Implications and recommendations

• UDDI does not map cleanly onto service requirements. This means that it may not function efficiently or even correctly for services
• UDDI has no "garbage collection" mechanism. This is needed to stop stale entries accumulating
• A directory mechanism more appropriate for web services would be better designed from scratch
• WS-Discovery is not a more suitable protocol

Session management

• HTTP is session-less
• Interactive web pages require session management
• Software "hacks" such as cookies, URL rewriting and hidden form fields are used to contain session information
• Web services have no access to these mechanisms
• Current solutions are "roll your own" - no standardisation yet exists e.g. Microsoft uses cookies in the header

Implications and recommendations

• SIP can already handle multi-party session management - there is no need to invent another square wheel
• Web services urgently need to standardise on robust mechanisms for session management
• Without that, much of the promise of web services simply cannot be met

Firewalls

• Middleware communicates using sockets, requiring a port
• Network managers increase security by closing ports
• The HTTP port 80 (or 8080) is nearly always open
• CORBA, RMI, ... normally use their own port, but can use port 80 - this is recognised as a hack around security
• SOAP uses the HTTP port by default and claims it as a feature: SOAP works around firewall restrictions and SOAP is firewall friendly
• Network administrators need to control SOAP calls - they could be a potentially uncontrolled revenue drain (like phones, email and Web surfing)
• Controlling SOAP calls requires additional software - more chances of error, more configuration costs - has spurred much work in "deep packet inspection"

Security

• SOAP documents are transmitted in the clear
• They can be sent over SSL sockets, so that they are secure in transmission
• Before encoding by SSL and after decoding, the documents are in the clear, and can be attacked
• XML encryption is claimed to be the answer
  • encrypt the entire document
  • encrypt an element's content (this also encrypts subelements)
  • encrypt both an element's content and its name

  
  HTTP/1.0 200
  CONTENT-TYPE: text/xml
  CONTENT-LENGTH: ..
  <?xml version="1.0"?>
  <Envelope>
    <Body>
      <CUSTOMERS>
        <CUSTOMER>
          <XML-Enc>
          1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
          </XML-Enc>
        </CUSTOMER>
        ...
      </CUSTOMERS>
    </Body>
  </Envelope>
  

• Any level of encryption breaks the specified binding of SOAP to HTTP
• Intermediate processing agents cannot process any level of encrypted document without needing to know a different WSDL specification

Implications and recommendations

• Security is not an afterthought - with web services, it clearly is
• It is hard to retrofit security in any way that does not break some existing part of the web services specifications
• Web services with security will be broken by design

Conclusion

• There is a strong need for some sort of agent-to-agent business middleware
• CORBA, DCOM "have failed" according to many
• Web services can use RPC mechanisms, but they are deficient to the protocols they claim to replace
• Some think that RPC is wrong, and point to web services as supporting e.g. messaging models
• Their claims are untested, but allow them to divert criticisms from RPC web services
• Web services using RPC are poor implementations of 30 year old technology. While some of this can be overcome, some problems may be better solved by starting again
• Web Service standards are "evolving" continually (not always backward compatable)
• Opinion: Web services are the "Visual Basic" of networked systems - good for small systems, lacking engineering support for large ones