Designing the Web Architecture: Problems and Insights
4.1 WWW Application Domain Requirements
4.1.1 Low Entry-barrier
1. Since participation in the creation and structuring of information was voluntary, a low entry-barrier was necessary to enable sufficient adoption. This applied to all users of the Web architecture: readers, authors, and application developers.
2. Simplicity was also a goal for the sake of application developers.
4.1.2 Extensibility
Extensibility: A system intending to be as long-lived as the Web must be prepared for change.
4.1.3 Distributed Hypermedia
1. The usability of hypermedia interaction is highly sensitive to user-perceived latency: the time between selecting a link and the rendering of a usable result.
2. The architecture needs to minimize network interactions.
4.1.4 Internet-scale
1. The Internet is about interconnecting information networks across multiple organizational boundaries.
2. Suppliers of information services must be able to cope with the demands of anarchic scalability and the independent deployment of software components.
4.1.4.1 Anarchic Scalability
1. Anarchic scalability refers to the need for architectural elements to continue operating when they are subjected to an unanticipated load, or when given malformed or maliciously constructed data, since they may be communicating with elements outside their organizational control.
2. The anarchic scalability requirement applies to all architectural elements.
3. Security of the architectural elements, and the platforms on which they operate, also becomes a significant concern.
4.1.4.2 Independent Deployment
4.2 Problem
4.3 Approach
The first step, is to identify the constraints placed within the early Web architecture that are responsible for its desirable properties.
Hypothesis I: The design rationale behind the WWW architecture can be described by an architectural style consisting of the set of constraints applied to the elements within the Web architecture.
The next step, is to identify the properties desirable in an Internet-scale distributed hypermedia system, select additional architectural styles that induce those properties, and combine them with the early Web constraints to form a new, hybrid architectural style for the modern Web architecture.
Hypothesis II: Constraints can be added to the WWW architectural style to derive a new hybrid style that better reflects the desired properties of a modern Web architecture.
The third step, is to use the new architectural style as a guide, we can compare proposed extensions and modifications to the Web architecture against the constraints within the style.
Hypothesis III: Proposals to modify the Web architecture can be compared to the updated WWW architectural style and analyzed for conflicts prior to deployment.
This approach as a single sequence, it is actually applied in a non-sequential, iterative fashion.
4.4 Summary
My approach is to use an architectural style to define and improve the design rationale behind the Web’s architecture, to use that style as the acid test for proving proposed extensions prior to their deployment, and to deploy the revised architecture via direct involvement in the software development projects that have created the Web’s infrastructure.