Post on 26-Dec-2015
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
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: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
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: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:henryford@hotmail.com</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:henryford@hotmail.com</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?