The Simple Object Access Protocol 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/mycomponent Content-Type: text/xml SOAPAction: 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. SOAP XML Schema (Classes) XML Information Set (Structure) XML + Namespaces (Elements and Attributes) XML (Documents and Entities)
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.aspx Content-Type: text/www-form-urlencoded fname=Clemens&lname=Vasters HTTP/1.1 200 OK Content-Type: text/html <html><body>Ha!</body></html>
Section 2: Protocol Layers SOAP Envelope SOAP Encoding SOAP RPC
The Protocol Layers XML Framework SOAP RPC SOAP Messaging SOAP layers it's own model on top of XML SOAP RPC SOAP Messaging SOAP Encoding SOAP Envelope Authentication Encryption BTF2.0 Attachments XML Framework
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: Encoding is defined by XML schema 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
SOAP:Envelope HTTP/1.1 POST /soap/myservice Content-Type: text/xml SOAPAction: 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 Basics: Must reference to the SOAP Envelope namespace 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/myservice Content-Type: text/xml SOAPAction: 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: May contain multiple child elements (headers) 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
Headers: Actors and Intermediaries Client SOAP Router Dept. Server <m:destination xmlns:m=“myNamespace-URI“ SOAP:mustUnderstand=“1“ SOAP:actor=“next“/> <m:dept> 2881 <m:dept> </m:destination> Dept. Server Envelope Header Dept. Server acts on header and routes to appropriate dept. server
SOAP:Body HTTP/1.1 POST /soap/myservice Content-Type: text/xml SOAPAction: 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: May contain an unlimited number of child elements 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
SOAP:Fault HTTP/1.1 POST /soap/myservice Content-Type: text/xml SOAPAction: 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 Basics: Child Elements: 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.
SOAPAction HTTP/1.1 POST /soap/myservice Content-Type: text/xml SOAPAction: 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 Basics SOAPAction attribute is a URI and may be empty 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 Scope and Inheritance „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
Encoding Simple Types Simple types are specified using the encoding namespace <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>
Encoding and Referencing Structures <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
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?