A Blueprint for SuccessStandardizing Enterprise Web

Application Architecture

Diane Keddie and Andrew GianniUniversity at Buffalo

Background

• Administrative Computing Services• 42 employees• 12 web developers

• Building Perl-based Web applications for eight years

• Significant training to develop expertise• How to improve capacity for development and

support?

Goals

• Standardize development process• Improve quality of code• Avoid duplication of effort• Decrease support costs• Increase agility of development process

How We Did It

• Developed standards and best practices (directory structures, naming schemes, coding standards, testing)

• Moved reusable code to central repository• Isolated data, data processing and display

through implementation of model/view/controller (MVC) architecture

MVCIn the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

Steve Burbeck, Ph.D.

Advantages of MVC

Ease of distributing development work

Ease of prototyping

Ease of testing

Ease of support

Same model can be used for various views

More scalable

Disadvantages of MVC

Complexity• Higher learning curve• More files to develop and maintain

Overcoming the challenge of complexity• Standard directory structure and naming

conventions• Shared Code Repository• Build project script• Code Review Process• Software Engineering Infrastructure Group

The View

• The interface layer• The HTML code, although some would argue the

browser• Also the logic to define display and formatting

The ViewSeparating Business Logic from Presentation Logic

Determine method to use for implementing

Determine how data will be passed to the view

Determine where to draw the line drawn between business logic and presentation logic?

Wrapper template

The View

Identify common page types

Identify common page components

Create a shared repository for common elements

The Model

• The data, usually in the form of a database• Can also be an interface layer for the database• We use a combination of the Class::DBI Perl

module and some home grown code• MVC line blurs when writing data access and

data aggregation code

The Model in the Enterprise

• Some tables are shared• Shared code developed to access them

(Class::DBI and SQL)• Object Oriented Class::DBI allows for shared

code through inheritance• All applications have a database class

(Project::DB) which inherit from ACS::ClassDBI, which in turn inherits from Class::DBI

The Controller

• Application behavior• Data validation• Business rules

Web Application Behavior

• Standard application on it’s head• User-driven not application driven• Stateless• Process data, then render the next page

Web Application Behavior

respond

render

Web Application Behavior

respond

render

Enter Name Enter Bio Enter Interest Submit

respond render

respond

render

respond render

respondrender

Building a Framework

before processing

before respond

respond

after respond

before render

render

after render

after processing

Framework Pseudocode$page = dispatch()$page->respond_enter()$next_page = $page->respond()$page->respond_leave()$next_page->render_enter()$next_page->render()$next_page->render_leave()

Framework Code in Perl (CGI::Prototype) $self->prototype_enter; $self->app_enter; my $this_page = $self->dispatch; $this_page->control_enter; $this_page->respond_enter; my $next_page = $this_page->respond; $this_page->respond_leave; if ($this_page ne $next_page) { $this_page->control_leave; $next_page->control_enter; } $next_page->render_enter; $next_page->render; $next_page->render_leave; $next_page->control_leave; $self->app_leave; $self->prototype_leave;

The Object Oriented Framework

• Allows for code reuse through inheritance• Page behavior becomes increasingly specific• Policy changes addressed through changes

towards top of class hierarchy

The Hierarchy

CGI::Prototype - defines general CGI application behavior

CGI::Prototype::Hidden - defines the behavior of a CGI application that uses hidden form fields to maintain state

ACS::CGIPrototype - defines departmental application behavior, including data validation, authorization, hours of availability, data policy acceptance

The Hierarchy (contd.)

Project::App - defines the general behavior of a given application (application specific authorization, validation, etc.)

Project::App::page - defines behavior specific to a given page within an application

Data Validation

• Validation of data is a common Web application challenge

• Basics• Format• Required-ness• Content

• Advanced• Business Rules

Data Validation

• Data::FormValidator Perl module• Basic validation of form fields is simple

• attributes (required, optional)• constraints (phone_number, email)

• Data::FormValidator facilitates explicit business rule implementation• Business rules are atomic chunks of code• valid_date_range is just a more complicated

constraint than phone_number

Rapid Prototyping and Development

• Application prototypes developed with HTML that will eventually be used in the application, not thrown out

• The object oriented framework allows for incremental, iterative implementation

• Users can perform acceptance testing at any point in the development cycle

ePTF Case Study

• Taking personnel transactions online• Working page prototypes developed within a

couple of weeks• Data model developed in parallel with interface

prototyping• General application behavior definition begins

before completion of data model• Working application, sans business rules within

six months with five part-time developers• Explicit business rules allow for backfill later

without maintenance penalty

Questions?

Andrew Gianni - agianni@buffalo.edu

Diane Keddie - dkeddie@buffalo.edu