- •Cloud Computing
- •Foreword
- •Preface
- •Introduction
- •Expected Audience
- •Book Overview
- •Part 1: Cloud Base
- •Part 2: Cloud Seeding
- •Part 3: Cloud Breaks
- •Part 4: Cloud Feedback
- •Contents
- •1.1 Introduction
- •1.1.1 Cloud Services and Enabling Technologies
- •1.2 Virtualization Technology
- •1.2.1 Virtual Machines
- •1.2.2 Virtualization Platforms
- •1.2.3 Virtual Infrastructure Management
- •1.2.4 Cloud Infrastructure Manager
- •1.3 The MapReduce System
- •1.3.1 Hadoop MapReduce Overview
- •1.4 Web Services
- •1.4.1 RPC (Remote Procedure Call)
- •1.4.2 SOA (Service-Oriented Architecture)
- •1.4.3 REST (Representative State Transfer)
- •1.4.4 Mashup
- •1.4.5 Web Services in Practice
- •1.5 Conclusions
- •References
- •2.1 Introduction
- •2.2 Background and Related Work
- •2.3 Taxonomy of Cloud Computing
- •2.3.1 Cloud Architecture
- •2.3.1.1 Services and Modes of Cloud Computing
- •Software-as-a-Service (SaaS)
- •Platform-as-a-Service (PaaS)
- •Hardware-as-a-Service (HaaS)
- •Infrastructure-as-a-Service (IaaS)
- •2.3.2 Virtualization Management
- •2.3.3 Core Services
- •2.3.3.1 Discovery and Replication
- •2.3.3.2 Load Balancing
- •2.3.3.3 Resource Management
- •2.3.4 Data Governance
- •2.3.4.1 Interoperability
- •2.3.4.2 Data Migration
- •2.3.5 Management Services
- •2.3.5.1 Deployment and Configuration
- •2.3.5.2 Monitoring and Reporting
- •2.3.5.3 Service-Level Agreements (SLAs) Management
- •2.3.5.4 Metering and Billing
- •2.3.5.5 Provisioning
- •2.3.6 Security
- •2.3.6.1 Encryption/Decryption
- •2.3.6.2 Privacy and Federated Identity
- •2.3.6.3 Authorization and Authentication
- •2.3.7 Fault Tolerance
- •2.4 Classification and Comparison between Cloud Computing Ecosystems
- •2.5 Findings
- •2.5.2 Cloud Computing PaaS and SaaS Provider
- •2.5.3 Open Source Based Cloud Computing Services
- •2.6 Comments on Issues and Opportunities
- •2.7 Conclusions
- •References
- •3.1 Introduction
- •3.2 Scientific Workflows and e-Science
- •3.2.1 Scientific Workflows
- •3.2.2 Scientific Workflow Management Systems
- •3.2.3 Important Aspects of In Silico Experiments
- •3.3 A Taxonomy for Cloud Computing
- •3.3.1 Business Model
- •3.3.2 Privacy
- •3.3.3 Pricing
- •3.3.4 Architecture
- •3.3.5 Technology Infrastructure
- •3.3.6 Access
- •3.3.7 Standards
- •3.3.8 Orientation
- •3.5 Taxonomies for Cloud Computing
- •3.6 Conclusions and Final Remarks
- •References
- •4.1 Introduction
- •4.2 Cloud and Grid: A Comparison
- •4.2.1 A Retrospective View
- •4.2.2 Comparison from the Viewpoint of System
- •4.2.3 Comparison from the Viewpoint of Users
- •4.2.4 A Summary
- •4.3 Examining Cloud Computing from the CSCW Perspective
- •4.3.1 CSCW Findings
- •4.3.2 The Anatomy of Cloud Computing
- •4.3.2.1 Security and Privacy
- •4.3.2.2 Data and/or Vendor Lock-In
- •4.3.2.3 Service Availability/Reliability
- •4.4 Conclusions
- •References
- •5.1 Overview – Cloud Standards – What and Why?
- •5.2 Deep Dive: Interoperability Standards
- •5.2.1 Purpose, Expectations and Challenges
- •5.2.2 Initiatives – Focus, Sponsors and Status
- •5.2.3 Market Adoption
- •5.2.4 Gaps/Areas of Improvement
- •5.3 Deep Dive: Security Standards
- •5.3.1 Purpose, Expectations and Challenges
- •5.3.2 Initiatives – Focus, Sponsors and Status
- •5.3.3 Market Adoption
- •5.3.4 Gaps/Areas of Improvement
- •5.4 Deep Dive: Portability Standards
- •5.4.1 Purpose, Expectations and Challenges
- •5.4.2 Initiatives – Focus, Sponsors and Status
- •5.4.3 Market Adoption
- •5.4.4 Gaps/Areas of Improvement
- •5.5.1 Purpose, Expectations and Challenges
- •5.5.2 Initiatives – Focus, Sponsors and Status
- •5.5.3 Market Adoption
- •5.5.4 Gaps/Areas of Improvement
- •5.6 Deep Dive: Other Key Standards
- •5.6.1 Initiatives – Focus, Sponsors and Status
- •5.7 Closing Notes
- •References
- •6.1 Introduction and Motivation
- •6.2 Cloud@Home Overview
- •6.2.1 Issues, Challenges, and Open Problems
- •6.2.2 Basic Architecture
- •6.2.2.1 Software Environment
- •6.2.2.2 Software Infrastructure
- •6.2.2.3 Software Kernel
- •6.2.2.4 Firmware/Hardware
- •6.2.3 Application Scenarios
- •6.3 Cloud@Home Core Structure
- •6.3.1 Management Subsystem
- •6.3.2 Resource Subsystem
- •6.4 Conclusions
- •References
- •7.1 Introduction
- •7.2 MapReduce
- •7.3 P2P-MapReduce
- •7.3.1 Architecture
- •7.3.2 Implementation
- •7.3.2.1 Basic Mechanisms
- •Resource Discovery
- •Network Maintenance
- •Job Submission and Failure Recovery
- •7.3.2.2 State Diagram and Software Modules
- •7.3.3 Evaluation
- •7.4 Conclusions
- •References
- •8.1 Introduction
- •8.2 The Cloud Evolution
- •8.3 Improved Network Support for Cloud Computing
- •8.3.1 Why the Internet is Not Enough?
- •8.3.2 Transparent Optical Networks for Cloud Applications: The Dedicated Bandwidth Paradigm
- •8.4 Architecture and Implementation Details
- •8.4.1 Traffic Management and Control Plane Facilities
- •8.4.2 Service Plane and Interfaces
- •8.4.2.1 Providing Network Services to Cloud-Computing Infrastructures
- •8.4.2.2 The Cloud Operating System–Network Interface
- •8.5.1 The Prototype Details
- •8.5.1.1 The Underlying Network Infrastructure
- •8.5.1.2 The Prototype Cloud Network Control Logic and its Services
- •8.5.2 Performance Evaluation and Results Discussion
- •8.6 Related Work
- •8.7 Conclusions
- •References
- •9.1 Introduction
- •9.2 Overview of YML
- •9.3 Design and Implementation of YML-PC
- •9.3.1 Concept Stack of Cloud Platform
- •9.3.2 Design of YML-PC
- •9.3.3 Core Design and Implementation of YML-PC
- •9.4 Primary Experiments on YML-PC
- •9.4.1 YML-PC Can Be Scaled Up Very Easily
- •9.4.2 Data Persistence in YML-PC
- •9.4.3 Schedule Mechanism in YML-PC
- •9.5 Conclusion and Future Work
- •References
- •10.1 Introduction
- •10.2 Related Work
- •10.2.1 General View of Cloud Computing frameworks
- •10.2.2 Cloud Computing Middleware
- •10.3 Deploying Applications in the Cloud
- •10.3.1 Benchmarking the Cloud
- •10.3.2 The ProActive GCM Deployment
- •10.3.3 Technical Solutions for Deployment over Heterogeneous Infrastructures
- •10.3.3.1 Virtual Private Network (VPN)
- •10.3.3.2 Amazon Virtual Private Cloud (VPC)
- •10.3.3.3 Message Forwarding and Tunneling
- •10.3.4 Conclusion and Motivation for Mixing
- •10.4 Moving HPC Applications from Grids to Clouds
- •10.4.1 HPC on Heterogeneous Multi-Domain Platforms
- •10.4.2 The Hierarchical SPMD Concept and Multi-level Partitioning of Numerical Meshes
- •10.4.3 The GCM/ProActive-Based Lightweight Framework
- •10.4.4 Performance Evaluation
- •10.5 Dynamic Mixing of Clusters, Grids, and Clouds
- •10.5.1 The ProActive Resource Manager
- •10.5.2 Cloud Bursting: Managing Spike Demand
- •10.5.3 Cloud Seeding: Dealing with Heterogeneous Hardware and Private Data
- •10.6 Conclusion
- •References
- •11.1 Introduction
- •11.2 Background
- •11.2.1 ASKALON
- •11.2.2 Cloud Computing
- •11.3 Resource Management Architecture
- •11.3.1 Cloud Management
- •11.3.2 Image Catalog
- •11.3.3 Security
- •11.4 Evaluation
- •11.5 Related Work
- •11.6 Conclusions and Future Work
- •References
- •12.1 Introduction
- •12.2 Layered Peer-to-Peer Cloud Provisioning Architecture
- •12.4.1 Distributed Hash Tables
- •12.4.2 Designing Complex Services over DHTs
- •12.5 Cloud Peer Software Fabric: Design and Implementation
- •12.5.1 Overlay Construction
- •12.5.2 Multidimensional Query Indexing
- •12.5.3 Multidimensional Query Routing
- •12.6 Experiments and Evaluation
- •12.6.1 Cloud Peer Details
- •12.6.3 Test Application
- •12.6.4 Deployment of Test Services on Amazon EC2 Platform
- •12.7 Results and Discussions
- •12.8 Conclusions and Path Forward
- •References
- •13.1 Introduction
- •13.2 High-Throughput Science with the Nimrod Tools
- •13.2.1 The Nimrod Tool Family
- •13.2.2 Nimrod and the Grid
- •13.2.3 Scheduling in Nimrod
- •13.3 Extensions to Support Amazon’s Elastic Compute Cloud
- •13.3.1 The Nimrod Architecture
- •13.3.2 The EC2 Actuator
- •13.3.3 Additions to the Schedulers
- •13.4.1 Introduction and Background
- •13.4.2 Computational Requirements
- •13.4.3 The Experiment
- •13.4.4 Computational and Economic Results
- •13.4.5 Scientific Results
- •13.5 Conclusions
- •References
- •14.1 Using the Cloud
- •14.1.1 Overview
- •14.1.2 Background
- •14.1.3 Requirements and Obligations
- •14.1.3.1 Regional Laws
- •14.1.3.2 Industry Regulations
- •14.2 Cloud Compliance
- •14.2.1 Information Security Organization
- •14.2.2 Data Classification
- •14.2.2.1 Classifying Data and Systems
- •14.2.2.2 Specific Type of Data of Concern
- •14.2.2.3 Labeling
- •14.2.3 Access Control and Connectivity
- •14.2.3.1 Authentication and Authorization
- •14.2.3.2 Accounting and Auditing
- •14.2.3.3 Encrypting Data in Motion
- •14.2.3.4 Encrypting Data at Rest
- •14.2.4 Risk Assessments
- •14.2.4.1 Threat and Risk Assessments
- •14.2.4.2 Business Impact Assessments
- •14.2.4.3 Privacy Impact Assessments
- •14.2.5 Due Diligence and Provider Contract Requirements
- •14.2.5.1 ISO Certification
- •14.2.5.2 SAS 70 Type II
- •14.2.5.3 PCI PA DSS or Service Provider
- •14.2.5.4 Portability and Interoperability
- •14.2.5.5 Right to Audit
- •14.2.5.6 Service Level Agreements
- •14.2.6 Other Considerations
- •14.2.6.1 Disaster Recovery/Business Continuity
- •14.2.6.2 Governance Structure
- •14.2.6.3 Incident Response Plan
- •14.3 Conclusion
- •Bibliography
- •15.1.1 Location of Cloud Data and Applicable Laws
- •15.1.2 Data Concerns Within a European Context
- •15.1.3 Government Data
- •15.1.4 Trust
- •15.1.5 Interoperability and Standardization in Cloud Computing
- •15.1.6 Open Grid Forum’s (OGF) Production Grid Interoperability Working Group (PGI-WG) Charter
- •15.1.7.1 What will OCCI Provide?
- •15.1.7.2 Cloud Data Management Interface (CDMI)
- •15.1.7.3 How it Works
- •15.1.8 SDOs and their Involvement with Clouds
- •15.1.10 A Microsoft Cloud Interoperability Scenario
- •15.1.11 Opportunities for Public Authorities
- •15.1.12 Future Market Drivers and Challenges
- •15.1.13 Priorities Moving Forward
- •15.2 Conclusions
- •References
- •16.1 Introduction
- •16.2 Cloud Computing (‘The Cloud’)
- •16.3 Understanding Risks to Cloud Computing
- •16.3.1 Privacy Issues
- •16.3.2 Data Ownership and Content Disclosure Issues
- •16.3.3 Data Confidentiality
- •16.3.4 Data Location
- •16.3.5 Control Issues
- •16.3.6 Regulatory and Legislative Compliance
- •16.3.7 Forensic Evidence Issues
- •16.3.8 Auditing Issues
- •16.3.9 Business Continuity and Disaster Recovery Issues
- •16.3.10 Trust Issues
- •16.3.11 Security Policy Issues
- •16.3.12 Emerging Threats to Cloud Computing
- •16.4 Cloud Security Relationship Framework
- •16.4.1 Security Requirements in the Clouds
- •16.5 Conclusion
- •References
- •17.1 Introduction
- •17.1.1 What Is Security?
- •17.2 ISO 27002 Gap Analyses
- •17.2.1 Asset Management
- •17.2.2 Communications and Operations Management
- •17.2.4 Information Security Incident Management
- •17.2.5 Compliance
- •17.3 Security Recommendations
- •17.4 Case Studies
- •17.4.1 Private Cloud: Fortune 100 Company
- •17.4.2 Public Cloud: Amazon.com
- •17.5 Summary and Conclusion
- •References
- •18.1 Introduction
- •18.2 Decoupling Policy from Applications
- •18.2.1 Overlap of Concerns Between the PEP and PDP
- •18.2.2 Patterns for Binding PEPs to Services
- •18.2.3 Agents
- •18.2.4 Intermediaries
- •18.3 PEP Deployment Patterns in the Cloud
- •18.3.1 Software-as-a-Service Deployment
- •18.3.2 Platform-as-a-Service Deployment
- •18.3.3 Infrastructure-as-a-Service Deployment
- •18.3.4 Alternative Approaches to IaaS Policy Enforcement
- •18.3.5 Basic Web Application Security
- •18.3.6 VPN-Based Solutions
- •18.4 Challenges to Deploying PEPs in the Cloud
- •18.4.1 Performance Challenges in the Cloud
- •18.4.2 Strategies for Fault Tolerance
- •18.4.3 Strategies for Scalability
- •18.4.4 Clustering
- •18.4.5 Acceleration Strategies
- •18.4.5.1 Accelerating Message Processing
- •18.4.5.2 Acceleration of Cryptographic Operations
- •18.4.6 Transport Content Coding
- •18.4.7 Security Challenges in the Cloud
- •18.4.9 Binding PEPs and Applications
- •18.4.9.1 Intermediary Isolation
- •18.4.9.2 The Protected Application Stack
- •18.4.10 Authentication and Authorization
- •18.4.11 Clock Synchronization
- •18.4.12 Management Challenges in the Cloud
- •18.4.13 Audit, Logging, and Metrics
- •18.4.14 Repositories
- •18.4.15 Provisioning and Distribution
- •18.4.16 Policy Synchronization and Views
- •18.5 Conclusion
- •References
- •19.1 Introduction and Background
- •19.2 A Media Service Cloud for Traditional Broadcasting
- •19.2.1 Gridcast the PRISM Cloud 0.12
- •19.3 An On-demand Digital Media Cloud
- •19.4 PRISM Cloud Implementation
- •19.4.1 Cloud Resources
- •19.4.2 Cloud Service Deployment and Management
- •19.5 The PRISM Deployment
- •19.6 Summary
- •19.7 Content Note
- •References
- •20.1 Cloud Computing Reference Model
- •20.2 Cloud Economics
- •20.2.1 Economic Context
- •20.2.2 Economic Benefits
- •20.2.3 Economic Costs
- •20.2.5 The Economics of Green Clouds
- •20.3 Quality of Experience in the Cloud
- •20.4 Monetization Models in the Cloud
- •20.5 Charging in the Cloud
- •20.5.1 Existing Models of Charging
- •20.5.1.1 On-Demand IaaS Instances
- •20.5.1.2 Reserved IaaS Instances
- •20.5.1.3 PaaS Charging
- •20.5.1.4 Cloud Vendor Pricing Model
- •20.5.1.5 Interprovider Charging
- •20.6 Taxation in the Cloud
- •References
- •21.1 Introduction
- •21.2 Background
- •21.3 Experiment
- •21.3.1 Target Application: Value at Risk
- •21.3.2 Target Systems
- •21.3.2.1 Condor
- •21.3.2.2 Amazon EC2
- •21.3.2.3 Eucalyptus
- •21.3.3 Results
- •21.3.4 Job Completion
- •21.3.5 Cost
- •21.4 Conclusions and Future Work
- •References
- •Index
1 Tools and Technologies for Building Clouds |
13 |
•The pairs are partitioned into groups for processing, and are sorted according to their key as they arrive for reduction. (In the example, the pairs are now grouped according to the key.)
•The key/value pairs are reduced, once for each unique key in the sorted list, to produce a combined result. (In this example, this will be the count of each word).
MapReduce has been applied widely in various fields including dataand computeintensive applications, machine learning, and multicore programming. Moreover, many implementations have been developed in different programming languages for various purposes.
The popular open source implementation of MapReduce, Hadoop [48], was developed primarily by Yahoo, where it processes hundreds of terabytes of data on at least 10,000 cores [49], and is now used by other companies, including Facebook, Amazon, Last.fm, and the New York Times [50]. Research groups from enterprises and academia are starting to study the MapReduce model as a better fit for cloud computing, and explore the possibilities of adapting it for more applications.
1.3.1 Hadoop MapReduce Overview
The Hadoop common [48], formerly called the Hadoop core, includes filesystem, RPC (remote procedure call), and serialization libraries, and provides the basic services for building a cloud computing environment with commodity hardware. The two main subprojects are the MapReduce framework and the Hadoop Distributed File System (HDFS).
The HDFS is a distributed file system designed to run on commodity hardware. HDFS is highly fault-tolerant and so can be deployed on low-cost hardware. HDFS provides high throughput access to application data and is suitable for applications that have large data sets. The Hadoop MapReduce framework is highly reliant on its shared file system, and it comes with plug-ins for HDFS, CloudStore [51], and the Amazon Simple Storage Service (S3).
The MapReduce framework consists of a single master JobTracker and one slave TaskTracker per cluster-node. The master is responsible for scheduling the jobs’ component tasks on the slaves (i.e., it queries the HDFS master Namenode about data block locations and assigns each task to the TaskTracker that is closest to where the data to be processed is physically stored), monitoring them, and re- executing any failed tasks. The slaves execute the tasks as directed by the master.
1.4 Web Services
To support cloud computing infrastructure efficiently, and to express business models easily, designers and developers need a group of web services technologies to construct a real, user-friendly, and content-rich set of applications on the top of
14 |
H. Jin et al. |
their clouds. This section introduces four fundamental tools and technologies, which can be employed to construct cloud applications viewed at the infrastructure, architecture, and presentational level. These technologies are: Remote Procedure Call (RPC), Service-Oriented Architecture (SOA), Representational State Transfer (REST), and Mashup.
1.4.1 RPC (Remote Procedure Call)
Reliable and stable communications among cloud resources are fundamental to the infrastructure, and thus are an important consideration. Remote Procedure Call (RPC) has proven to be an efficient mechanism for implementing the client-server model in a distributed computing environment. It was proposed initially by Sun Microsystems as a great advancement in comparison with sockets (e.g., the programmer is not concerned with the underlying communications, since they are embedded inside the RPC). In RPC, the client must know what features the server provides, which are indicated by a service definition, written in IDL (Interface Description Language). An RPC call is a synchronous operation that suspends the calling program until the results of the call are returned. When an RPC is compiled, a stub is included in the compiled code that represents the remote service. When the program runs, it calls the stub, which knows where the operation is and how to reach the service. The stub will send the message through the network to the server. The result of the procedure is returned to the client in the same way.
Many commercial products built over the RPC mechanism have been practically proven as efficient and convenient to construct enterprise applications.
In 2002, Microsoft released the .NET Remoting [52], which was incrementally evolved from DCOM and Active X, to support. NET applications intercommunicating in a loosely coupled environment. Similar to RPC stubs, .NET Remoting initializes the “Channel” objects to proxy the remote calls. To improve the transparency and convenience, the procedure of serialization and marshalling will be completed automatically by .NET runtime. Each .NET Remoting object is identified as a unique URL and safely accessed by clients remotely.
Extending from Java Remote Method Invocation (RMI) [53], Java community presents a complete specification J2EE [54] to standardize the communications among loosely coupled Java components. The enhancements include Enterprise Java Beans (EJB), connectors, servlets, and portlets. The complete J2EE structure of specifications helps designers to easily construct business logic and assists developers in clearly implementing them. Although .Net Remoting and J2EE have been widely adopted by the industry, RPC mechanism is not feasible to construct Cloud applications. One of the problems with RPC is that RPC implementations, as shown in Table 1.4, can be incompatible with each other. To use one of the possible implementations of RPC will result in a high dependence on the particular RPC.
1 Tools and Technologies for Building Clouds |
|
15 |
||||
Table 1.4 |
Web service toolkits comparisons |
|
|
|
||
|
|
|
|
|
|
|
|
Age |
Dep. |
Transport |
Key Tech. |
Categories |
Implementations |
RPC |
1974 |
– |
TCP/IP |
Stubs, IDL |
Infrastructure, |
Java RMI |
|
|
|
|
|
IaaS |
[52], XML |
|
|
|
|
|
|
RPC, .Net |
|
|
|
|
|
|
Remoting |
|
|
|
|
|
|
[53], RPyC, |
|
|
|
|
|
|
CORBA |
SOA |
1998 |
WS-RPC |
HTTP,FTP, |
WSDL |
Architecture |
IBM Websphere, |
|
|
|
SMTP |
UDDI |
level, PaaS |
Microsoft .Net |
|
|
|
|
SOAP |
|
IIS, Weblogic |
REST |
2000 |
HTTP |
HTTP,FTP, |
Web-oriented |
Architecture |
RIP, Rails, |
|
|
|
SMTP |
|
level, DaaS |
Restlet, Jboss |
|
|
|
|
|
|
RESTEasy, |
|
|
|
|
|
|
Apache CXF, |
|
|
|
|
|
|
Symfony |
MASHUP |
2000 |
REST |
HTTP |
Web-oriented |
Application |
Google Mashup |
|
later |
SOA |
|
(Web 2.0) |
level, SaaS |
editor, JackBe, |
|
|
RSS |
|
|
|
Mozilla |
|
|
|
|
|
|
Ubiquity |
1.4.2 SOA (Service-Oriented Architecture)
The goal of a Service-Oriented Architecture (SOA) [55,56] is to composite together fairly large chunks of functionality to form service-oriented applications, which are almost entirely built from the existing software services. SOA hired a bunch of open standards (1) to wrap the components in different localized runtime environment (e.g., in Java or .NET); (2) to enable different clients including pervasive devices free access; (3) to reuse the existing components to compose more services. This significantly reduces development costs and helps designers and developers to concentrate more on business models and their internal logic.
SOAs use several communication standards based on XML to enhance the interoperability among application systems. As the atomic access point inside an SOA, the web services are formally defined by three kernel standards: Web Service Description Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description Discovery and Integration (UDDI). Normally, the functional interfaces and parameters of specific services are described using the WSDL. Web services exchange messages are encoded in the SOAP messaging framework and transported over HTTP or other internet protocols (SMTP, FTP, and so forth). A typical web service lifecycle envisions the following scenario: A service provider publishes the WSDL description of their service in a UDDI, a registry that permits Universal Description Discovery and Integration of web services. Subsequently, service requesters can inspect the UDDI and locate/discover web services that are of interest. Using the information provided by the WSDL description, they can directly invoke the corresponding web service. Further, several web services can be
16 |
H. Jin et al. |
composed to achieve more complex functionality. All the invocation procedures are similar to RPC except that the communications and deployments are described in open standards.
Moreover, the open standards organizations such as W3C, OASIS, and DMTF contribute many higher-level standards to help different users construct their reusable, interoperable, and discoverable services and applications. Some of these standards were widely adopted to construct grid and cloud systems, such as Web Services Resources Framework (WSRF) [57], Web Services Security (WS-Security) [58], Web Services Policy (WS-Policy) [59], and so on.
1.4.3 REST (Representative State Transfer)
REST [60] is an architectural style that Roy T. Fielding, now chief scientist at Day Software, first defined in his doctoral thesis. REST stipulates mechanisms for defining and accessing resources in specific distributed systems such as the web. In a REST implementation, resources are addressed via uniform resource identifiers (URIs). That is, a given URI is used to access the representational state of a resource, and also to modify that resource. For example, web URLs can be used to give descriptive information about resources, and consumers then need to know only the URL to read the information. Furthermore, an authorized user can also modify the information if needed.
REST defines three architectural entities as follows [60–62]:
•Data elements: resource identifiers such as URIs and URLs, and resource representations, such as HTML documents, images, and XML documents
•Components: Origin servers, gateways, proxies, and user agents
•Connectors: Clients, servers, and caches
The representational state for resources in an HTTP-based REST system should be accessed using the standard HTTP methods.
A simple breakdown of these methods is as follows: GET is used to transfer the current representational state of a resource from a server to a client; PUT is used to transfer the modified representational state of a resource from the client to the server; POST is used to transfer the new representational state of a resource from the client to the server; and DELETE is used to transfer information needed to change a resource to a deleted representational state.
1.4.4 Mashup
A mashup has been defined in Wikipedia [63] as “a web page or application that combines data or functionality from two or more external sources to create a new service. To be more precise, Mashup technology concentrates on the following tasks