Client/Server, REST and RIA in Real-World

Scenario

In TIQ-Industrial we’re currently working on a revamping of a classic VB6 Client/Server application to WEB (for our customer’s Intranet).

This application is mission critical because it’s used to manage the production-planning and scheduling of the whole industrial site (accordingly to standard ISA-95, it’s a level 3 system). Obviously we’re talking about manufacturing sector.

Requirements

The main challenges we’ve to face are:

1. The user interaction, experience and responsiveness must be at least the same or improve the existing one;
2. We’ve to minimize the network round-trips because in some plant areas the available network bandwidth is scanty;
3. We cannot change the existing database (based on SQL-Server 2005) because the new system will run in parallel with the existing one, working at the same time with the same tables and stored-procedures but in the near future the customer would like to improve the current design (well we think so and we hope so :-D);

The technology standard for the new web application are ASP.Net 3.5 and SQL-Server 2005

The above requirements will be addressed the following ways (in vision):

Requirement 1
The application will be developed in a RIA-style (Rich Internet Application) strongly leveraging AJAX and 3rd party controls (Telerik RADControl for ASP.Net Ajax).
There will be a strong commitment by the development team on the user interface (…and not as happens sometimes on business components generalization and sexy technical stuffs creating no value for the customer)

Requirement 2
PostBack is the enemy!
Usually in ASP.Net forms development model, a PostBack is generated each time users click on a button, asking the server to perform some tasks.
We can also say that an event is generated on the browser and that event is processed by the web server generating a new page.
Today’s page are rich and large and where there is a lack on network bandwidth the user experience is bad!

Our aim is the reduction of the postbacks needed providing direct access to database data and business services to the client (browser).

This aim can be reached through a REST architecture where AJAX it the enabling technology providing richfull browser logic and functionality (…we’re emancipating the browser :-D )

Requirement 3
I’ve to admit that we don’t like the current database design but we cannot improve it!

Although this project is an opportunity to think about a new and improved database design. We’ll try doing this providing a virtual implementation of the database entities using an ORM (in this case ADO.net Entity Framework)

It this way, we take 2 advantages:

1. We can design the application working on an “ideal” and “optimized” database design abstracted through the Entity Framework and we can also evaluate if db model is working as expected…
2. In the future (if and when) the customer would decide to improve the db design, it will be feasible to reuse the existing db artifact experience (conceived in ORM) to drive the design of the new DB.
   From the application perspective, we will need to update the entities mapping to the new design (and obviously we’d like to achieve a 1:1 mapping).

Logical Architecture

The diagram below explains the main layers of the application:

Navigation Services

It’s the “classic” web-server and provides the navigational logic to the application (page generation and page navigation).
Nothing different than standard web development approach, reference technologies are based on IIS 6 and ASP.Net 3.5
When an user asks for Something to Show, a new page (for example a Report, a Master/Slave view) is generated by the WEB server and pushed to the browser (as HTML obviously with graphics and scripts mixed-up). The important thing is that the page doesn’t contain data!
Data will be bound later and page itself (hosted by the browser) will ask/pull for the data.

Data Services

It’s the service that exposes data to the browser through http in a restful way (…in this project data will be exposed in read-only)!

I don’t have time to explain REST approach here (and there are a lot of blogs about that). For more information take a look to:

Pablo Castro’s Blog

WCF: Developing RESTful Services

Here, the main idea is that page controls will directly ask the data needed (something to read) to this layer that will send them using JSON/ATOM without needing to generate a new page avoiding the PostBack.
The idea is easy to understand, but in the was tricky and challenging to be implemented. The good news is that today we’ve technology for doing effective development with this approach.

ADO.Net Data Services (built on top of Microsoft’s ORM ADO.Net Entity Framework mentioned above) is a framework to expose relational data sources and manage REST events.

We’re using this framework to expose our data model to the external clients (browsers).

Services

ADO.net Data Service is great to expose data clusters and also their basic operation (CRUD) to the browsers but it’s not effective enough to expose complex business services and transaction. It hasn’t conceived for this!

The Services layer is in charge of exposing to external client applications (hosted by browsers) high-level services (business actions) that can be invoked by users.

Technically, there is nothing new in doing this, we leverage WCF (Windows Communication Foundation) that is mediator between the clients and the stored-procedures that currently are implementing the business-logic.

Currently there is a 1:1 correspondence with a business-services to stored-procedure, but strategically we can compose more complex services aggregating stored-procedures in transactions.

What is new here is that we exposes WCF using the REST Starter Kit so that this interface is compliant to the way in which data are exposed by the Data Services layer (atom/json), providing a single pattern in accessing data and services.

Summary

With this approach we can satisfy all the customer requirements and further we‘ve a couple of more gains:

• Basic data are exposed though REST so that they can be “consumed” by other applications (for example warehouse mng, quality mng, etc.);
• Business-Services are exposed through a standard (still REST) and in a strategic perspective, they could be invoked by etherogeneous clients to perform complex and shared business actions (for example raw material allocation) avoiding the needing to create complex ETL to keep the underlying databases aligned.

That’s SOA!