A New Model used in Rich Internet Applications
For the past few months I have been working with an Ajax based Rich Internet Application. The architecture in this app is very different from the architecture used in traditional postback-based ASP.NET or JSP applications. This article explains that architecture.
Traditional n-tier Architecture
In traditional layered architectures, the focus is on creating a reusable middle tier in a .NET, Java, PHP or RoR platform. There are a couple of patterns to do so:
1. Create a database layer that accurately represents your business model. Then use an "Active Record" pattern to represent table rows with objects in the middle tier. This means, typically, that there is a class per table. Foreign key and primary key relationships are captured as associations in the middle tier. Each column in a table typically has a property in the middle tier class.
When you use Active Record, your middle tier is a close representation of your database structure.
2. The other option is to create a Domain Model as a representation of your business model. Then map from the domain model to the database using Object Relational Mappers.
In both these options, the use of the middle tier for reusable business logic is a given. Enetreprises usually stay away from business logic in the front end, because enterprises do not usually trust Javascript for expressing business logic. A few reasons for this are: the lack of strong typing, difficulty in automated unit testing, lack of intellisense and strong editor support.
Rich Internet Applications (RIA)
Many applications use Ajax. Usage of Ajax does not classify an app as a Rich Internet Application.
RIAs are typically "single-page" apps - Applications that load a single page with Javascript content and then do not show postbacks (browser refreshes).
Think about a Flash based business application. The Flash movie clip loads additional components on demand. Any communication is using XML and is perfromed with web services in the middle tier.
RIAs, somehow, feel like the "correct" way of developing applications on the web. The client (browser) and the server have a clean separation based on data contracts. Development teams can reach the holy grail of working independently without stepping on each other's code.
Flash and Flex provide a way to deliver business applications with a good user experience. But they are proprietary and there are enterprises that shy away from them because finding developers who code Flex used to be difficult.
Instead enterprises go for HTML/Javascript based RIAs. These have a set of unique challenges:
1. Browser compatibilty - you need a library like JQuery or Prototype to code uniformly across browsers.
2. Component based UI - it is difficult to create UI components in Javascript. Several libraries provide pre-packaged components for grids and trees. But creating your own custom component is still a challenge.
3. Loading additional content and separating dialogs - UI frameworks handle this using iframes. But there is no standard way of handling dialogs. You need to come up with your own framework for that purpose.
4. MVC implementation - the client requires an implementation of the Model-View-Controller pattern so that the server calls and client side data are not tightly coupled with the UI. You may require a custom event pump for handling user actions and messaging the controllers.
Implementing MVC in the client leads to easily maintainable and reusable code. The Flex world have an accepted model called the Cairngorm framework. I am working with a Javascript adapted implementation in my project.
The big question in this case, is the location of business logic.
The Middle-Tier Goes Away
If you end up creating a business model in Javascript and communicate via services with the middle tier, you now have three different places to model the business - the database, the middle tier and in the browser client.
Instead, in my current project, we use the middle tier as a gateway. It simply delegates to stored procedures on the database end. The "data-specific" logic resides
in the sprocs. The UI logic is in the client. there is nothing in the middle tier.
I have heard of a few other businesses using this kind of model.
The biggest relief in this case is that we go from custom XML trees to relational data directly. There is no O/R mapping. The sprocs use XQuery to translate from XML to the relational tables. The transactions are all in the database.
What we have ended up doing is remove the Domain Model from the equation.
Working in this model has raised some deep questions. There are reasons the Middle Tier is the preferred stage (physically) for a business model:
1. It is close to the database; there is less cost to round trips.
2. It provides an object oriented, richer language for expressing business relations.
3. It provides encapsulation much better than available in the database layer.
But creating a full-fledged domain model in our case is redundant because we have a rich Javascript model to handle most of the logic.
From the n-tier model, this new architecture takes us towards a heavy client and a heavy database with a thin middle tier sandwiched in between.
Traditional n-tier Architecture
In traditional layered architectures, the focus is on creating a reusable middle tier in a .NET, Java, PHP or RoR platform. There are a couple of patterns to do so:
1. Create a database layer that accurately represents your business model. Then use an "Active Record" pattern to represent table rows with objects in the middle tier. This means, typically, that there is a class per table. Foreign key and primary key relationships are captured as associations in the middle tier. Each column in a table typically has a property in the middle tier class.
When you use Active Record, your middle tier is a close representation of your database structure.
2. The other option is to create a Domain Model as a representation of your business model. Then map from the domain model to the database using Object Relational Mappers.
In both these options, the use of the middle tier for reusable business logic is a given. Enetreprises usually stay away from business logic in the front end, because enterprises do not usually trust Javascript for expressing business logic. A few reasons for this are: the lack of strong typing, difficulty in automated unit testing, lack of intellisense and strong editor support.
Rich Internet Applications (RIA)
Many applications use Ajax. Usage of Ajax does not classify an app as a Rich Internet Application.
RIAs are typically "single-page" apps - Applications that load a single page with Javascript content and then do not show postbacks (browser refreshes).
Think about a Flash based business application. The Flash movie clip loads additional components on demand. Any communication is using XML and is perfromed with web services in the middle tier.
RIAs, somehow, feel like the "correct" way of developing applications on the web. The client (browser) and the server have a clean separation based on data contracts. Development teams can reach the holy grail of working independently without stepping on each other's code.
Flash and Flex provide a way to deliver business applications with a good user experience. But they are proprietary and there are enterprises that shy away from them because finding developers who code Flex used to be difficult.
Instead enterprises go for HTML/Javascript based RIAs. These have a set of unique challenges:
1. Browser compatibilty - you need a library like JQuery or Prototype to code uniformly across browsers.
2. Component based UI - it is difficult to create UI components in Javascript. Several libraries provide pre-packaged components for grids and trees. But creating your own custom component is still a challenge.
3. Loading additional content and separating dialogs - UI frameworks handle this using iframes. But there is no standard way of handling dialogs. You need to come up with your own framework for that purpose.
4. MVC implementation - the client requires an implementation of the Model-View-Controller pattern so that the server calls and client side data are not tightly coupled with the UI. You may require a custom event pump for handling user actions and messaging the controllers.
Implementing MVC in the client leads to easily maintainable and reusable code. The Flex world have an accepted model called the Cairngorm framework. I am working with a Javascript adapted implementation in my project.
The big question in this case, is the location of business logic.
The Middle-Tier Goes Away
If you end up creating a business model in Javascript and communicate via services with the middle tier, you now have three different places to model the business - the database, the middle tier and in the browser client.
Instead, in my current project, we use the middle tier as a gateway. It simply delegates to stored procedures on the database end. The "data-specific" logic resides
in the sprocs. The UI logic is in the client. there is nothing in the middle tier.
I have heard of a few other businesses using this kind of model.
The biggest relief in this case is that we go from custom XML trees to relational data directly. There is no O/R mapping. The sprocs use XQuery to translate from XML to the relational tables. The transactions are all in the database.
What we have ended up doing is remove the Domain Model from the equation.
Working in this model has raised some deep questions. There are reasons the Middle Tier is the preferred stage (physically) for a business model:
1. It is close to the database; there is less cost to round trips.
2. It provides an object oriented, richer language for expressing business relations.
3. It provides encapsulation much better than available in the database layer.
But creating a full-fledged domain model in our case is redundant because we have a rich Javascript model to handle most of the logic.
From the n-tier model, this new architecture takes us towards a heavy client and a heavy database with a thin middle tier sandwiched in between.
Labels: architecture, RIA
posted by Ramiah Ariya at
3:00 AM
|
0 comments
