1.4.2.1  XML Models and Meta-Models

The basis for JeeWiz modeling and meta-modeling is the simplest possible form of XML. In other words, JeeWiz uses XML models and XML meta-models. Other formats, or more complex XML formats such as Web Service definitions or UML/XMI, are converted into the simple XML form by additional transforms. This approach means that

• Standard XML tools can also be used to generate, validate and transform JeeWiz models and meta-models
• XML data, models and meta-models can all be processed by the JeeWiz engine. (In fact, JeeWiz meta-models are simply a form of JeeWiz model: they are read and processed the same way.) This means that
  • there is only one set of concepts to learn
  • all the power of JeeWiz can also be applied to data transforms as well as system generation
  • it is easy to generate additional models in patterns - most developers now understand the structure of XML.

In some situations, subsidiary models are required in addition to the main model. For example, the meta-modeling system reads in all the ancestor meta-models to be able to validate base meta-classes. JeeWiz provides a general-purpose, recursive mechanism to read in multiple models - even a tree of subsidiary models - and make them available during rendering.

JeeWiz models and meta-models can also incorporate Java implementation code. This is incorporated into the Java meta-classes, which are created at generate-time by deserialising the input XML model or meta-model. This means that Java/XML programmers can be easily trained to create meta-models.

At the meta-model level, Java is used to create

• Bespoke queries and views (standard queries and views are created by the meta-model generator)
• Model constraints (validation expressions)
• Property defaults
• Helper functions that aid the writing of generation scripts.

1.4.2.2  Meta-model Inheritance

JeeWiz allows model objects to be grouped into meta-models and then use model objects from different meta-models during generation. The JeeWiz structure can support arbitrary levels of meta-models, so this is a flexible, universal and structured approach to creating rich models. JeeWiz provides features to

• inherit across meta-models (meta-model inheritance)
• plug meta-models together at generate time in various configurations depending on the target system to be generated (pluggable meta-models)

The benefit of this approach is that

• complex domains can be broken down into smaller modules (the individual meta-models), making the whole more manageable
• we can build up higher-level concepts by adding more meta-models - this allows JeeWiz to address a range of language, platform, technology and business concepts with the same structure.

To see what we mean by this last point, let us look at the key concepts in the stack of meta-models used to build the standard J2EE application rendering:

	Java		Class, Interface, Method
	Business Object		Business Object, Entity, Session, Relation, Data-view (a view/transform of inbound or persisted data).
	Screen		Page, Wizard-Page, Event

At the level of screen meta-model, pages, wizard-pages and events are high-level concepts: they generate the program code to define and control lower objects - data-views, sessions, classes etc. High-level concepts are more powerful and easier to use for modelers, so this feature means that JeeWiz can incrementally build more and more powerful generation systems.

The ability to plug different stacks of meta-models together for different generations means that the same model can be used with different meta-model configurations (specification polymorphism). This is how we can build different technologies into enterprise Java systems from the same model - we plug together different meta-models with their attached renderings.

1.4.2.3  Rendering

JeeWiz 'renders' the input model into various outputs using the features described below. The rendering covers artifact creation and build coordination - both are necessary for automatic system generation.

1.4.2.4  Velocity

Text artifacts are generated using the Velocity system. Velocity uses a'boiler-plate' approach, which means that artifacts are generated from a template text file using the structure of the target file with property values from the models inserted by substitutions. Velocity has general-purpose logic control structures (if, else, foreach, macros) to further process the model. The ability to express general-purpose logic here is crucial to the whole meta-programming process: it is how the meta-programmer quickly encodes the actions that normally a programmer would do manually.

Another benefit of Velocity is its easy access to Java classes. All the functionality of Java is available to the programmer.

One alternative approach to generation might be to use a more general language like Python, Java or Javascript and write the required text to an output stream. However, using Velocity's boiler-plate approach makes renderings easier to understand for specialists and non-specialists alike. This is particularly relevant for XML generation, which is difficult to produce using other approaches.

To make it easier to build complex systems, JeeWiz has made a number of additions to the Velocity language. The most important of these are Controls and Methods, described below. In addition:

• There are over 200 helper methods, broadly assisting with access to the model objects, control of the Velocity process, string processing and other specialised processors that are better expressed in Java.
• The ExtraHelperMethods class, which can be used to add additional Java helper methods locally.
• The #divert() and #revert() directives which allow the current output stream to be diverted to a variable and then to revert back to the original output stream.
• More legible scripts by allowing additional tabs to lay out scripts by discarding leading tabs.
• The ability to use multiple trees of objects as the overall context, by reading additional specifications.

1.4.2.5  Ant

JeeWiz uses Ant as its native build facility. This controls both text artifact generation and also processors like compilers and Jar to create binary targets. JeeWiz integrates Ant's variable accesses so that values in the model or created by Velocity scripts can also be used.

Large-scale build facilities are also provided by JeeWiz, by running a 'manufacturing assembly' process, driven by the input model. This allows subcomponents to be assembled into components automatically.

1.4.2.6  Rendering Inheritance

The facilities that support meta-model inheritance are also used with all the rendering features described above, giving rendering inheritance.

This means that parts of the rendering can be overridden to create variants, giving us rendering polymorphism. This is used for example to

• Adapt naming conventions to local conditions by adding a 'customer' rendering layer
• Change the generated language from Java to another language
• Insert a different persistence mechanism, such as changing J2EE's persistence from the default EJB to JDO.
• Add specialised processing to the Ant build for a particular meta-class to support local requirements.

Because meta-models and their associated renderings can be developed and used as a unit, they need only be developed once. This is important to the economic viability of the system generation approach. High-cost or complex meta-models and renderings can be created once, as a capital investment; per-project or per-company changes will be significantly smaller and cheaper to implement.

Some MDA-style tools have the concept of 'cartridges', which are a compination of the models objects (compiled coded for the meta-model) with the rendering for the meta-classes. JeeWiz takes a more "object-oriented" approach by

• separating the meta-classes from the rendering. This allows to (a) reuse meta-models in different stacks (b) plug in equivalent meta-models, but with different behaviour
• allowing much finer-grained overriding of rendering without altering or repackaging the original rendering. This makes it easier to take upgrades of lower-level meta-models or their renderings.

1.4.2.7  Name Management

A very common requirement is to generate systems using local naming conventions, and conventions for file names and directory structures. JeeWiz has a special name management facility to support this, so that all generated names and directory structures can be adapted in minutes.

The same technique also applies to the layout of generated source code, so that the generated code can be created in the structure most natural to the current user. The standard renderings provided by JeeWiz use these features to lay out code and other artifacts to look natural.

1.4.2.8  Patterns

JeeWiz provides a simple but very powerful pattern facility. In JeeWiz, we use 'pattern' to mean a form of rendering that produces not output files, but rather more model information (i.e. more detail in the specification). This is done by using all the rendering features described here to create XML for the new model fragment. This approach means there is only one meta-programming environment to learn.

Patterns

• can be arbitrarily complex by incorporating logic in Velocity
• are recursive - an object created from a pattern can trigger further patterns
• override in exactly the same way as other aspects of rendering described above
• can generate code as part of the methods or classes it creates
• are all resolved in a single build, automatically - this avoids the cost and risk of manual intervention (as in the 'manually-changed PSM' approach of pure MDA), and ensures that the architect's intentions are not subverted
• can be decomposed into pipelines for complex patterns, and can also have included files to make it easier to override individual parts of a pattern.

The combined result of these features is that JeeWiz patterns can create very complicated, multi-tier systems from simple and incomplete models: the complexity and completeness is added by patterns.

An important aspect of patterns is that the generated objects can change their meaning (via specification polymorphism) depending on the configuration of meta-models used in the build: a 'page' created by a pattern will mean different things, and have a different generate-time Java meta-class, between a J2EE and a .NET build. Similarly, a single pattern that generates a simple class, like a value object or delegate, will create classes in Java or another language depending on the build configuration In other words, a pattern writer uses declarative meta-programming: he declares his intention in a few lines of code via a generic object, which is then specialised by the particular meta-model configuration and may render into many files and other objects, as dictated by the requirements of the target system.

There is no restriction on the type of XML that can be used or the complexity of the patterns generating it. This allows JeeWiz patterns to express the domain knowledge, which used to have to be inserted by hand - modeling or programming . In consequence, JeeWiz can build complex multi-tier systems in one automatically-run step.

1.4.2.9  JeeWiz 'Controls'

In describing Velocity, we mentioned that text substitutions and business logic control could come from the models (either main or subsidiary). However, there is another dimension to this: often, substitutions are driven by the configuration rather than the model. For example, the configuration may request a certain language or database and this needs to be reflected in the rendering.

JeeWiz 'controls' are provided to do this. They allow the meta-programmer to create Velocity scripts that are completely independent of the particular details of the target configuration. This applies to

• the target language - there is a standard controls for Java
• the logging environment - a console output logging control is standard, but log4j and bespoke logging controls are easy to implement
• logical datatypes - the datatype controls handle the mapping of a modeled type (a logical type) to a real type (e.g. the 'int' logical datatype can turn into 'int/Integer' in Java) and the properties of the datatype. A set of controls for Java is provided as standard
• user interface controls, which map language types to a representation on a user interface - as one or more UI controls in the target user interface technology - plus the logic to map information between the two forms. For example, there are two types date control: one displays a text box for a DD/MM/YYYY format; the other displays discrete controls for the day, month and year. The choice between these, and whether they interface to .NET or Struts, is determined by the configuration, not the meta-program
• database controls, which map language types (e.g. Date) to the database representation (e.g. long).

As well as taking much of the detail out of the meta-programs, JeeWiz controls also

• future-proof meta-programs: they can be used in environments or languages not envisioned when the meta-programs were written
• make it easy to create minor variations for local needs, such as storing booleans data as '1' or '0' characters on the database.

1.4.2.10  Velocity Methods

JeeWiz has enhanced Velocity syntax in a number of ways, the most important being the addition of methods.

Methods can be defined on JeeWiz model objects or controls: this means that controls are also fundamentally object-oriented.

Methods take part in 'Rendering Inheritance' described above. A given object gets its complete complement of methods by aggregating across the various layers of technology in a system, and also across the various object types. Methods can be overridden and new methods created as layers are added. This feature makes it easier to plug together different layers of generation technology.

Velocity methods complement the available Java methods: Velocity methods are tried first, and then Java methods are tried. This means that a programmer can code methods where it is easiest - in Java as part of a meta-model, or in Velocity.

Methods can also operate as normal language methods - just returning a value - or as Velocity script, sending text to the target file.

1.4.3.1  Simple Generation Systems

A simple generation system is the first-step approach to advanced 'code generation': take a 'model' and feed that through a template-driven processor. For example, some systems propose XML as the model, XSL-T for the templates and an XSL-T engine as the template-driven processor.

For particular areas, simple generation systems offer a data-driven way of creating additional parts of a system. If the data can to drive the generation can be largely deduced from other artifacts (e.g. from JavaDocs), then the generation system can produce additional artifacts at minimal cost.

The disadvantage of simple generation systems is that they don't go very far - it is difficult to achieve high levels of automation. Typically

• representing patterns (design-level transforms) is not possible,
• re-use of templates is difficult or impossible, so variation of a template is done by copying
• the coordination of the build process is done by an external engine, which does not coordinate with the generation process.

The result is a very fragile system: even minor changes become very costly and error-prone.

1.4.3.2  'Pure' Model-Driven Architecture (MDA)

MDA is the Object Management Group's (OMG's) vision of a higher-level approach to building systems that makes design models a central part of the development and maintenance process. This is in contrast to the typical attitude of software engineers: "We use models to communicate with the business ... and then forget them when real development starts."

However, 'pure' MDA - the set of OMG standards for describing design transformations - has a narrower goal: transforming designs from a more abstract ('Platform Independent') model to a more concrete ('Platform Specific') model. This is a necessary first step in automating some of the design process. Currently there are some issues with this process:

• XMI is not practical as an interchange standard - there are too many variations;
• the insistence on UML (or another MOF-based language) as the design language;
• the delay in defining the standards covering the generation process, which is where the real value is added.

The target of JeeWiz is wider: generating almost all the development artifacts - not just the detailed design - from the model. This includes mechanisms for specifying patterns that generate large quantities of code, creating configuration and build scripts, and controlling large complicated builds automatically. The point is that these mechanisms and the MDA model-model transformations can be implemented by the same tool features. As we will see later, this allows us to build arbitrarily high-level models with controlled mappings to lower level models or artifacts, that can be easily customised for local architectures and standards.

1.4.3.3  Domain-Specific Languages (DSLs)

DSLs create higher-level programming 'languages', typically using visual construction paradigms. These languages are used to create models which will typically have a textual representation in, or a trivial generation to, XML. The idea that this can be mapped down to lower-level implementation languages by templates.

DSL-based tools provide the visual construction paradigm and means of creating a range of 'languages'. In the UML world, UML is a base modeling language, which can be specialised by creating domain- or platform-specific profiles. In most cases, the template facilities are restricted to simple generation systems, as described above.

JeeWiz and DSL-based tools are complementary; a DSL-based tool provides the user interface portion; JeeWiz can provide a more sophisticated back-end. The interface between the two is the textual representation of the model. JeeWiz uses XML dialects for its models that are isomorphic to the XML specifications from DSL tools; in other words, a JeeWiz model can be automatically transformed to a DSL specification, or vice versa.

JeeWiz can add features to - the ability to construct DSL 'languages' from a more general-purpose (and powerful) meta-model - a more powerful generation environment for the code-generation aspect - the integration of the code generation with the other aspects of the build - configuration and build generation, build staging etc.