The Simple Object Access Protocol

Name: The Simple Object Access Protocol
Uploaded: 2017-08-12T14:28:35+00:00
Duration: PTM21S21
Channel: Kathleen Poole
Description: The Simple Object Access Protocol

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

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/ 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: 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 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= “ 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> <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

Encoding Simple Types Simple types are specified using the encoding namespace <SOAP:Envelope xmlns:SOAP=“ xmlns:SOAP-ENC=“ encoding/“ SOAP:encodingStyle=“ schemas/encoding/“> [...] <title xsi:type=„SOAP-ENC:string“> My Life and Work </title> <price xsi:type=„SOAP-ENC:float“> </price> [...] </SOAP:Envelope>

Encoding and Referencing Structures
<e:Book> <title>My Life and Work</title> <author> <name>Henry Ford</name> <address> <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> <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?

The Simple Object Access Protocol

Similar presentations

Presentation on theme: "The Simple Object Access Protocol"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The Simple Object Access Protocol

Similar presentations

Presentation on theme: "The Simple Object Access Protocol"— Presentation transcript:

Similar presentations

About project

Feedback