CloudComputing

W3C Headlights Project - WACI: Web Application Cloud Interface

Background: W3C Headlights Program

The W3C headlights program (see also a separate blog) is a process at W3C whereby new, possible areas of activities are explored. These are technical areas which may have a large impact on the future of the Web, but in which the W3C has not previously been involved. For each of these areas, the fundamental question that has to be answered is “Should the W3C community become involved in this area?”. A number of informal groups have been set up to explore the areas listed W3C headlights program page for 2012. The plan is to make a decision on W3C’s involvement (or not) in these areas in July 2012.

One of the technical areas is cloud computing. This wiki page is the reflection of the discussions, happening on a separate mailing list (with a member-only archive) and through regular teleconferences. No document or opinion on these pages (or referenced from these pages) should be considered as official W3C policies or plans.

This Wiki Provides Discussion

The information presented here is for discussion only. The group has regular phone meetings where these ideas are flashed out, and the details presented below merely reflect the state of those discussions. Member of the group are expert from various companies (IBM, HP, Intel, Boeing, etc.); however these experts act as individuals and do not necessarily represent company policies either.

WACI Proposal Overview

There are number of cloud technologies and frameworks; all of provide similar functionality but using different methods, techniques and APIs. In order to take advantage of the additional scalability and adaptability offered by cloud frameworks third party developers must select a cloud framework and technology upon which they will base their application. This dependency on a specific cloud framework and technology results in an application which cannot run on other cloud frameworks, limiting application portability and developer to framework mobility.

Additionally each cloud framework / technology supports different guest operating systems and software package. This means that applications built using Linux and open source products on one cloud framework may not run at all on another framework.

This document seeks to address this by presenting a concept for an environment which can be supported across a number of cloud frameworks and technology. Based on web technology it isolates the developer and the execution environment from the underlying cloud technology and infrastructure while still providing the developer with access to the scalability and adaptability advantages of a the underlying cloud framework and technology.

W3C’s interests

Obviously, it is not W3C’s goals to cover all standardizations needs of cloud computing in general. It is already the case that existing cloud computing environments rely on Web technologies, and in particular W3C technologies, like URIs, HTTP, Linked Data, XML, etc; from W3C’s point of view, these technology usages may be considered as specialized applications which may not have a direct influence on the development of the core Web technology itself.

There is, however, a particular area that may be of interest. The Open Web Platform, whose components are being built by the W3C, provides a comprehensive set of technologies to develop sophisticated applications on the Web. These applications often (though not exclusively) run in Web Browsers, are built on top of HTML5 and JavaScript, use HTTP protocols, and various APIs to access local resources.

More and more of the Web Applications rely on cloud computing facilities. They may use the cloud for computing power, or as a versatile, and high capacity storage medium. The fundemantal question arises, therefore: what can be done to make such Web Applications easier to develop, so that they would be interoperable among various cloud environments or at least it should be easy and not costly to move such applications from one cloud provider to the other? Standard environments may be needed to achieve these goals: such standards may constitute the interest of W3C.

Some intended Use Cases

Mobile applications in need of computing power

Web Applications, running on a mobile device may want to perform some sophisticated computing for which the mobile device is not powerful enough. Examples may be advanced speech recognition, image and video processing, complex encryption, etc. Typically, such applications rely on a company server that performs the necessary computing; the client and the server communicate through the Internet, typicall through HTTP. However, setting up such computing server, ensuring proper load balancing, etc, may be a major challenge for a small company; an obvious approach would be to use cloud computing facilities for that purpose. To provide real time responses for the mobile user, the Web Application should communicate with the cloud computing server directly, without any intermediate company servers. The danger is, however, that the Web Application becomes locked in to a particular cloud computing environment; if the company decides to move from one cloud computing facility to another, the Web Application may have to be re-written. This is costly, requires lots of time, etc.

Data intensive Web Applications

Some of the Web Applications (mobile or not) are based on the access and the integration of a large number of data, often accessed via direct URIs (e.g. Linked Data). To increase response time, a viable options is to copy those data(sets) that are of interest to the application to the cloud and make them available via cloud storage services. That, however, raises a number of practical issues in terms of what URIs to use for a RESTful Web Application, whether moving from one cloud environment to the other would force the Web Application to re-engineer itself, etc.

A goal may be to separate the cloud-specific portions of a Web Application. The core of the application should be able to use the same code, the same URIs to access and possibly modify the data; adaptation of the cloud environment (e.g., setup, load balancing, “DNS magic”) should be done via standard API calls.

Host Technology Portable Web Applications

Allow a 3rd party developer who has created a web application using existing web technology such as JavaScript to move their hosted implementation between existing cloud technology environments, but providing a standard WebIDL interface. This would provide a developer convenient view of cloud services consistently between cloud technologies and works in harmony with existing REST based cloud standards.

Intended Audience

It is intended that this document would provide sufficient information to allow a cloud application developer and a cloud hosting provider to technically understand the proposed standard and how it would benefit the cloud industry.

Technical Concept

<TODO:>

• Why is this needed
• Overview of existing cloud based web application structure.

A modern cloud hosted web application not only interacts with end user devices, but also with the underlying cloud technology. This allows the web application to scale and adapt based on traffic or other application changes. Increasingly cloud application technologies are leveraging existing web based standards and technology. Node.JS is an example of how web technology (JavaScript) is being leveraged on the server side.

However each cloud technology provides its own interfaces and development environments making it hard for a 3rd party developer to port or move applications between cloud technologies.

Modern web applications are leveraging the compute and storage power of cloud providers to provide compelling features and user experiences across a range of end user devices. Currently developers have to invest in creating web technology based frameworks to provide their web applications with the ability to leverage the compute and storage power within the cloud.

This provides scope for innovation and standardisation in two areas:

1. Standardisation of WebIDL compute environment

   Allowing developers to move their applications between cloud technologies and frameworks.

1. Innovation of client and cloud

   Providing web application developers with the necessary interfaces to leverage the compute and storage within the cloud.

The following diagram illustrates the structure of a typical cloud based web application.

Technical Overview

This concept presents a cloud developer with a JavaScript based runtime environment. This runtime environment is standardised and available across all cloud frameworks and technologies. Traditionally a cloud application is defined as a set of virtual machine instances. Each instance contains a set of processes. Together these virtual machines and processes represent a cloud application. This concept presents a cloud application as a number of instances of a predefined JavaScript environment referred to as the “W3C Cloud Application Environment”. Each environment instance would contain a set of JavaScript files representing the processes a 3rd party developer would need the instance to execute. Together the instances of the W3C Cloud Application Environment and the developer supplied JavaScript files would represent the cloud application. The following diagram illustrates the concept for a single instance of the W3C Cloud Application Environment.

The W3C Cloud Application Environment is further broken down into the core environment and the W3C Cloud Infrastructure Interface. The W3C Cloud Infrastructure Interface is a set of JavaScript APIs, defined in WebIDL which would be standardised by the W3C and would define how applications get access to and control over the four core cloud framework technologies which enable an application to be both scalable and adaptable. These four technologies are:

1. Cloud Storage

   All storage is provided as a service with the cloud. Block and Object storage shall be supported.

1. Cloud Compute

   A cloud application will need to monitor the number of instances of the W3C Cloud Application Environment are running, and what tasks (developer supplied JavaScript) they are running. The cloud application will be able to scale up by adding additional instances and scale down by removing instances.

1. Cloud Message Queues

   The instances of the W3C Cloud Application Environment will need to communicate between each other to share work load and coordinate effort. This communication is provided by load balancers (see Cloud Networking) and a Cloud based Message Queue. The W3C Cloud Infrastructure Interface provides a standard API to access and manipulate a message queue.

1. Cloud Networking

   Instances of the W3C Cloud Application Environment will need to configure themselves within the network; this can range from assigning themselves to an external IP address via a cloud provided load balancer, to placing themselves behind a firewall and only accepting network traffic from other instances of the W3C Cloud Application Environment. Such configuration is dependent on the tasks the instance will execute and should be configurable at runtime using a standard API.

The following diagram illustrates how multiple instances of the W3C Cloud Application Environment may co-operate and work together on a HTTP based workload.

A Sceptical Point-of-View

Let us take a quick look at how Google Maps works. If you point your browser at http://maps.google.com/ an HTML page is returned. This page loads the maps API which fetches the JavaScript. The JavaScript then determines the location to be displayed, depending on whether Geolocation is enabled, whether a default location has been set, etc. Based on this, an [XMLHttpRequest] is made to the server to pull down the tiles for the default map and these are used to generate the display.

If you work with Google Maps, some of the map manipulation such as panning, zooming and scrolling is done on the client side. If new information is requested to embellish the map, such as traffic, this requires a trip to the server. If you want a link to the displayed map that you can send to your friend, you click the "Link" button on the right and it gives you a URI to the map displayed. For example: http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=212+Hessian+Hills+Rd,+Croton-on-Hudson,+NY+10520&sll=37.0625,-95.677068&sspn=32.527387,51.679688&ie=UTF8&hq=&hnear=212+Hessian+Hills+Rd,+Croton-on-Hudson,+Westchester,+New+York+10520&z=16

Notice the structure of this URI; it includes the address as well as other parameters encoded as a long query parameter string but no fragment identifier. Thus, the map that you see is generated by JavaScript on the client, based on information gathered from the server, but when you use the "Link" button, the URI that is generated encapsulates all the information and the manipulations as query parameters. If your friend does a GET on this URI, the server uses JavaScript to generate the representation and return it to your friend.

So, in this case and many other similar applications, the client browser sends a request to a server/cloud which provides the necessary services and returns the representation. What else do we need?

The above is modified from: http://www.w3.org/2001/tag/doc/IdentifyingApplicationState

Concept Benefits

<TODO>

Relationship with the Cloud World

<TODO, Notes from meeting>
HTML5/JavaScript is the cloud. Today this is very true from a client/consumer perspective. From a service/provider there are currently growing views and activities that JavaScript is also applicable (e.g. node.js).

Existing Standards

<TODO, Notes from meeting>

• Description of why this is not being addressed by other standards group
• Most are taking a bottoms up approach and look squarely from the infrastructure perspective (e.g. virtual machines, virtual networks etc.)
  

Cover:

• OCCI
• CIMI
• CDMI
• Cloud Frameworks (EC2, OpenStack etc.…)
• Many others are listed at cloud-standards.org
• TOSCA OASIS

Implementations / Implementers

<TODO:>