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.

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 apps often evolve in unpredictable and surprising ways
  • simpler languages make it easier to quickly adapt
  • sometimes adaptations may require switching languages

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

Resources, REST, UI

Multiple UIs

Mash-Ups

Mash-Apps

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?
  • if you need social networking, why not use OpenSocial?
  • if you need location, why not use Fireeagle?

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

Divide and Conquer

• Divide Web Apps into REST and UI
• Choose a project to do one or both
• Come up with a project plan for implementing the app
• Choose an app that you care about
  • something you would like to see as a Web app
  • something you want to do for your final project
  • something for the services or publishing course