Case Study: A Turly Component Base Approach for Web 2.0 Development

(by Mark Qian) - Under construction

Introduction

"Web 2.0" and "AJAX" are now hot words in the industrial. They are always "linked" to each other and even "equaled" to each other in many people's mind. "Web 2.0" is actually a business model while "AJAX" is just a built-in function in javascript for remote scriting. You can build a "Web 2.0" web site/application like Craigslist.com without AJAX (remote scriting) or build a truely "Web 1.0" web site/application with AJAX. When people talk about "Web 2.0" and "AJAX", they may not realize that they are saying "building a web 2.0 application with AJAX" or "building a business model with a function". As you can see, the "link" between the high-level abstruct business model and the low-level function is missing: the architecture. In this case study, I will share my own design experience: designing a web 2.0 architecture using ajax.

There are so many issues to address in order to achieve an "architecture of participation" but the center issue is how to give "Power To The Users" efficiently at both run time and maintenance time. "Run time efficiently" requires you to maximize the capability of users' power quickly while "maintenace time efficiently" requires that it is mostly your "web platform" and your users instead of your engineers to self-maintains the application in order to chase a varity of user requests.

In this article, I will discuss one of my approach, specially from UI point of view, for a highly dynamically-configurable, flexible and scalable web application.

Traditionally, a web application consists of pages. That is, similar content (or pages containing slightly-modified content), generated by servers, is sent over and over to the browsers. This may seem very inefficient but the fact is that many major application frameworks, such as ASP.NET and JSF, are still provide this kind of approach as "default" with some "ajax" addition (or correction).

A key difference between a traditional web application and a new, web 2.0 (or AJAX), application (I will call this kind of application "AJAX" in the rest of the article. Personall, I think that "AJAX" is really not an accurate term to describe the territory. It should be Remote Scriting.) is that the later does not communicate by page replacement mostly. Just like a regular windows application, an AJAX only update minimum part of the screen to refect the result of user activity instead of an entire screen to increase usability and efficiency. Most importantly, most user activity is processed within the browser instead of sending back to poll servers.

Many "AJAX" applications (including those I took over in my experience) appear as "part-time" where AJAX (remote scriting) is used only when "necessary". And many others still use the form-base manner for communication and only obay the "partially update" rule of remote scriting. There are different level of AJAX needs for different kind of web applications.

The architecture I will introduce here is a pure AJAX approach where

  • There is no "pages" but components
  • There is no "forms" but events
  • There is no difference between "client side" and "server side"

Forces

In order to define the concrete forces, let's start with a concrete page. Every web application or web site has its own level of user interaction and flexibility. I am going to put together a page that requires highly flexiblity. Even though a web 2.0 page, such as Craigslist.com, may not necessarily require such a highly flexible environment the key point here is that to maximize users' ability to self-manage the content you need to have a very flexible environment.

Let's assume that we are building a "more web 2.0" (or Advance) Craigslist, a place where users can not buy and sell with posting, do auction, manage their money in their acount (pay from their account) but also provide a social network where they can make connection for dating, arranging party and so on.

If you familar with the Craigslist.com, you will see even though it is doing something web 2.0 it is doing it in a "minimum" way: users' power is very limited. Let me show you what my Advance "Craigslist" can do beyond what the regular Craigslist can do, it

  • 1). allows user to watch current auction status
  • 2). provides users a trading console to trade
  • 3). allows users to view their account information like balances
  • 4). allows users to caculate/estimate their profit
  • 5). allows users to watch what they searched
  • 6). allows users to personalize their own pages like iGoogle
  • 7). allows users to create "sub-market" (or sub-craiglist)
  • 8). allows users to view the best sellers/traders
  • 9). allows ...
Now we can write down our forces in technical terms based on the requirements above:
  • The page should be able to be "splited" to a varity of ways to meet 6 above

    • 6 above requires that users should be able to select and arrange their own content.
  • The platform needs to provide a very loosely way for "pieces" in the page to communicate to each other

    • This mean each piece, like 1 and 2 and 3 and 8, can't see others per 6 since others won't be there when uesrs remove them but 1, 3 and 8 needs to be updated by 2.
  • The platform should allow any "piece" on the page to communicate back to server dedependently

    • According to 6 above, any "piece" on the page can't not depend on any other "pieces" since they may not exist.
  • ...

Solutions

In order to meet the requirements above, my design (or "Framework") obeys following rules:
  • The framework consists of nothing but "components".

    • These components are called "gadgets" in the presentation layer and "services" in the application layer. Components are ruled by following requirements:
    • A component is a highly self-contained object with all the data and data processing logic encapsulated within itself.
    • A component can not do any type of communication except publishing or subscribing topics (see the communication pattern below for details)
      • This means that a component should not make any direct reference to any other components. In other words, components never know anything about other components and their states are only changed by publishing a topic or receiving a subscribed topic.
    • A gadget (a presentation layer component) appear as a small MVC
      • M - the model that consists of two type of data: native data and shared data like session information
      • V - the views. A gadget may have one or more views that represents a single physical price of screen.
      • C - the controller including all the logic to run the gadget
    • A gadget is "driven" by information sent from the server.
      • This is one of "extreme" approaches I used.

      One key difference here, comparing to traditional web pages, is that my framework users won't "see" web pages but only components. Let me give a concrete example. Assuming we have a submit button in the trading console (area 2 mentioned above) and the submission will cause an order to be placed and many areas (1, 3 and 8)on the page needs to be updated. In order to do that, a traditional web developer needs to define a form and reconstruct the page completely with new data. For my framework users, they don't care about the page since it is never reloaded. The only two kind of tasks they need to take care. First one is to have the Trading Console (Area 2)publish a topic carrying the order data as parameters. The second task is to have Area 1, 3 and 8 subscribe the response topic of the topic published by area 2.

      For developers work on non-componentized "AJAX" application with hard-wired reference, life will be hard since they need to face many issues since Area 2 needs to know what to update after it receives the AJAX response. To satisfy requirment 6 above (allow users to dynamically drop in new screen "pieces" or remove existing "pieces"), a common solution is to write a series of "if" statements to verify if a "piece" exists before updating it. This will cause a lot of overhead for development and maintenance since you need to add new "if" statements when new "pieces" are introduced and remove those you no longer use as died codes. In an environment like iGoogle, where user can upload their own "pieces" at runtime, the "if" statement approach won't work. ...

  • The inter-component communication in the framework must use publish/subscribe mode.

    • The framework should provide such an environment where the "client/server" (or browser tier/web tier) should be transparent to all the components. That is, it doesn't matter which side (browser or server) the publisher reside and it doesn't matter where the subscribers reside. A topic publish from any place will be received by subscribers anywhere. You may be familiar the event system if you are a JSF user but the key difference here is that my framework integrate client (javascript name spance in browsers) and server (java name space in web containers) into a single event system. Another key difference in term of
  • ...

    • (To be continue...still working on it)