Barracuda - Scope Summary
barracuda.gif (11456 bytes)TABLE OF CONTENTS

1 BARRACUDA SCOPE - OVERVIEW
    1.1    Document History
    1.2    Open Issues
2  THE BARRACUDA PRESENTATION FRAMEWORK PROJECT
    2.1    Project Objectives
    2.2    High Level Requirements
    2.3    Detailed Project Requirements
    2.4    Project Scope Limitations
3  BARRACUDA - FUNCTIONAL ANALYSIS
    3.1    Application Paradigms
    3.2    Understanding the Problem Domain
    3.3    Functional Objectives
    3.4    Functional Requirements / Recommendations
4  PROJECT RISKS AND RISK MANAGEMENT
    4.1    Risk: Community and user acceptance
    4.2    Risk: Legacy application support
    4.3    Risk: Performance concerns
    4.4    Risk: Security concerns
    4.5    Risk: Stability concerns
    4.6    Risk: Paradigm limitations

5 PROPOSAL
    5.1    Summary
    5.2    Proposed Project Schedule
    5.3    Summary: Schedule Risk Management


1    BARRACUDA SCOPE - OVERVIEW

Enhydra.org is pleased to present this Scope Summary Document for the Barracuda project. This document is designed to kickoff the initial effort to understand the Barracuda project requirements and to provide a preliminary roadmap to fulfill the Barracuda goals and objectives. The content of this document is intended to provide information and constructive direction to all project participants in order to facilitate the projects success.

The next step in the development of the Barracuda project is to solicit feedback from the open source community and to initiate the Discovery Stage of project development. As we move into this phase it is essential that all participants have a shared vision of the scope and objectives of the project and the Discovery process for the initial phases of the Barracuda Presentation Framework. The scope and objectives for the Discovery process will directly and profoundly impact both the schedule and the content of what is delivered in the Barracuda project. The purpose of this document is to assist the Enhydra community in the selection of the scope and objectives for the Discovery effort of the Barracuda project. Additionally, this document highlights strengths, weaknesses, and risks of various alternative routes that may be pursued in the implementation of the Barracuda project.

1.1    Document History

Version Published Notes
0.72 1/05/01 Changed all references from 'Rocks' to 'Barracuda'. Updated everything to reflect project changes since October (there really have not been very many) and to clarify our current direction. Also added section 2.4 identifying what Barracuda is NOT addressing.
0.71 10/05/00 Expanded the summary at the end of section 5.2 to clarify how we intend to be focusing on phased delivery.
0.70 9/14/00 Initial release of Rocks Scope Summary working draft version
Notes:

1.2    Open Issues

  • Release to community and incorporate feedback

2    THE BARRACUDA PRESENTATION FRAMEWORK PROJECT

This section is intended to provide a high level overview of the goals, objectives, and requirements for the Barracuda project.

2.1    Project Objectives

The primary purpose of the Barracuda project is to create a presentation-layer framework of reusable server-side development components designed to make it easier to build and maintain complex web applications. This will benefit the Enhydra community at large.

Consequently, our key objectives may be summarized accordingly:

  1. Make it easier for Enhydra developers in general to build and maintain the presentation layers of web-applications
  2. Foster community involvement in the design & development of the Barracuda project
  3. Encourage developer adoption of the Enhydra platform by adding value through the Barracuda framework
  4. Do such a good job that Barracuda become the de facto standard throughout the industry

2.2    High Level Requirements

This project is responsible for creating a powerful, flexible framework that can significantly improve the process of building and maintaining the presentation layers within web applications.

A successful Barracuda framework will exhibit the following characteristics:

  1. Raise the Bar - provide a presentation layer paradigm that is cohesive, scalable, and intuitive
  2. Improve Process - streamline the design and development process for the presentation layer
  3. Simplify Development - make it easier to build web applications with a higher level of functional complexity
  4. Encourage Separation - continue to encourage the proper separation of content from code that began with XMLC
  5. Promote Simplicity - ensure the framework is simple to learn, understand and use
  6. Ensure Flexibility - always provide a way to get "under the hood" to handle tasks beyond the scope of our abstractions
  7. Handle Multiple Domains - support applications that range in functionality from simple to complex
  8. Guarantee Interoperability - allow integration with other presentation architectures and support any Servlet 2.2 compliant container
  9. Support Diversity - simplify usage of multiple presentation layers in the same application (HTML, WML, etc.)
  10. Allow Tools Integration - make it possible to integrate the framework into visual development tools
  11. Facilitate Economy of Scale - allow for parallel development efforts involving lots of developers and designers

While not being tied exclusively to XMLC, one of Barracuda's chief goals is to make it easier to work with this powerful framework. Consequently, the Barracuda project is working closely with Mark Diekhans -- XMLC's chief architect -- to ensure we stay abreast of changes and enhancements in the XMLC arena. For the latest XMLC details, please refer to the the XMLC Webpage.

We believe the Barracuda framework will consist of several distinct layers:

  1. Forms Validation & Mapping Framework - When working with web applications, one of the more tedious aspects tends to lie in taking data entered in web pages as Strings and validating it according to the application's business rules (which often expect data as first class Java objects like Date, Integer, etc.). This subsystem will make it easy to map HTML form data to first class Java objects and validate it automatically.

  2. Model 2 Flow Control System - Most popular presentation frameworks have rallied around the Model 2 presentation paradigm as an effective way to realize many of the benefits of client-server's Model-View-Controller (MVC) approach in a web-app environment.  In Model 2, there are essentially 2 phases: a controller receives a request, updates the business model, and then redirects program flow to the appropriate view, which generates a response to be sent back to the client. Barracuda will offer a Model 2 flow control subsystem.

  3. Server-Side Event Model - Many developers who have seen the benefits of event driven programming in client-server applications have begun to look for ways to apply this approach to web-application development as well. Barracuda will provide a robust event model especially geared towards the intricacies of server side event handling. This is particulary strategic in that it sets us up to develop a server-side component model (see below) that will enable developers to add listeners to components and receive notification when those components generate an event, just  like they would in stated application development.

  4. MVC Component Model - Barracuda will go one step further than Model 2 to define a full blown server-side component model that offers a true MVC style interface, much like Java's Swing toolkit has done for stated UIs. This subsystem will be the key to leveraging XMLC by allowing developers to bind components to DOM structures and then programming against the component Models instead of dealing with the XMLC or DOM APIs.

  5. MVC Component Library - Building on the component model, Barracuda will provide a basic suite of MVC style components for the server. Such a library might include components like Label, Image, Form, TextField, PasswordField, TextArea, ComboBox, List, Button, CheckBox, RadioButton, Link, Script, Table, Tree, and TabbedPane. It will also allow developers to create and reuse more complex components.

  6. JavaScript Framework & Library - This subsystem will provide a simple bridge between Javascript and the Barracuda component model, allowing developers to create reusable Javascript components that can be plugged into the server-side component model to provide client-side control for other components. We have not yet defined the specific components that might be included.

The overarching goal for each of these subsystems is to minimize interdependencies so developers can use as much or as little of the Barracuda framework as they desire. We also want to maximize interoperability and portability so Barracuda can coexist with other approaches and attract developers outside the existing Enhydra community.

2.3    Detailed Project Requirements

Please see the Requirements Specification document for each specific subsystem for a detailed list of the Barracuda project requirements. It is important to note that at this point there are still a large number of requirements that have not been defined. These to be defined requirements will have a large impact upon the design decisions that will be addressed during the analysis portion of the project. Until these requirements are well understood all estimates, independent of the source, regarding the duration of the development effort should be considered very rough.

2.4    Project Scope Limitations

It is often helpful to specifically address what is NOT being addressed by the project. There are several specifics worth noting:

  1. Application Flow Control Framework - Barracuda is specifically NOT addressing the issue of application flow control, which would involve creating a framework to control how users can navigate through an application. This type of problem domain has been variously addressed by others with Storyboard frameworks, StateChart Frameworks, etc. While this certainly falls under the realm of an overarching presentation framework, we are not addressing it at this time because:

    • such frameworks typically exist at a higher level than where Barracuda is currently focused
    • lack of a clear consensus on which specific flow control approach is best
    • developer bandwidth issues

    This does not mean that a flow control framework is incompatible with Barracuda; on the contrary, we feel it will make an excellent foundation for any number of presentation frameworks. At the same time, we really want to constrain our focus to make sure we get the lower layers right first.

  2. Application Assembly Framework - Some people have expressed interest in assembling web-applications from XML descriptors, rather than by coding. While this is certainly intriguing, and we feel Barracuda will be fundamentally compatible with this approach, we're not actively addressing this issue at the present (same issues as above).

  3. Applets - There's been some discussion about using headless applets in J2ME environments. We are certainly not opposed to this, but we're not actively addressing it either.

Of course all of these subjects can be revisited as Barracuda implementation progresses.


3    BARRACUDA - FUNCTIONAL ANALYSIS

This section provides a functional analysis of the Barracuda project. We begin by highlighting the differences between Client-Server and Web-Application paradigms, and then proceed to evaluate the problem domain. Finally we address the objectives, requirements, and risks for the Barracuda project.

3.1    Application Paradigms

In the realm of distributed development, there are currently two main paradigms that have enjoyed widespread adoption: Client-Server and Web-Applications. Most distributed applications fall into one of these two categories.

Historically, many distributed applications have been built using Client-Server technology. Programs built on this model can provide powerful, feature rich interfaces that give users a tremendous amount of flexibility and control over highly complex problem domains. Unfortunately, client-server applications are often expensive to build and have proven difficult to deploy, especially over multiple client platforms. Typically, even simple applications require a large amount of supporting infrastructure to get off the ground.

The following diagram demonstrates this effect:

web_vs_cs_arch.gif (25667 bytes)

As we can see, although client-server applications may provide a long-term payoff, they generally require a much higher up-front investment.

In recent years a new application paradigm has emerged -- the Web Application development model. The concept is actually quite simple: a server generates application content that is then downloaded across the network to run in a universal client, the user's Web Browser.

This server-centric approach offers many distinct advantages. As the diagram illustrates, it requires far less effort to build and deploy applications, which in turn translates to a lower cost of entry. However, the inevitable desire to provide the user with a richer UI experience coupled with a web browser's limited functionality means that web applications are still difficult to build and maintain as functional requirements increase.

Consequently, Web-Application architecture has enjoyed widespread adoption and growth, and as many client-server developers have made the shift we are starting to see attempts to apply proven OO design techniques to the model.

Most developers today recognize the intrinsic value of a layered architecture that separates applications into data, business, and presentation layers. While tools like databases and object-relational mappers have greatly streamlined development in the non-GUI layers, the process of building the presentation layer has remained surprisingly tedious for web applications, even in light of new technologies like Servlets, and JSP.

The Barracuda framework intends to make it easier to build the presentation layers for complex web applications by creating a reusable component model for server-side development.

3.2    Understanding the Problem Domain

Development Issues

There are a number of specific issues that complicate server-side presentation development.

  1. presentation issues - There are a number of problems relating specifically to the presentation aspects of web applications:

    1. code / content coupling - Creating content on the server often involves mixing both programming logic (Java), and client presentation code (HTML, JavaScript, etc). For instance, using Servlets to build pages usually means embedding HTML in Java; JSP requires embedding Java in HTML. CGI, Perl, and ASP suffer from the same problems. All these approaches become problematic as complexity increases because developers end up mixing multiple languages in one source file.

    2. single tier architecture - Often, classes meant to generate dynamic presentation content are tightly intertwined with lower tier (non-presentation) logic. This coupling of business and presentation logic contradicts good object-oriented design and makes it more difficult to enhance the application later on.

    3. multiple client views - Quite frequently, content destined for the browser needs to be modified based on specific client constraints. These often include things like internationalization, configurable views or skins, security constraints, and a variety of output formats (HTML, WML, XML, etc).

    4. lack of a standard presentation framework - In Java client-server applications, Swing has become the de facto UI development model. Unfortunately, a similar presentation paradigm has not yet emerged for the web-app model. This may be to lack of well-defined industry standards, widespread use of add-hoc development styles, and varying levels of programmer skill.

    5. client side scripting - Often times web applications may need to leverage client side scripting. Because this scripting code must be generated on the server side, the developer often ends up writing "code within code", which can be very difficult to develop, debug, and maintain. This again adds to the overall application complexity and slows the development process.

    6. DOM complexity - The industry appears to be converging on the Document Object Model as a powerful approach to generating dynamic content. This makes sense because the DOM provides structured access to content as an object hierarchy. However, programming against the DOM is still low-level and tedious, which again makes the overall development efforts more difficult.

  2. protocol limitations - Most web applications leverage HTTP as a transport protocol. Because HTTP is a client-initiated request-response protocol, it is very difficult for server code to initiate unsolicited callbacks to the client. These factors make it harder to implement real time user interfaces like those used in typical client-server applications.

  3. high maintenance / TCO - The basic nature of the web-app paradigm makes web applications difficult to build and maintain as functional complexity increases. The problem is exacerbated by the lack of common methodologies and the proliferation of proprietary approaches. As a result, it is often difficult for developers to learn and understand applications that they did not write. This makes web apps expensive to own and maintain.

Why do these Problems Exist?

Given the number of obstacles identified above, there is obviously a window of opportunity for an application development model that can successfully address these issues. However, it may be helpful to ask "Why haven't these problems already been solved?"

We believe there are several reasons:

  1. new territory - while the enabling technologies behind web-based applications has been around for quite some time (i.e. HTTP, CGI, Perl, Java), the internet has evolved around a page-based, linear navigation paradigm -- users move from page A to page B -- that has only recently (within the last 3 years) been applied to applications. This creates subtle yet significant differences when compared to client-server development; it takes time for developers to understand these details and apply this knowledge to new application domains.

  2. ad hoc development - historically developers lacking solid OO skills have found it easier to get started in the web-app model. While this low technical barrier to entry greatly encourages adoption, the quality of implementation sometimes suffers. In many cases, this facilitates ad hoc development, which in turn results in classic "spaghetti code". Typically in cases like this, application design problems extend far deeper than just the presentation layers.

  3. paradigm differences - even developers with very good OO skills have had difficulty creating frameworks for the presentation layer within web applications. For instance, some client-server OO presentation techniques like MVC are more difficult to apply because of limitations within the underlying paradigm -- because HTTP is not a bi-directional protocol, the server cannot notify the client when something changes on the server, but must instead wait for the next client request cycle. This makes some client-server design patterns more difficult to implement.

Consequently, we should recognize that while there may be a fundamental limitation to the overall complexity that can be addressed by the Web-Application paradigm, we still believe there is significant room for improvement.

We intend to make Barracuda the framework that elevates the standard for web based development.

3.3    Functional Objectives

In light of the above difficulties, we have identified key functional objectives for each of the Barracuda subsystems:

Forms Validation & Mapping Framework

Typically, a developer must manually retrieve form values from an HttpServletRequest. The values are returned as Strings, and then it's up to the developer to manually parse, convert, validate, etc.  This tends to be cumbersome. The form mapping and validation package should make it easier to work with HTML forms.

  1. allow developers to specify which elements a form should contain and how they should be mapped (eg. support String, Boolean, Integer, Date, Long, Short, Double, and Float)
  2. allow developers to specify how elements and forms should be validated
  3. make it possible to create reusable validators that can be assembled into groups to form more complex validation procedures without recoding
  4. make it easy to trap validation errors so the users can be notified of what went wrong

Model 2 Flow Control System

MVC stands for Model-View-Controller. Model 2 is a term coined by Sun to describe an MVC architecture for web-apps (stateless) in which HTTP requests are passed from the User Agent to a "Controller" Servlet, which updates the "Model" and then invokes the appropriate "View" renderer (JSP, Servlet, etc), which in turn renders the view from the updated model. You can learn more about Sun's view of Model 2 by reading the J2EE Blueprints. In short, a Model 2 Flow Control system should meet the following objectives:

  1. provide for programmatic separation of "Control" logic from "View" logic
  2. provide the opportunity for Controllers to specify which View should be generated
  3. make the system generic enough so that the Views can be generated by any URI (Servlets, JSP, template engine, etc)
  4. support the concept of complex, nested views (aka Hierarchical MVC)

Server-Side Event Model

A server-side Event Model should make it easy for developers to use event driven programming in the context of web apps. There are several key objectives:

  1. translate HTTP Requests into events and dispatch to all interested listeners
  2. ensure that for every HTTP Request there is always only one HTTP Response
  3. make the model as similar to traditional event models as possible without minimizing the differences between web-app and client-server paradigms (stateless vs. stated)
  4. make the system completely pluggable for maximum configurability
  5. lay the necessary event delivery infrastructure for a server-side component model

MVC Component Model & Library

By representing documents as DOMs, XMLC provides an object-oriented approach to developing dynamic content. However, the DOM API is low-level and tedious to use -- operations are at the level of the HTML and XML elements, attributes and text data. The DOM Widget Framework provides support for the development of higher level classes, resembling GUI widgets, on top of DOM nodes. Consequently, a DOM Widget Framework should meet the following functional objectives:

  1. provide a complete widget set that maps onto the DOM
  2. provide a flexible set of classes and interfaces such that complex, nested HTML structures may be represented by a hierarchical structure of widget APIs.

JavaScript Framework & Library

The Barracuda JavaScript Framework should make it easier for server-side Java developers to work with JavaScript. We see several key functional objectives:

  1. provide a Java-based component model for implementing client-side scripting
  2. free Java programmers from having to understand JavaScript implementation issues, especially with regard to generating client scripting logic from a server-side application
  3. facilitate mapping JavaScript to server-side dynamic documents, raising the level of DOM programming

3.4    Functional Requirements / Recommendations

Based on our objectives, we can identify a number of preliminary requirements for each subsystem. As work on Barracuda progresses, we will provide links to more detailed requirements documents.

Forms Validation & Mapping Framework

Please refer to the Form Validation & Mapping Requirements document.

Model 2 Flow Control System

Please refer to the Event Model Requirements document (the Model 2 Flow Control System has been integrated within the Server-Side Event Model framework).

Server-Side Event Model

Please refer to the Event Model Requirements document.

MVC Component Model & Library

In order to meet the stated high-level objectives we will create a Model-View-Controller (MVC) framework based on the following list of essential functional requirements: (design work in progress)

  1. Define common Components - Label, Image, Form, TextField, PasswordField, TextArea, ComboBox, List, Button, CheckBox, RadioButton, Link, Script, Table, Tree, and TabbedPane
  2. Define common Models - Create model interfaces for each component (much like's Swing MVC Model interfaces)
  3. Component Binding - Enable components to be bound to DOM nodes. When the components are rendered they will load data from their model into the appropriate portions of the DOM view.
  4. Component Actions - Enable components to generate action events (ie. when the user does something to invoke a URL). Some components may need to utilize scripting in order to generate events. Components that generate events should allow developers to add event listeners to them.
  5. Component Nesting - Enable components to be nested, allowing complex components to be assembled from simpler ones.
  6. Multiple L&F - Recognize that components may need to be rendered differently depending on L&F requirements (ie internationalization, user prefs, etc).
  7. Multiple Output Formats - Recognize that components may need to generate different output formats, depending on client capabilities. This probably means we will need some kind of structure to identify client capabilities. It may also be helpful for components to be able to indicate which output formats they can support.

This list is still highly speculative and will be refined as the design process continues.

Note that we do NOT feel that component scope (ie. how long the component hierarchy lives, is it shared by multiple threads, etc.) is a distinct aspect of the component model. We feel that should be addressed by a higher layer within the presentation framework. At the same time, we recognize that we need to account for the possibility that developers may want to provide shared access to component hierarchies, and as such intend to take this into account in the design process.

JavaScript Framework & Library

We have identified the following list of key functional requirements for a JavaScript Framework & Library:

  1. Library of common scripts - The Barracuda JavaScript Framework will consist of modules that provide specific types of JavaScript functionality.  These modules provide a library of common JavaScript functions and utilities.  For example, a single module handles a particular style of form verification.

  2. Encapsulates client scripting - These components will shield the application developer from dealing with JavaScript implementation issues.  Such issues include any aspects of JavaScript management that are common to using JavaScript in general, as well as implementing specific scripts.

  3. Flexible scripting framework - Specific modules do not depend on other modules that provide other types of JavaScript functionality.  That is, though module wrappers may be extended, or used with other wrapper classes, they do not otherwise require the presence or use of others.  This ensures that their implementation details can change at any time, without requiring the programmer to change how they are used.

This list is still highly speculative and will be refined as the design process continues.


4    PROJECT RISKS AND RISK MANAGEMENT

This section highlights key known risks and plans for mitigating these risks. These risks have been identified during the Scope phase of the project and are discussed in the context of this particular project. This risk analysis is very important in the evaluation of what we can realistically achieve during the Discovery phase of the project.

4.1     Risk: Community and user acceptance - Given the wide range of problem domains for web applications, coupled with numbers of competing approaches and the lack of a de facto standard, it may be difficult to create a framework that will be acceptable for everyone.

Mitigation Strategy - We believe there are a number of things we can do to help minimize this risk:

  1. Release early design documents and white papers to familiarize the Enhydra community and users about our design paradigm. 
  2. Provide early and complete examples with appropriate documentation.
  3. Actively solicit community for feedback and suggestions to ensure we account for all aspects of the problem domain
  4. Evaluate and monitor other presentation framework efforts to fully understand the pros/cons of existing approaches
  5. Focus on creating an architecture that is
    • open ended and flexible (allowing developers to use as much or as little of the framework as they desire)
    • interoperable and portable (allowing for coexistence with other approaches and avoiding vendor lock-in)
    • incredibly easy to learn and use (making it the obvious path of least resistance)

4.2     Risk: Legacy application support - Application maintenance is a fact of life; frameworks that can not integrate well with existing applications or alternate development approaches may not be useful to developers in the trenches.

Mitigation Strategy - We believe there are a number of things we can do to help minimize this risk:

  1. Ensure the existing Enhydra 'Super Servlet' and Presentation Object model can be incorporated within the new framework.  This will allow enhancements to existing Enhydra applications to occur within the new framework without modifying existing code.
  2. Allow for incremental adoption of the Barracuda framework as much as is possible.
  3. Provide a clear migration path for alternate approaches to make it easy to move to the Barracuda framework.

4.3     Risk: Performance concerns - Scalability and throughput are major issues for most web application developers. Creating layers of abstraction inevitably adds overhead which eats away performance or increases system resource requirements. Significant performance degradation can impede widespread acceptance of the Barracuda framework.

Mitigation Strategy - Historically, many of these same concerns have been applied to Java and OO development in general, where it has been demonstrated that in many cases performance concerns can be minimized simply through good design and development processes.  In addition, we see several specific ways to further offset these risks:

  1. Ensure object designs can easily be modified to provide optimization routines such as object pooling. 
  2. Take precautions to avoid breaking backward compatibility with previous releases
  3. Make framework components configurable where possible to allow for performance tuning at runtime
  4. Perform regular performance audits of the Barracuda framework
  5. Evaluate Barracuda in the context of real-world applications to ensure sufficient "reality factor" in our performance testing
  6. Develop a performance oriented testing suite that
    1. provides a basic performance analysis for major components within the Barracuda framework
    2. establishes known performance baselines and helps prevent performance degradations from creeping into the framework over time
    3. makes it possible to compare Barracuda performance with that of alternative presentation frameworks
  7. Create performance utilities that make it easier for developers to test the performance of the applications they build

4.4     Risk: Security concerns - Web applications built on Request-Response paradigm often suffer from security issues that are exacerbated by HTTP's "connectionless" nature.

Mitigation Strategy - While this is an issue that faces all web application development, it is critical that the Barracuda framework makes it easier to address these types of problems.

First and foremost, we make sure the Barracuda framework itself does not introduce any additional security weaknesses. We can work towards this goal by:

  1. Performing regular security audits of the Barracuda framework
  2. Building the notion of security into the core aspects of the flow control framework
  3. Develop a testing suite focused on security that
    1. helps prevent protocol and framework vulnerabilities
    2. protects the fundamental security of Barracuda framework
    3. ensures appropriate regression tests are developed and executed prior to all releases

In addition, we must recognize that no framework can prevent all security vulnerabilities within application specific code. As such, we should:

  1. Make it easy to build secure web applications by supporting security concepts with the Barracuda framework itself
  2. Clearly document common mistakes and weaknesses
  3. Provide lots of examples of good security practices
  4. Create security tools that help application developers spot potential weaknesses

4.5     Risk: Stability concerns - An development framework which is unstable or unreliable rarely succeeds; if Barracuda does not provide a high level of stability between releases it may be difficult to establish long term viability and win over new developers.

Mitigation Strategy - We feel that the best means to ensure stability is through a combination of sound design, quality implementation, and thorough testing. There are a number of ways this plays itself out:

  1. Provide regular releases incorporating the latest fixes and enhancements to ensure rapid turnaround and quick response time
  2. Create a rigorous testing suite that
    1. contains comprehensive unit and regression test subsystems (these tests should focus on API specifications and strive for complete code coverage.)
    2. contains a performance test subsystem
    3. contains a security test subsystem
    4. is executed and validated prior to all releases. 
  3. Clearly document known bugs and issues, providing workarounds whenever possible
  4. Encourage an open and frank discussion within the Enhydra community of Barracuda flaws and weaknesses for the purposes of improving the overall quality of the framework

4.6     Risk: Paradigm limitations - Because the Web-Application paradigm is based on the HTTP Request-Response protocol, there are certain fundamental limitations due to the uni-directional nature of component communication. Unlike the Client-Server paradigm, which usually supports bi-directional communication, with web applications only client components can initiate communication with the server -- server components can never contact the clients on their own. This subtle yet significant paradigm difference, combined with the limited feature set of HTML, may ultimately limit the amount of functional complexity that web applications can effectively handle.

Mitigation Strategy - The best way of handling this risk is primarily to acknowledge its presence and to recognize that  Web-Applications may not be the best solution for every problem domain. Nevertheless, we still see tremendous room for improvement, and believe that a high quality presentation layer can significantly extend the overall complexity that can be appropriately handled with web applications.


5    PROPOSAL

5.1    Summary

Barracuda intends to thoroughly address the web application problem domain and provide a vision for web-based presentation layer frameworks. This approach will place the Barracuda Presentation Framework at the forefront of current web-development approaches.

We will accomplished these objectives by:

  1. Relying on and improving best-of-breed object oriented design techniques
  2. Providing white-papers and extensive tutorials.
  3. Supplying lots of example code.
  4. Ensuring proper regression and unit testing.

These advantages should accelerate development, simplify maintenance, and decrease total cost of ownership by providing a common architecture across web applications. This in turn will help establish Barracuda as the de-facto standard for web-application architectures.

5.2    Proposed Project Schedule

Based on sound engineering methodologies, we see the Barracuda project progressing through a series of stages captured in the following outline:

  1. Discovery Stage - Discovery is the cornerstone of a successful project, providing the foundation for any useful framework. It can be broken into six distinct phases, each of which provide an important set of process control documents that capture the information needed to drive development. The resulting documents detail the development objectives, the solution architecture, the development plan, and a detailed project plan.

    The Discovery stage phases are:

    1. Scope - "How Big is Discovery"
    2. Requirements - "Define the Problem"
    3. Analysis - "Define the Functionality"
    4. Architecture - "Lay Out the Blueprint"
    5. Prototype - "Demonstrate the Solution"
    6. Confirmation - "Verify the Solution"

  2. Development Stage - Development is where the actual framework development occurs. In large, multi-faceted frameworks like Barracuda, we intend to provide deliverables incrementally, rather than in a single monolithic block. The benefits of this approach include more immediate developer feedback, faster course corrections, and a better overall framework.

    Process control in this stage revolves around change control procedures to accommodate evolving develop requirements.

    Development is divided into four phases:

    1. Engineering Design - "Document the Detailed Design"
    2. Incremental Development - "Build It"
    3. System Test - "Test It"
    4. Community Preview - "Feedback & Adjustment Loop"

  3. Release Stage - As the Barracuda framework approaches functional completion, we will enter a period of beta testing and quality assurance. During this time we will be actively working to "polish" the framework functionality, implement performance tuning, create developer documentation and tutorials, and then ultimately release the framework into production.

  4. Maintenance Stage - Once the Barracuda has been released, we will enter a maintenance mode aimed at improving the framework based on actual developer feedback. During this time, newly identified enhancements may start this whole process all over again as we move forward with the next round of development to ensure that Barracuda continues to meet developer needs and expectations.

This document represents the Scope Phase of the Discovery process. As we move forward, we will continue the Discovery process treating each subsystem of the Barracuda framework as its own "mini-project". This means developers can expect to see separate requirements, analysis, and design documentation for each of the core Barracuda subsystems:

  1. Forms Validation & Mapping Framework
  2. Model 2 Flow Control System
  3. Server-Side Event Model
  4. MVC Component Model
  5. MVC Component Library
  6. JavaScript Framework & Library

These subsystems are ranked loosely in terms of development priority, and we expect simultaneous development to be occurring where possible. At this point (Barracuda PR1), the first 3 phases have been completed and released for community review. We are now shifting design emphasis to the latter three phases. We hope to include these in beta release by the end of January.

5.3    Summary: Schedule Risk Management

In this section we have identified a number of risks that could negatively impact our planned development effort. We have also identified a number of management plans intended to mitigate these risks. It is important to note that mitigation strategies rarely eliminate identified risks or their negative impact. The goal of the mitigation strategy is to minimize the potential negative impact. It should also be noted that this early analysis of the risks facing this project is undoubtedly incomplete. There will be other risks that surface during the remainder of this project. Additionally, there will be the interaction of the identified risks.

Review of this risk assessment section drives us to conclude three fundamental recommendations:

  1. This development effort will be greatly benefited by a strict adherence to standard software development methodology. We need to stay focused on an up-front design and analysis phase for the project. Due to this projects level of complexity, inadequate investment in the analysis phase will inevitably cause significant impact on the projects cost and schedule. Insufficient analysis also has a high probability of undermining the projects objective of producing a product foundation for future development efforts.

  2. The large number of identified risks indicates that planning with detailed and conservative effort estimates is the only prudent management strategy. We are currently planning with high level and optimistic effort estimates. These estimates will invariably slip and it is likely that they will slip drastically.

  3. Project management and clear team communication are going to be critical to the success of this project. It will be critical to ensure that there are appropriate and adequate resources staffed in order to ensure that the risk management plans are executed.

For all the latest information on Barracuda, please refer to http://barracudamvc.org
Questions, comments, feedback? Let us know...