1 WS Technologies I SOAP Roberto Bruni Dipartimento di Informatica Università di Pisa Models and...

1

WS Technologies ISOAP

Roberto BruniDipartimento di Informatica Università di Pisa

Models and Languages for Coordination and Orchestration

IMT- Institutions Markets Technologies - Alti Studi Lucca

2

Roberto Bruni @ IMT Lucca 15 March 2005


InstitutionsMarketsTechnologies

IMT

Contents Web Services, informally SOAP: a protocol for WS UDDI registries

3




IMT

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




IMT

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?)

SOAP as Web Middleware

Middleware applications Web publishing

SOAP

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

XML for RPC via HTTP

5




IMT

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




IMT

Example:RMI on Remote Server

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;

}Where is the network code?

The only code needed is that for extending the

Remote interface

It is the advantage of middleware applications

è sufficiente designare alcuni

oggetti come remoti per gestire gli aspetti di rete e di protocollo. La

designazione varia anche in funzione della

tecnologia utilizzata.

è sufficiente designare alcuni

oggetti come remoti per gestire gli aspetti di rete e di protocollo. La

designazione varia anche in funzione della

tecnologia utilizzata.

7




IMT

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




IMT

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




IMT

An XML-RPC Request IPOST /xmlrpc HTTP/1.0

User-Agent: Handson (Win98)

Host: joker.psol.com

Content-Type: text/xml

Content-length: 454

<?xml version=“1.0”?>

<methodCall>

<methodName>com.psol.res.BookingService.getFreeResOn</methodName>

<params>

<param>

<value>

<dateTime.iso8601>2004-01-15T00:00:00</dateTime.iso8601>

</value>

</param>

10




IMT

An XML-RPC Request II

<param>

<value>


</value>

</param>

</params>

</methodCall>

11




IMT

Encoding of the RPC call

The content is an XML document

An XML-RPC Request IIIHTTP POST request

Says which remote method is invoked

Contains the parameter list

A param element for each parameter

POST /xmlrpc HTTP/1.0




Content-length: 454


<methodCall>


<params>

<param>

<value>


</value>

</param>

12




IMT

An XML-RPC Request IV

Element for the parameter value

Type of (the value) of the parameter

Other types supported by XML-RPC:

• int (signed integer)

• boolean (0 false, 1 true)

• string (string)

• double (floating point)

• base64 (binary stream)

POST /xmlrpc HTTP/1.0




Content-length: 454


<methodCall>


<params>

<param>

<value>


</value>

</param>

13




IMT

An XML-RPC Answer IHTTP/1.0 200 OK

Content-length: 485


Server: Jetty/3.1.4 (Windows 98 4.10 x86)


<methodResponse>

<params>

<param>

<value>

<array>

<data>

<value><string>Meeting Room 1</string></value>

<value><string>Meeting Room 2</string></value>

<value><string>Board Room</string></value>

14




IMT

An XML-RPC Answer II

</data>

</array>

</value>

</param>

</params>

</methodResponse>

15




IMT

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




IMT

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




IMT

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 HTTP SMTP

BindingHTTP

BindingSMTP

Messaging structure(envelope)

Coding rules

SOAPRPC

Other standards

(transport,routing,

packeting)

18




IMT

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




IMT

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




IMT

A SOAP 1.1 Request IPOST /soap/servlet/rpcrouter HTTP/1.0


Content-Type: text/xml; charset=utf-8

Content-length: 557

SOAPAction: "http://www.psol.com/2004/soapaction"

<?xml version='1.0' encoding='UTF-8'?>

<env:Envelope xmlns:xsd="…XMLSchema"

xmlns:env="…soap/envelope/"

xmlns:xsi="…XMLSchema-instance">

<env:Body>

<ns1:getFreeResOn xmlns:ns1="…"

enc:encodingStyle="…soap/encoding/">

<start xsi:type="xsd:timeInstant">2004-01-15T00:00:00Z</start>

<end xsi:type="xsd:timeInstant">2004-01-17T00:00:00Z</end>

21




IMT

A SOAP 1.1 Request II

</ns1:getFreeResOn>

</env:Body>

</env:Envelope>

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




IMT

A SOAP 1.1 Answer IHTTP/1.0 200 OKServer: 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; charset=utf-8Content-length: 692

<?xml version='1.0' encoding='UTF-8'?><env:Envelope xmlns:xsd="…XMLSchema" xmlns:env="…soap/envelope/" xmlns:xsi="…XMLSchema-instance"> <env:Body> <ns1:getFreeResOnResponse xmlns:ns1="…" env:encodingStyle="…soap/encoding/"> <return xmlns:ns2="…/soap/encoding/" xsi:type=“ns2:Array” ns2:ArrayType=“ns1:String[3]”>

23




IMT

A SOAP 1.1 Answer II

<item xsi:type="xsd:string">Meeting Room 1</item>

<item xsi:type="xsd:string">Meeting Room 2</item>

<item xsi:type="xsd:string">Board Room</item>

</return>

</ns1:getFreeResOnResponse>

</env:Body>

</env:Envelope>

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




IMT

Structure of SOAP Messages

SOAP Blocks single logic computational units represented as XML elements identifies from qualifying name

namespace and local name env:Envelope

source of SOAP request env:Header

optional: it contains additional info about routing, authentication env:Body

mandatory: it contains the main info env:Fault

it may appear in the body: it denotes errors occurring at the protocol level

env:Envelope

SOAP block

env:Header

SOAP block

env:Body

25




IMT

The Envelope Analogy

SOAP messages as actual letters(remember those antiquated things in envelopes with postage and an address scrawled across the front?)

26




IMT

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




IMT

Travel Reservation: Request Header

<?xml version='1.0' ?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Header>

<m:reservation xmlns:m="http://travelcompany.example.org/reservation"

env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

env:mustUnderstand="true" >

<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>

<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>

</m:reservation>

<n:passenger xmlns:n="http://mycompany.example.com/employees"



<n:name>Fred Smith</n:name>

</n:passenger>

</env:Header>

28




IMT

Travel Reservation: Request Body

<env:Body> <p:itinerary

xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>New York</p:departing> <p:arriving>Los Angeles</p:arriving> <p:departureDate>2001-12-14</p:departureDate> <p:departureTime>late afternoon</p:departureTime> <p:seatPreference>aisle</p:seatPreference> </p:departure> + <p:return> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:Body></env:Envelope>

<p:return> <p:departing>Los Angeles</p:departing> <p:arriving>New York</p:arriving> <p:departureDate>2001-12-20</p:departureDate> <p:departureTime>mid-morning</p:departureTime> <p:seatPreference/> </p:return>

29




IMT

Travel Scenario:Structure of SOAP Message

env:Envelope

env:Header

q:lodging

p:itinerary

env:Body

n:passenger

m:reservation(reference, timestamp)

Header blocks can be inspected by

intermediary nodes ultimate receiver

Body can be inspected by

ultimate receiver only (in principle) cannot prevent malicious behaviours

30




IMT

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




IMT

Header Main attributes of tags inside the header:

env:role 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

env:mustUnderstand a node should not elaborate the request when it

does not "understand" an element marked by env:mustUnderstand="true"

32




IMT

Example: Proxy Processing

client proxy server

env:Envelope

env:Header

env:Body

env:Envelope

env:Body

In the example, the env:role attribute specifies thatall header blocks are addressed to the proxy

33




IMT

Travel Reservation: Response Header



<env:Header>

<m:reservation xmlns:m="http://travelcompany.example.org/reservation"



<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>

<m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>

</m:reservation>

<n:passenger xmlns:n="http://mycompany.example.com/employees"



<n:name>Fred Smith</n:name>

</n:passenger>

</env:Header>

34




IMT

Travel Reservation: Response Body

<env:Body>

<p:itineraryClarification

xmlns:p="http://travelcompany.example.org/reservation/travel">

<p:departure>

<p:departing>

<p:airportChoices>

JFK LGA EWR

</p:airportChoices>

</p:departing>

</p:departure>

+ <p:return>

</p:itineraryClarification>

</env:Body>

</env:Envelope>

<p:return> <p:arriving> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:arriving> </p:return>

35




IMT

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 (date&time)

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




IMT

Travel Reservation: Response to Response (Header)

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> <m:dateAndTime>2001-11-29T13:36:50.000-05:00</m:dateAndTime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Fred Smith</n:name> </n:passenger> </env:Header>

37




IMT

Travel Reservation: Response to Response (Body)

<env:Body>

<p:itinerary

xmlns:p="http://travelcompany.example.org/reservation/travel">

<p:departure>

<p:departing>LGA</p:departing>

</p:departure>

<p:return>

<p:arriving>EWR</p:arriving>

</p:return>

</p:itinerary>

</env:Body>

</env:Envelope>

38




IMT

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




IMT

Field Coding Basic rule: all values are always

encoded inside elements ex. a field name can become

<name>Board Room</name> but not

<item name="Board Room" />

40




IMT

Coding of Simple Types 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 xsi:type attribute can help to resolve ambiguity

issues

<start xmlns:xsi=“…XMLSchema-instance”

xmlns:xsd=“…XMLSchema”

xsi:type=“xsd:dateTime”>2004-01-15T00:00:00Z</start>

Java utilizza xsi:type senza

problemi,

altri linguaggi meno restrittivi

potrebbero ignorarlo se

genera conflitti

documenti XML validi (con schema)

riducono le ambiguità!

Java utilizza xsi:type senza

problemi,

altri linguaggi meno restrittivi

potrebbero ignorarlo se

genera conflitti

documenti XML validi (con schema)

riducono le ambiguità!

41




IMT

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




IMT

Example: Resource Class

public class Resource {

public int id;

public String name;

public String description;

}

<rs:Resource xmlns:rs="…"

xmlns:xsi="…XMLSchema-instance"

xmlns:xsd="…XMLSchema"

xmlns:env="…/soap-envelope"

env:encodingStyle="…/soap-encoding">

<id xsi:type="xsd:int">0</id>

<name xsi:type="xsd:string">Auditorium</name>

<description xsi:type="xsd:string">Largest room</description>

</rs:Resource>

43




IMT

Travel Scenario:RPC 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




IMT

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




IMT

Reservation Charge as RPC:Invocation I


<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >

<env:Header>

<t:transaction xmlns:t="http://thirdparty.example.org/transaction"

env:encodingStyle="http://example.com/encoding"

env:mustUnderstand="true" >5</t:transaction>

</env:Header>

<env:Body>

<m:chargeReservation xmlns:m="http://travelcompany.example.org/"

env:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

+ <m:reservation xmlns:m="http://travelcompany.example.org/reservation">

+ <o:creditCard xmlns:o="http://mycompany.example.com/financial">

</m:chargeReservation>

</env:Body>

</env:Envelope>

method name

application-specific transaction indentifier input 1

input 2

46




IMT

Reservation Charge as RPC:Invocation II



<env:Header>




</env:Header>

<env:Body>






</env:Body>

</env:Envelope>

input 1

<m:reservation xmlns:m="http://travelcompany.example.org/reservation"> <m:code>FT35ZBQ</m:code> </m:reservation>

47




IMT

Reservation Charge as RPC:Invocation III



<env:Header>




</env:Header>

<env:Body>






</env:Body>

</env:Envelope>

<o:creditCard xmlns:o="http://mycompany.example.com/financial" xmlns:n="http://mycompany.example.com/employees" > <n:name>Fred Smith</n:name> <o:number>123456789099999</o:number> <o:expiration>2005-02</o:expiration></o:creditCard>

input 2

48




IMT

Reservation Charge as RPC:Response I

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true" >5</t:transaction> </env:Header> <env:Body> <m:chargeReservationResponse xmlns:m="http://travelcompany.example.org" env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <m:code>FT35ZBQ</m:code> <m:viewAt> http://travelcompany.example.org/reservations?code=FT35ZBQ </m:viewAt> </m:chargeReservationResponse> </env:Body></env:Envelope>

output 1

output 2

added by convention

49




IMT

Reservation Charge as RPC:Response II



+ <env:Header>

<env:Body>

<m:chargeReservationResponse xmlns:m="http://travelcompany.example.org"

xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"


<rpc:result>m:status</rpc:result>

<m:status>confirmed</m:status>

<m:code>FT35ZBQ</m:code>

+ <m:viewAt>

</m:chargeReservationResponse>

</env:Body>

</env:Envelope>

a specific return valuecan be distinguished

among output parameters

(it is assumed to be voidwhen not otherwise

specified)

50




IMT

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




IMT

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/soap+xml 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




IMT

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




IMT

A Discouraged ApproachPOST /Reservations HTTP/1.1

Host: travelcompany.example.org

Content-Type: application/soap+xml; charset="utf-8"

Content-Length: nnnn



<env:Body>

<m:retrieveItinerary

env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"

xmlns:m="http://travelcompany.example.org/">

<m:reservationCode>FT35ZBQ</m:reservationCode>

</m:retrieveItinerary>

</env:Body>

</env:Envelope>

the resource identifiershould not be in the body!

URI of HTTP request

54




IMT

Improving the POSTPOST /Reservations/itinerary?reservationCode=FT35ZBQ HTTP/1.1


Content-Type: application/soap+xml; charset="utf-8"

Content-Length: nnnn



<env:Body>

<m:retrieveItinerary

env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"

xmlns:m="http://travelcompany.example.org/">

<m:reservationCode>FT35ZBQ</m:reservationCode>

</m:retrieveItinerary>

</env:Body>

</env:Envelope>

OK

55




IMT

RPC as GETGET /Reservations/itinerary?reservationCode=FT35ZBQ HTTP/1.1


Accept: application/soap+xml

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




IMT

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 env:Fault with the following sub-elements env:Code (mandatory): it tells the error code

has two sub-elements: env:Value (mandatory) and env:Subocde (optional) env:Reason (mandatory): errore message for human understanding not

for algorithmic processing has one or more sub-elements env:Text (xml:lang for different languages)

env:Detail (optional): additional info, related to the specific application (required if the error concerns the body, prohibited otherwise)

env:Node (optional): URI of the SOAP node issuing the error (is absent it is implicit that the node is the ultimate receiver)

env:Role (optional): role of the SOAP node issuing the error

57




IMT

Example: rpc:BadArguments


<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"

xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">

<env:Body>

<env:Fault>

+ <env:Code>

<env:Reason>

<env:Text xml:lang="en-US">Processing error</env:Text>

</env:Reason>

+ <env:Detail>

</env:Fault>

</env:Body>

</env:Envelope>

<env:Code>

<env:Value>env:Sender</env:Value>

<env:Subcode>

<env:Value>rpc:BadArguments</env:Value>

</env:Subcode>

</env:Code>

<env:Detail>

<e:myFaultDetails

xmlns:e="http://travelcompany.example.org/faults">

<e:message>Name does not match card number</e:message>

<e:errorcode>999</e:errorcode>

</e:myFaultDetails>

</env:Detail>

58




IMT

SOAP with Attachments SMTP binding is also possible

Content-type as before (application/soap+xml) 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




IMT

SOAP Binding on SMTP:Request Example

From: [email protected]

To: [email protected]

Subject: Travel to LA

Date: Thu, 29 Nov 2001 13:20:00 EST

Message-Id: <[email protected]>

Content-Type: application/soap+xml


<env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-envelope">

+ <env:Header>

+ <env:Body>

</env:Envelope>

60




IMT

SOAP Binding on SMTP:Response Example

From: [email protected]

To: [email protected]

Subject: Which NY airport?

Date: Thu, 29 Nov 2001 13:35:11 EST

Message-Id: <[email protected]>

Content-Type: application/soap+xml


<env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-envelope">

+ <env:Header>

+ <env:Body>

</env:Envelope>

61




IMT

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 env:role among those blocks, the node must process those marked

by env:mustUnderstand="true" only the ultimate receiver processes the env:Body

Processed blocks must be removed (but they can be reinserted) env:relay marks those blocks that can be relayed even if

not processed Faults can be generated when processing any block

62




IMT

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!

env:actor in SOAP 1.1, env:role in SOAP 1.2 env:relay 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 env:Code/env:Reason SOAP 1.2 no longer support sparse array encoding ...

63




IMT

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/webservicespack.html

1 WS Technologies I SOAP Roberto Bruni Dipartimento di Informatica Università di Pisa Models and...

Documents

Transcript of 1 WS Technologies I SOAP Roberto Bruni Dipartimento di Informatica Università di Pisa Models and...