Variants and Analysis

Web Architecture [./]
Fall 2008 — INFO 290-03 (CCN 42584)

Erik Wilde, UC Berkeley School of Information
2008-12-02

Creative Commons License [http://creativecommons.org/licenses/by/3.0/]

This work is licensed under a CC
Attribution 3.0 Unported License [http://creativecommons.org/licenses/by/3.0/]

Contents E. Wilde: Variants and Analysis

Contents

E. Wilde: Variants and Analysis

(2) Abstract

Today's landscape of Internet and Web technologies offers a sometimes confusingly wide array of implementation choices. Given some application idea, implementation can be done using basic Web technologies, newer Web 2.0 technologies, it can use browser-embedded functionality such as Flash, Java Applets, ActiveX, Silverlight, or Google Gears, or it can be built with Web-oriented application development platforms such as Adobe Integrated Runtime (AIR) or JavaFX. Starting from a desired objective (such as the successful implementation of a well-designed Web app), it can be very informative to assess factors influencing the pursuit of this objective. One way to do it is the analysis of the Strengths, Weaknesses, Opportunities, and Threats (SWOT) of implementation variants, which supports a more structured way of comparing variants, and can be a starting point for choosing the best one.



Implementation Variants

Outline (Implementation Variants)

  1. Implementation Variants [9]
    1. The Principle of Least Power [2]
    2. Application Architecture [4]
    3. Web-Based Application [1]
    4. Rich Internet Application (RIA) [1]
    5. Conclusions [1]
  2. SWOT Analysis [9]
    1. Conclusions [2]

The Principle of Least Power

Outline (The Principle of Least Power)

  1. Implementation Variants [9]
    1. The Principle of Least Power [2]
    2. Application Architecture [4]
    3. Web-Based Application [1]
    4. Rich Internet Application (RIA) [1]
    5. Conclusions [1]
  2. SWOT Analysis [9]
    1. Conclusions [2]
The Principle of Least Power E. Wilde: Variants and Analysis

(5) Simpler is Better

  • Choose the simplest possible language to solve a problem
  • Languages must be chosen on different levels
    • data model (informal, ER, UML, …)
    • data semantics (informal, microformats, RDF, OWL, …)
    • data representation (text, HTML, XML, …)
    • data storage (file system, RDBMS, XDBMS, …)
    • data retrieval (SQL, SQL/XML, XQuery, …)
    • programming language (PHP, Ruby, Python, Java, …)
    • programming framework (Rails, J2EE, …)
  • Decisions ideally should be future-proof
    • Web applications often evolve in unpredictable and surprising ways
    • simpler languages make it easier to quickly adapt
    • sometimes adaptations may require switching languages


The Principle of Least Power E. Wilde: Variants and Analysis

(6) Iterative Development

  • Models are important and useful
    • thinking about the problem space is essential
    • being able to conceptualize the problem space is important
  • Heavyweight models make it hard to change the model
    • changing the model is an expensive undertaking
    • everything connects to the model and must be changed as well
  • Lightweight models make it risky to change the model
    • the model can change easily without everybody noticing
    • components may break or misbehave because of a new model
    • well-designed components should ignore model extensions


Application Architecture

Outline (Application Architecture)

  1. Implementation Variants [9]
    1. The Principle of Least Power [2]
    2. Application Architecture [4]
    3. Web-Based Application [1]
    4. Rich Internet Application (RIA) [1]
    5. Conclusions [1]
  2. SWOT Analysis [9]
    1. Conclusions [2]
Application Architecture E. Wilde: Variants and Analysis

(8) Resources, REST, UI

Web Application Tiers

Application Architecture E. Wilde: Variants and Analysis

(9) Multiple UIs

Web Application with Multiple UIs

Application Architecture E. Wilde: Variants and Analysis

(10) Mash-Ups

Mash-Up

Application Architecture E. Wilde: Variants and Analysis

(11) Mash-Apps

Mash-App

Web-Based Application

Outline (Web-Based Application)

  1. Implementation Variants [9]
    1. The Principle of Least Power [2]
    2. Application Architecture [4]
    3. Web-Based Application [1]
    4. Rich Internet Application (RIA) [1]
    5. Conclusions [1]
  2. SWOT Analysis [9]
    1. Conclusions [2]
Web-Based Application E. Wilde: Variants and Analysis

(13) Shipping Data vs. Shipping Code

  • Applications should ship data, not code
    • REST-based back-ends can support any kind of interface
    • shipping code is very client-specific and should be avoided
  • Applications should focus on the service perspective
    • how to deliver a service that can be easily used by others
    • how to describe the service's data model for potential users
    • how to control access and authenticate service users
  • If possible, other services should be integrated
    • if you need authentication, why not use OpenID [http://openid.net/]?
    • if you need social networking, why not use OpenSocial [http://code.google.com/apis/opensocial/]?
    • if you need location, why not use Fireeagle [http://fireeagle.research.yahoo.com/]?


Rich Internet Application (RIA)

Outline (Rich Internet Application (RIA))

  1. Implementation Variants [9]
    1. The Principle of Least Power [2]
    2. Application Architecture [4]
    3. Web-Based Application [1]
    4. Rich Internet Application (RIA) [1]
    5. Conclusions [1]
  2. SWOT Analysis [9]
    1. Conclusions [2]
Rich Internet Application (RIA) E. Wilde: Variants and Analysis

(15) Shipping Code vs. Shipping Data

  • Rich Internet Applications are based on the idea of a smarter client
    • Ajax applications ship JavaScript code for modern browsers
    • Flash applications ship ActionScript code for flash players
    • ActiveX applications ship Windows components for IE
  • RIAs should be built on top of a RESTful service
    • standard services will provide XML-based interactions
    • Ajax-specific services may provide JSON representations
  • Service and RIA should be completely separated
    • if required, the service can be provided as an API
    • if required, alternative UIs can be implemented


Conclusions

Outline (Conclusions)

  1. Implementation Variants [9]
    1. The Principle of Least Power [2]
    2. Application Architecture [4]
    3. Web-Based Application [1]
    4. Rich Internet Application (RIA) [1]
    5. Conclusions [1]
  2. SWOT Analysis [9]
    1. Conclusions [2]
Conclusions E. Wilde: Variants and Analysis

(17) Divide and Conquer

  • Divide Web applications into REST and UI
  • RESTful Web applications scale and map well to stateless UIs
  • Stateful UIs maybe easier to build, but may not scale well


SWOT Analysis

Outline (SWOT Analysis)

  1. Implementation Variants [9]
    1. The Principle of Least Power [2]
    2. Application Architecture [4]
    3. Web-Based Application [1]
    4. Rich Internet Application (RIA) [1]
    5. Conclusions [1]
  2. SWOT Analysis [9]
    1. Conclusions [2]
SWOT Analysis E. Wilde: Variants and Analysis

(19) Structured Analysis



SWOT Analysis E. Wilde: Variants and Analysis

(20) SWOT Matrix

swot.png

SWOT Analysis E. Wilde: Variants and Analysis

(21) Decision-Making and Planning



SWOT Analysis E. Wilde: Variants and Analysis

(22) Strengths: Helpful and Internal



SWOT Analysis E. Wilde: Variants and Analysis

(23) Weaknesses: Harmful and Internal



SWOT Analysis E. Wilde: Variants and Analysis

(24) Opportunities: Helpful and External



SWOT Analysis E. Wilde: Variants and Analysis

(25) Threats: Harmful and External



Conclusions

Outline (Conclusions)

  1. Implementation Variants [9]
    1. The Principle of Least Power [2]
    2. Application Architecture [4]
    3. Web-Based Application [1]
    4. Rich Internet Application (RIA) [1]
    5. Conclusions [1]
  2. SWOT Analysis [9]
    1. Conclusions [2]
Conclusions E. Wilde: Variants and Analysis

(27) SWOT Problems

  • No focus on long-term strategic goals
  • Little focus on ROI (life after reaching the objective)
  • Comparing SWOT analyses can be hard (no metrics)


Conclusions E. Wilde: Variants and Analysis

(28) SWOT Essentials

  • SWOT always needs a well-defined objective
  • SWOT analyses are highly subjective
  • Structuring tools can be used as personal tools


2008-12-02 Web Architecture [./]
Fall 2008 — INFO 290-03 (CCN 42584)