Skip to main content

Power-N Architectures

Posted by elevy on September 21, 2007 at 7:28 AM PDT

Early in the dot com boom era, a lot of companies implemented the popular portals. Those portals allowed us to "integrate" multiple applications together into a single screen. I write "integrate" between quotes, because there was nothing really integrated, it was just that the set of applications were displayed in the same screen. The reason for the low level of integration was not because of lack of need, or lack of will. It was primarily because the applications at the time were written to produce data mixed with the rendering information, loosing all the semantics of the "data" that was being produced as a result of a request from the clients.

With the services and technologies that are available today I see a completely different future.

The ability to create a Rich Client user interface, with most of the benefits that a Thin Client offer, is an amazing technological resource. Think about it for a second. You can create a Rich Client application, that has zero maintenance cost. It is downloaded from the web, it runs on your client machine, and when there is a newer version, it downloads automatically an update (auto-update). For those of you that haven’t have the exposure to it, take a look at Java WebStart.

Adding to that we have lots of "backend" services sitting on the web, that can be easily accessed (i.e. google base, etc) and integrated, and semantically integrated.

These resources (technologies + services) give birth to what I am calling power-N architectures.

We can write a Rich Client application that accesses M * N-Tier services on the Web, integrate the data that the services have, and provide a really powerful tool for the end user.

Power-N Architectures

On many cases, as an application/service provider, writing the client application is not going to be enough. Most likely you will still have to provide your own services that provide an extra touch to make your application really unique, but I claim that most of the services that you would need are out there, just waiting to be integrated.

There are 2 fundamental differences with the approach I am presenting here.

Distribution of Tasks

The first one, is using a Rich Client interface that directly accesses the services that are distributed across the network. This is a very important difference. You are having all the advantages of a truly distributed application.

Specially scalability and high availability.

With the old model, all the services were tunneled through one server that acted as a proxy for you application. With JavaScript, AJAX, and all those technologies you really have no choice but do something like that. It would be extremely complicated to write an application in AJAX that goes to multiple services, and merges the data in an intelligent way. Not the case for full rich client java applications. In this scenario, having your server down, means your application is fully down.

In the Power-N architecture, the clients are more independent of the backend availability. If one of the services is down, that only means that the areas of the application that depend on that service is down. But the user can continue using the rest of the services without a problem.

I will not write about Scalability, I think it is obvious.

Integration

The second fundamental difference is Integration. With XML, and the semantic web technologies, we can write application that truly integrate different services. Here I am not talking about just presenting different unrelated information in the same screen. I am talking about real integration.

Specialized Browers

What will end up happening is that these Rich Client applications distributed across the web, are going to be sort of specialized browsers, that will access and integrate different web services, and provide rich and unique functionalities that are going to facilitate the life of the users.

You can access the reviews of a book in amazon.com, and query wikipedia on that book, find the author and its place of birth, get the geo coordinates and map the location, then go to another service and find how much would be a flight ticket to get there, and on, and on, and on…

I am not trying to present here a specific use case of a business that would work. I am just presenting an architecture that is here in front of us just waiting to be exploded into what will be the real new web.

Related Topics >>