WS Technologies I SOAP

1
WS Technologies ISOAP
Models and Languages for Coordination and
Orchestration IMT- Institutions Markets
Technologies - Alti Studi Lucca
Roberto Bruni Dipartimento di Informatica
Università di Pisa
2
Contents

• Web Services, informally
• SOAP a protocol for WS
• UDDI registries

3
Simple Object Access Protocol (SOAP)

• SOAP
• provides a simple and lightweight mechanism
• stateless, one-way
• basis for complex interaction patterns
• ex. RPC, request/(multiple) response, back and
  forth conversations
• for exchanging structured and typed information
  between peers in a decentralized, distributed
  environment using XML
• it does not itself define any application
  semantics such as a programming model or
  implementation specific semantics
• silent on routing, reliability, firewall
  transversal
• it defines a modular packaging model and encoding
  mechanisms for encoding data within modules
• required actions can be expressed in SOAP

4
SOAP as Web Middleware

• Internet is designed for a
• more heterogeneous
• clients than middleware
• applications
• editorial publishing, for readers (ad-hoc RPC)
• available everywhere
• suitable also for small companies
• Easy access
• easy to prepare
• easy to publish on a web host
• easy to update

• Distributed applications require the
• implementation of network protocols
• open/close sockets, monitor ports
• format requests, decode messages
• RPC makes life simpler
• usual procedure calls
• protocol code delegated to precompiler
• Ok on LAN/Intranet, problems on Internet
• ease programming, but not distribution
• firewall could block protocols different from
  http (would the firewall reconfiguration be
  compatible with the security policy of the
  company?)

XML for RPC via HTTP
5
Modern RPC

• CORBA (Common Object Request Broker Architecture)
• strength open standard, multiplatform
• weakness complex, not optimizable
• RMI (Remote Method Invocation)
• Java technology for RPC (its strength and
  weakness is Java)
• DCOM (Distributed Component Object Model)
• Microsoft technology for remote communication
  (its strength and weakness is Windows)
• Different solutions, not necessarily compatible
• They try to achieve the better outcome for RPC
  with object oriented mechanisms

6
ExampleRMI on Remote Server
è sufficiente designare alcuni oggetti come
remoti per gestire gli aspetti di rete e di
protocollo. La designazione varia anche in
funzione della tecnologia utilizzata.
The only code needed is that for extending the
Remote interface

• import java.util.Date
• import java.rmi.Remote
• import java.rmi.RemoteException
• public interface remoteBooking extends Remote
• public Resource getAllRes() throws
  RemoteException
• public Resource getFreeResOn(Date start, Date
  End)
• throws RemoteException
• public void bookRes(int resource,
• String email,
• Date start,
• Date end) throws RemoteException

It is the advantage of middleware applications
Where is the network code?
7
Sites, XML and Automation

• Thanks to the evolution of the web, there have
  been other attempts to develop web sites tailored
  to applications instead of human beings
• Often XML comes into play
• Ex. RSS format (RDF Site Summary)
• where RDF Resource Description Framework
• (standard for definition of metadata)
• developed by Netscape for its own portal
• a RSS document can emphasize the main URLs, or
  the titles and the news
• authorized servers can download and integrate RSS
  documents in suitable databases

8
XML-RPC

• Another step towards SOAP
• calls similar to ordinary RPC
• binary protocol replaced by the use of XML and
  HTTP
• The RPC corresponds to a XML document inserted
  inside a request (POST) addressed to an HTTP
  server
• An example is shown in the next slides
• the client calls, remotely, the method
  getFreeResOn()
• BookingService.getFreeResOn(startDate,endDate)
• XML-RPC packs the request
• the server answer is also coded in XML

9
An XML-RPC Request I

• POST /xmlrpc HTTP/1.0
• User-Agent Handson (Win98)
• Host joker.psol.com
• Content-Type text/xml
• Content-length 454
• lt?xml version1.0?gt
• ltmethodCallgt
• ltmethodNamegtcom.psol.res.BookingService.getFree
  ResOnlt/methodNamegt
• ltparamsgt
• ltparamgt
• ltvaluegt
• ltdateTime.iso8601gt2004-01-15T000000lt
  /dateTime.iso8601gt
• lt/valuegt
• lt/paramgt

10
An XML-RPC Request II

• lt!-- (segue)
  --gt
• ltparamgt
• ltvaluegt
• ltdateTime.iso8601gt2004-01-17T000000lt
  /dateTime.iso8601gt
• lt/valuegt
• lt/paramgt
• lt/paramsgt
• lt/methodCallgt

11
An XML-RPC Request III

• POST /xmlrpc HTTP/1.0
• User-Agent Handson (Win98)
• Host joker.psol.com
• Content-Type text/xml
• Content-length 454
• lt?xml version1.0?gt
• ltmethodCallgt
• ltmethodNamegtcom.psol.res.BookingService.getFree
  ResOnlt/methodNamegt
• ltparamsgt
• ltparamgt
• ltvaluegt
• ltdateTime.iso8601gt2004-01-15T000000lt
  /dateTime.iso8601gt
• lt/valuegt
• lt/paramgt

12
An XML-RPC Request IV

• POST /xmlrpc HTTP/1.0
• User-Agent Handson (Win98)
• Host joker.psol.com
• Content-Type text/xml
• Content-length 454
• lt?xml version1.0?gt
• ltmethodCallgt
• ltmethodNamegtcom.psol.res.BookingService.getFree
  ResOnlt/methodNamegt
• ltparamsgt
• ltparamgt
• ltvaluegt
• ltdateTime.iso8601gt2004-01-15T000000lt
  /dateTime.iso8601gt
• lt/valuegt
• lt/paramgt

13
An XML-RPC Answer I

• HTTP/1.0 200 OK
• Content-length 485
• Content-Type text/xml
• Server Jetty/3.1.4 (Windows 98 4.10 x86)
• lt?xml version1.0?gt
• ltmethodResponsegt
• ltparamsgt
• ltparamgt
• ltvaluegt
• ltarraygt
• ltdatagt
• ltvaluegtltstringgtMeeting Room
  1lt/stringgtlt/valuegt
• ltvaluegtltstringgtMeeting Room
  2lt/stringgtlt/valuegt
• ltvaluegtltstringgtBoard
  Roomlt/stringgtlt/valuegt

14
An XML-RPC Answer II

• lt!-- (segue)
  --gt
• lt/datagt
• lt/arraygt
• lt/valuegt
• lt/paramgt
• lt/paramsgt
• lt/methodResponsegt

15
From XML-RPC to SOAP I

• XML-RPC is simple and effective
• it has some disadvantages anyway
• no optimal/unique mechanism for transmitting
  generic XML documents
• (string / base64 parameter must be used)
• difficult to extend request/answer format coding
  for a given service
• not aligned to XML standard
• (ex. namespaces are not used and special data
  types are introduced)
• based on HTTP
• (SMTP could be more suitable for certain
  applications)

16
From XML-RPC to SOAP II

• SOAP as an evolution of XML-RPC
• not as easy as XML-RPC
• but it is more powerful and expressive
• XML-RPC offered the solution to a specific
  problem (RPC via HTTP)
• SOAP leaves many more possibilities open
• useful also for applications that are not based
  on RPC
• (however XML-RPC is not yet obsolete and it is
  still the favourite for many developers)

17
SOAP Architecture

• SOAP defines an open framework for messaging
• envelope
• encoding rules (serialization mechanism)
• binding to the transmission protocol
• RPC requires all these three components, but it
  is independent from / indifferent to them

SOAP RPC
Other standards (transport, routing, packeting)
Coding rules
Messaging structure (envelope)
Binding HTTP
Binding SMTP
HTTP
SMTP
18
SOAP Basics

• A SOAP message is a
• one-way transmission
• between
• SOAP nodes
• from a
• SOAP sender
• to a
• SOAP receiver
• that can traverse
• several others SOAP intermediaries
• they can "act" on the message

19
SOAP Namespaces

• env
• http//www.w3.org/2003/05/soap-envelope
• enc
• http//www.w3.org/2003/05/soap-encoding
• rpc
• http//www.w3.org/2003/05/soap-rpc

20
A SOAP 1.1 Request I

• POST /soap/servlet/rpcrouter HTTP/1.0
• Host joker.psol.com
• Content-Type text/xml charsetutf-8
• Content-length 557
• SOAPAction "http//www.psol.com/2004/soapaction"
• lt?xml version'1.0' encoding'UTF-8'?gt
• ltenvEnvelope xmlnsxsd"XMLSchema"
• xmlnsenv"soap/envelope/"
• xmlnsxsi"XMLSchema-instance"gt
• ltenvBodygt
• ltns1getFreeResOn xmlnsns1""
• encencodingStyle"soap/e
  ncoding/"gt
• ltstart xsitype"xsdtimeInstant"gt2004-01
  -15T000000Zlt/startgt
• ltend xsitype"xsdtimeInstant"gt2004-01
  -17T000000Zlt/endgt

21
A SOAP 1.1 Request II

• lt!-- (segue)
  --gt
• lt/ns1getFreeResOngt
• lt/envBodygt
• lt/envEnvelopegt

Maybe the reading becomes more complex, but now
XML features are fully exploited (ex. schema and
namespaces)

• For the moment, just note the
• presence of two SOAP blocks
• the Envelope
• the Body

22
A SOAP 1.1 Answer I

• HTTP/1.0 200 OK
• Server Jetty/3.1.4 (Windows 98 4.10 x86)
• Servlet-Engine Jetty/3.1 (JSP 1.1 Servlet 2.2
  java 1.3.0)
• Content-Type text/xml charsetutf-8
• Content-length 692
• lt?xml version'1.0' encoding'UTF-8'?gt
• ltenvEnvelope xmlnsxsd"XMLSchema"
• xmlnsenv"soap/envelope/"
• xmlnsxsi"XMLSchema-instance"gt
• ltenvBodygt
• ltns1getFreeResOnResponse xmlnsns1""
• 
  envencodingStyle"soap/encoding/"gt
• ltreturn xmlnsns2"/soap/encoding/"
• xsitypens2Array
• ns2ArrayTypens1String3gt

23
A SOAP 1.1 Answer II

• lt!-- (segue)
  --gt
• ltitem xsitype"xsdstring"gtMeeting
  Room 1lt/itemgt
• ltitem xsitype"xsdstring"gtMeeting
  Room 2lt/itemgt
• ltitem xsitype"xsdstring"gtBoard
  Roomlt/itemgt
• lt/returngt
• lt/ns1getFreeResOnResponsegt
• lt/envBodygt
• lt/envEnvelopegt

• Notice the namespace env
• used in SOAP 1.2
• was SOAP-ENV in SOAP 1.1
• (not always compatible)
• but the syntax is irrelevant, the URI counts

24
Structure of SOAP Messages
envEnvelope

• SOAP Blocks
• single logic computational units
• represented as XML elements
• identifies from qualifying name
• namespace and local name
• envEnvelope
• source of SOAP request
• envHeader
• optional it contains additional info about
  routing, authentication
• envBody
• mandatory it contains the main info
• envFault
• it may appear in the body it denotes errors
  occurring at the protocol level

envHeader
SOAP block
envBody
SOAP block
25
The Envelope Analogy
SOAP messages as actual letters (remember those
antiquated things in envelopes with postage and
an address scrawled across the front?)
26
Travel Reservation Scenario

• The travel reservation application for an
  employee of a company negotiates a travel
  reservation with a travel booking service for a
  planned trip using SOAP messages
• ultimate recipient is a travel service
  application
• but messages can be routed through one or more
  SOAP intermediaries
• for logging, auditing, amendment travel requests

27
Travel Reservation Request Header

• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope"gt
• ltenvHeadergt
• ltmreservation xmlnsm"http//travelcompany.exa
  mple.org/reservation"
• envrole"http//www.w3.org/2003/05/soa
  p-envelope/role/next"
• envmustUnderstand"true" gt
• ltmreferencegtuuid093a2da1-q345-739r-ba5d-pqff9
  8fe8j7dlt/mreferencegt
• ltmdateAndTimegt2001-11-29T132000.000-0500lt/m
  dateAndTimegt
• lt/mreservationgt
• ltnpassenger xmlnsn"http//mycompany.example.c
  om/employees"
• envrole"http//www.w3.org/2003/05/soa
  p-envelope/role/next"
• envmustUnderstand"true" gt
• ltnnamegtFred Smithlt/nnamegt
• lt/npassengergt
• lt/envHeadergt

28
Travel Reservation Request Body

• ltenvBodygt
• ltpitinerary xmlnsp"http//travelcompany.examp
  le.org/reservation/travel"gt
• ltpdeparturegt
• ltpdepartinggtNew Yorklt/pdepartinggt
• ltparrivinggtLos Angeleslt/parrivinggt
• ltpdepartureDategt2001-12-14lt/pdepartureDategt
  
• ltpdepartureTimegtlate afternoonlt/pdepartureT
  imegt
• ltpseatPreferencegtaislelt/pseatPreferencegt
• lt/pdeparturegt
• ltpreturngt
• lt/pitinerarygt
• ltqlodging
• xmlnsq"http//travelcompany.example.org/reser
  vation/hotels"gt
• ltqpreferencegtnonelt/qpreferencegt
• lt/qlodginggt
• lt/envBodygt
• lt/envEnvelopegt

ltpreturngt ltpdepartinggtLos
Angeleslt/pdepartinggt ltparrivinggtNew
Yorklt/parrivinggt ltpdepartureDategt2001-12-20
lt/pdepartureDategt ltpdepartureTimegtmid-morni
nglt/pdepartureTimegt ltpseatPreference/gt
lt/preturngt
29
Travel ScenarioStructure of SOAP Message

• Header blocks
• can be inspected by
• intermediary nodes
• ultimate receiver
• Body
• can be inspected by
• ultimate receiver only (in principle)
• cannot prevent malicious behaviours

envEnvelope
envHeader
mreservation (reference, timestamp)
npassenger
envBody
pitinerary
qlodging
30
Header

• Specifies the way in which the call must be
  processed
• analogous to header of electronic mail
• it is not part of the message, but it provides a
  way to pass information that is not application
  payload
• control information includes
• passing directives
• contextual information related to the processing
  of the message
• headers can be inspected, inserted, deleted and
  forwarded
• ex. travel policies for the passenger appended as
  another header block
• this allows application-specific extensions
• child elements can be individually targeted to
  specific SOAP nodes

31
Header

• Main attributes of tags inside the header
• envrole
• tells that the element is addressed to some
  specific node
• "next" is either next intermediary or ultimate
  receiver
• every node must be willing to play the "next"
  role
• envmustUnderstand
• a node should not elaborate the request when it
  does not "understand" an element marked by
  envmustUnderstand"true"

32
Example Proxy Processing
envEnvelope
envEnvelope
envHeader
envBody
envBody
client
proxy
server
In the example, the envrole attribute specifies
that all header blocks are addressed to the proxy
33
Travel Reservation Response Header

• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope"gt
• ltenvHeadergt
• ltmreservation xmlnsm"http//travelcompany.exa
  mple.org/reservation"
• envrole"http//www.w3.org/2003/05/soa
  p-envelope/role/next"
• envmustUnderstand"true" gt
• ltmreferencegtuuid093a2da1-q345-739r-ba5d-pqff9
  8fe8j7dlt/mreferencegt
• ltmdateAndTimegt2001-11-29T133500.000-0500lt/m
  dateAndTimegt
• lt/mreservationgt
• ltnpassenger xmlnsn"http//mycompany.example.c
  om/employees"
• envrole"http//www.w3.org/2003/05/soa
  p-envelope/role/next"
• envmustUnderstand"true" gt
• ltnnamegtFred Smithlt/nnamegt
• lt/npassengergt
• lt/envHeadergt

34
Travel Reservation Response Body

• ltenvBodygt
• ltpitineraryClarification
• xmlnsp"http//travelcompany.example.org/rese
  rvation/travel"gt
• ltpdeparturegt
• ltpdepartinggt
• ltpairportChoicesgt
• JFK LGA EWR
• lt/pairportChoicesgt
• lt/pdepartinggt
• lt/pdeparturegt
• ltpreturngt
• lt/pitineraryClarificationgt
• lt/envBodygt
• lt/envEnvelopegt

ltpreturngt ltparrivinggt
ltpairportChoicesgt JFK LGA EWR
lt/pairportChoicesgt lt/parrivinggt
lt/preturngt
35
Conversational Message Exchanges

• The response seeks to refine some information in
  the request
• namely the choice of airports in the departing
  city
• the Header are returned with some sub-element
  values altered (datetime)
• the Body contains a list of various alternatives
  for the airport
• The travel application can now send another
  message in response
• reference value in the header-block reservation
  establishes the correlation (at the application
  level) between all messages exchanged

36
Travel Reservation Response to Response (Header)

• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope"gt
• ltenvHeadergt
• ltmreservation
• xmlnsm"http//travelcompany.example.org/res
  ervation"
• envrole"http//www.w3.org/2003/05/soa
  p-envelope/role/next"
• envmustUnderstand"true"gt
• ltmreferencegtuuid093a2da1-q345-739r-ba5d-pqff
  98fe8j7dlt/mreferencegt
• ltmdateAndTimegt2001-11-29T133650.000-0500lt/
  mdateAndTimegt
• lt/mreservationgt
• ltnpassenger xmlnsn"http//mycompany.example.c
  om/employees"
• envrole"http//www.w3.org/2003/05/soa
  p-envelope/role/next"
• envmustUnderstand"true"gt
• ltnnamegtFred Smithlt/nnamegt
• lt/npassengergt
• lt/envHeadergt

37
Travel Reservation Response to Response (Body)

• ltenvBodygt
• ltpitinerary
• xmlnsp"http//travelcompany.example.org/reser
  vation/travel"gt
• ltpdeparturegt
• ltpdepartinggtLGAlt/pdepartinggt
• lt/pdeparturegt
• ltpreturngt
• ltparrivinggtEWRlt/parrivinggt
• lt/preturngt
• lt/pitinerarygt
• lt/envBodygt
• lt/envEnvelopegt

38
Data Coding

• Unlike usual middleware applications, SOAP does
  not map explicitly/uniquely its own code on
  programming languages
• ex. There is no standard mapping of SOAP for Java
• Two different SOAP implementations can generate
  different code for the same object / data
• Not a big issue, thanks to the use of meta-data

39
Field Coding

• Basic rule all values are always encoded inside
  elements
• ex. a field name can become
• ltnamegtBoard Roomlt/namegt
• but not
• ltitem name"Board Room" /gt

40
Coding of Simple Types
Java utilizza xsitype senza problemi, altri
linguaggi meno restrittivi potrebbero ignorarlo
se genera conflitti documenti XML validi (con
schema) riducono le ambiguità!

• Like XML-RPC, also SOAP supports a few simple
  types, such as
• string, base64Binary, integer, byte, short, int,
  long, decimal, float, double, boolean, dateTime,
  time, date, duration
• Simple types are encoded as XML elements
• the xsitype attribute can help to resolve
  ambiguity issues

ltstart xmlnsxsiXMLSchema-instance
xmlnsxsdXMLSchema
xsitypexsddateTimegt2004-01-15T000000Zlt/star
tgt
41
Coding of Complex Structures

• Structures are logical groups of elements
• elements are identified by their names
• The coding transforms field names to elements
• they are unqualified elements (no namespace)
• Analogously for representing instances of Java
  classes
• an example is in the next slide

42
Example Resource Class
ltrsResource xmlnsrs""
xmlnsxsi"XMLSchema-instance"
xmlnsxsd"XMLSchema"
xmlnsenv"/soap-envelope"
envencodingStyle"/soap-encoding"gt ltid
xsitype"xsdint"gt0lt/idgt ltname
xsitype"xsdstring"gtAuditoriumlt/namegt
ltdescription xsitype"xsdstring"gtLargest
roomlt/descriptiongt lt/rsResourcegt
public class Resource public int id
public String name public String
description
43
Travel ScenarioRPC in SOAP

• Let us assume that the conversational exchanges
  have resulted in a confirmed itinerary
• Suppose the payment for the trip is issued using
  a credit card
• The payment happens in the context of an overall
  transaction where the credit card is charged only
  when
• the travel
• and the lodging
• (not shown in any example, but presumably
  reserved in a similar manner)
• are both confirmed
• the travel reservation application provides
  credit card information and the successful
  completion of the different activities results in
  the card being charged and a reservation code
  returned
• This reserve-and-charge interaction between the
  travel reservation application and the travel
  service application is modelled as a SOAP RPC

44
RPC in SOAP Requirements

• To invoke a SOAP RPC, the following information
  is needed
• The address of the target SOAP node (ultimate
  Receiver)
• URI inside SOAP header blocks
• or carried outside the SOAP envelope when binding
  supports that (ex. HTTP)
• The procedure/method name
• The parameters and return value
• A clear separation of the arguments used to
  identify the target Web resource, as contrasted
  with those that convey data or control
  information used for processing the call
• The message exchange pattern which will be
  employed to convey the RPC
• Optionally, data which may be carried as a part
  of SOAP header blocks

45
Reservation Charge as RPCInvocation I

• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope" gt
• ltenvHeadergt
• ltttransaction xmlnst"http//thirdparty.exampl
  e.org/transaction"
• envencodingStyle"http//example.com/e
  ncoding"
• envmustUnderstand"true"
  gt5lt/ttransactiongt
• lt/envHeadergt
• ltenvBodygt
• ltmchargeReservation xmlnsm"http//travelcompa
  ny.example.org/"
• envencodingStyle"http//www.w3.org/20
  03/05/soap-encoding"gt
• ltmreservation xmlnsm"http//travelcompany.ex
  ample.org/reservation"gt
• ltocreditCard xmlnso"http//mycompany.example
  .com/financial"gt
• lt/mchargeReservationgt
• lt/envBodygt
• lt/envEnvelopegt

application-specific transaction indentifier
input 1
input 2
method name
46
Reservation Charge as RPCInvocation II

• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope" gt
• ltenvHeadergt
• ltttransaction xmlnst"http//thirdparty.examp
  le.org/transaction"
• envencodingStyle"http//example.com/e
  ncoding"
• envmustUnderstand"true"
  gt5lt/ttransactiongt
• lt/envHeadergt
• ltenvBodygt
• ltmchargeReservation xmlnsm"http//travelcompa
  ny.example.org/"
• envencodingStyle"http//www.w3.org/20
  03/05/soap-encoding"gt
• ltmreservation xmlnsm"http//travelcompany.ex
  ample.org/reservation"gt
• ltocreditCard xmlnso"http//mycompany.example
  .com/financial"gt
• lt/mchargeReservationgt
• lt/envBodygt
• lt/envEnvelopegt

input 1
ltmreservation xmlnsm"http//travelcompany.examp
le.org/reservation"gt ltmcodegtFT35ZBQlt/mcodegt
lt/mreservationgt
47
Reservation Charge as RPCInvocation III

• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope" gt
• ltenvHeadergt
• ltttransaction xmlnst"http//thirdparty.examp
  le.org/transaction"
• envencodingStyle"http//example.com/e
  ncoding"
• envmustUnderstand"true"
  gt5lt/ttransactiongt
• lt/envHeadergt
• ltenvBodygt
• ltmchargeReservation xmlnsm"http//travelcompa
  ny.example.org/"
• envencodingStyle"http//www.w3.org/20
  03/05/soap-encoding"gt
• ltmreservation xmlnsm"http//travelcompany.ex
  ample.org/reservation"gt
• ltocreditCard xmlnso"http//mycompany.example
  .com/financial"gt
• lt/mchargeReservationgt
• lt/envBodygt
• lt/envEnvelopegt

ltocreditCard xmlnso"http//mycompany.example.co
m/financial"
xmlnsn"http//mycompany.example.com/employees"
gt ltnnamegtFred Smithlt/nnamegt
ltonumbergt123456789099999lt/onumbergt
ltoexpirationgt2005-02lt/oexpirationgt lt/ocreditCar
dgt
input 2
48
Reservation Charge as RPCResponse I

• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope" gt
• ltenvHeadergt
• ltttransaction xmlnst"http//thirdparty.exampl
  e.org/transaction"
• envencodingStyle"http//example.com/enc
  oding"
• envmustUnderstand"true"
  gt5lt/ttransactiongt
• lt/envHeadergt
• ltenvBodygt
• ltmchargeReservationResponse xmlnsm"http//tra
  velcompany.example.org"
• envencodingStyle"http//www.w3.org/2003
  /05/soap-encoding"gt
• ltmcodegtFT35ZBQlt/mcodegt
• ltmviewAtgt
• http//travelcompany.example.org/reservat
  ions?codeFT35ZBQ
• lt/mviewAtgt
• lt/mchargeReservationResponsegt
• lt/envBodygt
• lt/envEnvelopegt

added by convention
output 1
output 2
49
Reservation Charge as RPCResponse II

• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope" gt
• ltenvHeadergt
• ltenvBodygt
• ltmchargeReservationResponse xmlnsm"http//tra
  velcompany.example.org"
• xmlnsrpc"http//www.w3.org/2003/05/soap
  -rpc"
• envencodingStyle"http//www.w3.org/2003
  /05/soap-encoding"gt
• ltrpcresultgtmstatuslt/rpcresultgt
• ltmstatusgtconfirmedlt/mstatusgt
• ltmcodegtFT35ZBQlt/mcodegt
• ltmviewAtgt
• lt/mchargeReservationResponsegt
• lt/envBodygt
• lt/envEnvelopegt

a specific return value can be distinguished among
output parameters
(it is assumed to be void when not
otherwise specified)
50
Transport Options

• In principle, using SOAP for RPC is independent
  of the decision to use a particular means for
  transferring the RPC call and its return
• but certain protocol bindings that support the
  Request-Response message exchange pattern may be
  more naturally suited for such purposes
• they can provide a built-in correlation between a
  request and a response
• In the commonly used case, of using HTTP as the
  underlying transfer protocol, an RPC invocation
  maps naturally to the HTTP request and an RPC
  response maps to the HTTP response
• Even though most examples of SOAP for RPC use the
  HTTP protocol binding, it is not limited to that
  means alone
• The designer of an RPC-based application could
  choose to put a correlation ID relating a call
  and its return in a SOAP header
• making the RPC independent of any underlying
  transfer mechanism
• In any case, application designers have to be
  aware of all the features of the particular
  protocols chosen, such as latency, synchrony,
  etc.

51
HTTP Binding

• SOAP offers an HTTP binding
• HTTP requests and answers have their own headers
  and bodies
• a SOAP message is transmitted by the POST/GET
  command
• Content-Type is set to application/soapxml
• HTTP supports other commands but they are not
  used by SOAP standard yet
• the answer is sent as an ordinary HTTP answer
• answer code 2xx is OK 500 if elaboration failed

52
Compliance to Web Architecture

• One of the most central concepts of the World
  Wide Web
• URI as a resource identifier
• SOAP services with HTTP binding that wish to
  interoperate with other Web software should use
  URIs to address all important resources in their
  service
• ex. a predominant use of the WWW is pure
  information retrieval
• the representation of an available resource,
  identified by a URI, is fetched using a HTTP GET
  request without affecting the resource in any way
• this is called a safe and idempotent method in
  HTTP terminology
• as opposed to uses that perform resource
  manipulation
• the use of a SOAP body to carry the request for
  the state, with an element of the body
  representing the object in question, is seen as
  counter to the spirit of the Web
• because the resource is not identified by the
  Request-URI of the HTTP GET
• The key point is that the publisher of a resource
  makes available its URI, which consumers may "GET"

53
A Discouraged Approach

• POST /Reservations HTTP/1.1
• Host travelcompany.example.org
• Content-Type application/soapxml
  charset"utf-8"
• Content-Length nnnn
• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope"gt
• ltenvBodygt
• ltmretrieveItinerary
• envencodingStyle"http//www.w3.org/2003/
  05/soap-encoding"
• xmlnsm"http//travelcompany.example
  .org/"gt
• ltmreservationCodegtFT35ZBQlt/mreservationCod
  egt
• lt/mretrieveItinerarygt
• lt/envBodygt
• lt/envEnvelopegt

URI of HTTP request
the resource identifier should not be in the body!
54
Improving the POST

• POST /Reservations/itinerary?reservationCodeFT35Z
  BQ HTTP/1.1
• Host travelcompany.example.org
• Content-Type application/soapxml
  charset"utf-8"
• Content-Length nnnn
• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope"gt
• ltenvBodygt
• ltmretrieveItinerary
• envencodingStyle"http//www.w3.org/2003/
  05/soap-encoding"
• xmlnsm"http//travelcompany.example
  .org/"gt
• ltmreservationCodegtFT35ZBQlt/mreservationCod
  egt
• lt/mretrieveItinerarygt
• lt/envBodygt
• lt/envEnvelopegt

OK
55
RPC as GET

• GET /Reservations/itinerary?reservationCodeFT35Z
  BQ HTTP/1.1
• Host travelcompany.example.org
• Accept application/soapxml

• When an RPC definition is such that all parts of
  its method description can be described as
  resource-identifying, then the entire target of
  the RPC may be identified by a URI
• in this case, if the supplier of the resource can
  also assure that a retrieval request is safe,
  then SOAP Version 1.2 recommends
• the choice of the Web method property of GET
• and the use of the SOAP Response message exchange
  pattern
• this will ensure that the SOAP RPC is performed
  in a Web architecture compatible manner

56
SOAP Errors

• In many cases, applications define the content of
  the body
• The only exception is in case of errors, for
  which SOAP defines the element envFault with the
  following sub-elements
• envCode (mandatory) it tells the error code
• has two sub-elements envValue (mandatory) and
  envSubocde (optional)
• envReason (mandatory) errore message for human
  understanding not for algorithmic processing
• has one or more sub-elements envText (xmllang
  for different languages)
• envDetail (optional) additional info, related
  to the specific application (required if the
  error concerns the body, prohibited otherwise)
• envNode (optional) URI of the SOAP node issuing
  the error (is absent it is implicit that the node
  is the ultimate receiver)
• envRole (optional) role of the SOAP node
  issuing the error

57
Example rpcBadArguments

• lt?xml version'1.0' ?gt
• ltenvEnvelope xmlnsenv"http//www.w3.org/2003/05
  /soap-envelope"
• xmlnsrpc"http//www.w3.org/2003/05
  /soap-rpc"gt
• ltenvBodygt
• ltenvFaultgt
• ltenvCodegt
• ltenvReasongt
• ltenvText xmllang"en-US"gtProcessing
  errorlt/envTextgt
• lt/envReasongt
• ltenvDetailgt
• lt/envFaultgt
• lt/envBodygt
• lt/envEnvelopegt

ltenvCodegt ltenvValuegtenvSenderlt/envValuegt
ltenvSubcodegt ltenvValuegtrpcBadArgumentslt/env
Valuegt lt/envSubcodegt lt/envCodegt
ltenvDetailgt ltemyFaultDetails
xmlnse"http//travelcompany.example.org/faults"gt
ltemessagegtName does not match card
numberlt/emessagegt lteerrorcodegt999lt/eerrorcode
gt lt/emyFaultDetailsgt lt/envDetailgt
58
SOAP with Attachments

• SMTP binding is also possible
• Content-type as before (application/soapxml)
• To and From according to SMTP
• but now the communication is fully asynchronous
• if the answer is transmitted, it will arrive
  inside a later email message
• (there still exists some FTP implementations for
  SOAP)
• SOAP with attachments is a suitable extension
  that fully supports the use of attachments to the
  main message
• it allows for including images or other files
• it exploits the MIME multipart/related format

59
SOAP Binding on SMTPRequest Example

• From f.smith_at_myorg.example.com
• To reservations_at_travelcompany.example.org
• Subject Travel to LA
• Date Thu, 29 Nov 2001 132000 EST
• Message-Id ltEE492E16A090090276D208424960C0C_at_myorg
  .example.comgt
• Content-Type application/soapxml
• lt?xml version'1.0' ?gt
• ltenvEnvelope
• xmlnsenv"http//www.w3.org/2003/05/soap-env
  elope"gt
• ltenvHeadergt
• ltenvBodygt
• lt/envEnvelopegt

60
SOAP Binding on SMTPResponse Example

• From reservations_at_travelcompany.example.org
• To f.smith_at_myorg.example.com
• Subject Which NY airport?
• Date Thu, 29 Nov 2001 133511 EST
• Message-Id lt200109251753.NAA10655_at_travelcompany.e
  xample.orggt
• Content-Type application/soapxml
• lt?xml version'1.0' ?gt
• ltenvEnvelope
• xmlnsenv"http//www.w3.org/2003/05/soap-env
  elope"gt
• ltenvHeadergt
• ltenvBodygt
• lt/envEnvelopegt

61
SOAP Processing Model

• Actions taken by a SOAP node on receiving a SOAP
  message
• overall check that the SOAP message is correct
• select the header blocks addressed to itself
• depending on the envrole
• among those blocks, the node must process those
  marked by envmustUnderstand"true"
• only the ultimate receiver processes the envBody
• Processed blocks must be removed
• (but they can be reinserted)
• envrelay marks those blocks that can be relayed
  even if not processed
• Faults can be generated when processing any block

62
Does Interoperability Concern Past and Present?

• SOAP 1.2 has a number of changes in syntax and is
  improved in many ways w.r.t. SOAP 1.1
• their interoperability is not obvious!
• envactor in SOAP 1.1, envrole in SOAP 1.2
• envrelay introduced in SOAP 1.2
• "client"/"server" fault codes replaced by
  "Sender"/"Receiver", respectively
• use of dot notation for errors disallowed in SOAP
  1.2
• faultcode/faultstring replaced by
  envCode/envReason
• SOAP 1.2 no longer support sparse array encoding
• ...

63
Using SOAP

• SOAP is a relatively "lightweight" protocol
• many binding are possible (compression,
  encryption, ...)
• it is not very complicated to write / program
  SOAP nodes using JSP, servlet, CGI, PHP, ASP,
• but it is most likely that you won't do that
• It is even more convenient to use the available
  SOAP libraries
• Apache SOAP
• http//ws.apache.org/soap/index.html
• SAAJ (Sun)
• http//java.sun.com/webservices/downloads/webservi
  cespack.html