Justin R. Erenkrantz Where do you want to go today?

Architectural Dissonance and Harmony in REST-based Applications
Background and Problem
Due in large part to the reformations introduced in HTTP/1.1 via the REpresentation State Transfer (REST) style, the World Wide Web overcame looming scalability and reliability challenges.  In recent years, however, Web-based applications have evolved from distributed hypermedia systems to a rich collection of dynamic services.  These new applications however have often introduced architectural dissonance – the state of a realized architecture not providing the style’s anticipated benefits.  This dissonance with REST jeopardizes the reformations that REST put into place.  We can partly attribute this dissonance to a lack of expressiveness and guidance from REST concerning the construction of these emerging services.  Yet, if more effective and expressive guidelines coupled with accompanying frameworks and tools were at an architect’s disposal, then the impact of the dissonance could be mitigated and architectural harmony on the Web could be restored.
Insights and Research Questions/Hypotheses
Insight: The Web is just one in a class of systems that exhibit specific properties that allows for clear separation of control along macro and micro architectural views.
Question: Can we introduce a vocabulary to better explain the relationship between macro and micro architectures?
Hypothesis: It is possible to construct a set of additional principles that can more precisely and effectively guide the architecture in a REST-based environment.
Insight: Computation should be a first-class concept in the Web.  Adding computation leads to a new set of constraints at the macro level: computational namespaces, locus of computation, and execution dynamism.  It also teases at new micro constraints such as: migrating computations, constraining transformations, minimizing core functions, mitigating latency, and providing multiple interfaces.
Approach and Validation
Approach
  1. Identify the causes of dissonance in REST-based systems which are not fully explained by REST
  2. Introduce a set of additional architectural guidelines (CREST) that provide more guidance for a REST-based architecture that minimizes inadvertent dissonance
  3. Analyze the effectiveness of these guidelines in harmonizing architectures
Validation
  • Explore the tenor and degree of the dissonance CREST identifies
  • Examine the effectiveness of bringing CREST to the Web through new versions of key Web components (client, server, and protocol)
  • Assess the dissonance present in architectures that either extend REST or are not even REST-based that share similar macro and micro interactions.
Contributions and Schedule
Contributions
  1. Understanding of previous REST-based architectures (Survey)
  2. Identification of missing constraints in REST and an understanding of their real-world impact (mod_mbox, Subversion)
  3. Design guidance for REST-based applications through a new architectural style (CREST)
  4. Harmonized versions of selected REST-based applications (Serf, Apache HTTP Server, HTTP/NG)
Schedule
November 2006: Topic Defense
Winter 2007: Bring Serf & Apache in line with CREST principles; Propose redesign of HTTP to better support CREST principles
September 2007: Final defense

Last Modified Sunday, 05-Aug-2018 13:13:16 EDT These pages were made by Justin R. Erenkrantz unless otherwise stated. This work is licensed under a Creative Commons License. These pages will look best in an XHTML 1.0 compliant browser.

Creative Commons Attribution License Valid XHTML 1.0 Strict! Valid CSS!
[Blue Ribbon Campaign icon] [frdm] Support SFLC