This chapter is from the book
This chapter is from the book
This chapter is from the book
Active Code Generators
Active code generators have the power to deliver extremely high productivity gains. Unlike passive generators, the active code generator does not rely upon the services of a software engineer to modify the code generated. Instead, the active code generator is able to inject code directly into the application as and when needed.
Active code generators typically comprise three different parts: metadata, a pattern template, and the code generator itself:
-
Metadata.
Metadata is data that describes other data, thereby giving data shape and form. Metadata is available from many sources, including databases, XML schemas, and UML models.
-
Pattern template.
The pattern template is used by the code generator to render the data described by the metadata in a new form.
-
Code generator.
The code generator binds the metadata with the pattern template to produce the desired output. The code generator can also embody code generation rules that further define the form of the generated code.
Figure 6-1 illustrates how metadata, templates, and code generator combine to produce source code.
)
Figure 6-1 Elements of active code generation.
Benefits of Active Code Generation
The benefits of code generation are best conveyed by example. One such example comes from a project I was involved with in which a developer on the team was able to apply an active code generator very successfully.
A requirement of the system was to transmit information across a system boundary via a messaging service to the client's enterprise information system (EIS). The payload of the message was an XML document, and the project plan called for the development of a suitable XML schema to define the contents of the message for validation purposes.
The customer stipulated that the structure of the XML document must be driven by the schema of the database being used as a staging area for holding requests ready for sending. The physical design of the database was not under the control of the project but was instead designed and maintained by the customer's own enterprise data group.
One of the first tasks on the project plan called for the specification of the XML schema for the messages, using the design of the customer-supplied database as a model. On the surface, this appeared to be one of those mundane tasks common to enterprise development projects. However, instead of taking the traditional approach and handcrafting a first cut of the XML schema, the developer charged with the task opted to build a code generator.
The code generator was written in Java and used a JDBC connection to query the metadata held in the database. The metadata from the database provided all the information necessary from which to generate a schema.
The code generation approach was successful for the following reasons:
-
Increased speed.
The time taken to write the code generator and produce the first version of the XML schema was less than the time estimated to produce the XML schema by hand.
-
Improved accuracy.
The code generator removed the opportunity for human error, which is a serious flaw of the handcrafting approach. Once the code generator had been adequately tested, a repeatable, accurate result was possible each time the generator was run.
-
Better agility.
The underlying database was prone to change. Changes in the database design were easily accommodated by simply rerunning the code generator. By incorporating the code generator into the project's daily build process, it was possible to guarantee that database and XML schema remained in sync.
This ability to rerun the code generator to produce a new XML schema at virtually no cost made the project highly agile. The customer's database was covered contractually by change-control procedures. Thus, any change by the customer to the database that resulted in an impact on the project team was a chargeable piece of work. The database did indeed change throughout the life of the project, but the code generator made it possible to turn these changes around with minimal cost to the customer and a high degree of accuracy. For this reason, the project team established a reputation with the customer as a group capable of working very productively and delivering changes quickly.
Active Code Generators and Boilerplate Code
The ability of active code generators to turn around change very quickly and at low cost makes them a powerful tool for rapid development. The more of an application's code that can be generated, the less code has to be written by the development team. In this way, the use of active code generators increases the productivity of the language, thereby making the team agile. We code only what is needed, and the code generator and the compiler do the rest
Active code generators are especially well suited to J2EE projects, as they offer a solution to the large amounts of boilerplate code that must be written when developing a J2EE application. Boilerplate code is code that has to be implemented for software to comply with the demands of a particular framework. This type of code is extraneous from a business perspective because it implements no business functionality and exists solely for the purposes of the hosting platform.
For the J2EE platform, one of the worst offenders in this regard is the Enterprise JavaBean (EJB). An enterprise bean is a heavyweight component that requires a considerable amount of framework-dependent code to be written in order to be able to interact with the EJB container.
Some of the additional program artifacts associated with EJB technology include the following:
-
Configuration information.
J2EE applications require extensive configuration in order to operate. For an enterprise bean, it is necessary to produce both the standard configuration information for the EJB deployment descriptor and vendor-specific deployment information for the target J2EE application server.
-
Required interfaces.
Each enterprise bean deployed into the container must provide home and remote interfaces. The list grows if local interfaces are also to be supported on the enterprise bean.
-
Design pattern artifacts.
Though not strictly classed as boilerplate code, the architecture of a system employing EJB technology relies upon the application of best-practice J2EE design patterns. The use of patterns such as Transfer Object and Business Delegate results in standard classes being developed to support the enterprise bean in its environment. Although these additional classes are not mandated by the J2EE platform, good architectural design necessitates their development.
These additional program artifacts make for a code-intensive development process that is not conducive to the needs of rapid development. Thankfully, active code generation addresses this issue by generating much of the boilerplate code on our behalf.
A programming paradigm has been conceived that seeks to employ active code generation techniques to overcome the problem of developing heavyweight components for code-intensive platforms like J2EE. This paradigm is known as attribute-oriented programming and is discussed next.