Below are the different types of web application architecture:
1 Client-side Static Mashup
Examples: Goople Maps: http://maps.google.com/
The client downloads an application that then runs locally. These applications are often called "widgets". Typically, the client sends some data to the website, perhaps by filling a form, and a customized widget is downloaded.
The data submitted by the user may be sensitive so security and privacy considerations apply.
1.1 Trust
Trust between the client and the widget source is established by using crypto signatures. Trust is often proxied by use of an "app-store" model.
Widget authors and distributors can digitally sign widgets as a mechanism to ensure continuity of authorship and distributorship. Prior to instantiation, a user agent can use the digital signature to verify the integrity of the widget package and to confirm the signing key(s)." However, this should not be confused with "trust" in any way (e.g., an author I trust could turn evil, or the widget could be hijacked).
Re. app-store he says: an appstore cannot really guarantee trust (as above). There are lots of trust models that will hopefully emerge around widgets (such as community mediated trust - where a community needs to approve something as safe before it can be used on devices). Depending on single points of trust is a bad thing, IMO. The central idea is that anyone can be an app store and that (hopefully) widgets engines will be able to get widgets from anywhere on the Web (i.e., totally decentralized distribution model).
There is also the question of whether the form should be trusted. If the form came from the same authority as the URI assignment authority, then it is definitely trustworthy but if it comes from some other authority then it might be trustworthy.
1.2 Client-side URIs
When the widget starts it displays a URI. As the application proceeds, for example, by scrolling on a map, the URI changes. These URIs are constructed dynamically but conform to general URI usage, i.e. they can be stored on the server, sent to others in email, etc.
2 Server-side Static Mashup
Examples: iGoogle: http://www.google.com/ig/
- Widgets on the server-side
- No separate download step, but often requires installation of content to a "container"
- One website combines content from multiple other websites, often by means of iFrames
- External content validated statically by (for example) Caja, FBJS
- DNS-based trust, proxied by "container" site
3 Client-side Dynamic Mashup
- One site creates content which includes requests for content to other sites, or for information provided by the client
- Content is assembled dynamically on the client, based on content from multiple places
- Trust based on a combination of "user grant", enforcement of restrictions such as SOP, and other techniques (CORS, UMP, OAuth et al)
4 General Web Application Architecture
The general architecture for Web Applications can be described as a user, from a browser, initiating an application that may run on one or more websites. The websites communicate to one another and may exchange data or start processes.
The user initiates the application on one websites, sending parameters and other customizing information to it. This website may enlist the aid of other websites. The display on the user's browser, in general, may consist of data from several websites .In some cases, code may be transferred to run on the user's browser.
In addition to the usual concerns with browsers and URIs this architecture provides several additional challenges. For example:
- Secure communication between the websites
- Trust between the cooperating websites
- Need for client-side storage
Client-side Storage
Note that the multiple websites in this model could be copies of the same website. Thus, you could be executing a single transaction in which you buy two different airline tickets from the same website. If you use cookies to remember the details of the tickets, the cookies would go to both copies of the website and the details of the tickets would get mixed up.What is needed is, clearly, separate "cookies" for each copy of the website. The Web Applications WG is attempting to address this requirement with a facility called Session Storage. This essentially, provides a local database that can be used to store name-value pairs for each session with a website.
The second requirement comes from a situation where the user is working with multiple windows, and wants the session to persist across interruptions in connectivity. To enable this a local database can be used to store name-value pairs and this data can be used while the website is offline.
Again, cookies do not handle this case well, because they are transmitted with every request. This requirement is also being addressed by the Web Applications WG with a facility called Local Storage which allows name-value pairs to be stored locally. Such a facility can also be used to improve performance. The user may wish to store megabytes of user data, such as entire user-authored documents or a user's mailbox, on the client side and work on them offline.
While Session Storage and Local Storage provide simple name-value pair storage to cover the above mentioned use cases, they do not provide advanced "database" facilities such as in-order retrieval of keys, efficient searching over values, r storage of duplicate values for a key. To provide such facilities the Web Applications WG is working on a specification called Indexed Database API. A competing specification that provides similar capabilities called Web SQL Database. This specification seems to be on hold for the time being. Some have argued against it because, despite its name, it does not follow the SQL standard. Others have argued against it because it is based on a proprietary product and it is difficult to get two independent implementations.