There is a huge number of different applications available in the web. In the following, we distinguish two separate types of web applications -- web sites and web services. Web sites are web-based applications that are designed for humans and browser-based access. By contrast, web services are web-based interfaces for machine-to-machine communication. Although this distinction is rather arbitrary, it will help us to identify different requirements and features.
Web sites have evolved from hyper-referenced, text-based research documents to highly interactive, social and collaborative applications for many different purposes. Web content has become increasingly dynamic and based on content provided by the users. Web technologies such as JS, AJAX, and HTML5 have introduced more interactive user interfaces and boosted this transition. Thanks to powerful APIs provided by modern browsers, web applications are already starting to replace traditional desktop applications and native mobile applications.
We will now introduce some popular types for web sites that are interesting in terms of scalability and concurrency.
Social networks are sites that transfer social interactions to the web. They often try to reflect real world social relations of its users (e.g. Facebook) or focus on specific topics (e.g. dopplr for travelling). Social network sites motivate their users to interact, for instance via instant messaging. Also, social networks heavily rely on user generated content and context-specific data, such as geo-tagged content. User content and actions are often published into activity streams providing a "real-time" feed of updates that can be watched live by other users.
These web applications allow a group of people to collaborate via the web. Traditional examples are wiki systems, where users can collectively edit versions of text documents. More recent collaborative applications incorporate soft real-time aspects. For example, Etherpad is a web-based word processor that supports multiple users working on the same document concurrently.
E-Commerce sites such as Amazon are traditional commercial sites in the web selling products online. Interestingly enough, many sites have adopted features known from social sites for business purposes. By commenting, rating and tagging products, users can participate on these sites beyond just buying items. User-generated content is then used to cluster product items and compute accurate recommendations. Thus, commercial sites face similar challenges to social sites to some extend.
Web services provide access to application services using HTTP. Thus, web services often resemble traditional mechanisms for distributed computing such as RPC or message passing, though based on web technologies.
Opposed to web sites, web services are not targeting direct (human) user access in a first place. Instead, web services enable machine-to-machine communication and provide application features via an interface and structured messages. Several web applications provide both, a web site and a web service interface (API). While the web site is used for browser-based access, the web service can be used for custom applications such as mobile client applications or scripted program-based service interactions.
XML-RPC has been one of the first attempts to transfer traditional RPC-based services to the web. It makes use of HTTP POST requests for dispatching procedure calls and an XML-based serialization format for call parameters and return values. The following listing provides an example taken from the original specification [Win99]:
POST /RPC2 HTTP/1.0 User-Agent: Frontier/5.1.2 (WinNT) Host: betty.userland.com Content-Type: text/xml Content-Length: 181 <?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall> HTTP/1.1 200 OK Connection: close Content-Length: 158 Content-Type: text/xml Date: Fri, 17 Jul 1998 19:55:08 GMT Server: UserLand Frontier/5.1.2-WinNT <?xml version="1.0"?> <methodResponse> <params> <param> <value><string>South Dakota</string></value> </param> </params> </methodResponse>
It is important to clarify that XML-RPC is using HTTP as a generic transport protocol for RPC calls. It does not take advantage of any HTTP features such as caching, status codes for error handling or header fields for negotiation.
The stack of SOAP [Gud07], WSDL [Liu07], UDDI [Cle04] and a myriad of additional extensions (WS-*) forms a more comprehensive approach for machine-to-machine communication, mostly based on web technologies. It is widely used and particularly popular in enterprise environments. As previously mentioned, SOAP is a successor of XML-RPC. It specifies the format, call semantics and exchange patterns of XML-encoded messages between parties. Various extension specifications, often labeled as WS-*, address additional features of SOAP-based web services such as security or orchestration. The WSDL is another important specification for this kind of web services. It provides XML-based, machine-readable service descriptions, comparable to interface definition languages of traditional RPC protocols. UDDI was originally a third component providing registry functions for web services, but it has almost entirely lost its significance in practice.
Although the SOAP/WSDL stack is generally known as web service stack, it dismisses parts of the original idea of the web. For instance, the stack uses HTTP as a pure communication protocol for exchanging messages, that can be replaced by other protocols. Similarly to XML-RPC, this web service stack does not use HTTP as an application-level protocol.
REST is an architectural style that embraces the fundamentals of the WWW. It has been introduced as part of the doctoral thesis of Roy T. Fielding [Fie00], who was also responsible for the HTTP specifications to some extent. Not surprisingly, the REST style takes full advantage of HTTP features. Fielding suggests a resource-oriented architecture that is defined by a set of constraints:
The broad interest in REST and its recent popularity is not the only reason it is listed here. The conceptual ideas behind REST are taken from HTTP and based on the lessons learned from the WWW. The ideas promote loose coupling, stateless communication, reusability and interoperability. Thus, they establish a great basis for scalability of architectures that are complying with the REST style.