Abstract

The basic Web Services technologies of SOAP and WSDL are being used by various companies to provide service access for B2B communications. Google and Amazon are two popular examples, with both companies providing access to their traditionally browser-based services through SOAP. Google has a very simple service, while Amazon's is much more complex, allowing more types of interactions with Amazon. In both cases, the service is not anonymous, so that service usage can be controlled.

Web Service Examples

• Web Services technologies often are focused on three core standards
  • Simple Object Access Protocol (SOAP)
  • Web Services Description Language (WSDL)
  • Universal Description, Discovery, and Integration (UDDI)
• Practical examples often use only two of these
  • SOAP and WSDL are very tightly coupled
  • UDDI often is not used and/or not required
• Services (for reuse) require additional considerations
  • GUIs vs. APIs (is the GUI model appropriate for an API?)
  • Access Control (should service usage be controlled?)
  • Choreography (how complex are the interactions with the service?)

Service Design

• GUIs and APIs are often considered separate issues
  • GUIs are designed for human users only
  • APIs are designed for machine-level interaction
  • GUIs may build on APIs (for example, a Web interface)
  • APIs may build on APIs (for example, a SOAP service)
• Web-based services may be APIifications of existing GUIs
  • a direct mapping is most easy to design and implement
  • a re-design may lead to a better interface
  • this is new ground, traditionally APIs are the foundation of GUIs

APIification

• GUIs are built for human users
• Human users need human-readable representations
  • services very often provide HTML-based interfaces
  • too much or too detailed information is not advisable
• Human users provide information in specific ways
  • simple data may (and should) use simple data entry support
  • complex data needs a complex interface for supporting humans
• Machines are less sensitive to information overload
  • APIs may purposefully expose too much information
  • APIs may request very complex information with little support
• Interactions
  • many non-trivial service interfaces use more than one Web page
  • HTTP is stateless, so multi-page transactions require state management

HTTP Cookies

• Cookies have been invented for state management
  • HTTP is a stateless protocol, each request is a separate transaction
  • many Web applications need to track state across several pages
• Cookies are small data packets stored on the client
  • if a server need to track state, it sets a cookie using Set-Cookie2
  • the client only stores the cookie, it does not do anything else with it
  • whenever the client requests a page with the cookie's context, it sends the Cookie
  • the server can the identify the client based on the cookie it receives
• Cookie contents are never executed or interpreted
  • for clients, cookie contents are completely opaque
  • cookies should contain no security-relevant information
  • the most relevant cookie fields are Domain, Path, and Max-Age

Cookie Handling

Cookie Problems

• Cookies introduce some important security and privacy issues
  • cookies identify browsers and not users, which can be inconvenient
  • users can be (and are) tracked on a large scale (third-party cookies)
  • unless HTTPS is used, cookie data is unprotected
  • cross-site scripting can expose locally stored cookies to inappropriate sites
• Alternatives to using cookies are available (privacy issues remain valid)
  • IP Addresses: links users to physical locations (not good)
  • Query Strings: append IDs to URIs, requires page rewriting (adds other threats)
  • some sites use cookies or query strings (e.g., PHP provides transparent session handling)
• Cookies should be used wisely
  • do not use third-party cookies for essential functionality
  • only include perfectly anonymized data as cookie content
  • provide a fallback solution if cookies are not supported

Humans vs. Machines

• Service usage often is associated with a business model
  • human users should be attracted (advertising opportunities)
  • machines should be refused or limited (no advertising)
• Authentication mechanisms could be used to control usage
  • users must provide some identity (identity/password)
  • users must prove that they are humans (often used when acquiring an identity)
  • machines may then have other terms of usage
• CAPTCHA is one way to test for human users

Deep Linking

• Is it allowed to bypass the intended usage of a service?
  • the most popular lawsuit was built around framing of contents
  • the Web makes it much harder to draw a clean line
• Linking
  • HTML's simplicity avoids some of the hardest problems
  • other contents can be embedded using images, frames, or iframes
  • machine-based extraction and reuse is always possible
• Transclusion (real hypermedia)
  • classical hypermedia has the ideal of all content being one document
  • reused content can always be tracked back to its source
  • the design of such a system relied on a payment system being in place

Keeping Robots Away

• Robot Exclusion Standard for keeping crawlers out
  • search engines quickly started to overload servers with requests
  • the first engines sometimes were poorly implemented (depth-first searches)
• Site administrators can add simple files for search engine control
  • /robots.txt is read by all well-behaving search engines
  • may prevent search engines from crawling a site
  • more often is used to prevent search engines from getting lost

Preventing Anonymous Usage

• Web Services often require some kind of registration
  • unlimited usage would make it easy to replicate the service
  • registration means terms of usage means legal consequences
• Registration lets service providers monitor service usage
  • only registered users are allowed to use the service
  • daily limits are designed to encourage small-scale usage
  • larger scale usage must be individually negotiated
• Service providers also have other means of control
  • counting service usage by IP is simple but effective
  • more elaborate techniques detect specific patterns of usage
  • providing a service introduces risks which must be considered

Services & Operations

• WSDL defines services and operations
  • operations are defined by input and/or output messages
  • services are a collection of operations (with the ports in between)
• WSDL does not say anything about interdependencies
  • service may be designed in a way which make operations interdependent
  • proper service-oriented design should minimize interdependencies
  • services with more than just read access will often have interdependencies

 <portType name="GoogleSearchPort">
  <operation name="doGetCachedPage">
   <input message="typens:doGetCachedPage"/>
   <output message="typens:doGetCachedPageResponse"/>
  </operation>
  <operation name="doSpellingSuggestion">
   <input message="typens:doSpellingSuggestion"/>
   <output message="typens:doSpellingSuggestionResponse"/>
  </operation>
  <operation name="doGoogleSearch">
   <input message="typens:doGoogleSearch"/>
   <output message="typens:doGoogleSearchResponse"/>
  </operation>
 </portType>

Choreography Example

APIified GUIs

• Google was one of the first Web Services available
  • first published when SOAP was the way to go
  • the Google Search Protocol returns customizable HTML or XML
  • the newest addition is the Google AJAX Search API (embedding Google HTML into other Web pages)
• Amazon is diversifying into the services area
  • the Amazon service for looking up items is one part
  • Amazon Web Services try to commercialize Web Services
  • for example, selling Web site thumbnails for $0.0002 per thumbnail

Google Search API

• Google's search UI is form-based and user-oriented
  • even very simple browsers can compose and submit URI query strings
  • the search returns a manageable amount of information (10-100 hits per page)
• Google's search API is SOAP-based and application-oriented
  • all query string parameters have been encoded as an XML Schema type
  • the search returns small amounts of information (1-10 hits per page)
• It would have been easier to provide a REST service
  • the UI is a REST service
  • the query parameters format could have been reused (adding new parameters)
  • instead of HTML, the request would return XML (the Google Search Protocol does this)

Google Search Message

 <message name="doGoogleSearch">
  <part name="key" type="xsd:string"/>
  <part name="q" type="xsd:string"/>
  <part name="start" type="xsd:int"/>
  <part name="maxResults" type="xsd:int"/>
  <part name="filter" type="xsd:boolean"/>
  <part name="restrict" type="xsd:string"/>
  <part name="safeSearch" type="xsd:boolean"/>
  <part name="lr" type="xsd:string"/>
  <part name="ie" type="xsd:string"/>
  <part name="oe" type="xsd:string"/>
 </message>

Google Search Result

   <xsd:complexType name="GoogleSearchResult">
    <xsd:all>
     <xsd:element name="documentFiltering" type="xsd:boolean"/>
     <xsd:element name="searchComments" type="xsd:string"/>
     <xsd:element name="estimatedTotalResultsCount" type="xsd:int"/>
     <xsd:element name="estimateIsExact" type="xsd:boolean"/>
     <xsd:element name="resultElements" type="typens:ResultElementArray"/>
     <xsd:element name="searchQuery" type="xsd:string"/>
     <xsd:element name="startIndex" type="xsd:int"/>
     <xsd:element name="endIndex" type="xsd:int"/>
     <xsd:element name="searchTips" type="xsd:string"/>
     <xsd:element name="directoryCategories" type="typens:DirectoryCategoryArray"/>
     <xsd:element name="searchTime" type="xsd:double"/>
    </xsd:all>
   </xsd:complexType>

WSDL Description

• WSDL describes the mechanics of a Web Service
  • where is the service available (WSDL Ports)
  • what operations are available (WSDL Services)
  • what messages are being exchanged (WSDL Messages)
• WSDL does not describe the service semantically
  • what does the data in the messages mean (schemas do not define semantics)?
  • what service does the interface provide?
  • what non-interface properties does the service have (reliability, speed, security, privacy)?
  • is the service provider trustworthy?

WSDL Documentation

Amazon as a Service

• Amazon tries to foster reuse
  • a number of services are available through Amazon
  • accessing their product catalog is only one example
• More users mean more customers
  • TouchGraph Amazon Browser
  • adapting to the environment means integration rather than segregation

Amazon Search Request

   <xs:element name="ItemSearch">
    <xs:complexType>
     <xs:sequence>
      <xs:element name="MarketplaceDomain" type="xs:string" minOccurs="0"/>
      <xs:element name="AWSAccessKeyId" type="xs:string" minOccurs="0"/>
      <xs:element name="SubscriptionId" type="xs:string" minOccurs="0"/>
      <xs:element name="AssociateTag" type="xs:string" minOccurs="0"/>
      <xs:element name="XMLEscaping" type="xs:string" minOccurs="0"/>
      <xs:element name="Validate" type="xs:string" minOccurs="0"/>
      <xs:element name="Shared" type="tns:ItemSearchRequest" minOccurs="0"/>
      <xs:element name="Request" type="tns:ItemSearchRequest" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
    </xs:complexType>
   </xs:element>
   <xs:complexType name="ItemSearchRequest">
    <xs:sequence>
     <xs:element name="Actor" type="xs:string" minOccurs="0"/>
     <xs:element name="Artist" type="xs:string" minOccurs="0"/>
     <xs:element name="Availability" minOccurs="0">

WSDL Documentation

REST Alternative

• Amazon provides SOAP and REST interfaces
  • the service provided through these interfaces is the same
  • choosing one interface over the other is a matter of taste
• Programmers might like the SOAP style
  • stubs can be created in the programming language of their choice (better integration)
  • interaction with the service can be done very easily (through generated classes)
• Web technology people (mashup builders) might like the REST style
  • there is less overhead and less generated code required
  • it maybe advantageous to work with the XML directly
• the service is the same, but the interface is designed differently
  • how easy can both interfaces be maintained and developed synchronously?

Web Service Examples

• Web Services come in different flavors
• Popular service providers increasingly provide Web-based services
• Simple data models can be documented reasonably using text

Assignment 4

• Assignment 4 is about using an XML-oriented service
  • the bibliography service has been extended to return XML
  • using SimpleXML, it is now easier to access specific parts of the results
• Other services can now be integrated into your service
  • augment your service with links to other services (e.g., Google Scholar)