Create powerful custom tools quickly with Rational Software Architect Version 7.0

Introduction to the Transformation Authoring feature

Learn how you can use IBM Rational Software Architect, Version 7.0, to build your own, customized tools to solve the problems that matter the most for your software projects. This article introduces a new Transformation Authoring feature that enables you to build development tools with a graphical interface and standards-based templates.

Share:

Robert Peterson (rrpeters@us.ibm.com), WebSphere Enablement, Austin, TX, EMC

Author photoRobert R. Peterson is part of the Enablement Team under IBM Software Services for WebSphere. He travels the world implementing strategic proof of concept projects for future IBM software systems. He has published numerous technical books and papers, is a frequent conference speaker, and has filed several US Patents for enterprise systems. You can visit his website here.


developerWorks Contributing author
        level

09 January 2007

Also available in Chinese Russian

The world of a software developer or architect is a complex one, where you often need to integrate different technologies that have never been combined before. With the overwhelming permutations of emerging and legacy technologies, even the best out-of-the-box tools for enterprise development can help only to a certain extent.

IBM® Rational® Software Architect 7.0 includes a new feature called Transformation Authoring that allows you to create custom tools without any knowledge of Eclipse frameworks or the need for custom coding. It uses graphical tooling and templates that use simple XPath syntax. (See Resources for information on XPath, the XML Path language.) This article explains the business case for this technology, describes how the Transformation Authoring feature works, and gives a step-by-step example that creates a simple tool for database access.

Business benefits of Transformation Authoring

The Rational Software Architect Transformation Authoring feature provides a way to build custom tools that are relevant to your business needs and can be created without specialized skills. Let's review the key benefits of Transformation Authoring.

Increases productivity. A development team often needs to integrate two separate technologies or systems. For example, you may need to integrate a legacy backend and a cutting-edge business process modeling system. Yet, there are often no tools available to handle such integration. You can use Transformation Authoring to create custom tools that solve these specific problems, thereby greatly increasing your team's productivity and, ultimately, reducing the total cost of ownership of the software system.

Consistency minimizes maintenance. Two key benefits of creating such a custom tool are convention and consistency. If you build a custom tool, your development team can generate system components with consistent patterns that follow best practices. This often results in a system that is a well-oiled machine, so it is easy to document and maintain.

Agile, flexible, and specific. Sometimes, you need a tool to solve a very specific problem, but there are no products on the market in the form factor that you need. That can mean that you have to break the bank to buy a Swiss Army knife when you all you need is a Philips screwdriver. Thus, a key benefit of building a tool with Transformation Authoring is that it is custom-tailored to your needs. You can invest in a tool that generates Web services specific to your industry, for example, rather than working with tools that are more generic or too complex because they are designed to handle the general case.

Easy to learn and use. When it comes to building a custom tool, Rational Software Architect software has a lot to offer. Transformation Authoring is based on an Eclipse open-source project called JET which is a mature offering (JET was started in 2002) and uses open standards, such as XPath. Most important, it is easy to use, because it provides a graphical user interface to make life as easy as possible for the person who is creating the tool.

Note: JET was formerly known as Java™ Enabler Templates; however, the nomenclature has changed to simply JET because it is no longer limited to Java expressions. XML-based templates can now be used which makes building tools with JET programming language agnostic.

Two tradeoffs

Before you drop your current development tools and start trying to create world peace with this technology, there are a couple of tradeoffs. As we'll discuss in the next section, not all development tools can be constructed quickly with the Transformation Authoring graphical interface (at least not without significant custom code in the form of XML tags or embedded Java code). Also, to use Transformation Authoring effectively, you must understand the problem that you need to solve at a mastery level. For example, if you want to build a tool that generates XML property files, you need to understand the XML that it is to generate in detail.

Thus, Transformation Authoring can save your organization a lot of time, and it can fill in gaps in your toolset to increase productivity where you need it the most. However, it does not solve every tooling problem, and you have to thoroughly understand the problem before you can craft a tool to solve it.


Core concepts

This technology is considered an extensibility feature that, broadly speaking, enables you to extend the capabilities of the standard tools included in the Rational Software Architect software. The Transformation Authoring features are based on Eclipse open-source technology called JET (See Resources).

As Figure 1 shows, before you build a tool with Transformation Authoring, you need to identify the nature of the tool that you need, which really means that you need to clearly define the problem that you need to solve. There are two types of tools that you can readily create by using Transformation Authoring:

  • A tool that generates files. You can use Transformation Authoring to quickly develop tools that generate collections of files of any type. This includes source code in any language, XML files, and, as you'll see in this example, even entire Java 2 Platform, Enterprise Edition (J2EE) projects. For instance, if you have a series of workflow processes that are very similar and numerous, you can build a tool that automatically generates them. More specifically, you can create a tool that generates Business Process Execution Language (BPEL) business process projects for IBM WebSphere Process Server, so that you don't have to build each one by hand.
  • A tool that transforms files to different file structures or file formats. You can create tools that perform transformations. If you are familiar with XSLT, a JET template can transform one file format to another, similar to how an XSL stylesheet can. The difference is that XSLT is essentially a programming language, but Transformation Authoring uses a process called exemplar analysis, which has a visual interface. Additionally, Transformation Authoring can generate any type of file, including binary, thus it can naturally create file structures on a larger scale. This allows you to generate anything that can be represented in an Eclipse workspace, such as Java 2 Platform, Enterprise Edition (J2EE) utility Java archive files (JARs) and enterprise application projects (EARs).

Not all problems can be solved with Transformation Authoring, however. In general, if it does not involve either generating file artifacts or source code or else converting a file to another format, it is not a good fit. Here are a couple of examples of custom tools that are not as straightforward to create with Transformation Authoring:

  • Build tools. Build scripts, such as Apache Ant, often make external calls, such as a call to the file system, compiler, or source control system. Although the JET templates that are part of Transformation Authoring can perform external calls, their purpose is transformation, rather than this type of control logic.
  • Visual editors. As you'll see shortly, the result of a Transformation Authoring project is a tool that can be executed. It is essentially an engine that takes in input and produces some from of output to the Eclipse workspace. That's why traditional Eclipse plug-in development is better-suited to create a visual editor.

As Figure 1 shows, when you have identified a suitable problem to solve, the next step is to create an exemplar. An exemplar is an example solution to the problem. For instance, if you want to build a tool that generates a portlet that conforms to the look and feel of your organization's Web portal, you'll need to start with an example portlet as an exemplar. An exemplar can be any collection of files in your workspace. A single XML file or a folder with a dozen Java classes can serve as exemplars, for instance, as long as they represent what you want the tool you are building to ultimately produce.

Note: Advanced users can skip this step and manually create the input model and JET templates without an exemplar, but even for advanced users the exemplar analysis process often saves time.

Figure 1. Transformation Authoring process
Figure 1. Diagram of the Transformation Authoring process

After you have an exemplar in your workspace, the next step is to create a JET Transformation Authoring project. This project allows you to perform exemplar analysis, which is a process that instructs Rational Software Architect about what you want to stay the same for the tool's output from the exemplar and what should change. For example, if you want to build a tool that creates Java classes, you probably don't want the names of those objects to be hardcoded in the tool. Instead, you probably want to provide some input to your tool to specify what class names to use. This is exactly the type of decisions made during exemplar analysis.

The result of exemplar analysis is an input model and JET templates (actually many other files are created as well, but these are the only ones you need to know about). The input model to your tool can take several functionally equivalent forms including an XML schema, Eclipse Modeling Framework (EMF) Ecore Model, or UML model. Thus, for example, if you wanted to create a trivial tool that generates arbitrary folders and empty files with an XML schema input model, the input to your tool might look like code Listing 1.

Listing 1. Simple input example
   <root>
   <folder name="bozo-folder">
      <file name="im-an-empty-file1.txt"/>
   </folder>
   <folder name="blueberry-folder">
      <file name="im-an-empty-file2.txt"/>
      <file name="im-an-empty-file3.txt"/>
   </folder>
   </root>

JET templates are also created as part of the exemplar analysis process. Initially, they are exact replicas of the files in the exemplar. Therefore, if you provide a Book.java file in the exemplar, the exemplar analysis will produce a corresponding Book.java.jet file. You can decorate the JET templates with JET tags based on XPath 1.0 (see Resources). The tags again distinguish what should be static and what should be dynamically changed by the tool. In Figure 1, this is the Edit Templates step in the diagram. The Pojo database example later in this article covers this in more detail.

After you finish editing the templates, the Transformation Authoring project itself becomes a customized, reusable tool as shown inFigure 2. You can run the JET transformation with any input that conforms to the input model.

Figure 2. Illustration of custom tool use
Figure 2. Illustration of custom tool use

The rest of this article walks you through the construction of a simple database access tool that illustrates the exemplar analysis process.


Prerequisites

In addition to a standard Rational Software Architect 7.0 installation, ensure that the Transformation Authoring feature is enabled, as shown in Figure 3 . To check whether it is installed, in Microsoft® Windows, select Start > Programs > IBM Installation Manager. When the Installation Manager is open, select Modify Packages.

Figure 3. Adding the Transformation Authoring feature
Figure 3. Screen capture that shows where to start when adding the Transformation Authoring feature

Pojo database example

This section details a step-by-step example of building a tool with Transformation Authoring. The problem solved by the tool that you are going to build is that of consistent database access within a large application. When you access a database with an object-oriented language, you often need to map a database table to an object. A common pattern for doing this is the Database Access Object (DAO) pattern (see Resources). This pattern performs table-per-object mapping, where each table has a corresponding object type. However, when you have many database tables, it is often tedious to write a corresponding object for each table. In the case of Java, this can entail writing many Java beans or plain old Java objects (Pojos), as well as numerous bean properties. The purpose of this example tool will be to generate the Pojo database for you. This also brings consistency to your organization, because your entire development team can use a standard tool to create database access objects.

Note: Of course, there are far better tools out there to solve this type of object-relational mapping problem, such as Apache iBatis and the Java Persistence API. We chose this simple tool as an example because its purpose is easy to understand, yet it is complex enough to be modestly useful.

As we discussed previously, you’ll need an exemplar to begin the process of building the tool. That is, you need an example of what you want your tool to ultimately produce. Figure 4 illustrates the Java object that will serve as our exemplar for this example. It corresponds to a customer table in a relational database.

Figure 4. Pojo exemplar used for example here
Figure 4. Pojo exemplar used for example here

Figure 5 illustrates the Transformation Authoring process for this example. We'll start with a Web project in our Rational Software Architect workspace, which contains the customer Pojo as our exemplar. Then the majority of the example details the process of exemplar analysis to create the database Pojo generation tool. When the tool is finalized, you'll be able to modify a simple XML file and run it to generate any number of Web projects and an encapsulated database Pojos.

Figure 5. Transformation Authoring process for the example
Figure 5. Diagram that illustrates the Transformation Authoring process for the example here

Create an exemplar

In this section, you'll import the Web project that will serve as our exemplar in this exercise. You'll also take a look at the customer, Pojo, as well as the Web project configuration in more detail.

  1. Open Rational Software Architect in the Web perspective.
  2. Select File > Import... > Other > Project Interchange and import the Exampleexemplar.zip file.
  3. Inspect the Web project.

Notice that this is a J2EE Web project with a single Java bean, or Pojo, in it, called CustomerDAO (see Listing 2). The Pojo has several bean properties and a static method called retrieveCustomer to query a customer from the database by primary key and then to return an instance of CustomerDAO.

Listing 2. CustomerDAO Pojo

Click to see code listing

Listing 2. CustomerDAO Pojo

   public class CustomerDAO {
	
	/* constants */
	private static String SQL = "SELECT CUSTOMER FROM ACME.DB WHERE SOCIAL = ?"; [1]
	private static String DATASOURCE = "java:comp/env/jdbc/ACMEDataSource"; [2]
	
	/* attributes */
	private int social;
	private String name;
	private Date joined;
	
	/* getters and setters */
	public int getSocial() { return social; }
	public void setSocial(int social) {	this.social = social; }
	public Date getDateJoined() { return joined; }
	public void setDateJoined(Date joined) { this.joined = joined; }
	public String getName() { return name; }
	public void setName(String name) { this.name = name; }
	
	/* constructor */
	public CustomerDAO(int social, String name, Date joined) {
		setSocial(social);
		setName(name);
		setDateJoined(joined);
	}
	
	/* DAO method to retrieve a customer from the database */ [3]
	public static CustomerDAO retrieveCustomer(int social) throws ServletException {
		CustomerDAO customer = null;
		try {
			// execute database query
			InitialContext ctx = new InitialContext();
			DataSource ds = (DataSource) ctx.lookup(DATASOURCE);
			Connection conn = ds.getConnection();
			PreparedStatement stmt = conn.prepareStatement(SQL);
			stmt.setInt(1, social);
			stmt.execute();
			ResultSet result = stmt.getResultSet();
			
			// create and populate CustomerDAO object
			customer = new CustomerDAO(result.getInt(1), result.getString(2), result.getDate(3));
		} catch(NamingException ne) {
			throw new ServletException(ne);
		} catch(SQLException sqle) {
			throw new ServletException(sqle);
		}
		return customer;
	}
    }

Several points of interest are denoted by the numbers in brackets in Listing 2:

  1. A constant string at the top of the class is used to store the SQL query to retrieve the customer.
  2. A constant string is also used to store the context reference to the JDBC data source.
  3. A static method to retrieve the customer from the database.

Double-click web.xml under DatabasePojo/WebContent/WEB-INF/, and then select the References tab. Notice that there is an external reference to a Java® Database Connectivity (JDBC) data source for the Web project, as Figure 6 shows. Keep this in mind, because this resource reference will play a role in subsequent sections.

Figure 6. JDBC data source resource reference
Figure 6. Screen capture showing the JDBC data source resource reference

Create an exemplar analysis project

This section shows you how to create a Transformation Authoring project and the exemplar analysis project. During this process, you'll create the XML schema that will define the input to your tool. You’ll also configure the tool to produce the directory structure and file names of the output Web projects to be dynamic in a way that directory names, such as DatabasePojo, or file names that start with Customer from the exemplar are not hardcoded, but rather come from the input provided by the user of the tool.

  1. Create an exemplar analysis project.
    1. Right-click the DatabasePojo Web project, and select New > Other > Transformation Authoring > EMFT JET Project with exemplar Authoring.
    2. Enter MyExamplarAnalysis for the project name, and select Finish.
  1. Create the input model types and attributes.
    1. Right-click root, select New > Type, and name it war.
    2. Right-click war, select New > Attribute, and name it datasourceJNDI.
    3. Continue creating types and attributes as necessary to create the directory structure (tree) that you see on the right side of Figure 7.
Figure 7. Definition of the input model
Figure 7. Screen captures showing the completed definition of the input model

The right side of Figure 7 illustrates the input model for the tool. The corresponding XML schema is in the MyexemplarAnlysis/schema.xsd file. Table 1 describes the purpose of each of the types and attributes in the input model.

Table 1. Description of input model
NameDescription
rootThis is the default root type for all input models created with Transformation Authoring.
warThis refers to a Web archive (war), which is the archive format for a J2EE Web project. Users can specify as many war nodes as they want in the input model, which results in the output of that number of Web projects by the tool.
datasourceJNDIEach Web project produced by the tool can use a different JDBC data source specified by this Java™ Naming and Directory Interface (JNDI) name. As you may recall, it was jdbc/ACMEDataSource for the exemplar.
nameThis is the name of the Web project.
daoBean The user can specify any number of DAO Java beans to be created by the tool for a given Web project.
keyThe user must input the name of the primary key attribute (this simple example assumes that the primary key is always composed of a single attribute).
nameThis is the name to be used for the DAO Java bean.
SQLThis is the SQL query text used to fetch the bean properties from the database.
beanProperty The user can specify any number of properties for the bean.
nameThe name of the property (in lowercase).
typeThe Java type of the property.

This is only an example of an input model. It can be changed any time. For example, after you finish this example, you could add a package attribute to daoBean so the user could specify what Java package is used for each bean.

  1. Configure naming for War project folder.
    1. Drag the DatabasePojo folder to the war type on the right, as shown in Figure 8.
    2. Select Create Project: DatabasePojo and then the Properties tab.
    3. In the *name field, right-click the Database text from DatabasePojo and select Replace withModel Reference....
    4. Select the name attribute under the war type.
Figure 8. Figure 8. Generalization of the Web project name
Figure 8. Screen capture showing the generalization of the Web project name as DatabasePojo at the Create Project level
  1. Configure naming and folder structure for Pojo Java class.
    1. Drag CustomerDAO.java to daoBean, as shown in Figure 9.
    2. Select Create File: CustomerDAO, and then the Properties tab.
    3. In the *path field, right-click the Database, select Replace with Model Reference..., and replace it with the name attribute under the war type.
    4. Similarly, replace the Customer text from CustomerDAO with the name attribute under the daoBean type.
Figure 9. Generalization of the Pojo path and file name
Figure 9. Screen capture showing the generalization of the of the Pojo path and file name
  1. Configure naming and folder structure for remaining files.
    1. Drag the files highlighted on the left side of Figure 10 to the war type on the right side.
    2. Select Create File: .project and then the Properties tab.
    3. In the *path field, replace the Database text with the name attribute under the war type from the input model, as shown in Figure 11.
    4. Repeat this step for the remaining eight files that you just copied.
Figure 10. Configuration of the remaining Web project files
Figure 10. Screen capture showing the configuration of the remaining Web project files
Figure 11. Generalizing the path of the .project file
Figure 11. Screen capture after generalizing the path of the .project file

Modify the JET templates

At this point, your tool knows how to create the right folder and file name structure based on the input model, but does not know how to modify the contents of the files. In this section, you edit templates, based on the files in the exemplar, to specify what text needs to remain static and what text needs to be based on the user's input.

To generate the initial JET templates, you need to update the Transformation Authoring project.

  1. Right-click the right input model panel and select Update Project, as shown in Figure 12.
Figure 12. Update project
Figure 12. Update project screen menu
  1. Inspect the MyexemplarAnalysis project, and you'll find several new files generated under templates (see Figure 13).
Figure 13. JET templates
Figure 13. Screen display showing JET templates

At this stage, the templates are exact replicates of the files in the exemplar project. You'll be working primarily with the web.xml.jet and CustomerDAO.java.jet templates, because they contain text that should be changed by the tool, based on the input model. The majority of the remaining files will just be copied to the Web projects output.

In the web.xml.jet template, there are two things that you need to change. First, the name of the project is hardcoded as <display-name>DatabasePojo</display-name>. Notice that Database is underlined in the blue. Rational Software Architect automatically detects that you probably want to change Database to the war name attribute in the input model, so you can make this change without any editing by hand:

  1. Edit the web.xml template to generalize display name.
    1. Open MyexemplarAnalysis/templates/war/web.xml.jet.
    2. Select the Problems tab.
    3. Scroll down and select the Info item that corresponds to web.xml.jet as the resource, as shown in Figure 14.
    4. Right-click and select Quick Fix and then OK.
Figure 14. Replacement based on Rational Software Architect suggestion
Figure 14. Screen capture showing a replacement based on Rational Software Architect suggestion

The second change that you need to make is name of the JDBC data source. Currently, it is hardcoded as jdbc/ACMEDataSource This was not automatically detected, so you'll have to specify what attribute from the input model to change it to, which is the war datasourceJNDI attribute:

  1. Edit web.xml template to generalize JDBC Datasource JDNI name.
    1. Select the jdbc/ACMEDataSource text.
    2. Right-click and select Replace with Model Reference....
    3. Replace it with the datasourceJNDI attribute under the war type.

The resulting web.xml.jet template should look like Listing 3.

Listing 3. The web.xml.jet template
<web-app id="WebApp_ID" version="2.4">
   <display-name>
      <c:get select="$war/@name" />Pojo
   </display-name>
   <welcome-file-list>
      <welcome-file>index.html</welcome-file>
      <welcome-file>index.htm</welcome-file>
      <welcome-file>index.jsp</welcome-file>
      <welcome-file>default.html</welcome-file>
      <welcome-file>default.htm</welcome-file>
      <welcome-file>default.jsp</welcome-file>
   </welcome-file-list>
   <resource-ref id="ResourceRef_1164745141546">
      <description></description>
      <res-ref-name>
         <c:get select="$war/@datasourceJNDI" />
      </res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
      <res-sharing-scope>Shareable</res-sharing-scope>
   </resource-ref>
</web-app>

The remainder of this section explains modifying the CustomerDAO.java.jet template. You need to replace certain text with tags so that it will be retrieved from the input model when your Customer tool runs. Specifically, you need to replace text that refers to Customer or any of its Java bean properties, such as social or joined.

When you first open the Customer template, you’ll notice that Rational Software Architect has already underlined a lot of the text, which suggests that it has detected what needs to be replaced. Start by accepting all of the suggestions.

  1. Replace text with tags using remaining Info suggestions.
    1. Open MyexemplarAnalysis/templates/daoBean/CustomerDAO.java.jet.
    2. Select the Problems tab.
    3. Right-click the first Info item for the CustomerDAO.java.jet resource.
    4. Select Quick Fix > Replace all instances, as shown in Figure 15, and then click OK.
Figure 15. Accept all suggestions within the Customer template
Figure 15. From the Quick Fix screen, choose: accept all suggestions within the Customer template
  1. A few suggestions remain in the Problems tab. Go ahead and apply those also.

The Customer template should look exactly as Listing 4 shows. Notice, however, that there is still a lot of hardcoded information from the exemplar that needs to be changed to synchronize with the input model. For example, the SQL query for customer is still hardcoded, as is information related to the social, name, and joined properties.

Listing 4. Customer template should now look like this
public class <c:get select="$daoBean/@name" />DAO {
	
   /* constants */
   private static String SQL = 
      "SELECT CUSTOMER FROM ACME.DB WHERE SOCIAL = ?";
   private static String DATASOURCE = 
      "java:comp/env/<c:get select="$war/@datasourceJNDI" />";
	
   /* attributes */
   private int social;
   private String name;
   private Date joined;
	
   /* getters and setters */
   public int getSocial() { return social; }
   public void setSocial(int social) { this.social = social; }
   public Date getDateJoined() { return joined; }
   public void setDateJoined(Date joined) { this.joined = joined; }
   public String getName() { return name; }
   public void setName(String name) { this.name = name; }
	
   /* constructor */
   public <c:get select="$daoBean/@name" />DAO
      (int social, String name, Date joined) {
	
      setSocial(social);
      setName(name);
      setDateJoined(joined);
   }
	
   /* DAO method to retrieve a customer from the database */
   public static <c:get select="$daoBean/@name" />DAO 
      retrieve<c:get select="$daoBean/@name" />
      (int social) throws ServletException {
		
      <c:get select="$daoBean/@name" />DAO customer = null;
         try {
            // execute database query
            InitialContext ctx = new InitialContext();
            DataSource ds = (DataSource) ctx.lookup(DATASOURCE);
            Connection conn = ds.getConnection();
            PreparedStatement stmt = conn.prepareStatement(SQL);
            stmt.setInt(1, social);
            stmt.execute();
            ResultSet result = stmt.getResultSet();
			
            // create and populate <c:get select="$daoBean/@name" />DAO object
            customer = new <c:get select="$daoBean/@name" />DAO
               (result.getInt(1), result.getString(2), result.getDate(3));
         } catch(NamingException ne) {
            throw new ServletException(ne);
         } catch(SQLException sqle) {
            throw new ServletException(sqle);
      }
      return customer;
   }
}
  1. Generalize SQL query string.
    1. Select the text that says SELECT CUSTOMER FROM ACME.DB WHERE SOCIAL = ?.
    2. Right-click, and replace it with the SQL attribute in the input model.

If you look at the Attributes section, you'll see that you've run into a situation where a simple replacement from the input model is no longer sufficient. The reason is that you don't know how many properties the user will provide for the Pojo (for the customer Pojo from the exemplar, it was three). The solution is to use a JET <c:iterate/> tag over the bean properties provided by the tool user:

  1. Replace the social, name, and joined attributes with a <c:iterate/> tag, as shown in Listing 5.
Listing 5. Modification of the Attributes section
/* attributes */
 <c:iterate select="$daoBean/beanProperty" var="prop">
   private  <c:get select="$prop/@type" /> <c:get select="$prop/@name" />;
 </c:iterate>

To build the get-and-set methods section, you again run into a new situation. This time, you need to use an iterate tag, but the problem is that you need to capitalize the first letter of the property name for the get methods. For example, if the user enters foo for the name of a bean property, you need to construct getFoo(). The solution is to use a JET XPath expression called uppercaseFirst(), as follows:

  1. Replace the social, name, and joined get and set methods with the <c:iterate/> tag, as shown in Listing 6.
Listing 6. Modification of get and set methods
/* getters and setters */
<c:iterate select="$daoBean/beanProperty" var="prop">
   public <c:get select="$prop/@type" />
      get<c:get select="uppercaseFirst($prop/@name)" />() { 
         return <c:get select="$prop/@name" />; 
      }
   public void set<c:get select="uppercaseFirst($prop/@name)" />
    (<c:get select="$prop/@type" /> <c:get select="$prop/@name" />){ 
      this.<c:get select="$prop/@name" /> = <c:get select="$prop/@name" />; 
   }
</c:iterate>

The arguments section of the constructor requires an iterate tag, but a comma-separated list needs to be generated. You can use the delimiter attribute of the iterate tag to handle this:

  1. Replace the (int social, String name, Date joined) for the constructor signature Listing 7 shows.
Listing 7. Modification of the constructor signature
(<c:iterate select="$daoBean/beanProperty" var="prop" delimiter=", ">
   <c:get select="$prop/@type" /> <<c:get select="$prop/@name" />
</c:iterate>)
  1. Replace the body of the constructor as shown in Listing 8.
Listing 8. Modification of the constructor body
<c:iterate select="$daoBean/beanProperty" var="prop">
   set<c:get select="uppercaseFirst($prop/@name)" />(<c:get select="$prop/@name" />);
</c:iterate>

There are three instances of the word customer in the Customer template. Again, you use a JET XPath expression, lowercaseFirst(), to ensure that the first letter is generated as lowercase:

  1. Replace the three instances of customer with <c:get select="lowercaseFirst($war/@name)" />.

The static retrieval method in the Customer template takes in the primary key as the argument. Determining the type for the primary key requires a little more advanced XPath. considering that you must first check the name of the key and then match it to a beanProperty, as Figure 16 shows.

Figure 16. Where to determine the primary key type
Figure 16. Screen element showing where to determine the primary key type

To accomplish this, you’ll need to use what is referred to an XPath predicate. A predicate includes a Boolean statement that qualifies an XPath path to ensure that a particular node or set of nodes is selected:

  1. Replace the argument for the retrieval method of (int social), as shown in Listing 9.
Listing 9. Modification of the retrieval method signature
(<c:get select="$daoBean/beanProperty[@name 
= $daoBean/@key]/@type" /> <c:get select="$daoBean/@key" />)
  1. Replace the stmt.setInt(1, social); text as shown in Listing 10.
Listing 10. Modification of the JDBC statement
stmt.set<c:get select="uppercaseFirst($daoBean/beanProperty[@name 
= $daoBean/@key]/@type)" />(1, 
<c:get select="$daoBean/@key" />);

When retrieving the information from the JDBC ResultSet, you run into a new problem, because the ResultSet requires a numerical index for data access (in the exemplar, you used number 1-3). A standard XPath function returns the current node position while iterating through a node set called position() Thus, you can use the position to populate the indexes:

  1. Replace the (result.getInt(1), result.getString(2), result.getDate(3)) text, as shown in Listing 11.
Listing 11. Modification of JDBC ResultSet access
(<c:iterate select="$daoBean/beanProperty" var="prop" delimiter=", ">
   result.get<c:get select=" uppercaseFirst($prop/@type)" />
      (<c:get select=" position()" />)
</c:iterate>>)

This completes the exemplar analysis process and the development of your custom tool. If you run into problems or have a question about how to modify the templates, you may find it helpful to import the Solution.zip project interchange and inspect it (see Resources).

Run the transformation

Now that you are finished with exemplar analysis, you are ready to run your custom tool. You’ll create the input XML, and then execute the transformation.

  1. Define the input that you want to transform.
    1. Open MyexemplarAnalysis/test.xml.
    2. Populate the <root/> node as shown in Listing 12.
Listing 12. Example of input
<root xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' 
   xsi:noNamespaceSchemaLocation='schema.xsd'>
   <war name='MyResult' datasourceJNDI='jdbc/MyDatasource'>
      <daoBean name="Boat" sql="SELECT BOAT FROM ACME.DB WHERE ID = ?' key='id'>
         <beanProperty name='d' type='int'/>
         <beanProperty name='desc' type='String'/>
      </daoBean>
      <daoBean name='Plane' sql="SELECT PLANE FROM ACME.DB WHERE ID = ?' key='id'>
         <beanProperty name='id' type='long'/>
         <beanProperty name='color' type='String'/>
      </daoBean>		
   </war>
</root>
  1. Run the transformation.
    1. Right-click test.xml.
    2. Select Run As > Input for JET Transformation, as shown in Figure 17.
Figure 17. Run the JET transformation
Figure 17. Screen captures showing the sequence to run the JET transformation

As a result, you should see a new Web project in your workspace called MyResultPojo, as Figure 18 illustrates.

Figure 18. Transformation result
Figure 18. Screen capture showing the transformation result

Notice that two Pojos were created, called BoatDAO and PlaneDAO, as shown in Figure 19.

Figure 19. Resulting Database Access Objects
Figure 19. Resulting Database Access Objects

This is, of course, only a single possible output of the custom tool you've created. Take some time to change the XML input to generate different possible outputs. For example, you may want to generate more than one Web project at a time.


Avoid tedious integration and migration problems

This article introduced Transformation Authoring and provided a hands-on example to get you well on your way to building useful custom tools with Rational Software Architect 7.0. After reading the explanations and going through the exercise, you're probably already thinking of numerous immediate applications of Transformation Authoring. You'll notice common patterns emerging for tedious integration problems, migration problems, and the like. In such cases, you and your team should greatly benefit from creating custom tools to make your work easier, faster, and more productive.


Downloads

DescriptionNameSize
ExamplesExampleExemplar.zip6KB
ExamplesSolution.zip25KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, Architecture
ArticleID=186947
ArticleTitle=Create powerful custom tools quickly with Rational Software Architect Version 7.0
publish-date=01092007