Application Factories - How Application-Aware Is Your IDE?

Ravi Kumar

We introduced the concept of application-specific metadata to capture the structure, evolution and logic of the application, and we also discussed Application Modules as simply a collection of application source artifacts accompanied by Application Factory Metadata.  In the previous article we started to discuss some examples of application-specific metadata. Now, let’s look at what we mean by application-specific metadata in more detail. And in that context let’s discuss the tools and facilities required to effectively capture and use metadata.

Application-Specific Metadata

Let’s begin by restating the intent of application-specific metadata. The intent is to capture application history. History pertains both to the application code as well as the collective intelligence the development team holds as to how to work with the application code.


The purpose of capturing metadata in the IDE is to allow the IDE to interpret it, become aware of the application it is working on and come alive with tooling capability specifically for that application. This is what we call transforming the IDE from the generic to the specific.

Now let’s look at a few common categories of metadata.


In general, an IDE works with any application using generic constructs such as a Java project, modeling project, plugin project, dynamic Web project, and the like.

Based on these generic constructs, the IDE lets the developer navigate the application artifacts typically using an explorer of one kind or another. An explorer presents a navigation paradigm which is meaningful to the generic project type it is dealing with.

However, the individual application instance has an intrinsic notion of grouping which almost always transcends the generic boundaries. For instance in most Web applications, a database table is wrapped by an Entity Class, which is referenced by a Data Access Object (DAO Class), which then is referenced by the container or the control layer, or both.  In turn, this is referenced by the presentation layer, which could be a page with some additional configuration information in a menu layer. If you start adding custom logic instead of simple CRUD-like functionality to this scenario, you will very quickly draw in knowledge of the domain or the business process.

What is needed is a means by which you can associate an application-specific construct and use that to navigate source artifacts. Such navigation still needs to be in the context of the Package Explorer and other tools we use so that we don’t lose any of the base capabilities.

To achieve this, metadata should provide dynamic application context and the IDE should be able to overlay those as filters over standard tools such as the Package Explorer. In Figure 1, you can see an illustration of how this might look in an IDE.

And of course, we would expect this classification to be completely dynamic and so the tool set needs to have the ability to do exactly that with features such as descriptive text based markup, resource linking, dynamic patterns, hierarchy of markup, dynamic layout, etc. Many of these aspects are captured in Figure 2.


In general, wizards and code generation tools are specific to a framework, library, domain or a project structure. With very few exceptions, they are not intended for the generation of application-specific code artifacts such as inserting a snippet of code, flipping a few configuration options, or creating one or more artifacts for a given application.

But that's exactly what one does when enhancing an application to add features, expand integrations or create additional components. There is generally a steep learning process involved in acquiring the knowledge to perform this task. The question to pose is 'can this intent and knowledge be captured and reused'. If it is possible, then a person who knows how to add additional database adapters can capture that, so any further integration can be done by someone else on the team, and doesn't rely on this one individual.

So, let's consider what it means to capture this. Let's start by listing a couple of core capabilities which are required in such a tool:

The metadata must have the ability to prompt the user for input otherwise any code generation is nearly meaningless.

The metadata must have the capability to modify the resource in the project directly.

The metadata must have an option to mine previous changes and extract changes and use them in code generation.

Such a facility is available as part of the producer tool set in the Application Factories feature set of JBuilder 2008. These aspects are captured in Figure 3. As you can see, this feature set uses scripts and templates to procedural code generation functionality.

In addition, aspects of user interaction and resource changes are known constructs in any IDE. Typically, IDEs prompt the user to choose artifacts in the workspace as input to create or modify other artifacts also in the workspace. Application Factories automate the creation of templates and scripts which provide such functionality. As an illustration, the example in Figure 4 shows the creation of a user interface which was itself created from a script and one or more templates.


We discussed organizational and procedural metadata thus far. Now let’s look at a few other types of metadata at random.

As part of code generation through the procedural metadata, the creator of the metadata is able to create either full working code or lay out bread-crumbs to follow and complete a desired function.

However, the creator can also overlay educative information in the procedural metadata. A consumer of such metadata will be automatically put through a ‘learn and resolve’ phase. This allows for learning and continuous adoption of the procedural metadata along-side the application itself. Another use of metadata is to preserve this information and present in an archeological context. Both of these are illustrated in Figure 5. 

An Application-First Development Model

Once we have the application code and the metadata, we have the right ingredients to create meaningful reusable software assets – meaningful and reusable in the sense that it avoids the ‘code over the wall’ syndrome by design. An Application Factory explorer should be able to mine the metadata and present meaningful information which is actionable in the IDE.

In conclusion, enterprise productivity is directly proportional to using higher-order reusable software assets and the team’s ability to leverage the collective intelligence on a given application. Enterprises can avoid constant relearning and re-inventing of the wheel by using and creating reusable software assets. In addition, by using this approach to development enterprises can leverage the team’s collective intelligence, and significantly cut developer’s time spent on application-specific learning.

For more information on Application Factories watch for upcoming announcements at and read about CodeGear’s JBuilder, JGear and 3rdRail IDEs.  We also invite you to join in discussions and share best practices with the more than 6 million developers doing Java, Eclipse, Rails, Windows, PHP and database development in our CodeGear’s Developer Network -

About Author:

Ravi Kumar is principal architect in the Java tools group at CodeGear and is responsible for the vision and architecture of CodeGear’s Eclipse-based JBuilder product line. He was the driving force behind the JBuilder ProjectAssist team system vision. He specializes in SOA, Web Services and Database tooling.

These days he is working on making the new paradigm of Application Factories a reality in future versions of CodeGear products.