A brief history of XML, SOAP and RESTsoftware reuse – a mantra over three decadesA quest began in the 1980’sMajor client-server distributed computer paradigmsby the late 1990’s…1998, birth of XMLSOA, a grand(iose) vision for “web services”idealized runtime web service scenarioHigh ExpectationsWeb service standards were ready by about 2000Web services gradually became viableBacklashThe balanced viewSOAP strengths and weaknesseswhat do these have in common?what do all these have in common?the end of this PowerPoint fileJan 14, 2019 1A brief history of XML, SOAP and RESTPat Palmer, early 2011v1.0Jan 14, 2019 rpc_quest.ppt 2software reuse – a mantra over three decades•In the early 1980’s, software was not yet “distributed”, only “copied around”•Programmers wanted to install software once on a server, and then call it remotely over a network from many clients•“Remote Procedure Call” (RPC)A quest began in the 1980’s•Several major efforts were made to do RPC over the next 25 years•All suffered from at least one of the common “fallacies of distributed computing”:•The network is secure•The network is homogeneous•The network is fast enough•HTTP partially fulfilled the need in the early 1990’s•Programmers could make HTTP GET requests in those days, but the language support for it was not great until recent yearsJan 14, 2019 rpc_quest.ppt 3Major client-server distributed computer paradigms•1980’s: •RPC using C/C++•EDI with ASN.1•Microsoft DCOM•1990’s: •CORBA (for Unix/Linux only)•HTTP (so-called REST web services)Jan 14, 2019 rpc_quest.ppt 4Jan 14, 2019 rpc_quest.ppt 5by the late 1990’s…•still no way to distribute an application across multiple computers that was:•standards-based•platform-independentJan 14, 2019 rpc_quest.ppt 61998, birth of XML•XML was standardized by the W3C in 1998•soon all the compilers started supporting XML•driven in part by Microsoft, but supported by many other companies, work began on a series of standards for XML-based RPC’s•based on the idea of an existing open-source initiative called “XML RPC”•A new idea was taking shape due to XML being standardized:•“web services” and Service Oriented Architecture (SOA)Jan 14, 2019 rpc_quest.ppt 7SOA, a grand(iose) vision for “web services”•they would be standards-based, platform-independent, and immune to firewalls•some kind of XML would be the wire format•each service’s contract would be expressed in a formal manner and registered in a catalog•programming languages could “parse” this contract and utilize it at runtime, like an interface in Java•there would be a “factory” call that returned a reference to the currently preferred implementation of a given service contract•software architects would “compose” designs by shopping among available services •network and machine speed and capacity would increase to make the overhead of XML tolerable•massive software reuse would be achievedJan 14, 2019 rpc_quest.ppt 8idealized runtime web service scenario1. discoveryrequest2. discoveryresponse (WSDL contract)3. servicerequest4. serviceresponsediscoveryserviceHTTP serverwebserviceHTTP serverclientapplicationprogram (desktop or web-based)High Expectations•From time to time, the software industry latches onto an idea so eagerly that expectations are raised to fever pitch, sometimes far beyond the reality of the new technology to filfill:•Object-oriented databases•SOA•Ajax and Web 2.0•Cloud computing (?)•These slides will talk about web services, which fulfilled a part of the SOA visionJan 14, 2019 rpc_quest.ppt 9Jan 14, 2019 rpc_quest.ppt 10Web service standards were ready by about 20001. For automatic discovery (service catalot)•Universal Description, Discovery and Integration (UDDI)2. For the contract•Web Service Definition Language (WSDL)•an XML-based schema for web service contracts: how to call a service, but not how it’s implemented3. For message serialization•SOAP•client/server protocol for exchanging messages over computer networks, with HTTP/HTTPS (POST) as the transport; it passes parameters in XML and return values in XML, and has a standardized error mechanismWeb services gradually became viable•2004: Web Services Interoperability Organization (WS-I ) issued a SOAP test tool suite•http://www.ws-i.org•2005: Microsoft made calling a web service simple with C# 2.0 and .NET 2 •Programmer providse a web service URL and calls it (via a local proxy object) in a try-catch block; the proxy hides all of the SOAP messaging and error handling•2006-8: Ruby and many other languages provided proxy-automated web service calling•In 2009, Java provided proxy-automated web service calling with Netbeans 6.7 •Of course, web services could always be done without an automated proxy, but in practice, this was too much trouble and few did thatJan 14, 2019 rpc_quest.ppt 11Backlash•Many companies, including Yahoo! and Google, initially provided SOAP-based API’s•Windows programmers used these a lot due to the automation included in .NET 2.0 •Then, a massive anti-SOAP campaign arose•Led by Roy Fielding (then employed by SUN)•REpresentational State Transfer (REST)•Really HTTP GET calls with incoming parameters in the URL•Claim: RPC calls not needed, even “harmful”, too inefficient, and no bookmark for the data object that is the topic of the call•During the fray, Amazon, Yahoo! and Google cancelled all their SOAP API’s and switched back to API’s using HTTP GET•Ted Neward refers to this movement as “RESTafarians”, due to their anti-SOAP rants which had the passion of a cult, and which were possibly motivated by a competitive spirit with Microsoft (which had strongly supported SOAP)•They touted early interoperability problems as a show-stopperJan 14, 2019 rpc_quest.ppt 12The balanced view•XML-RPC and SOAP web services are prone to inefficiency•due to the verboseness of XML as compared with more concise wire formats•XML-RPC and SOAP web services are capable of being automated (“easy” to use) and platform independent•This has true value at times, especially for quick prototyping•Add-ons to the web services standards have now made it possible to send binary files in the data (multimedia), to authenticate users, and for transaction processing (multiple actions with roll-back if any fail)Jan 14, 2019 rpc_quest.ppt 13Jan 14, 2019
View Full Document