EWD: Simplifying Web Application Architecture

(1)

EWD:

Simplifying Web

Application Architecture

Rob Tweed M/Gateway Developments Ltd http://www.mgateway.com Twitter: @rtweed

(2)

A bit about me

• 1980s:

– Lead Mumps developer at Royal Marsden

Hospital, London: Hospital Information System

• Early 1990s: Management consultant at Touche Ross, London

• Major NHS Networking project for Dept of Health

• Mid-1990s – present:

– Caché/Mumps web app framework developer – Javascript expert

(3)

A bit about me

• Pioneer of web development for Mumps

& Caché

– WebLink & WebLink Developer

• Sold to InterSystems: 1996

– Consultant for early CSP design

– Assisted most of InterSystems' major

customers worldwide on Web Application design & development

(4)

A bit about me

• Author of EWD

– 2004 – present

– Advanced web/ajax development framework

• EWD:

– Supports the largest Internet-facing Caché-based web applications

• World's largest Caché-based web app: – Quest Diagnostics Care360 "EziOrder"

» 30,000+ concurrent users » 500,000 test requests/day

(5)

(6)

(7)

Why Do I Despair?

• This is the industry-standard way it's done, right?

(8)

Why Do I Despair?

• This is the industry-standard way it's done, right?

• Yes, but nobody seems to ask the basic question:

– How on earth did something so simple (the web) end up being such a complex mess of stacks and layers? – Web apps were supposed to make things simpler!

(9)

What the "Experts" miss

• The technology on which VistA was built

(Mumps) turns out to also be a technology that could have been designed specifically as a web application platform

– Almost no layers or moving parts needed

– The entire web application development framework, runtime AND application(s) can run on a single

technical platform

• Mumps/Caché: the world's most misunderstood database technology

(10)

So why is this kind of nonsense the

accepted norm for web apps?

(11)

When it could be as simple as this:

Browser Web Server (Apache/ IIS) G a te w a y Caché http/ https W e b L in k in te rfa c e Caché C S P in te rfa c e Caché G a te w a y EWD Runtime VistA Page Scripts

(12)

(13)

(14)

(15)

Why does this matter anyway?

• 1 day of coding will cost 13 days of maintenance • Fewer moving parts and

layers means that one person can understand the entire application

• Remember: the people who will maintain the

application are rarely the original developers

(16)

So why is this kind of nonsense the

accepted norm for web apps?

(17)

To understand:

• We need to go back through the history of the web

(18)

Why was the web successful?

• "Good enough" at the right price – Free!

– Simple architecture

– Simple to build web pages

• No special tools required

• Anyone could create a web site

– Simple to access web pages – Basic graphical UI

(19)

"Static" web architecture

Browser Web Server File Store

Apache IIS HTTP

(20)

"Static" web architecture

Browser Web Server File Store

Apache IIS HTTP

(21)

Step2: Dynamic Pages

• Instead of fixed data in my pages, I want to display the latest figures in a table

– Dynamically generate the data in the document

(22)

How to do this?

Browser HTTP Web Server File Store Response

Database Dynamically build a page of

(23)

Enter CGI

Database CGI Interface

(24)

But databases don't have a

scripting environment, so:

Browser HTTP Web Server File Store Response Database CGI Interface Scripting Language eg Perl

(25)

Step 3

• This is ~1995, the era of Client/Server • Lots of problems emerging:

– Deployment and maintenance of thick clients – Complexity of development:

• Logic split between client & server

(26)

Step 3

• Why not use the browser as a universally-available standard smart UI?

• Move our application logic all back to the back-end

• Simulate an interactive UI session via a succession of generated HTML pages • Web Apps were born!

(27)

Problem 1:

• HTTP is stateless

• An interactive user application requires maintenance of state

– Persistent information available throughout the user's session

(28)

Problem 2:

• Browser still just communicates with the web server using just HTTP requests

• So, how to deal with security?

– How can we uniquely and reliably recognise the incoming request as being from the

person they claim to be?

– How can we protect an individual's session from malicious access?

(29)

Combine Problems 1 & 2:

• How can we reliably determine who the user is from the incoming request?

• How can we determine what they want to do on the basis of their request?

• How can we recreate their session state before handling their request?

(30)

The layers start to appear

Browser HTTP Web Server File Store Response Corporate RDBMS CGI Interface Security Management State Management HTML Page Generation

(31)

Security Management

Browser HTTP Web Server File Store Response Corporate RDBMS CGI Interface Security Management State Management HTML Page Generation User Credentials?

(32)

State Management

• Requirement:

– High-performance, highly scalable key/value store

– Ideally not just simple key/value store – RDBMS too heavy, slow

– State management database requires something more dynamic and free-form

(33)

Enter In-memory Key/Value Stores

• memcache

(34)

For more complex session data:

• NoSQL "Document" databases: – MongoDB

• NoSQL Columnar databases – Hadoop

(35)

More layers appear

Browser HTTP Web Server File Store Response Corporate RDBMS CGI Interface Security Management State Management HTML Page Generation User Credentials? NoSQL Database(s)

(36)

CGI too slow, so fast APIs

Browser HTTP Apache File Store Response Corporate RDBMS ISAPI / FastCGI Security Management State Management HTML Page Generation User Credentials? NoSQL Database(s)

(37)

"Proper" scripting languages

• Perl too weird and clunky

• "Professional" languages needed – Enter .Net and Java

• While we're at it, lets encapsulate all those other layers in our own special flavours

• "Hide" all that complexity by creating our own new complexity

(38)

Let's rationalise app design

• Model/View/Controller (MVC)

• Mapping URLs to resources (dynamic pages)

• Model for the data

• Views define the returned content

• Controllers access the database and business logic

(39)

(40)

A complete nightmare

• Everyone pretends to understand it

– Nobody actually does

• It's supposedly designed to be manageable

– Nobody really knows how to manage it because nobody really understands it

• If programmers can barely understand it, what chance do designers have?

– Design, not programming, is what makes an application a success

(41)

Result

• Timescales slip • Budgets soar • Staff turnover:

– the people who originally designed it have gone and new people can't understand what they've inherited

• Version 1 maybe eventually gets delivered • Don't hold your breath for versions 2 and

(42)

Web Applications

• They were supposed to be simpler than Client/Server, right?

• The industry has managed to turn them into as big a mess!

(43)

(44)

Wind back to 1994

• I realised that web pages could be generated dynamically

• The browser could provide all the UI

capabilities that we'd required for clinical applications at the Royal Marsden Hospital

(45)

Mumps: the World's Least

Understood database

• Databases normally need to be accessed and manipulated via a separate scripting language

• Mumps & Caché are almost unique in that they have an integrated, tightly-coupled

scripting language – Mumps database – Mumps language

(46)

Mumps: Tailor-made for the web

• Very high peformance, highly scalable language

& database

• Interpreted, "fast and loose" language

• Dynamic, schema-free hierarchical database

– "Universal" NoSQL capabilities:

• Key/value store • Document store • Columnar store • Graph store

• Native XML Database / DOM • Relational & Object (aka Caché)

(47)

Mumps: the layers disappear

ISAPI / FastCGI

Caché / Mumps Web Application

Management

Environment Corporate Applications

(48)

EWD: back to simplicity

• High-level abstraction for app design

– To the developer, it's as if you're designing using static pages

– Native XML DOM-based compilation stage

• State & Session management happens automatically

• No baffling MVC complexity • Simple, intuitive concepts • High-speed development • Simple maintenance

(49)

EWD makes it as simple as this:

Browser Web Server (Apache/ IIS) G a te w a y Caché http/ https W e b L in k in te rfa c e Caché C S P in te rfa c e G a te w a y EWD Runtime VistA * Page Scripts * EWD Pages EWD Session Store Caché or GT.M

(50)

What about non-Mumps

integration?

• Several alternatives:

– Ensemble

• Integration engine built on top of Cache

• Adaptors for most other databases and languages • EWD is 100% compatible with Ensemble

– Web Service access

• EWD can consume external web services

– Behave as an HTTP client

– Node.js (server-side Javascript) opens up new alternatives

• ewdGateway.js: Node.js gateway module for EWD

(51)

Ensemble Example:

Browser Web Server (Apache/ IIS) G a te w a y Caché W e b L in k in te rfa c e Caché C S P in te rfa c e G a te w a y EWD Runtime VistA Page Scripts Ensemble Adaptor DoD EWD Pages EWD Session Store

(52)

iEHR

• You don't need to go down the industry-standard route

• EWD is tried-and-tested technology • Direct integration with ExtJS v4 and

Sencha Touch (for mobile)

• It is demonstrably orders of magnitude faster to develop with and cheaper and simpler to maintain

(53)