- 1 W3C Headlights Project - WACI: Web Application Cloud Interface
- 2 WACI Proposal Overview
- 3 Technical Concept
- 4 Relationship with the Cloud World
- 5 Existing Standards
- 6 Implementations / Implementers
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.
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.
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
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.
- Why is this needed
- Overview of existing cloud based web application structure.
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:
- Standardisation of WebIDL compute environment
- Allowing developers to move their applications between cloud technologies and frameworks.
- 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.
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.
The following diagram illustrates the concept for a single instance of the W3C Cloud Application Environment.
- Cloud Storage
- All storage is provided as a service with the cloud. Block and Object storage shall be supported.
- Cloud Compute
- 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.
- 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
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
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
Relationship with the Cloud World
<TODO, Notes from meeting>
<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.)</br>
- Cloud Frameworks (EC2, OpenStack etc.…)
- Many others are listed at cloud-standards.org
- TOSCA OASIS
Implementations / Implementers