Transcript Overview
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 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 HTTP/1.1 200 OK fname=Clemens&lname=Vasters Content-Type: text/html
Ha!Section 2: Protocol Layers
SOAP Envelope SOAP Encoding SOAP RPC
The Protocol Layers
SOAP layers it's own model on top of XML
SOAP RPC SOAP Messaging SOAP Encoding
Authentication Encryption BTF2.0
SOAP Envelope
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: 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
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/myservice Content-Type: text/xml SOAPAction: MyInterface#MyComponentMethod
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
Headers: Actors and Intermediaries
Client
Server Dept.
Server Dept.
Server
SOAP:Body
HTTP/1.1 POST /soap/myservice Content-Type: text/xml SOAPAction: MyInterface#MyComponentMethod
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
SOAP:Fault
HTTP/1.1 POST /soap/myservice Content-Type: text/xml SOAPAction: MyInterface#MyComponentMethod
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.
SOAPAction
HTTP/1.1 POST /soap/myservice Content-Type: text/xml SOAPAction: MyInterface#MyComponentMethod
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
Encoding Simple Types
Simple types are specified using the encoding namespace
[...]
Encoding and Referencing Structures
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