SOAP and Web Services

Mark Nottingham mnot@akamai.com

for Stanford University CS244b - Dr. Peter Danzig

Goals

• Introduction to SOAP, XML Messaging and Web Services
• Overview of the motivations for SOAP standardization and surrounding politics
• Review of one standard's progress and issues, to give insight into the mechanics and politics of standardization

SOAP in a Nutshell

• SOAP aims to be a simple, lightweight XML messaging convention for exchanging structured and typed information on the Web
• Most common use: RPC using XML over HTTP
  • getStockQuote()
  • sendPurchaseOrder()
  • runQuery()
• However, it can be used for any XML messaging application
  • one-way messaging
  • multicast

(material in following slides from HFN's Introduction to SOAP)

SOAP Message Model Overview

• Transport Binding (mandatory)
  • how to get the message to its destination
  • isolates message from transport, for portability across transports
• Message Envelope (mandatory)
  • what features and services are represented in a message (as blocks)
  • who should deal with them (actor attribute + implied semantics)
  • whether they are optional or mandatory (mustUnderstand attribute + implied semantics)
• Serialisation Mechanism (optional)
  • to exchange instances of application-defined data types and directed graphs
  • uniform model for serializing abstract data models that cannot be expressed in XML Schema
• RPC Convention (optional)
  • how to make calls and responses for a particular type of service

SOAP Design Principles

• KISS - absolute minimum of functionality
• Modularity and Extensibility
  • no application or transport semantics
  • think "XML datagram"
• Evolvability
  • the Web tends to be extended incrementally, based on existing applications
  • as a result, applications have different capabilities at the same time
  • applications supporting a particular features should be able to employ it without prior agreement
  • applications can require support for a feature, otherwise aborting the operation
  • evolvability represents a tradeoff with interoperability
• Composability
  • Vertical - multiple features can exist in the same message
  • Horizontal - features within a message can be intended for different recipients
• Versioning
  • no central registry - Web approach is to use URIs

SOAP Message Example

POST /Accounts/Henrik HTTP/1.1
Host: www.webservicebank.com
Content-Length: nnnn
Content-Type: text/xml; charset="utf-8"
SOAPAction: "Some-URI"

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
 SOAP:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP:Header>
    <t:Transaction xmlns:t="some-URI"
     SOAP:mustUnderstand="1">
    </t:Transaction>
  </SOAP:Header>
  <SOAP:Body>
      <m:Deposit xmlns:m="Some-URI">
      <m:amount>200</m:amount>
    </m:Deposit>
  </SOAP:Body>
</SOAP:Envelope>
    

SOAP Stack Examples

Service SOAP Message Protocol Binding HTTP TCP	Service SOAP Message Protocol Binding SMTP TCP	Service SOAP Message Protocol Binding SIP UDP
Service SOAP Message Protocol Binding TCP	Service SOAP Message Protocol Binding UDP

SOAP Modules

• Allow extension of SOAP core mechanisms, reduce redundant development of common functions
• Examples:
  • Digital Signatures
  • Encryption
  • Explicit Routing (SOAP-RP)
  • Caching
• Modules can address any SOAP processor using the "actor" attribute
• Can be optional or mandatory using the "mustUnderstand" attribute
• Directly allows "take it or leave it" negotiation (H calls this "US-style")
• "Let's talk about it" negotiation can be built on top

Why SOAP? Web Services.

• SOAP enables Web Services - machine-to-machine communication on the Web
• To enable ubiquitous use, Web Services require
  • Description of the service's semantics and metadata (WSDL)
  • Discovery of appropriate services (UDDI)
• ...allows services to be 'defined, deployed, manipulated and evolved in an automated fashion' (Layman)
• On top of these, higher-level business logic can be expressed, with flow languages (XLANG), etc.
• Ultimately, Web Services have a number of potential consumers:
  • EDI replacement
  • ERP acclerator
  • Middleware reduction
  • Desktop integration

SOAP/Web Services Status

• Currently 59 implementations
• Most focus on RPC-over-HTTP
• Growing number of UDDI implemenations and testbeds
• Web Services as a system still being developed

Who is driving SOAP and Web Services?

• Microsoft - .NET, Hailstorm
• Sun - Sun ONE
• HP - e-speak
• IBM - Dynamic e-business
• UN/CEFACT & OASIS - ebXML
• many more... (Oracle, Borland, etc.)

SOAP History - IETF

• Submitted as an Internet-Draft, November 1999
• Although not formally discussed by a Working Group or BoF, SOAP was and is rejected by many "IETF old-timers", because:
  • SOAP is a protocol; however, it does not fit cleanly into the OSI stack
  • As such, it was seen as a 'layer violation' - the mark of doom
• Many efforts are moving away from the IETF, as SOAP did, because:
  • vendors don't have any control; anyone can participate, and therefore stall the process
  • IETF is well-suited for lower-layer, ubiqutiously deployed protocol development, but less suited to standardisation of higher-layer application-specific semantics and formats

SOAP History - W3C

• Submission - May 8, 2000
• WWW9 Panel - May 17, 2000
  • Included Dave Winer of XML-RPC fame
• Working Group - chartered September 2000
  • largest WG in W3C history (~90 participants, ~45 Members)
  • experiment for the W3C - all technical work to happen in public
  • charged with quickly publishing a definitive XML Protocol specification, without being seen to 'rubber-stamp' SOAP
  • also, to clarify the specification and make it viable, where appropriate
  • this is proving difficult in practice
• Web Services Workshop - April 2001
  • many participants
  • lots of vision, little direction (large list of todos resulting)
  • most work seems to be started behind closed doors, then pushed to public
  • will probably result in more working groups in the XML Protocol Activity

XML Protocol Working Group Status

• Has produced an Abstract Model and a Requirements document (derived from the Charter)
• Just getting into the 'meat' of the work - addressing the Issues list
• Expects to be in Candidate Recommendation by the end of the year

Issue - Processing Model

• Processing Model is the determination of when and how modules in messages will be processed by nodes - both the ultimate receiver, and intermediaries
• Defining a meaningful processing model for XMLP messages is difficult, because it is a generic (not application-specific) transfer protocol
• For example: dependencies:
  • describe using a graph, or
  • rely on lexical ordering?
• Module rewriting - how is it useful? is it dangerous?
• Best answers will be:
  • simple to implement and express
  • cover common cases well
  • extensible to cover uncommon cases
• Unfortunately, it's difficult to determine what common cases will be before they get wide adoption

Issue - Message Path and Routing

• SOAP is built on underlying transports, which have their own concepts of:
  • Message Exchange Pattern (HTTP: request/response, SMTP: one-way)
  • Message Routing (HTTP: proxies, DNS lookup, SMTP: DNS MX record, intermediary configuration)
• However, some applications using SOAP may need to determine their own concepts of MEP and routing
• Additionally, message path and routing has an implied relationship with the processing model; intra-node processing and inter-node processing are linked.

Issue - SOAPAction

• The SOAPAction HTTP header was originally intended to give hints about the content of a message to devices at lower layers (e.g., HTTP intermediaries, firewalls)
  • example: SOAPAction: http://www.example.com/stockquote_service_definition
• Some implementations also use it for application-layer dispatch (routing the message to the appropriate code)
• Originally, SOAPAction had to be the same as the body's namespace
• SOAP/1.1 loosened this to allow any arbitrary URI
• Issues:
  • SOAPAction is often touted as useful for security (i.e., firewall filtering). Security people point out that it is too trusting ("This message is safe. Honest.")
  • Using SOAPAction for dispatch raises the question - aren't URIs for dispatch?
  • Identifying the message content is a task already satisfied by Content-Type in MIME
  • SOAPAction's purpose is muddy at best, yet implementations and services are already baking it in
• Should SOAPAction be perpetuated to satisfy current users, and not break implementations, at the expense of a 'clean' specification?

In Retrospect...

• Charter specificity - in the W3C, the charter is difficult for the WG to change. As a result, it needs to be well-thought out, and the problem it addresses needs to be well-understood. XMLP's charter was heavily based on SOAP, which locked us into a SOAP-shaped solution.
• Working Group size - so many people means it is difficult to gain consensus, or even know everyone's face. Conference calls are difficult.
• Working Group composition - WG is mostly 'application' people, not those with a protocol background. As a result, group tends to want to define APIs, misunderstands the protocol nature of SOAP, finds it difficult to communicate with protocol experts (such as the IETF)
• Relationship with SOAP community - WG output's relationship to SOAP still under debate - many don't want to break current SOAP implementations, at any cost

Challenges Facing SOAP and Web Services

• Ambition - Web Services has many potential pitfalls, as all 'big plans' do
• Interoperability - without interoperability, Web Services are useless. So far, vendors have shown a surprising tendency to work towards interoperability (but we're still at the easy part)
• Keeping Simplicity - it's always tempting to add those extra features that are useful for your application...

Possible Futures

• The W3C is serious about Web Services, but that does not guarantee success
• Many large vendors are serious about Web Services, which guarantees that something will happen
• Whether or not it is successful depends on the vendors, the market and the assumptions of the technology

More Information

• XML Protocol Activity -http://www.w3.org/2000/xp/
• SOAP/WebServices Resource Center - http://www.soap-wrc.com/webservices/
• http://www.webservices.org/
• http://www.soaprpc.com/
• Public SOAP Services listing - http://www.xmethods.com/