Enterprise Level Application Framework
A Case for Using A6fw

The selection of a framework for any project is a critical decision that affects many areas, not limited to: functionality, flexibility, maintainability, deployability, and development speed.  The effects of the decision currently before you can make or break a project.  The creators of A6fw believe that the selection of A6fw for a new project, or a project rewrite, is the best choice you can make.  The rest of this document presents the case for the utilization of A6fw.

Project Success Factors

Some of the major factors for selecting A6fw are:

  • Speed of development
  • Flexibility for End-Users and Functional Analysts
  • Future Functional needs and Technology Friendly
  • Quality of Deliverable
  • Product-izable
  • Other Risk Reduction Factors

Background

As a data point in selecting an approach to creating a new system, a Bake-off was conducted to compare the resulting code base and efficiency of development. A third party selected a use case with the only constraint that all parties needed to agree that they thought that they could fully develop it in a day.  The selected use case included three windows/pages, and reflected a fully functional sub-set of a real use case from a real new project.

Two frameworks/organizations participated in the Bake-off: A6fw and a framework based on Struts and Hibernate with a state machine to produce smart wizards with built in action level security (which for the purposes of this document we’ll call: SHwiz).

Speed of Development

The Bake-off demonstrated that the approach to managing a complex project would have a significant impact on the pace of deliverables.  A6fw was explicitly created, and has explicitly evolved, to handle a very complex project (Property Tax Management).

The results of the Bake-off were:

  • Using A6fw the use-case was built, functionally complete, in 3 hours;
  • Using SHwiz the initial simple search page was mostly completed in 6.5 hours.  (For comparison, the initial simple search page was built, functionally complete, with A6fw within the first 15 minutes of the Bake-off)

Many aspects of A6fw were added to facilitate speed of development.  A summary of some of these are:

  • Declarative User Interface [1]
  • Type-Safe attribute references [2]
  • Automatic externalization of all strings [3]
  • Automatic and consistent component selection (including compound components: Date/Year Ranges, and Zoom-outs for foreign key object selection via complex queries) [4]
  • Support for Editable Tables has shown to reduce the overall number of pages/screens actually needed.
  • Automatic action and field level security [5]
  • The entire infrastructure for the base line window types (query/result, menu, and view/editor) with their supporting behavior is already coded and tested.
  • Generation of window templates for business objects: query/result, and view/editor [6]
  • Generation of Business and supporting classes from external specification [7]
  • Generation of initial string externalization. [8]
  • Automatic input validation with consistent error reporting [9]
  • Automatic redeployment of testing DB when DB schema is changed
  • Documentation driven with automatic notification to developers of required behavior thru documentation/behavior injection [10]
  • Unit testing framework [11]
  • Advanced Components are supported without application developer concern (tables, spinners, splitters, calendars, ...) [12]
  • Supports rich Java Swing Client and Rich Web Client with no content code changes.  [13]
  • Transactional support for complex object/graph creation and update is built-in and hidden from the content developer [14]
  • To support testing (functional, regression, & unit) and DB schema changes, a Data loader and un-loader already exists and is tested.
  • Adding additional fields to the query criteria does not add complexity. [15]
  • Quick window/screen prototyping is supported with Proposed Fields [16]
  • Developer utilization of the Business Object graph is completely seamless (all related objects are lazy loaded as needed), no explicit pre-fetch is required.[17]
  • Application developers need not bother with explicit knowledge of Data Base table and columns names.  But may focus on the Application’s business object and attribute names.

Flexibility for End-Users and Functional Analysts

The fundamental question in system design is:

  1. Is the problem space well known and constrained?
  2. Is the problem space expansive, dynamic, and only partially known?

It is our opinion that there are at least some tasks that fall under number 2 above in all complex projects (such as Property Tax Management).  In this sense the approach taken in these projects must be empowering, not constraining.  To this end, the following features were built into A6fw:

  • Business Logic/Rules can be coded in four levels: hard-coded, data-driven, dynamically loaded analyst language, or external.  Currently A6fw has built in support for the first three.
  • By embracing a fully integrated, powerful multi-window centric interface; neither the Functional Analysts design options, nor the End-User’s operational options are constrained.
  • At many places and times it has been requested to support Editable Tables to facilitate a better End-User experience.  A6fw supports Editable Tables.
  • Since the number of fields on a window, is unrelated to window behavior complexity, adding more fields is a purely business/functional decision.
  • To reduce User Interface clutter, context sensitive menus are supported.
  • Complex state-driven multi-tab and/or multi-page wizards are already currently supported.

Future Functional needs and Technology Friendly

The popularity of certain technologies (such as JSP/Struts) is already waning.  Newer technologies are gaining more and more favor (e.g. JSF and other component frameworks, AJAX, Flash, etc...).  Given the aggressive deadlines of most projects, and the projected lifespan of the resulting systems, it would be prudent to select a framework that is friendly to future functional needs and/or technology trends.  A6fw addresses these goals with the following features:

  • Due to the declarative nature of A6fw it inherently has the ability to change many of the underlying implementation strategies without application code changes.
  • A6fw’s Service Oriented Approach facilitates easily exposing services to, and utilizing services of; other applications as needed.
  • Supports rich Java Swing Client or Rich Web Client with no content code changes. [18]
  • Able to embrace AJAX without any content code change. [19]
  • Can work without JavaScript. [20]
  • New UI components and behavior can be automatically introduced by the framework [21]
  • Notification framework for changes to persisted data to facilitate event driven integration needs (e.g. Workflow) [22]
  • Infrastructure to support user defined search windows. [23]
  • Workflow support for window selection with data injection. [24]
  • UI behavior infrastructure independent of UI presentation. [25]
  • Various levels of ADA support are possible. [26]

Quality of Deliverable

We believe a good framework should increase the quality of the deliverable by providing consistency across the developed application and includes a rich end-user experience which is backed with a thorough set of regression tests. A6fw supports these goals with the following features:

  • Automatic and consistent component selection (including compound components: Date/Year Ranges, and Zoom-outs for foreign key object selection via complex queries) [27]
  • Automatic and consistent action and field level security [27]
  • Automatic input validation with consistent error reporting [27]
  • Consistent approach to Transactional support built-in [27]
  • Base line window types for: query/result, menu, and view/editor; result in consistent look & feel
  • Unit testing framework
  • Functional testing framework [28]
  • Advanced Web UI features (e.g. Accelerator Keys (Hot Keys), Filtering Combo Box, and UI table/grid: column width adjustability, column order adjustability, ...)
  • Support for wild card search criteria (*, <, >, !). [29]
  • Handles user font size changes (without damaging the presentation). [30]

Product-izable

Many products for vertical markets start as one-off custom projects.  Creating a product is more difficult then producing a one-off custom project.  The conversion from a one-off custom project to a product for a vertical market quite often involves quite a bit of re-coding.  A6fw was built to produce a product without loosing sight of the speed of development that happens on one-off custom projects. To that end, A6fw supports the following features:

  • Built in scalability options through modular application components [31]
  • A6fw’s Service Oriented Approach facilitates easily exposing services to, and utilizing services of; other applications in a pluggable way
  • Supports rich Java Swing Client or Rich Web Client with no content code changes. [32]
  • Not dependant on any specific application server. [33]
  • Automatic externalization of all strings [34]
  • The already existing data loader and un-loaders can be used for initial conversion of the legacy data, ongoing imports & exports, and evolution of the database schema.
  • Customer defined rules infrastructure has been implemented.  These rules are written in a procedural simplified language with full access to the business objects and are dynamically loaded at runtime.
  • UI behavior infrastructure independent of GUI. [35]
  • Multiple Web Browser support (e.g. Internet Explorer, Firefox, etc...)
  • Pluggable logging framework. [36]

Other Risk Reduction Factors

In addition to the major goals outlined above, other risk reduction factors that A6fw supports for a complex project are:

  • Immediately available framework developers.
  • Application developers can start immediately [37]
  • A System/Batch processing infrastructure with scheduled execution has already been implemented and tested.
  • Year/Date effectivity support for no-overlap, no-gap support has already been implemented and tested. [38]
  • Authentication infrastructure has already been built and tested. [39]
  • Administrative Windows have already been implemented and tested (e.g. security, code maintenance, externalization, etc...).
  • Full support for: notes, Year/Date effectivity, and lightweight audit; has already been implemented and tested.
  • The abstraction levels (declarative nature, code generation, implementation factories) provide for good separation of dependencies, thus facilitating ease of maintenance.

Arguments against A6fw and Rebuttal

Some developers, after an initial look at A6fw, have leveled three specific arguments against it: Standards, Complexity, and lack of distinct architectural layers. When mentioning standards they were implying that JSP/Struts is a standard and that Millstone/XSLT/Component Graph is not.  It has also been repeatedly expressed that A6fw is simply too complicated for the average Java developer.

Any framework built to maximize development efficiency in building any specific project will be unique to that project. Therefore, though it may use popular point-technologies it will end up, by definition, proprietary.

Regarding Standards; JSP is a SUN standard, Struts is a very popular point technology from Apache.  Neither is an official standard from any national or international standards body.  JSF is SUN’s standard Component Graph implementation.  In the past when project managers were asked why they did not embrace JSF, one of two answers were given: JSF was too immature, or there is a lack of available programmers.  A lack of available programmers is basically a simple statement that the technology is not popular enough yet.  Regarding popularity, the current industry trend is all about Web 2.0 (AJAX enabled Rich Web UIs, e.g. Web mail clients, Google Maps, etc...). [40]  In three to five years, Web 1.0 applications will be antiquated and uncompetitive with newer Web 2.0 versions.

Regarding Complexity; ASIX has had 13 developers working on and using A6fw.  Four of these developers had no difficulty understanding the complete framework and contributed to its major evolution.  Another five developers, in our opinion, would not have had any difficulty understanding the complete framework and made contributions while they were with us.  An additional two developers made significant contributions to specific areas.  These developers were working on the framework; much less skill is required to simply use it.  We believe that productive application/content developers could be hired directly from the pool of college CS majors.

Regarding lack of distinct architectural layers; the development focus on the UI might imply that all the code is intertwined within the user interface code.  However, the reality is:

  • The UI definition is independent from the UI expression,
  • The UI behavior (reactors) is independent from the UI components,
  • The UI window controller is independent from the UI behavior,
  • The application services are independent from the UI window controllers,
  • The Business Objects are independent from the application services and the business rules,
  • The Persistence Proxy is independent from the Business Objects.

From the above we hope that it is clear that any contention that the code is intertwined at any level, much less the UI, is simply not factual.

Arguments against Build from Scratch Framework

A6fw has evolved due to repeated product/project direction changes.  This application instability generated special and unique pressures on the development team.  The result of these pressures tended to push coded features from the shifting application level into the framework.

Producing a powerful framework, such as A6fw, from scratch for any single project, would be hard to justify from a ROI (Return On Investment) perspective.  However, without the technical options and constraints provided by a framework, there are many areas of an application’s development, which will need to be managed.  The more managed areas there are, the more disciplined the development team needs to be, and the better management must be.  These are difficult requirements to achieve, and if not achieved just right, the damage to the development process can be significant.

If you do choose to create a framework, an important issue is that:

    Application developers can NOT start until, at least the initial, Framework APIs are defined and coded.

If you do not choose to create a framework, but are starting (or currently on) a project that is based on JSP, Struts, & Hibernate; some of the issues that need to be kept in mind are:

  • Since the windows/pages are coded non-declaratively (i.e. by hand) – the consistency of the application must be managed, it is not automatic.
  • Due to the interpreted nature of directly coding the Hibernate Query Language for selection criteria, and using JSPs (Java Server Pages); errors can result that are only generated at run-time, and are therefore difficult to debug.
  • Developers must maintain an explicit knowledge of BOTH the Data Base table and column names AND the Application business object and attribute names. In SHwiz there were 3 places that duplicate Data Base knowledge [41] is required, and 9 places that duplicate Application knowledge [42] is required.
  • Non type-safe business objects and attribute name redundancies. [43]
  • The complexity of a powerful, vibrant, and ADA compliant html page is difficult to code and manage when the html page is hand coded statically. [44]

Summary

A major goal for the selection of a framework is:

    Meeting the Deliverable Timeline

Obviously our opinion is that overall project success and meeting the deliverable timeline is best achieved with A6fw.

By extrapolating the numbers from the Bake-off, the resulting ratios are at least 26 to 1 in favor of A6fw over SHwiz (or no framework). This implies that something complex enough to take a person day for A6fw would take a person month with Shwiz (or no framework).

If you assume a complex application might have 500 screens, then the fundamental question is:

    Do you want development to take 500 person days or 500 person months?

End Notes:

    [1] Declarative User Interface:
      By automating the generation of html, many simple consistency and typographic errors are eliminated.  It also allows the developer to focus on the actual application content and behavior without worrying about the details of component selection and html syntax.
    [2] Type-Safe attribute references:
      One of the largest problems in development is known as magic-strings.  The strings are not just display text, but have significance to the application.  When the same string is used in multiple locations the probability for errors is dramatic.  A6fw has explicit support to minimize the use of magic-strings.  The Type-Safe attribute references are a prime example of this.
    [3] Automatic externalization of all strings:
      No additional code or typing needs to be done to request externalization of all labels, Tabs, menus, buttons, ...
    [4] Automatic and consistent component selection:
      This means that the developer does not need to code or be concerned with particular component associated with a particular business object attribute. This forces a consistency in the application that can be overridden if necessary, but is automatic normally.
    [5] Automatic action and field level security:
      No additional code or typing needs to be done to weave in security.
    [6] Generation of window templates for business objects:
      Initial skeletons for all windows can be generated.
    [7] Generation of Business and supporting classes:
      Hand coding of these is extremely tedious, error prone, and susceptible to inconsistency.
    [8] Generation of initial string externalization:
      The supporting files and initial guess for English are automatically generated for the externalization infrastructure.
    [9] Automatic input validation with consistent error reporting:
      Code for support (catching and displaying) of User input errors exists in the framework, and is applied in an automatic and consistent basis.
    [10] Documentation driven behavior injection:
      This allows consistency and control of evolving business rules. Once a business rule is encoded it is automatically appropriately applied without additional developer interaction.  Should the rule definition be changed, the code is changed to force the developer to review and update it.
    [11] Unit testing framework:
      The current unit testing framework supports both client side and server side unit testing.
    [12] Advanced Components support:
      The combination of the advanced tables, splitters, page resizing, and font size adjustability, means that the customer requirements to minimize horizontal scrolling are under the customer’s control.  This obviously removes it from developer concern.
    [13] Java Swing Client and Rich Web Client:
      The use of the Java Swing Client (or more specifically, not using the Web/EJB container) has been observed to dramatic shortening the development lifecycle: code-validate-debug-code-validate-...
    [14] Transactional support for complex object/graph creation and update:
      Any data that is reachable (via the object graph) from the currently viewing object is automatically incorporated in the current transaction if referenced.
    [15] Adding additional fields to the query criteria:
      Since the search criteria is automatically created by joining all the individual fields changed, no additional work is required of the developer by simply adding additional fields.  This means that very complex query screens can be created with little or no work for the developer.
    [16] Window/screen prototyping and Proposed Fields:
      If during rapid prototyping it is determined that an additional attribute is called for, then instead of taking the time to add it to the business object definition, it can be added just to the screen as a  Proposed Field.  If this prototyping is occurring with an analyst and/or the customer, this keeps the flow going.
    [17] Seamless Developer utilization of the Business Object graph:
      Any data that is reachable (via the object graph) from the currently viewing object is automatically retrieved as needed.
    [18] Java Swing Client and Rich Web Client:
      There are currently no customer specified requirements for Java Swing Client.  However, there are two obvious places were a Java Swing Client may be needed or desirable: Heads down data entry (e.g. check entry) and fully disconnected operation (e.g. In-the-field Tablets for Assessment data gathering).
    [19] Able to embrace AJAX:
      In addition to improving the End-User’s experience, this would allow for common Java-based validation code to appear to be applied immediately without a heavy-weight (full page submit) round trip to the server.
    [20] Can work without JavaScript:
      With the actual generation of the HTML controlled by XSLT (an XML Transforming language) a UI design could be chosen that does not leverage JavaScript.
    [21] New UI components and behavior can be automatically introduced:
      Since the component and its behavior is selected and instantiated by the UI factory, should new data indicate the need for a new component, the factory would be enhanced to provide it.  No Application content code would need to be changed.
    [22] Notification framework for changes to persisted data:
      Listeners may be registered on any business object type.  These listeners are notified of all inserts, deletes, and updates.
    [23] User defined search windows:
      It was planned for Reporting, that the query criteria, result set definition, and predefined search values for any particular Report could be saved.  In support of this, the ability to have customized user defined search windows is relatively easy, and the majority of the infrastructure has already been coded and tested.
    [24] Workflow support:
      Window selection can be accomplished by Business Object name and context (view/edit, search) with the supporting Service session having values preset.  It was presumed that the Business Object Name and the preset values would come from the data attached to a Workflow Event/Task.
    [25] UI behavior independent of presentation:
      The UI is rendered (presentation) from the declarative UI definition (via factories), but the behavior is coded as reactions to UI events.  These reactions, and the code supporting them, are independent of the presentation (Swing / Web) utilized.
    [26] Various levels of ADA support are possible:
      With the actual generation of the HTML controlled by XSLT (an XML Transforming language) the actual HTML (and hence page design) can be tailored to optimal ADA support of different forms of physical challenges.  For the Blind: a straight linear page, with no inner scroll zones and No JavaScript.  For someone with sight but limited hand mobility: a rich UI with lots of JavaScript to enhance field selection.
    [27] Consistency:
      Application inconsistency or unpredictability is often perceived as shoddy workmanship.  These problems also hamper training and maintainability.  Since A6fw automatically controls almost all of the user experience, these problems are minimized.
    [28] Functional testing framework:
      A complete Functional testing framework exists to rapidly facilitate end-to-end regression testing.
    [29] Wild card search criteria:
      Infrastructure already has been coded and tested that supports the complexity of search criteria options that our current customers have demonstrated a need for.
    [30] User font size changes:
      While this could be considered an ADA requirement, it is simply common courtesy and industry practice to allow this capability for all those people with aging eyes.
    [31] Built in scalability options:
      By providing maximum flexibility in deployment options (from single box to large distributed clustering environments), A6fw fits any and all customer sizes.
    [32] Java Swing Client and Rich Web Client:
      Some customers may opt for a rich Swing Client or combination of rich Web Client and Swing Client instead of a pure rich Web Client expression. One place that a customer may choose a Java Swing Client would be for heads down data entry (e.g. check entry).
    [33] No application server dependencies:
      Assuming a Web UI is desired, a customer could choose to use WebLogic, WebShere, Tomcat, Jetty, or any other application container, the A6fw framework currently supports this freedom.
    [34] Automatic externalization of all strings:
      Different customers require that the application embrace their naming terminology.  In addition, multi-lingual support is allowed and expected.
    [35] UI behavior infrastructure independent of GUI:
      A customer may choose to express the GUI in a point-technology different from what is already supported by A6fw. A new point-technology could be added with out any changes to the content/application code. The whole look and feel of the application can be dramatically changed without any change to the content/application code.
    [36] Pluggable logging framework:
      Different customers may have different logging requirements (e.g.  local, distributed, centralized). The A6fw framework supports this.
    [37] Application developers can start immediately:
      Since the APIs (and the code that implements them) that the application/content developers will need to start, already exist, there is no delay to writing the actual application other than a very short training session.
    [38] Year/Date effectivity support:
      Support for effectivity is built into the framework.
    [39] Authentication infrastructure:
      The A6fw already assumes that End User authentication data is potentially externalizable.  Connecting to a 3rd party authentication system will present no hurdles.
    [40] AJAX article:
      http://www.infoworld.com/pdf/special_report/2005/42SRajax.pdf
    [41] Duplicate Data Base knowledge:
      SQL Table creation, SQL Data Loading, Hibernate Mappings
    [42] Duplicate Application knowledge in SHwiz:
      Hibernate Mappings, DTO: Value Objects, Search: Value Objects, Custom Queries, Search Queries, JSP attribute references, DTO: Value Objects conversion to/from Business Objects, Field Enablement for Application Components, Security References
    [43] Non type-safe redundancies:
      In SHwiz the use of magic strings is rampant, and would seem to be endemic to a JSP, Struts, & Hibernate project with no framework.  There were 3 places that duplicate Data Base knowledge and 9 places that duplicate Application knowledge.
    [44] Static html page definition:
      Without JavaScript support for adjustable table column order & widths, and inner scroll size coordination with page size, there is a conflict between showing all the important customer data, and their desire to minimize horizontal scrolling.  This conflict can NOT simply be wished away.