In order to do this JAG uses a generation template and produces an application file, which may be re-used at a later stage to regenerate the J2EE application (following changes to the system design).

The rest of this page describes the above concepts in greater detail:

System design
The initial phase of realising a J2EE project is the design phase; a process which sees the distillation of system knowledge through a high-level abstraction of functional requirements into a concrete model of the software components that will be used to build the system. Years of practical experience of commercial project management within Finalist IT Group have shown us that the recurring 'bottom line' issuing from the design phase most often takes the form of a database model and/or an object model.

These products issuing from the design phase are the starting points for generating a J2EE project with JAG.

Database model
JAG can also work from the basis of an existing database; reading in the information contained within the tables, columns and constraints (primary- and foreign-key) to produce a corresponding Enterprise Java Beans model of the system to be produced.

Object model
Using existing UML-modelling tools such as ArgoUML or PoseidonUML 3.x that support the XMI 1.2 standard (XML Metadata Interchange) for exporting UML documents, you can graphically model the system you intend to build. Once you have designed your application, you can import the UML design into JAG and use this as the basis upon which to generate a working J2EE project.
J2EE development couldn't be much simpler!

Application files
The 'application file' is JAG's representation of your project; an XML document that contains all the information JAG needs to generate your project (following the rules laid down in whichever code generation template you choose). Once you have successfully generated your J2EE project, it is possible at a later stage to make changes to the system design and use JAG to update the project with those changes. You can achieve this by reloading the application file for your project into JAG, making the desired changes in the graphical user interface, and then regenerating the project 'on top of' the existing project.

Code generation templates
Code generation templates are a major key to JAG's future extendibility. A generation template is in fact a directory that contains a collection of files, both templates and non-templates. Non-template files are copied as-is into the generated project, following the directory structure within the template directory. The template files themselves are Velocity templates - Velocity is an open-source template engine that JAG uses to dynamically create files within the generated project, based upon information from the application file.

The coupling of Velocity templates with the JAG application file makes for template files that are impressively simple to write and yet deceptively expressive. For example, here is an abridged version of a JAG template file that creates Java source code files for session façade beans (the special template directives have been highlighted in blue):

The code generation template defines the kind of project that is generated: for example one template can generate a project using EJB1.0-compliant beans, and another template can generate EJB2.0-compliant beans. The template supplied with JAG in the initial release creates projects conformant to the J2EE architecture that we have developed within Finalist IT Group as a result of years of real-world experience on commercial projects. The feature points of this architecture are:

• Apache Ant for building the project
• EJB2.0 container-managed persistence and relations
• J2EE 'BluePrint' patterns such as Session Façade, Fast Lane Reader and Value Objects
• "Clean" JSPs within a Struts 1.1 web tier with declarative client- and server-side user validations
• XDoclet for generating EJB Java sources, application server configuration files and Struts configuration files
• JUnit unit testing framework
• Application server independence with support for both JBoss and Weblogic

JAG-generated applications
The architecture and content of the applications generated by JAG depend entirely upon the generation template that was used. An automatically-generated application will by definition be relatively limited in scope; it is intended to serve as the basis for further development within the project. Such applications can nevertheless achieve two important goals.

Firstly, without any further configuration the generated application should serve as a showcase for the basic data manipulation and navigation functions within your project. These data manipulation functions typically comprise the so-called CRUD (Create, Retrieve, Update and Delete) functionality.

Secondly, the application architecture should be conceived in such a way as to anticipate further development - it should be extendable.