2. Topics
1. Introduction
2. Web services
3. Service descriptions and IDL for web services
4. A directory service for use with web services
5. XML security
6. Coordination of web services
7. Applications of web services
2
3. Introduction
• Web services provide an infrastructure for maintaining a richer and more
• structured form of interoperability between clients and servers.
• They provide a basis whereby a client program in one organization may
interact with a server in another organization without human supervision.
• In particular, web services allow complex applications to be developed by
providing services that integrate several other services.
• Due to the generality of their interactions, web services cannot be
accessed directly by browsers.
• The provision of web services as an addition to web servers is based on
the ability to use an HTTP request to cause the execution of a program.
• Recall that when a URL in an HTTP request refers to an executable
program, for example, a search, the result is produced by that program
and returned.
• In a similar way, web services are an extension of the Web and can be
provided by web servers. However, their servers need not be web
servers.
• The terms ‘web server’ and ‘web services’ should not be confused: a web
server provides a basic HTTP service, whereas a web service provides a
3
4. Introduction
• Recall that when a URL in an HTTP request refers to an executable
program, for example, a search, the result is produced by that program
and returned.
• In a similar way, web services are an extension of the Web and can be
provided by web servers. However, their servers need not be web servers.
• The terms ‘web server’ and ‘web services’ should not be confused: a web
server provides a basic HTTP service, whereas a web service provides a
service based on the operations defined in its interface.
• External data representation and marshalling of messages exchanged
between clients and web services is done in XML.
• The SOAP protocol (Section 9.2.1) specifies the rules for using XML to
package messages, for example to support a request-reply protocol.
• SOAP is used to encapsulate these messages and transmit them over
HTTP or another protocol, for example, TCP or SMTP.
• A web service deploys service descriptions to specify the interface and
other aspects of the service for the benefit of potential clients.
4
5. Web services
• A web service interface generally consists of a collection of
operations that can be used by a client over the Internet.
• The operations in a web service may be provided by a
variety of different resources, for example, programs, objects
or databases.
• A web service may be managed by a web server along with
web pages; or it may be a totally separate service.
• The key characteristic of most web services is that they can
process XML-formatted SOAP messages (see Section
9.2.1). An alternative is the REST approach which is outlined
in the box on page 386.
• Each web service uses its own service description to deal
with the service-specific characteristics of the messages it
receives.
5
6. Web services
• Combination of web services • Providing an interface for a
web service allows its operations to be combined with those
of other services to provide new functionality.
• Communication patterns • In general, web services either
use a synchronous request-reply pattern of communication
with their clients or communicate by means of asynchronous
messages. The latter style of communication may be used
even when requests require replies, in which case the client
sends a request and then later receives the reply
asynchronously. An event-style pattern can also be used: for
example, clients of a directory service may register for
events of interest and will be notified whenever certain
events (such as the arrival or departure of a service) occur.
6
7. Web services
• Loose coupling • In the context of web services, loose
coupling refers to minimizing the dependencies between
services in order to have a flexible underlying architecture
(reducing the risk that a change in one service will have a
knock-on effect on other services).
• Representation of messages • Both SOAP and the data it
carries are represented in XML. Textual representations take
up more space than binary ones and the parsing that they
require takes more time to process. In document-style
interactions speed is not an issue, but it is important in
request-reply interactions. However, it is argued that there is
an advantage in a human-readable format that allows for the
easy construction of simple messages and for debugging of
more complex ones.
7
8. Web services
Service references • In general, each web service has a URI, which
clients use to refer to it. The URL is the most frequently used form
of URI. Because a URL contains the domain name of a computer,
the service to which it refers will always be accessed at that
computer. However, the access point of a web service with a URN
can depend on context and can change from time to time – its
current URL can be obtained from a URN lookup service. This
service reference is known as an endpoint in web services.
Activation of services • A web service will be accessed via the
computer whose domain name is included in its current URL. That
computer may run the web service itself or it may run it on another
server computer. For example, a service with tens of thousands of
clients may need to be deployed on hundreds of computers. A web
service may run continuously, or it may be activated on demand.
The URL is a persistent reference, meaning that it will continue to
refer to the service for as long as the server the URL points to
exists.
8
9. Web services
Transparency • A major task of many middleware platforms is
to protect the programmer from the details of data
representation and marshalling; another is to make remote
invocations look like local ones. None of these things are
provided as a part of an infrastructure or middleware platform
for web services. At the simplest level, clients and servers
may read and write their messages directly in SOAP, using
XML. But for convenience, the details of SOAP and XML are
generally hidden by a local API in a programming language
such as Java, Perl, Python or C++. In this case, the service
description may be used as a basis for automatically
generating the necessary marshalling and unmarshalling
procedures.
9
10. SOAP (Simple Object Access Protocol)
• SOAP is designed to enable both client-server and asynchronous
interaction over the Internet. It defines a scheme for using XML to
represent the contents of request and reply messages (see Figure
5.4) as well as a scheme for the communication of documents.
Originally SOAP was based only on HTTP, but the current version
is designed to use a variety of transport protocols including SMTP,
TCP or UDP.
• The SOAP specification states:
• how XML is to be used to represent the contents of individual
messages;
• how a pair of single messages can be combined to produce a
request-reply pattern;
• the rules as to how the recipients of messages should process the
XML elements that they contain;
• how HTTP and SMTP should be used to communicate SOAP
messages. It is expected that future versions of the specification
will define how to use other transport protocols, for example, TCP.
10
11. SOAP (Simple Object Access Protocol)
• To support client-server communication, SOAP specifies how
to use the HTTP POST method for the request message and
its response for the reply message. The combined use of XML
and HTTP provides a standard protocol for client-server
communication over the Internet.
• It is intended that a SOAP message can be passed via
intermediaries on the way o the computer that manages the
resource to be accessed and that higher-level middleware
services such as transactions or security may use these
intermediaries to perform processing.
• SOAP messages • A SOAP message is carried in an
‘envelope’. Inside the envelope there is an optional header
and a body, as shown in Figure 9.3. Message headers can be
• used for establishing the necessary context for a service or
for keeping a log or audit of operations. An intermediary may
interpret and act on the information in the message 11
12. SOAP (Simple Object Access Protocol)
• SOAP messages • A SOAP message is carried in
an ‘envelope’. Inside the envelope there is an
optional header and a body, as shown in Figure 9.3.
Message headers can be used for establishing the
necessary context for a service or for keeping a log
or audit of operations. An intermediary may interpret
and act on the information in the message headers,
for example by adding, altering or removing
information. The message body carries an XML
document for a particular web service. The XML
elements envelope, header and body, together with
other attributes and elements of SOAP messages,
are defined as a schema in the SOAP XML
namespace. 12
13. SOAP (Simple Object Access Protocol)
• A SOAP message may be used either to convey a
document or to support client-server communication:
• A document to be communicated is placed directly
inside the body element together with a reference to
an XML schema containing the service description –
which defines the names and types used in the
document. This sort of SOAP message may be sent
either synchronously or asynchronously.
• For client-server communication, the body element
contains either a Request or a Reply. These two
cases are illustrated in Figure 9.4 and Figure 9.5.
13
14. SOAP (Simple Object Access Protocol)
SOAP headers • Message headers are intended to be used by
intermediaries to add to the service that deals with the message
carried in the corresponding body. However, two aspects of this
usage are left unclear in the SOAP specification:
1. How the headers will be used by any particular higher
middleware service. For example, a header might contain:
– a transaction identifier for use with a transaction service;
– a message identifier for relating messages to one another, for
example, for implementing reliable delivery;
– a username, a digital signature or a public key.
2. How the messages will be routed via a set of intermediaries to
the ultimate recipient. For example, a message transported by
HTTP could be routed via a chain of proxy servers, some of
which might assume a SOAP role.
14
15. SOAP (Simple Object Access Protocol)
• Transport of SOAP messages • A transport protocol is required to send
a SOAP message to its destination. SOAP messages are independent of
the type of transport used – their envelopes contain no reference to the
destination address. HTTP (or whatever protocol is used to transport a
SOAP message) is left to specify the destination address. Figure 9.6
illustrates how the HTTP POST method is used to transmit a SOAP
message. The HTTP headers and body are used as follows:
• The HTTP headers specify the endpoint address (the URI of the ultimate
receiver) and the action to be carried out. The Action header is intended
to optimize dispatching by revealing the name of the operation without the
need to analyze the SOAP message in the body of the HTTP message.
• The HTTP body carries the SOAP message.
15
26. 9.3 Service descriptions and IDL for web services
• IDL (Interface Definition Language)
• WSDL(Web Services Description Language)
• Interface definitions are needed to allow clients to communicate with
services. For web services, interface definitions are provided as part of a
more general service description, which specifies two other additional
characteristics – how the messages are to be communicated (for
example, by SOAP over HTTP) and the URI of the service. To cater for
use in a multi-language environment, service descriptions are written in
XML.
• A service description forms the basis of an agreement between a client
and a server as to the service on offer. It assembles all of the facts
concerning the service that are relevant to its clients. Service descriptions
are generally used to generate client stubs that automatically implement
the correct behaviour for the client.
• The IDL-like component of a service description is more flexible than
other IDLs, in that a service may be specified either in terms of the types
of messages that it will send and receive or in terms of the operations it
supports, to allow for both document exchange and request-reply-style
interactions.
26
27. 9.3 Service descriptions and IDL for web services
• Messages or operations • In web services, all that the client and the
server need is to have a common idea about the messages to be
exchanged. For a service based on the exchange of a small number of
different types of document, WSDL just describes the types of the
different messages to be exchanged. When a client sends one of these
• messages to a web service, the latter decides what operation to perform
and what type of message to send back to the client on the basis of the
message type received. In our Java example, two messages will be
defined for each of the operations in the interface – one for the request
and one for the reply. For example, Figure 9.11 shows the request
• and reply messages for the newShape operation, which has a single
input argument of type GraphicalObject and a single output argument of
type int. For services that support several different operations, it is more
effective to specify the messages exchanged as requests for operations
with arguments and their corresponding replies, allowing the service to
dispatch each request to the appropriate operation. However, in WSDL
an operation is a construct for relating request and reply messages, in
contrast to the definition of an operation in a service interface.
27
30. 9.3 Service descriptions and IDL for web services
• Interface • The collection of operations belonging to a web service are
grouped together in an XML element named interface (sometimes called
portType). Each operation must specify the message exchange pattern
between client and server. The available options include those shown in
Figure 9.12Figure 9.12 Message exchange patterns for WSDL operations
Name Messages sent byClient Server Delivery Fault message In-Out
Request Reply May replace Reply In-Only Request No fault message
Robust In-Only Request Guaranteed May be sent Out-In Reply Request
May replace Reply Out-Only Request No fault message Robust Out-Only
Request Guaranteed May send fault . The first one, In-Out, is the
commonly used request-reply form of client-server communication. In this
pattern, the reply message may be replaced with a fault message. In-Only
is for one-way messages with maybe semantics and Out-Only is for
oneway messages from server to client; fault messages cannot be sent
with either. Robust In-Only and Robust Out-Only are the corresponding
messages with guaranteed delivery; fault messages may be exchanged.
Out-In is a request-reply interaction initiated by the server. WSDL 2.0 is
also extensible in that organizations can introduce their own message
exchange patterns if the predefined ones prove to be inadequate. 30
33. 9.3 Service descriptions and IDL for web services
• Concrete part • The remaining (concrete) part of a WSDL document
consists of the binding (the choice of protocols) and the service (the
choice of endpoint or server address). The two are related, since the form
of address depends on the type of protocol in use. Binding: The binding
section in a WSDL document says which message formats and form of
external data representation are to be used. For example, web services
frequently use SOAP, HTTP and MIME. Bindings may be associated with
particular operations or interfaces, or they may be left free for use by a
variety of different web services. Figure 9.14 shows an example of a
binding enclosing a soap:binding that specifies the URL of a particular
protocol for transmitting SOAP envelopes: the HTTP binding for SOAP.
Optional attributes of this element may also specify the following:
• the message exchange pattern, which may be either rpc (request-reply)
or document exchange – the default value is document;
• the XML schema for the message formats – the default is the SOAP
envelope;
• the XML schema for the external data representation – the default is the
SOAP encoding of XML.
33
34. 9.3 Service descriptions and IDL for web services
• Service: Each service element in a WSDL document specifies
the name of the service and one or more endpoints (or ports)
where an instance of the service may be contacted.
• Each of the endpoint elements refers to the name of the
binding in use and, in the case of a SOAP binding, uses a
soap:address element to specify the URI of the service
location.
34
35. 9.3 Service descriptions and IDL for web services
• Documentation • Both human- and machine-readable
information may be inserted in a documentation element at
most points within a WSDL document. This information may
be removed before WSDL is used for automatic processing,
for example, by stub compilers.
• WSDL use • Complete WSDL documents can be accessed
via their URIs by clients and servers, either directly or
indirectly via a directory service such as UDDI. Tools are
available for generating WSDL definitions from information
provided via a graphical user interface, removing the need for
users to be involved in the complex details and structure of
WSDL. For example, the Web Services Description Language
for Java Toolkit (WSDL4J) allows the creation, representation
and manipulation of WSDL documents describing services
[wsdl4j.sourceforge.org]. WSDL definitions can also be
generated from interface definitions written in other
languages, such as Java JAX-RPC, discussed in Section
35
37. 9.4 A directory service for use with web services
• Any organization that plans to base its applications on web
services will find it more convenient to use a directory service
to make these services available to clients. This is the
purpose of the Universal Description, Discovery and
Integration service (UDDI) [Bellwood et al. 2003], which
provides both a name service and a directory service (see
Section 13.3). That is, WSDL service descriptions may be
looked up by name (a white pages service) or by attribute (a
yellow pages service). They may also be accessed directly
via their URLs, which is convenient for developers who are
designing client programs that use the service.
• Clients may use the yellow pages approach to look up a
particular category of service, such as travel agent or
bookseller, or they may use the white pages approach to look
up a service with reference to the organization that provides
it. 37
38. 9.4 A directory service for use with web services
• Data structures • The data structures supporting UDDI are
designed to allow all the above styles of access and can
incorporate any amount of human-readable information. The data is
organized in terms of the four structures shown in Figure 9.15,
each of which can be accessed individually by means of an
identifier called a key (apart from tModel, which can be accessed
by a URL):
• businessEntity describes the organization that provides these web
services, giving its name, address and activities, etc.;
• businessServices stores information about a set of instances of a
web service, such as its name and a description of its purpose (for
example, travel agent or bookseller);
• bindingTemplate holds the address of a web service instance and
references to service descriptions;
• tModel holds service descriptions, usually WSDL documents,
stored outside the database and accessed by means of URLs. 38
39. 9.4 A directory service for use with web services
• Lookup • UDDI provides an API for looking up services based on two
sets of query operations:
• The get_xxx set of operations includes get_BusinessDetail,
get_ServiceDetail, get_bindingDetail and get_tModelDetail; they retrieve
an entity corresponding to a given key.
• The find_xxx set of operations includes find_business, find_service,
find_binding and find_tModel; they retrieve the set of entities that matches
a particular set of search criteria, providing a summary of names,
descriptions, keys and URLs.
• Thus clients in possession of a particular key may use a get_xxx operation
to retrieve the corresponding entity directly, and other clients may use
browsing to assist with searches, starting with a large set of results and
gradually narrowing it down. For example, they may start by using the
find_business operation in order to get a list containing a summary of
information on matching providers. From this summary, the user may use
the find_service operation to narrow the search by matching the sort of
service required. In both cases, they will find the key of a suitable
bindingTemplate and thereby find the URL for retrieving the WSDL
document for a suitable service.
39
40. 9.4 A directory service for use with web services
Publication • UDDI provides an interface for publishing and
updating information about web services. The first time that a
data structure (see Figure 9.15) is published at a UDDI
server, it is given a key in the form of a URI – for example,
uddi:cdk5.net:213 – and that server becomes its owner.
Registries • The UDDI service is based on replicated data
stored in registries. A UDDI registry consists of one or more
UDDI servers, each of which has a copy of the same set of
data. The data is replicated between the members of a
registry. Each of them may respond to queries and publish
information. Changes to a data structure must be submitted to
its owner – that is, the server at which it was first published. It
is possible for an owner to pass on the ownership to another
UDDI server in the same registry.
40
41. 9.5 XML security
• XML security consists of a set of related W3C designs for signing, key
management and encryption. It is intended for use in cooperative work
over the Internet involving documents whose contents may need to be
authenticated or encrypted.
• Typically the documents are created, exchanged, stored and then
exchanged again, possibly after being modified by a series of different
users.
• As an example of a context in which XML security would be useful,
consider a document containing a patient’s medical records. Different
parts of this document are used at the local doctor’s surgery and at the
various special clinics and hospitals visited by the patient. It will be
updated by doctors, nurses and consultants making notes on the
patient’s condition and treatment, by administrators making
appointments and by pharmacists providing medicine. Different parts of
the document will be viewable by the different roles mentioned above,
and possibly the patient as well. It is essential that certain parts of the
document, for example, recommendations as to treatment, can be
attributed to the person that made them and can be guaranteed not to
have been altered. These needs cannot be met by TLS (previously 41
42. 9.5 XML security
These needs cannot be met by TLS (previously known as SSL and described
in Section 11.6.3), which is used to create a secure channel for the
communication of information. It allows the processes at the two ends of
the channel to negotiate as to the need for authentication or encryption
and the keys and algorithms to be used, both when a channel is set up
and during its lifetime. For example, data about a financial transaction
might be signed and sent in the clear until sensitive information such as
credit card details are to be given, at which point encryption will be
applied.
To allow for the new type of usage outlined above, the security must be
specified within the document itself and applied to the document rather
than as a property of the channel that will convey it from one user to
another.
This is possible in XML or other structured document formats, in which
metadata can be used. XML tags can be used to define the properties of
the data in the document. In particular, XML security depends on new tags
that can be used to indicate the beginning and end of sections of
encrypted or signed data and of signatures. Once the necessary security
has been applied within a document, it may be sent to a variety of different
users, even by means of multicast. 42
43. 9.5 XML security
• Basic requirements • XML security should provide at least the
same level of protection as TLS. That is:
• To be able to encrypt either an entire document or just some
selected parts of it.
• To be able to sign either an entire document or just some selected
parts of it.
• Additional basic requirements • Further requirements arise from
the need to store documents, possibly to modify them and then to
send them on to a variety of different recipients:
• To add to a document that is already signed and to sign the result:
• To authorize different users to view different parts of a document.
• To add to a document that already contains encrypted sections
and to encrypt part of.
• the new version, possibly including some of the already encrypted
sections.
43
44. 9.5 XML security
• Requirements concerning algorithms • XML secure documents
are signed and/or en-crypted well in advance of any consideration
as to who will be accessing them. If theoriginator is no longer
involved, it is not possible to negotiate the protocols and whetherto
use authentication or encryption. Therefore:
• The standard should specify a suite of algorithms to be provided in
any implementation of XML security: At least one encryption and
one signature algorithm should be mandatory to enable the widest
possible interoperability. Other optional algorithms should be
provided for use within smaller groups.
• The algorithms used for encryption and authentication of a
particular document must be selected from that suite and the
names of the algorithms in use must be referenced within the XML
document itself: If the places where the document will be used
cannot be predicted, then one of the required protocols should be
used.
44
45. 9.5 XML security
• Requirements for finding keys • When a document is
created and each time that it is updated, appropriate keys
must be chosen, without any negotiation with those parties
that may access the document in the future. This leads to the
following requirements:
• To help the users of secure documents with finding the
necessary keys.
• To make it possible for cooperating users to help one another
with keys. Provided that the KeyInfo element is not
cryptographically bound to the signature itself, information
may be added without breaking the digital signature.
45
46. 9.5 XML security
• The KeyInfo element • XML security specifies a KeyInfo
element for indicating the key to be used to validate a
signature or to decrypt some data. It may contain, for
example, certificates, the names of keys or key agreement
algorithms. Its use is optional: the signer may not want to
reveal any key information to all of the parties that access
the document, and in some cases the application using XML
security may already have access to the keys in use.
• Canonical XML • Some applications may make changes
that have no effect on the actual information content of an
XML document. This arises because there are a variety of
different ways of representing what is logically the same XML
document. For example, attributes may be in different orders
and differing character encodings may be used, yet the
information content is equivalent.
46
47. 9.5 XML security
• Use of digital signatures in XML • The specification for digital
signatures in XML [www.w3.org XII] is a W3C recommendation
that defines new XML element types to hold signatures, the
names of algorithms, keys and references to signed information.
The names provided in this specification are defined in the XML
Signature schema which includes the elements Signature,
SignatureValue, SignedInfo and KeyInfo.
• Key management service • The specification of the XML key
management service [www.w3.org XIII] contains protocols for
distributing and registering public keys for use in XML
signatures.
• XML encryption • The standard for encryption in XML is
defined in a W3C recommendation that specifies both the way to
represent encrypted data in XML and the process for encrypting
and decrypting it [www.w3.org XIV]. It introduces an
EncryptedData element for enclosing portions of encrypted data.
47
50. 9.6 Coordination of web services
• The SOAP infrastructure supports single request-response
interactions between clients and web services. However,
many useful applications involve several requests that need
to be done in a particular order.
• For example, when booking a flight, the price and availability
information is collected before the reservations are made. When
a user interacts with web pages by means of a browser, for
example, to book a flight or to make a bid in an auction, the
interface provided by the browser (which is based on the
information provided by the server) controls the sequence in
which the operations are performed.
• However, if it is a web service that is making reservations, like
the travel agent service shown in Figure 9.2, that web service
needs to work from a description of the appropriate way to
proceed when interacting with other services are used for, e.g.,
car hire and hotel bookings as well as flight bookings. Figure
9.18 shows an example of such a description. 50
51. 9.6 Coordination of web services
• The W3C uses the term choreography to refer to a language
based on WSDL for defining coordination.
• For example, the language might specify constraints on the
order and the conditions in which messages are exchanged
by participants. A choreography is intended to provide a
global description of a set of interactions, showing the
behaviour of each member of a set of participants, with a view
to enhancing interoperability.
51
52. 9.6 Coordination of web services
• Requirements for choreography • Choreography is
intended to support interactions between web services which
are generally managed by different companies and
organizations. A collaboration involving multiple web services
and clients should be described in terms of the sets of
observable interactions between pairs of them. Such a
description might be seen as a contract between the
participants, and could be used for the following purposes:
• • to generate code outlines for a new service that wants to
participate;
• • as a basis for generating test messages for a new service;
• • to promote a common understanding of the collaboration;
• • to analyze the collaboration, for example to identify possible
deadlock situations.
52
53. 9.6 Coordination of web services
• The W3C working draft document [www.w3.org XV] suggests that a
• choreography language should include the following features:
• hierarchical and recursive composition of choreographies;
• the ability to add new instances of an existing service and new services;
• concurrent paths, alternative paths and the ability to repeat a section of a
• choreography;
• variable timeouts – for example, different periods for holding reservations;
• exceptions, for example, to deal with messages arriving out of sequence
and user actions such as cancellations;
• asynchronous interactions (callbacks);
• reference passing, for example, to allow a car hire company to consult a
bank for a credit check on behalf of a user;
• marking of the boundaries of the separate transactions that take place, for
example, to allow for recovery;
• the ability to include human-readable documentation
53
54. 9.7 Applications of web services
Web services are now one of the dominant paradigms for
programming distributed systems. In this section, we discuss
a number of the major areas where web services have been
employed extensively: in supporting service-oriented
architecture, the Grid and latterly, cloud computing.
54
55. 9.7.1 Service-oriented architecture
• Service-oriented architecture (SOA) is a set of design principles
whereby distributed systems are developed using sets of loosely
coupled services that can be dynamically discovered and then
communicate with each other or are coordinated through
choreography to provide enhanced services. Service-oriented
architecture is an abstract concept that can be implemented using
a variety of technologies including the distributed object or
component-based approaches discussed in Chapter 8. The
principal means of realizing service-oriented architecture, however,
is through the use of web services, largely due to the loose
coupling inherent in this approach (as discussed in Section 9.2).
• This style of architecture can be used within a business or
organization to offer a flexible software architecture and to achieve
interoperability between the various services. Its prime use,
however is in the broader Internet, offering a common view of
services making them globally accessible and amenable to
subsequent composition. 55
56. 9.7.2 The Grid
• The name ‘Grid’ is used to refer to middleware that is
designed to enable the sharing of resources such as files,
computers, software, data and sensors on a very large scale.
The resources are shared typically by groups of users in
different organizations who are collaborating on the solution
of problems requiring large numbers of computers to solve
them, either by the sharing of data or by the sharing of
computing power. These resources are necessarily supported
by heterogeneous computer hardware, operating systems,
programming languages and applications. Management is
needed to coordinate the use of resources to ensure that
clients get what they need and that services can afford to
supply it. In some cases, sophisticated security techniques
are required to ensure that the correct use is made of
resources in this type of environment.
56
57. 9.7.2 The Grid
• Grid middleware • The Open Grid Services
Architecture (OGSA) is a standard for Grid-based
applications [Foster et al. 2001, 2002]. It provides a
framework within which the above requirements can
be met, based on web services. Resources are
managed by application-specific Grid services.
57
58. 9.7.3 Cloud computing
• Cloud computing was introduced in Chapter 1 as a set of
Internet-based application, storage and computing services
sufficient to support most users’ needs, thus enabling them to
largely or totally dispense with local data storage and application
software.
• Cloud computing also promotes a view of everything as a
service, from physical or virtual infrastructure through to
software, often paid for on a per-usage basis rather than
purchased. The concept is therefore intrinsically linked to a new
business model for computing where cloud suppliers offer a
range of computational, data and other services to customers as
required for their daily use, for example offering sufficient
storage capacity across the Internet to act as an archival or
backup service.
• Amazon Web Services are a set of cloud services implemented
on the extensive physical infrastructure owned by Amazon.com.
58
