I had my web 2.0 initiation working for one of our clients, a startup company which was taking the property valuation market of the pacific North West of the US by storm. This company was making money just few months after it went live. They didn’t charge users for the services and Google ads were initially their only revenue stream (Currently they have their own ad server and don’t rely on Google ads anymore). It was quite amazing to see a well grounded startup make the kind of money, just by selling ad space.

A huge database of properties and a carefully crafted valuation algorithm with ample room for users to create content, is what differentiated the startup from established players in that space.

The company had a number of challenges to deal with; the foremost among them was to get people’s attention on the web, which is a critical success factor for any web 2.0 business.

The company spent zero dollars on advertising; they pretty much relied on “Word of mouth” and some good press coverage. One of the things they did was, to decide on opening their services as an API for developers to build applications around it.

I was part of this API team. Number of things had to be considered; as opening up one’s services could well be a death march, if not carefully planned. The intention was to allow genuine users to get the best use of the services, and to check moves of users with ulterior motives. Other considerations were the grading of APIs and users.

The company had acquired data from other third parties. There were restrictions on this acquired data to be redistributed through a service. After toying with the idea of charging users for premium content, it was dropped as it didn’t augur well with the organization’s purpose of empowering users.

Finally after several rounds of discussions, a decision was made to support a basic and a premium API based on the data provided. The basic API would provide valuations, which did not involve third party data; whereas the premium API would provide detailed information on properties. Users, who normally sign up for a developer account would be given just the basic API. In the future, based on their need, they could upgrade this to a premium API. This differentiated users who signed up for the basic service, from being counted in as premium users. Also the API service could be offered for free with fewer premium content users.

Another goal was to control the number of user requests. There was a certain throttle limit that was defined for a user in a day. On crossing this limit, the service would be shut off for the user for that day. Users, who hit the throttle consistently, had the option of contacting the company’s marketing department and request for an increase in throttle limit. Before a decision was taken on raising the throttle limit for a user, usage stats and the nature of the service were reviewed. IP addresses were tracked, to ensure that a person didn’t signup multiple times to go over the throttle limit. It was necessary to make sure that the servers don’t get overwhelmed by somebody who wants to bring them down.

There were some things which were based on good faith. A user is not expected to persist the data obtained from the API or call the API from a backend service.  An account could be blacklisted if the organization came to know of such API misuse.  

I assisted the team in designing storage for the API service. The requirements were constantly changing and it was difficult to close on a design. Initially, we thought of having separate developer accounts for API users. Then, we decided that all API consumers had to be registered site users and developer account would be just a “role” attached to their user account. By this time, I could not continue with the API team, as I had to move to the geographic data team.

While I was working with the geographic data team – getting my hands dirty with points, lines and geometries; news was out that the API service was launched. There was lots of buzz around it! It helped the company in couple of ways: One was branding (as one of the requirements of API users is to display the brand and logo), and the other was the tapping of other user-bases. There was a noticeable increase in traffic to the primary website few months, post the API launch.

One fine day, we heard of somebody who had built a mobile application which gave instant property valuation using the API service with a whole lot of other features. A particularly useful tool for real estate agents on the move! It was surprising to see how people got creative with the API, well beyond what the API designer could have envisioned. The API was a rocking success!

It’s interesting to see the kind of attention a small company, with tons of user generated data and an established user base commanded from existing players in the industry. More often, Buying is an easier option, rather than entering the game late.

I’m not sure how the company is faring today, with the US realty market being spooked. However, the new web with content of the people, by the people and for the people is for here to stay.

Arun J D Devaraj Web 2.0 API, extensibility, Web 2.0

It’s a dream come true to have a company of my own and the day is not for away, the horizon is at my hand’s reach and this world waits to witness the success of a new Entrepreneur and his Entrepreneurship. Yes, if I get funded for a Start-up Product Company – The concept that I would bet on is unanimous– its OPD(Outsourced Product Development) complemented with another emerging model called SaaS(software as a service) and any technology that makes this endeavor reach to customers and organization, that envy to make this world a better place to live in.

The one-liner to my dream come true is - An OPD provider with SaaS modeling. Yes, and if u ask me to put this techie crunch in a simple way, I can rephrase this to something like, having a sandwich. Yes, the bread on either side is the OPD and the masala inside is the SaaS, I am very sure that once, people have this combination, they will feel the taste and realize what difference it can make to their meal. My friends, don’t forget that you are in a fast-food world, where u don’t find time to eat your meal with great leisure in a hotel lawn, but to have sandwiches, burgers, pizzas on the drive. This is an era where even the tortoise have adopted running fast, to win the race of market capitalization and customer satisfaction (The old granny’s story of hare & tortoise has gone obsolete with the fast changing time).

To make my stand crystal clear, and the reason why my firm will combine the power of OPD and SaaS, I wish to drill down the technical aspects of these powerful weapons (Emerging Markets) which will rule the software industry in the years to come.

My first stand of justification, as why I would prefer to root with Product development rather than being a services company is, I “Think Product”. Yes, software and any application for that matter, is all about “Generics” that would cater the needs of a wide variety of users, whereas application /service oriented approach will be “custom-built” for a single organization or targeting a set of users only. Moreover with application development it is just enough, if the functional requirement of the client is met, but for a product to sustain in the market and to met the ever changing needs of different customers, it has to be well architected with a solid and robust framework, to support building new features on top of it for attracting the customers with newer versions and enhancements. This is the most challenging part of “Product Development”. Myself being a product developer and an emerging entrepreneur, I would like to take up industrial challenges and want my co-owners (the emerging Technology Evangelists of my Dream) to stand by me in winning customer satisfaction.

Why OPD:

The advantages what the ISV (Independent Software Vendor) enjoys when their product development is given to a OPD provider are,

1. Release multiple versions of their product with newer enhancements every year.(Helps them to sustain in the competitive market)

2. Crashing the product road map by releasing newer versions well ahead of planned dates (Quick to Market), there by capturing new markets and business.

3. Helps focus more on product management and leave ample time in ideating newer products (foreseeing emerging markets).

4. Minimizing their development cost.
So, my company being an OPD provider, I will be granting all the above advantages to my client (ISVs) there by winning his goodwill and revenue.

Now, let me come to my second weapon, the most powerful of all, and the reason why I need this to win customer satisfaction. Before getting functional on this, I wish to share my thirst on why and what for, I wish to start a firm of my own. Yes, the lifeline of my dream is to “Have, What you Want”. Henceforth the slogan of my company is “We Deliver your Desire”. The time has come for each of us, an individual or an organization for that matter, to have what they want and own what they wish. No one will be forced to buy an elephant just because he/she desired to have one pleasant, memorable ride on top of it. All you have to do is pay the cost for one pleasure ride and enjoy yourself. I hope this little example would have given a brief note on my second weapon – SaaS (software as a service). Readers please don’t confuse this term “service” with the one that I was opposing in the being of my post. The term “service” in this context, altogether holds a different meaning. Here the service refers to a part of functionality that can be used independently. In the above example Elephant is the Product, which can offer multiple services like

a) A pleasure ride.

b) A mode of transport.

c) Helps to move massive trees and logs from one place to another.

d) A symbol of pride and prestige (a Jumbo welcome to their guests –The King’s way).

So it’s with the person to choose his need out of the product. You can own one, if you require all the services all the time, or just make use of the needy service at the needed time by paying the cost for the usage, it’s as simple as that.

Why SaaS:

Also known as On-Demand software or Web delivered software, which is hosted by vendors and accessed over the web.

SaaS focus more on what the customer wants rather than what the vendor can provide.

SaaS rules out the scope of ownership and procurement model and provides scope for outsourced and subscription services model.

This method of software delivery eliminates the risk and large expense associated with a system purchase and the cost of maintenance of hardware and huge servers at the end-user level.

SaaS model is mostly centered on MDA – Model Driven Approach, which offers customizable product that can be easily upgraded as technology changes.

As we have seen the advantages of both the models - OPD and SaaS now let me justify

Why Both:

To give life to my ideology and make my dream come true, I wish to start a firm which combines both the models (OPD and SaaS) and serve the world with better prospects and greater opportunities. I firmly believe that, this combination will be a trend-setter for the aspirants to follow upon.

With this new product development model, I not only serve my client (ISVs) with a single unit of product what he asked for, but with an end-product which compose of multiple loosely coupled components which can serve their end-users as independent services, based on their need.

This model will open up new opportunity for the end-users and will provide them freedom to choose between the either of

1) To acquire the entire product in order to enjoy all the services the product is capable of. Or

2) Just make use of the service that is needed to him by offering the cost for the level of usage.

This freedom of choice paves way to newer paradigm and will take technology to the deepest level, to the common most man and address all his needs, thereby making this world a better place to live-in and grow rapidly.

This paragraph is not to indicate the end of my post, but here to address you, about the birth of a new entrepreneur, beginning of a fresh software era, growth of the world to a greater horizon. That day I will walk with great pride, prestige and privilege; for which I know,

“I have promises to keep, And miles to go before I sleep”

Sethuram Ragunathan Coffee House, Life at Aditi Idea Innovation Thoughts

MVC architecture consists of Model, View and the Controller. Model is the common app logic which will insert, update, delete and modify data into/from suitable data source.View would be the GUI.Controller is the heart, is what we will discuss upon.

When developing complex dynamic ASP.NET applications, it’s important to minimize code duplication to increase the reusability, scalability and flexibility of the application. In some applications, users may perform many different actions that have various controller logic but result in the same view (UI).

In order to develop reusable logic we have to minimizing the amount of server side code in the code behind pages as they pertain to a single object i.e. they are the controller for a single page. The logic on code behind and scripted pages is difficult or impossible to reuse and results in poor separation between the view and the controller. The active server scriplets are also more difficult to test and debug, additionally they defy the basic ASP.NET feature of pre-compiling of code as they are compiled and translated at run. Instead of adding script code to an .aspx page, it’s more efficient to implement the controller using classes, which allows you to implement common appearance and navigation across your Web application and reuse presentation logic throughout the application.

There are two different patterns that address the implementation of controller classes for ASP.NET applications. The Page Controller assists you in building an application in which the navigation patterns are static but the pages are generated dynamically. For more complex applications where the navigation is dynamic or configurable based on a set of rules (e.g., user privileges or application state), the Front Controller allows for a more efficient implementation.

They are as follows:

Page controller:
Similar to Default asp.net controller .This would have a base page controller which will act like a master controller, will have all the events contained by an aspx.cs code behind page, but will contain logic for security verification , session managements,

The Front Controller pattern:
The Page Controller pattern becomes inefficient when you need to coordinate processing across multiple Web pages because of its implementation of a single object per logical page. The Front Controller is more efficient in such cases because it funnels all requests through a single controller and then directs requests through a single handler and a hierarchy of command classes. The handler retrieves parameters from the HTTP request, chooses the correct command, and transfers processing to it. After each command object performs the specified action, it can choose which view is required to render the page properly. Implementing the Front Controller results in more centralized application control because all page requests come through a single controller instead of being handled by different Page Controllers. But this can also be a liability if the handler does expensive processing, such as database lookups that could cause the entire application to operate slowly. The handler should be as efficient as possible and use external resources only when absolutely necessary. You should also consider caching any external resources to increase the handler’s performance.

You implement the Front Controller class by creating a Handler and a ActionFactory, which determines the necessary action using the request parameters (like action class name, query strings…etc) to execute in response to a request. ASP.NET provides the IHttpHandler interface to create custom interfaces required to service incoming HTTP requests.The Handler class would be implemented by inheriting from System.Web.IHttpHandler and adding the logic to instantiate and call the appropriate action from the ActionFactory. The ActionFactory defines a collection of actions and the logic that determines which of the actions should be executed. Calling the HandlerFactory returns the appropriate action object for which the Handler can call an Execute method (which will be the default method i.e if the action does not specify any method then Execute method would be called). Using this pattern, you can create more robust navigation scenarios and implement them centrally by extending the ActionFactory logic and creating additional actions to handle the required scenarios.
The type of action would be mapped with an Xml file. So every aspx page would have an action however multiple pages can have same action (reusability).
But this mapping would involve reflection, hence a performance issue (reflection being very expensive).

Handler/ HandlerFactory:
This module would be responsible for handling all requests through the pipe line and process it accordingly. Basically this would consist of a Handler class which will be inheriting from IHttpHandler interface. The ‘Process Request’ would be the method which will interpret a request and generate a suitable response. You will be rewriting/modifying the request through Http Context in this class.
This module would also take care of session validation and other user validation.

Action Factory:
This module would create/re-use action instances which will be retrieved by the request. These action instances would be cached. If an action does not figure in the cache then it will be created.
This module would map the request to generate an action instance. This would be done as a mapping through a xml file. The xml would be a config file which would house all action mappings.
Eg.
For a request

“\\SomeReleventUrl.aditi?action=releventaction&method=releventmethodname”".aditi" - would invoke the respective handler class.

"releventaction" - would map to the xml config file and specify the action instance.

"Releventmethodname" - would specify the method to be invoked in the class. If not specified would take the default method.

Mapping in xml file:


<actionfactory>
<action name=” releventaction” type=”FullyQualifiedAcitonClassName” actionifSucess=”SomeReleventSuccessUrl” actionifError=”SomeReleventErrorUrl” >
</action>
<action name=” releventaction_one” type=”FullyQualifiedAciton_OneClassName”
actionifSucess=”SomeReleventSuccessUrl” actionifError=”SomeReleventErrorUrl” >
</action>
<action name=” releventaction_twotwo” type=”FullyQualifiedAciton_TwoClassName”
actionifSucess=”SomeReleventSuccessUrl” actionifError=”SomeReleventErrorUrl” >
</action>
<action name=” releventaction_three” type=”FullyQualifiedAciton_ThreeClassName”
actionifSucess=”SomeReleventSuccessUrl” actionifError=”SomeReleventErrorUrl” >
</action>
</actionfactory>


The type attribute would give the reference of the action class to be instantiated, which would bring reflection into play (hence a performance issue).But looking at the overall flexibility and scalability this can be tolerated.
actionifSucess attribute would specify the url to navigate in case the action returns as success.
actionifError attribute would specify the url to navigate in case the action returns an error or failed validation..

Using reflection we will invoke the Releventmethodname method in the action instance.
This would be the basic process flow for the entire incoming request.

Action: The action will interact with the ‘Model’ layer and will do all kind of data processing and logic implementation. This module would also interpret/recognize user inputs and translate into more generic data sources. All the user entered values would be retrieved though the request objects. The action would take context object as the parameter as it house both request and response objects.

Entity Objects: These can be either xml based objects or generic classes. These entity objects would store data and would be transferred across different layers.

State Management: Since performance is an issue, use of session would be discouraged unless of high necessity.
Caching to be implemented wherever possible.
ViewState to be made false by default for all the controls.
HttpContext would be used extensively to store value spanning through a single post cycle.

Code snippets:
Handler class
public class Handler : System.Web.IHttpHandler
{
///
/// Will process all request and send appropriate response
///
///
public void ProcessRequest(HttpContext context)
{
//Create an instance of Action Factory class
//Invoke CreateInstance of the Action Factory Class
//The Action Factory would return a URL as the response
//Navigate to the New URL }
///
/// Whether the handler can be re used
///
public bool IsReusable
{
get
{
return true;
}
}
public Handler()
{
//
// TODO: Add constructor logic here
//
}
}
}

Action Factory
[Serializable]
public class ActionFactory
{
///
/// Translate the request parameter to intanstiate the action
/// and invoke the suitable method
///
///
public void CreateAcionInstance(HttpContext context)
{
//Translate the request params
//Use reflection to create an instance of action class
//Use reflection to invoke suitable method.
//Action class would return success or failure value .
//Translate the returned value as the new Url
//Transfering the new URl to Handler class
}}

Action

[Serializable]
public class Action:IBaseActionClass
{
///
/// Translate the request parameter to intanstiate the action
/// and invoke the suitable method
///
///
public void ExecuteAcion(HttpContext context)
{
//Translate user inputs through request forms containted in //Httpcontext object//Make Functions calls

//Use reflection to invoke suitable method.

//Action class would return success or failure as response.
}

}

IBaseActionClass would be an interface all action class would be inheriting from. Necessary for runtime castins of all the actions

Further logic and DB calls would be done in the “Model” layer.

The MVC architecture is released with framework 3.0, which will be integrated part of it.

Tanmoy Biswas ASP.NET, Architecture & Design ASP.NET