198 Cloud Computing
dissertation of Roy Fielding,
3
one of the principal authors of the Hypertext
Transfer Protocol (HTTP) specification.
REST refers to a collection of network architecture principles which
outline how resources are defined and addressed. The term is often used in a
looser sense to describe any simple interface which transmits domain-spe-
cific data over HTTP without an additional messaging layer such as SOAP
or session tracking via HTTP cookies. These two meanings can conflict as
well as overlap. It is possible to design a software system in accordance with
Fielding’s REST architectural style without using HTTP and without inter-
acting with the World Wide Web.
4
It is also possible to design simple
XML+HTTP interfaces which do not conform to REST principles, but
instead follow a model of remote procedure call. Systems which follow
Fielding’s REST principles are often referred to as “RESTful.”
Proponents of REST argue that the web’s scalability and growth are a
direct result of a few key design principles. Application state and functional-
ity are abstracted into resources. Every resource is uniquely addressable using
a universal syntax for use in hypermedia links, and all resources share a uni-
form interface for the transfer of state between client and resource. This
transfer state consists of a constrained set of well-defined operations and a
constrained set of content types, optionally supporting code on demand.
State transfer uses a protocol which is client-server based, stateless and cache-
able, and layered. Fielding describes REST’s effect on scalability thus:
REST’s client-server separation of concerns simplifies component
implementation, reduces the complexity of connector semantics,
improves the effectiveness of performance tuning, and increases the
scalability of pure server components. Layered system constraints
allow intermediaries—proxies, gateways, and firewalls—to be intro-
duced at various points in the communication without changing
the interfaces between components, thus allowing them to assist in
communication translation or improve performance via large-scale,
shared caching. REST enables intermediate processing by constrain-
ing messages to be self-descriptive: interaction is stateless between
requests, standard methods and media types are used to indicate
3. Roy T.Fielding, “Architectural Styles and the Design of Network-Based Software Architec-
tures,” dissertation, University of California, Irvine, 2000, http://www.ics.uci.edu/~fielding/
pubs/dissertation/rest_arch_style.htm.
4. Ibid.
Chap7.fm Page 198 Friday, May 22, 2009 11:27 AM
Standards for Messaging 199
semantics and exchange information, and responses explicitly indi-
cate cacheability.
5
An important concept in REST is the existence of resources, each of
which is referenced with a global identifier (e.g., a URI in HTTP). In order
to manipulate these resources, components of the network (user agents and
origin servers) communicate via a standardized interface (e.g., HTTP) and
exchange representations of these resources (the actual documents convey-
ing the information). For example, a resource which is a circle may accept
and return a representation which specifies a center point and radius, for-
matted in SVG (Scalable Vector Graphics), but may also accept and return a
representation which specifies any three distinct points along the curve as a
comma-separated list.
Any number of connectors (clients, servers, caches, tunnels, etc.) can
mediate the request, but each does so without “seeing past” its own request
(referred to as “layering,” another constraint of REST and a common prin-
ciple in many other parts of information and networking architecture).
Thus an application can interact with a resource by knowing two things: the
identifier of the resource, and the action required—it does not need to
know whether there are caches, proxies, gateways, firewalls, tunnels, or any-
thing else between it and the server actually holding the information. The
application does, however, need to understand the format of the informa-
tion (representation) returned, which is typically an HTML, XML, or
JSON document of some kind, although it may be an image, plain text, or
any other content.
REST provides improved response time and reduced server load due
to its support for the caching of representations. REST improves server
scalability by reducing the need to maintain session state. This means that
different servers can be used to handle different requests in a session.
REST requires less client-side software to be written than other
approaches, because a single browser can access any application and any
resource. REST depends less on vendor software and mechanisms which
layer additional messaging frameworks on top of HTTP. It provides
equivalent functionality when compared to alternative approaches to
communication, and it does not require a separate resource discovery
mechanism, because of the use of hyperlinks in representations. REST
5. Ibid.
Chap7.fm Page 199 Friday, May 22, 2009 11:27 AM
200 Cloud Computing
also provides better long-term compatibility because of the capability of
document types such as HTML to evolve without breaking backwards or
forwards compatibility and the ability of resources to add support for new
content types as they are defined without dropping or reducing support
for older content types.
One benefit that should be obvious with regard to web-based applica-
tions is that a RESTful implementation allows a user to bookmark specific
“queries” (or requests) and allows those to be conveyed to others across
email, instant messages, or to be injected into wikis, etc. Thus this “repre-
sentation” of a path or entry point into an application state becomes highly
portable. A RESTFul web service is a simple web service implemented using
HTTP and the principles of REST. Such a web service can be thought of as
a collection of resources comprising three aspects:
1. The URI for the web service
2. The MIME type of the data supported by the web service (often
JSON, XML, or YAML, but can be anything)
3. The set of operations supported by the web service using HTTP
methods, including but not limited to POST, GET, PUT, and
DELETE
Members of the collection are addressed by ID using URIs of the form
<baseURI>/<ID>. The ID can be any unique identifier. For example, a
RESTFul web service representing a collection of cars for sale might have
the URI:
http://example.com/resources/cars
If the service uses the car registration number as the ID, then a particu-
lar car might be present in the collection as
http://example.com/resources/cars/yxz123
SOAP
SOAP, originally defined as Simple Object Access Protocol, is a protocol
specification for exchanging structured information in the implementation
Chap7.fm Page 200 Friday, May 22, 2009 11:27 AM
Standards for Messaging 201
of Web Services in computer networks. It relies on XML as its message for-
mat and usually relies on other application-layer protocols, most notably
Remote Procedure Call (RPC) and HTTP for message negotiation and
transmission. SOAP can form the foundation layer of a web services proto-
col stack, providing a basic messaging framework on which web services can
be built.
As a simple example of how SOAP procedures can be used, a SOAP
message can be sent to a web service-enabled web site—for example, a
house price database—with the parameters needed for a search. The site
returns an XML-formatted document with the resulting data (prices, loca-
tion, features, etc). Because the data is returned in a standardized machine-
parseable format, it may be integrated directly into a third-party site.
The SOAP architecture consists of several layers of specifications for
message format, message exchange patterns (MEPs), underlying transport
protocol bindings, message processing models, and protocol extensibility.
SOAP is the successor of XML-RPC. SOAP makes use of an Internet appli-
cation-layer protocol as a transport protocol. Critics have argued that this is
an abuse of such protocols, as it is not their intended purpose and therefore
not a role they fulfill well. Proponents of SOAP have drawn analogies to
successful uses of protocols at various levels for tunneling other protocols.
Both SMTP and HTTP are valid application-layer protocols used as
transport for SOAP, but HTTP has gained wider acceptance because it
works well with today’s Internet infrastructure; specifically, HTTP works
well with network firewalls. SOAP may also be used over HTTPS (which is
the same protocol as HTTP at the application level, but uses an encrypted
transport protocol underneath) with either simple or mutual authentica-
tion; this is the advocated WS-I method to provide web service security as
stated in the WS-I Basic Profile 1.1. This is a major advantage over other
distributed protocols such as GIOP/IIOP or DCOM, which are normally
filtered by firewalls. XML was chosen as the standard message format
because of its widespread use by major corporations and open source devel-
opment efforts. Additionally, a wide variety of freely available tools signifi-
cantly eases the transition to a SOAP-based implementation.
Advantages of using SOAP over HTTP are that SOAP allows for easier
communication through proxies and firewalls than previous remote execu-
tion technology. SOAP is versatile enough to allow for the use of different
transport protocols. The standard stacks use HTTP as a transport protocol,
Chap7.fm Page 201 Friday, May 22, 2009 11:27 AM
202 Cloud Computing
but other protocols are also usable (e.g., SMTP). SOAP is platform-inde-
pendent, language-independent, and it is simple and extensible.
Because of the verbose XML format, SOAP can be considerably slower
than competing middleware technologies such as CORBA (Common
Object Request Broker Architecture). This may not be an issue when only
small messages are sent. To improve performance for the special case of
XML with embedded binary objects, Message Transmission Optimization
Mechanism was introduced. When relying on HTTP as a transport proto-
col and not using WS-Addressing or an ESB, the roles of the interacting
parties are fixed. Only one party (the client) can use the services of the
other. Developers must use polling instead of notification in these com-
mon cases.
Most uses of HTTP as a transport protocol are made in ignorance of
how the operation is accomplished. As a result, there is no way to know
whether the method used is appropriate to the operation. The REST archi-
tecture has become a web service alternative that makes appropriate use of
HTTP’s defined methods.
7.5.5 Communications (HTTP, SIMPLE, and XMPP)
HTTP is a request/response communications standard based on a client/
server model. A client is the end user, the server is the web site. The client
making a HTTP request via a web browser or other tool sends the request
to the server. The responding server is called the origin server. HTTP is not
constrained to use TCP/IP and its supporting layers, although this is its
most popular application on the Internet. SIMPLE, the Session Initiation
Protocol for Instant Messaging and Presence Leveraging Extensions, is an
instant messaging (IM) and presence protocol suite based on Session Initia-
tion Protocol, and it is managed by the IETF. Like XMPP, SIMPLE is an
open standard. Extensible Messaging and Presence Protocol (XMPP) is also
an open, XML-based protocol originally aimed at near-real-time, extensible
instant messaging and presence information (e.g., buddy lists) but now
expanded into the broader realm of message-oriented middleware. All of
these protocols are discussed in detail in the following paragraphs.
Hypertext Transfer Protocol (HTTP)
HTTP is an application-level protocol for distributed, collaborative,
hypermedia information systems. Its use for retrieving linked resources led
to the establishment of the World Wide Web. HTTP development was
Chap7.fm Page 202 Friday, May 22, 2009 11:27 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.