Transaction Awareness with Qualified Trust

Welcome to this web site

Transaction Awareness with Qualified Trust proposes some ideas for developing Web applications, together with a simple multithreading framework called AWebSvr.

Step 1: SIMPLIFY

The starting points are well known:

1. REST and the trend away from session state.

2. The trend towards server virtualisation whereby servers (and even server farms) often host just one application.

But then consider the consequences:

No entity frameworks or middleware containers

Transaction awareness and stateless HTTP means we shouldn�t try to build client state in middleware. Minimise the client state for any dynamic data � anything you download will likely be out of date soon, so use some method such as row-versioning to check if it has changed next time you use it.

No server-generated HTML or server-generated JavaScript

You can make all of the HTM, JS and CSS objects static and cacheable. Client state can all be obtained more efficiently using asynchronous requests. So no ASP scripting, server-side controls, events or Razor. There�s even no need for HTML Forms.

Script on the client is okay, and client-side script can call REST services.

No runtime interaction with libraries

It is much more secure to build the application complete, and supply components from the custom server rather than expect clients to get components from public repositories.

No separate web service

For a single server, the application can manage its own HTTP request service. There is no need for the extra security management required by multi-tenancy web servers. This represents a considerable cost saving in software and maintenance.

Even when the system grows to multiple servers they don�t need a separate web server: for example hosts can filter and redirect requests by IP origin.

No separate database server

At least for the single server case, there is no need for a client-server database system. This also represents a huge saving in complexity.

When the system grows to multiple servers, partitioning is a good plan, and a client-server database that supports this is required: possibilities include MongoDB sharding.

Step 2: DESIGN

The resulting strategy is

1. A custom web server for each application

2. Use an embedded (service-based) database

3. Use transacted AJAX/REST calls for all dynamic content

Custom web services

There are many frameworks that enable web servers to be written in a transparent way. On this website we will showcase several. Today we include Python's http server and Microsoft's .NET HttpListener class. Then add a set of controllers to provide the REST interfaces.

MODEL-CONTROLLER

Create model classes for each database table (REST resource) and controllers for each REST url (at most one method each for get, put, post and delete). Controller methods should receive and deliver JSON rather than HTML.

Database Connection

Depending on your chosen DBMS and threading strategy, build a database connection for your REST services. DBMS vary widely in their transaction support and SQL language despite 40 years of supposed standardisation.

An embedded database is specific to the web application, and should be provisioned from and supply data to other corporate services on a transparent basis.

TRANSACT REST calls

Each RESTful call to the server should be a transaction unit. In many cases they will correspond to a single database operation. Where client requests result in more than one change to the database, the steps should be accomplished as a single transaction.

Few business are happy to serve a page of contradictory or incorrect information, and customers hate web sites that report that an error has occurred. The goal should be to avoid both, e.g. by using row versioning methods as in the tutorials here.

Handle authentication

For this style of design, Basic authentication (for Internet) is better than it sounds, and Integrated Windows authentication is a good option for Windows based intranets. But any style of authentication can be supported by a User table in the database, and this can have additional key columns for partitioned solutions.

Provide a LOG

Qualified trust means that it should always be possible for a business owner to see how the current state was reached, to review the actions of any participants, and to find the previous state of any data. Most banks operate on this basis for their customer accounts: by contrast with services that insist on 'full trust'' you don't have the right to question their actions.

Step 3: BUILD

This web site will contain tutorials, samples and frameworks to exemplify the approach. The first tutorial shows how to use a customisable web server framework AWebSvr written for .NET with Google's AngularJS library on the client, and SQLite as the embedded database. The second tutorial is a REST server written in Python3.4, also using SQLite. All of these are free to use and copy.

Download: AWebSvr for .NET and source

Download: AWebSvr for Python3.4

AngularSQLite tutorial for Python

AngularSQLite tutorial for .NET

RESTPython tutorial using http.server

Step 4: CONTRIBUTE

Contact Malcolm.Crowe@tawqt.com if you have comments, performance reports, further tutorials and case studies, and suggestions to share. And if you disagree with any of the above analysis I promise to conduct an open debate on this site. Peter Checkland once said: "To a man who has a hammer, everything looks like a nail". I would add: a man who sells hammers will try to persuade people that nails are the only way to build.