A Blueprint for Success

1. A Blueprint for Success Standardizing Enterprise Web Application Architecture Diane Keddie and Andrew Gianni University at Buffalo

2. 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?

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

4. 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

5. MVC • In 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.

6. 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

7. 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

8. The View • The interface layer • The HTML code, although some would argue the browser • Also the logic to define display and formatting

9. 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

10. The View • Identify common page types • Identify common page components • Create a shared repository for common elements

11. 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

12. 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

13. The Controller • Application behavior • Data validation • Business rules

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

15. Web Application Behavior respond render

16. Web Application Behavior Enter Name Enter Bio Enter Interest Submit respond render respond render respond render respond render render respond

17. Building a Framework before processing before respond respond after respond before render render after render after processing

18. 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()

19. 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;

20. 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

21. 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

22. 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

23. Data Validation • Validation of data is a common Web application challenge • Basics • Format • Required-ness • Content • Advanced • Business Rules

24. 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

25. 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

26. 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

27. Questions? • Andrew Gianni - agianni@buffalo.edu • Diane Keddie - dkeddie@buffalo.edu