soap the simple object access protocol. objectives provide an introduction to soap rationale and...

SOAP

The Simple Object Access Protocol

Objectives

Provide an Introduction to SOAP Rationale and history Protocol description Syntax structure

Illustrate Infrastructure around SOAP Security and Authentication Service description and discovery

Overview

Section 1: Fundamentals

Section 2: Protocol Layers

Section 3: Message Elements

Section 4: Infrastructure

Summary

Section 1: Fundamentals

SOAP Definition

Evolution of an Open Standard

SOAP as RPC Protocol

SOAP as Messaging Protocol

XML and HTTP

SOAP Definition Simple Object Access Protocol 1.1

Envelope for XML Letters

Specification definition:

"Lightweight mechanism for exchanging structured and typed information between peers [...] using XML."

Designed both for messaging and RPC

Specifies three parts: SOAP envelope for message framework SOAP encoding for standardized marshaling SOAP RPC as remote procedure call convention

Evolution of an Open Standard

SOAP 0.x by UserLand and DevelopMentor

Predecessor UserLand‘s XML-RPC

SOAP 1.0 co-authored by Microsoft

SOAP 1.1 co-authored by IBM, Lotus Endorsed by Sun, IONA, Apache, etc. Submitted as a proposal to W3C Foundation for XML Protocol (XP) working group

http://www.w3.org/TR/SOAP

How it looks

A Simplified Request:

HTTP/1.1 POST /soap/mycomponentContent-Type: text/xmlSOAPAction: MyComponentMethod

<SOAP:Envelope> <SOAP:Body> <m:MyMethodArgumentsRoot>

<MyArgument>1</MyArgument> </m:MyMethodArgumentsRoot> </SOAP:Body></SOAP:Envelope>

SOAP as RPC Protocol

Marshals procedure calls via XML

Transport can be HTTP, SMTP, etc.

Roughly equivalent to DCOM & IIOP

No expensive middleware required

Anyone can implement easily Simplicity as a design goal

Designed for existing Internet infrastructure

Default wire-protocol for .NET Remoting

SOAP as Messaging Protocol

Descriptive container for any XML data exchange

Transport can be SMTP, X.400, Queues etc.

EDI-like: Equivalent to EDIFACT/X12 headers

Mail-like: Similar to Exchange Forms idea

Basis for BizTalk Framework

Interoperable and platform agnostic

Why XML ?

XML is a layered, (mostly) simple, text-based and standardized data exchange architecture.

XML (Documents and Entities)

XML + Namespaces (Elements and Attributes)

XML Information Set (Structure)

XML Schema (Classes)

SOAP

XML for Messaging and RPC

Simplicity XML documents are plain text

Portability No platform dependencies No issues as with binary protocols (byte-ordering) XML parsers exist for virtually every platform

Universally accepted XML is the #1 data exchange language

Why HTTP for RPC?

#1 application protocol used on the Internet

Available on all platforms

Simple to implement

Good infrastructure + extensibility

Not Connection oriented Designed for bad network conditions Designed to scale

HTTP services are easily deployed No firewall configuration problems

HTTP Characteristics Connectionless request/response mechanism

GET is the access protocol for resources

POST is the application protocol for interaction

Calls are directed to a URI

Headers specify options

Response codes indicate success/failure/status

HTTP/1.1 POST /signup.aspxContent-Type: text/www-form-urlencoded

fname=Clemens&lname=Vasters

HTTP/1.1 200 OKContent-Type: text/html

<html><body>Ha!</body></html>

Section 2: Protocol Layers

SOAP Envelope

SOAP Encoding

SOAP RPC

The Protocol Layers

SOAP layers it's own model on top of XML

SOAP Envelope

XML Framework

SOAP Encoding

SOAP RPC SOAP Messaging

Authentication Encryption BTF2.0 Attachments

SOAP Envelope

Purpose: Uniform container for XML messages

SOAP:Envelope is defined by XML Schema URI: http://schemas.xmlsoap.org/soap/envelope/

Contains SOAP:Header for handling instructions SOAP:Body for XML Payload

Specifies order, cardinality for structural elements

Defines SOAP:Fault for communication errors.

SOAP Encoding Purpose:

Uniform type and encoding system for data in SOAP Envelopes

Encoding is defined by XML schema http://schemas.xmlsoap.org/soap/encoding/

Optional recommendation Ensures interoperability of data

Defines rich type system: Simple Types, Enums Compound Values, Structures and References Arrays (incl. Sparse Arrays, Partial Arrays)

SOAP RPC

SOAP RPC is a set of rules for remote procedure calls

Key Points Interface/Service identified by URI Method invocation is modeled as structure Parameter order for [in/out] in response must be the

same as in request. Behavior on error (return SOAP:Fault)

Section 3: Message Elements

SOAP:Envelope element

SOAP:Header element

SOAP:Body element

SOAP:Fault element

SOAPAction HTTP header

SOAP:encodingStyle

HTTP/1.1 POST /soap/myserviceContent-Type: text/xmlSOAPAction: MyInterface#MyComponentMethod <SOAP:Envelope> <SOAP:Header> <m:myHeader xmlns:m=“myURI“ SOAP:mustUnderstand=“0“> HeaderInfo </m:myHeader> </SOAP:Header> <SOAP:Body> <m:MyMethodArgumentsRoot xmlns:m=“myURI“ > <MyArgument>1</MyArgument> </m:MyMethodArgumentsRoot> </SOAP:Body></SOAP:Envelope>

SOAP:Envelope

SOAP:Envelope

Basics: Top-level (root) element of every SOAP message Must be present

Must reference to the SOAP Envelope namespace xmlns:SOAP=

“http://schemas.xmlsoap.org/schemas/envelope/“

May have additional, custom attributes If present, they also must be namespace qualified

May contain at most one „Header“ child element

Must contain exactly one „Body“ child element

SOAP:Header


SOAP:Header Basics:

Optional element If present, must be immediate child of Envelope

May contain multiple child elements (headers) Specify processing hints for the message All child elements must be namespace-qualified

Special attributes for child elements: SOAP:mustUnderstand={“0“|“1“}

Specifies whether the header must be understood. If the server cannot understand the header, it must fail

SOAP:actor=“someURI“ Specifies who must or should process the header

Client

Dept.Server

SOAP Router

<m:destination xmlns:m=“myNamespace-URI“

SOAP:mustUnderstand=“1“ SOAP:actor=“next“/> <m:dept> 2881 <m:dept></m:destination>

acts on header and

routes to appropriate dept. server

Headers: Actors and Intermediaries

Dept.Server

Dept.Server

Envelope

Header

SOAP:Body


SOAP:Body

Basics: Must be present Must be an immediate child of the Envelope

May contain an unlimited number of child elements Children are called „body entries“ Body entries may be namespace- qualified Not subject to any encoding rules by default

HTTP/1.1 POST /soap/myserviceContent-Type: text/xmlSOAPAction: MyInterface#MyComponentMethod

<SOAP:Envelope> <SOAP:Body> <SOAP:Fault> <faultcode>Server.InvalidArg</faultcode> <faultstring>Type is wrong </faultstring> <detail/> </SOAP:Fault> </SOAP:Body></SOAP:Envelope>

SOAP:Fault

SOAP:Fault

Basics: SOAP Fault carries status and error information. Must be a body entry and may appear only once.

Child Elements: faultcode:

machine-readable reason-code

faultstring: human-readable reason explanation.

faultactor: indicates actor

detail: arbitrary data as detail info.

HTTP/1.1 POST /soap/myserviceContent-Type: text/xmlSOAPAction: MyInterface#MyComponentMethod

<SOAP:Envelope> <SOAP:Header> <m:myHeader xmlns:m=“myURI“ SOAP:mustUnderstand=“0“> HeaderInfo </m:myHeader> </SOAP:Header> <SOAP:Body> <m:MyMethodArgumentsRoot xmlns:m=“myURI“ > <MyArgument>1</MyArgument> </m:MyMethodArgumentsRoot> </SOAP:Body></SOAP:Envelope>

SOAPAction

SOAPAction

Basics SOAPAction header applies only to HTTP binding Must be present for HTTP SOAP calls Must be accompanied by „Content-Type: text/xml“

SOAPAction attribute is a URI and may be empty V1.1 specification issue

Role of HTTP URI vs. SOAPAction header vaguely defined

Recommended interpretation Use HTTP URI to specify the service

Use SOAPAction to specify interface and method

SOAP:encodingStyle Basics

„encodingStyle“ is a global attribute Encoding identified by URI May be applied to any element at any level Enforces common rules for serialization of data

Scope and Inheritance If present on an element, it applies to all children Any child may override encoding with own choice

SOAP defines an optional, standard encoding style Section 5 of the specification http://schemas.xmlsoap.org/schemas/encoding

<SOAP:Envelope xmlns:SOAP=“http://schemas.xmlsoap.org/schemas/envelope/“

xmlns:SOAP-ENC=“http://schemas.xmlsoap.org/schemas/ encoding/“ SOAP:encodingStyle=“http://schemas.xmlsoap.org/ schemas/encoding/“>[...]

<title xsi:type=„SOAP-ENC:string“> My Life and Work</title><price xsi:type=„SOAP-ENC:float“> 49.95</price>

[...]

</SOAP:Envelope>

Simple types are specified using the encoding namespace

Encoding Simple Types

<e:Book> <title>My Life and Work</title> <author> <name>Henry Ford</name> <address> <email>mailto:[email protected]</email> <web>http://www.henryford.com</web> </address> </author></e:Book>

„single-reference“ and nested structures are embedded

Encoding and Referencing Structures

<e:Books><e:Book>

<title>My Life and Work</title> <author href="#Person-1"/>

</e:Book><e:Book>

<title>The Success of Tin Lizzy</title> <author href="#Person-1"/>

</e:Book></e:Books><e:Person id="Person-1">

<name>Henry Ford</name><address> <email>mailto:[email protected]</email>

<web>http://www.henryford.com</web></address>

</e:Person>

„multi-reference“ structures use id & href attributes

Encoding and Referencing Structures

Section 4: Infrastructure

Authentication

Message Encryption and Signature

Service description: WSDL

Service discovery: DISCO and UDDI

Authentication SOAP enables high-capacity web-services

Raw information, no ads. Different business model Authentication required to control access

Authentication is intentionally skipped in SOAP 1.1 Can utilize HTTP authentication framework Can use S/MIME signatures

SOAP shall work „cross-everything“ Must use standardized authentication schemes Authentication must be reasonably secure Resistant against various attack types

Use Digest Authentication with .NET

Privacy

SOAP may carry sensitive information Use HTTPS instead of HTTP Use S/MIME encoding instead of MIME

SOAP Extensions for Privacy underway from IBM

WSDL Think "TypeLib for SOAP"

WSDL = Web Service Description Language

Uniform representation for services Transport Protocol neutral Access Protocol neutral (not only SOAP)

Describes: Schema for Data Types Call Signatures (Message) Interfaces (Port Types) Endpoint Mappings (Bindings) Endpoints (Services)

DISCO

Think "IDispatch for SOAP"

Dynamic Discovery of Services

Very, very easy discovery model for HTTP

Basics: Call endpoint with GET Check whether this is a DISCO file or a redirect DISCO file contains link to WSDL If redirect goto 1

UDDI

Think "Yahoo!" for WebServices

Universal Description and Discovery Interface

WebService-Programmable "Yellow Pages"

Advertise Sites and Services

May point to DISCO resources

Initiative driven by Microsoft, IBM, Ariba

Summary

Platform agnostic XML based protocol

Can implement anywhere easily

Very Extensible model for messaging and RPC

Embedded into existing Internet technology set Built for the Internet, works best for the Internet

Open discovery and description infrastructure

Foundation for the WebServices model

Foundation for .NET Internet Remoting

Questions?

soap the simple object access protocol. objectives provide an introduction to soap rationale and...

Documents

rpc protocol soap

messaging protocol xml

xml protocol xp

http slide

soap security

soap rationale

microsoft soap

xml transport