330 likes | 492 Views
SOAP, REST, POX, RSS – The What's What of Services. Aaron Skonnard Co-Founder, Pluralsight http://pluralsight.com/aaron. Outline. Story of My First Service The Origins of XML The Origins of Services SOAP vs. REST Trade-offs & Guidance. Story of My First Service. Partner Systems.
E N D
SOAP, REST, POX, RSS – The What's What of Services Aaron Skonnard Co-Founder, Pluralsight http://pluralsight.com/aaron
Outline • Story of My First Service • The Origins of XML • The Origins of Services • SOAP vs. REST • Trade-offs & Guidance
Story of My First Service Partner Systems Our Application ASCEND 97
1997 Implementation Message parsing became the most difficult aspect [Distributor] Name=Dave Jones ID=1234-1000 ... [Distributor] Name=Sara Jones ID=1234-1001 Sponsor=1234-1000 ... Text-based data format, easier than binary Partner Systems Our Application HTTP Specs Specs ASCEND 97 Specs Specifications defined message types
Architecture Fundamentals • Message-based architecture • Communication transport • Data format • Standard message types • Defined in a specification • Extensibility
1998: A Big Turning Point • XML, an innocuous new technology, hit the scenes in 1998 • Offered a "standard" data format • Based on a simplification of SGML • Quickly noticed and embraced • Promised to simplify scenarios like mine
The Origins of XML Today XML ubiquitous throughout the industry 1998 XML approved as W3C Recommendation 1996 XML proposed to W3C as a simplification of SGML, led by Jon Bosak (Sun) 1994 TBL forms the W3C with MIT and CERN CERN declares WWW free-to-all, NCSA releases Mosaic browser 1993 1989 Tim Berners-Lee invented HTML at CERN, calls it the World Wide Web SGML approved as ISO standard (ISO 8879) 1986 1980 First ANSI Standard Generalized Markup Language (SGML) draft released Goldfarb, Mosher, and Rice invented GML (IBM) 1969 Tunnicliffe and Rice introduce the concept of generic markup 1967
What Made XML Successful? • The format wasn't better, so what gives? • The success of HTML made it familiar • Not very many people involved • They produced a simple specification • Didn't require huge investments • Simplicity allowed anyone to get involved
Simple XML Foundation • Key XML technologies quickly developed • Laid solid foundation for apps to build on • Simplified numerous business scenarios XSLT XPath APIs XML Infoset Namespaces
Angle Bracket Factions • Once XML was commonplace, the factions became apparent XML Document-Centric Focused on document-based systems, electronic publishing, etc. Data-Centric Focused on data structures, services, distributed application scenarios, etc.
On Defining Standards • The Web has shown ubiquity is king • Defining standards is tricky business • Requires collaboration and consensus • Forces everyone to compromise • The more people, the harder it becomes • Usually takes a long time "Only a committee can make a decision that's dumber than any of its members."
The Origins of Services Today SOAP 1.1 / 1.2 ubiquitous throughout the industry 2/2005 POX enters the lexicon 10/2003 Tenets of Service Orientation introduced at PDC 6/2003 SOAP 1.2 released as W3C recommendation 3/2001 WSDL 1.1 released as W3C Note 2/2001 ebXML integrates SOAP into Messaging Services Specification 5/2000 SOAP submitted to the W3C as Note, work on SOAP 1.2 begins 4/2000 SOAP 1.1 released on vendor Web sites REST architecture published by Roy Fielding 2000 2/1999 SOAP 1.0 released as an IETF Internet Draft 4/1998 Userland releases XML-RPC (subset of original SOAP work) 1998 Work on SOAP commenced, first spec never published
SOAP Architecture • SOAP is an extensible XML framework • SOAP defines: • A standard XML framing mechanism that can be used with any transport • A standard representation for errors • A standard processing model • SOAP itself doesn't define: • A standard metadata (type) system
SOAP Framing • SOAP framing allows future extensibility • Headers pushed into XML to decouple functionality from transport <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> <soap:Header> </soap:Header> <soap:Body> </soap:Body> </soap:Envelope> Headers define additional layers (WS-*) <!-- headers go here --> <!-- payload go here -->
XSD and WSDL • SOAP was completed by XSD and WSDL • XML Schema (XSD) introduced type system for XML applications • WSDL introduced an interface definition language for services • WS-I sanctioned them in the basic profile • Basic Profile 1.1 released 8/2004
SOAP/WSDL Frameworks • Tool support simplifies the dev experience • Code generation built on XSD and WSDL • Move between XML and native type systems • Hides virtually all XML/HTTP coding details adwords = makeProxy( ‘http://.../KeywordService’, ‘nelson’, ‘ossifrage’) adwords.setKeywordMaxCpc(53834, ‘flowers’, $0.05) This tool support is one of SOAP's key advantages
CoordinationAtomic Transactions Business Activities Reliable Messaging CoordinationAtomic Transactions Business Activities Reliable Messaging XML Schema WSDL Policy Discovery Discovery WS-* protocol stack Message SecuritySecure ConversationTrust Security Policy ReliableDelivery Security Transactions Metadata Messaging XML Transports HTTP TCP Cross-AppDomain XML Infoset XMLMTOM Binary SOAP Addressing Eventing Transfer
WCF (WinFX) • Microsoft's WCF provides full WS-* support • SOAP-based security, RM, and transactions • Supports numerous transports (HTTP, TCP, named pipes, MSMQ, P2P, etc) • Hides complexity through simplified OM
SO Design Principles • Service Orientation (SO) emerged to help us think about service design • SO is a set of design principles: • Boundaries are explicit • Services are autonomous • Share schema and contract only • Policy-based compatibility
Orchestration (Workflow) • A future trend is orchestration / workflow • Automating business processes that consist of XML message exchanges • BPEL is the standard laying the foundation • Based on XML, XSD, and WSDL foundation • Supported by MS, IBM, BEA, etc • See BizTalk and WF (WinFX) for support
Is SOAP Too Much? • Some believe SOAP is overkill at times • When the Basic Profile is enough • No need for SOAP-based SRT • Plain Old SOAP approach often used • Leverage SOAP but without WS-* • Increases interoperability potential • Frameworks/tools hide XML/HTTP code
Plain Old XML (POX) • Some go further: Plain Old XML (POX) • Ditch SOAP altogether • Just exchange XML messages over HTTP • Interoperability is virtually guaranteed • Requires more XML/HTTP coding
REST Architectures • In 2000, Roy Fielding introduced REST • "REpresentational State Transfer" • An architecture for services on the Web • An observation of how the Web works • Fundamentally different from SOAP/WS-*, but similar goals in mind
REST Design Principles • REST design principles: • Stateless client/server protocol (HTTP) • Well-defined operations (GET, POST, PUT, DELETE) • Universal resource identifier syntax (URI) • Use of hypermedia (HTML, XML)
Understanding REST • SOAP emphasizes verbs while REST emphasizes nouns Generic HTTP verbs can be used with each noun (GET, POST, PUT, DELETE) Tunnels through HTTP POST REST SOAP User { } Location { } getUser() addUser() removeUser() updateUser() listUsers() findUser() getLocation() addLocation() ... POX representation <user> <name>Jane User</name> <gender>female</gender> <location href= "http://www.example.org/locations/us/ny/new_york_city">New York City, NY, US</location> </user>
Weblogs and RSS • Most of blogosphere is REST-based • Each item is addressable by URI • You can retrieve lists of items, etc • RSS versions define representations • RSS 0.9x, 1.0 and 2.0 are common today • Very different, influenced by vendors
Atom 1.0 • Atom 1.0 is emerging as the syndication standard today • Submitted to IETF, published as RFC 4287 • Completely vendor-neutral • Atom Publishing API is REST-based
REST Pros & Cons • Pros • Simplifies traditional CRUD-style scenarios • Addressability, consistency • Optimized for reads (GET) • Cons • Tied to HTTP for all practical purposes • Hence, limited to HTTP feature set • Lacks metadata standards & tool support
SOAP/REST Sightings • Both have carved out their own turf • Many popular sites offer services via SOAP or REST or both • Google, Yahoo!, Amazon, eBay, etc • The jury is still out in certain areas • Enterprises are embracing SOAP/WS-* • Complexity exposes REST limitations
Guidance • Embrace POX/HTTP for reach integration • Use Plain Old SOAP for better tool support • Consider REST principles for CRUD-driven scenarios (may extend reach further) • Leverage SOAP + WS-* for deep enterprise integration • WSE, WCF, BizTalk, WF, etc.
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
Special training offer from Pluralsight • Mention you attended this talk, and receive a $200 discount on your next course • Upcoming courses • .NET Campsight, Building Connected Systems • September 18-22 in Redmond, WA • Double Feature: WCF & Workflow • August 28-September 1 in Mountain View, CA