Improve Your Career with Tomcat and Aspire

Information technology companies today have a hidden resource that they have barely started to exploit. IT companies have, over the years, spent a considerable amount of money equipping themselves with strong relational database expertise. But these relational teams are traditionally isolated and kept behind the glass doors, primarily supporting the development teams that churn out end-user applications. This practice largely continues even today as the programming face of IT moves to the Web.

There are alternatives to this picture. Thanks to the openness and simplicity of Java, innovation in the Web programming space is bursting at the seams. As a result, developing enterprise systems has never been easier, cheaper, faster, or more robust. In this article, I want to show you how your IT relational teams can make use of two products in the J2EE/XML space and expose their relational business expertise to the outside world.

Tomcat, the first of the two suggested products, is an open source implementation of the servlet standard (a part of J2EE) in a very small accessible package (four to five megabytes). The second product is a declarative data access tool called Aspire that allows your relational developers to write business logic in stored procedures while using such front-end tools as Dreamweaver and FrontPage. Aspire provides the declarative middle tier that ties predesigned Web pages to SQL and stored procedures. Using these two products, relational developers will be able to write comprehensive interactive Web sites that can also include charts, graphs, reports, XML, etc.

Who are Relational developers and why Should IT Take a Serious Look at Them?

You have nurtured them.
IT departments have nurtured relational talent for years. Universities have programs that are constantly teaching database skills at the graduate level. Relational talent is becoming increasingly common, due to the increasing availability of relational tools such as Microsoft Access, MySQL, etc.

They know your data.
Relational teams are the closest to your data model. They know the tables well. They know how these tables are inter-related. They know how to retrieve queries for a given question. They are the ones that typically generate reports, run batch programs, find data inconsistencies, and optimize for performance. There is a treasure trove that is waiting to be given more responsibilities and higher status, and hence higher pay, in IT.

Relational teams tend to be the more stable part of IT, giving them the added benefit of exposure to the business over a longer time. Coupled with their understanding of the data model, this experience is a great asset, allowing them to be excellent candidates for application development. Relational teams also have the necessary tools for writing business logic in the three-tier programming model of the Web. This three-tier programming model is primarily transactional, giving an extra value to stored procedures that are supported by most of the modern relational databases. Even where they are not supported, they can be simulated using predesigned Java components.

Relational Developers Have Potential

These qualifications of relational teams position them to be your greatest assets in the transactional Web programming world. As I have said, they have the third tier, the business tier, down. I want to suggest here that with minimal training:

They can be transformed into developing comprehensive interactive Web
applications using J2EE/XML with the help of Tomcat and Aspire.

They can present data to end users via the Web.

They can present comprehensive reports via the Web.

They can create online forms where users can interact with the database
via the Web.

They can validate user input either on the client side or the server side
(via stored procedures).

They can raise exceptions in stored procedures and respond to them on the
front end.

They can present data as tables, list boxes, trees, etc.

They can provide their data as graphs and XML.

They can provide access control and authorization for users based on their
tables.

How They Get There

The truth of the matter is that it is trivial to get there with Tomcat and Aspire. I know, based on my experience at a large company, that this will
save considerable amount of time and money to IT. Here is my reasoning:

The developers will start out understanding off-the-shelf HTML design tools such as FrontPage and Dreamweaver. These tools allow you to mock up your entire Web site, including the navigation between pages and frames. Except for the basics of HTML, the developer will be able to do this and be proficient in less than a week. In this phase, the developer will have to hone the following skills:

Understand HTML frames.

Understand JavaScript and how to control frames using JavaScript.

Understand how to read fields from an HTML form.

Understand how to post URLs using parameters to the server side.

Understand how to work with basic JavaScript calendars.

Understand how to work with regular expressions for validating form fields.

Understand how style sheets work for presentation.

A quick read of the JavaScript Bible by Danny Goodman will quickly provide the above. The above exercise will give the developer a firm handle on the GUI tier. The developer will then proceed to examine each page and the data requirements for each page. The developer will proceed to write SQL or stored procedures for each page, and test and document them. Now the developer has the following two assets under the belt:

The complete mockup of the HTML Web site.

Stored procedures or SQL required for each Web page on that mockup Web site.

Guess what? The developers have done 90% of the work. If you were to use J2EE without the help of any tools, there is still a lot of work left to do, such as:

Write JDBC statements to call the procedures and paint a page with JSP.

Make sure the user has logged in.

Manage a session for that user so that his interactions are kept.

Make sure a user has access to a certain page.

But if you were to use Aspire along with J2EE, all of the above would be taken care of. The developer will combine the page with the stored
procedures through a declarative configuration file. In other words, all of the steps above are accomplished by a configuration section for that page. Essentially Aspire is allowing you to join your pages to your stored
procedures through a declarative middle tier. It's as if there is a "transparent data pipeline" between your stored
procedures and your Web pages.

What Tools Will Get Them There?

So how is this different from other RAD tools or JSP tags where you can execute these SQL and stored procedures in your HTML page itself? There is
a crucial similarity and a crucial difference; both are equally powerful and equally important. Aspire is designed with a clear separation of GUI and data access.
A lot of tools and technologies seem to advertise this fact quite prominently.
Aspire does separate the tiers cleanly; as a result, the SQL and stored procedures are kept in a configuration file.

Aspire also allows this data access via an abstraction so that you can migrate your stored procedures to other means of writing business logic, such as Java or EJBs, or COM+, for that matter. At the same time, Aspire recognizes the need for keeping the stored procedures as close to the front end as possible. So you get the best of both worlds: faster development from the RAD world and flexible architecture from
the J2EE world.

What It Takes to Use Tomcat

Tomcat is an application server that works with a Web servers like Apache. Tomcat is written in Java and implements the Java Servlet API. To work with Tomcat, you need to know a couple of things:

The very basics of the Java language (mostly syntactic nuances).

What .jar files and classpaths are (the administrative details of how to run a Java program).

A basic understanding of servlets. (How does preexisting Java logic get invoked by a URL?)

A basic understanding of the Web. (What are URLs, what is a POST?)

All of these can be taught in a day or two to any reasonably industrious programmer. The key is not to focus on the details; you only need the concepts. Tomcat comes with documentation to install and set it up. I will be more than happy to help
anyone with this process -- email me at satya@activeintellect.com

Using Aspire

Aspire has been field-tested on multiple applications to make sure as much development as possible can be done with relational developers, while always preserving the ability to write in Java. So it is especially easy for relational developers to be productive from day one. The first step is to set up Aspire. Here are the things that you will need to do:

Download Aspire.

Initialize Tomcat with Aspire as a webapp.

Identify Aspire's master properties file.

Walk through Aspire's sample application.

This process should take about half a day. More importantly, let us see how Aspire can help in connecting your business procedures to screen design.

Connecting Screens to Business Procedures

As I have identified, you already have a screen mockup and a set of stored procedures for that screen. That is, a screen may have more than one stored procedure necessary to retrieve all of the data. For example, you may have in a screen a list box whose data may come from a flat file, a table whose data may come from a stored procedure, and yet another table from SQL. Aspire allows you to write a configuration file where the page name is linked to these multiple data access schemes.

The above example just gets the point across. The details of the
configuration may differ when you actually start the development process. The
details are a bit more involved, as they cover more ground to give the developer
lots of options. Having thrown that caution in, let me see what you can do with this data on your predesigned page. The goal is to merge this data with your predesigned page. There are three alternatives for doing this:

Use Aspire's simplified tags

Use JSP.

Use XSLT.

Aspire's Simplified Tags

The goal here is not to be detailed but to give you an understanding of the complexity (really, the simplicity) involved. In this case, the merging is accomplished through a replacement tag pair that looks like {{ and }}.

Here is an example:

Hello my first name is {{arg1}} and my last name is {{arg2}}

Aspire will replace arg1 and arg2 from the maindata data set. Here is how you can use the data from the list1-data set.

The same thing goes for table1-data and table2-data.
The tags are
designed with two important goals. The first is to preserve the design of the
page with the tags present. That is, the tags should not impede the ability of
the designer to see the page in the design tool with minimal impact. For this
reason, the tags are embedded either in comments or directly exposed to the
designer. The second goal is to allow the designer to directly identify the
dynamic elements while in the design tool itself. In the case above, {{arg1}} can
be directly typed in FrontPage with out switching back to the HTML view. To
allow for conditional inclusion of a page based on a certain matching criteria,
there is a programmable IF tag available as well.

Merging with JSP

When the page is too difficult to handle with the simple tags documented
above, you can use JSP instead. Here is an example of using JSP for merging data
and the screen:

<%
//Get the data object
IFormHandler pageData = request.getAttribute("Aspire.Dataset");
%>
Hello my first name is <%=pageData.getValue("arg1") %>
and my last name <%=pageData.getValue("arg2")%>

At the top of your HTML page (or JSP page) you receive the object into a
local variable called pageData. This object and the available methods on that
object are used to retrieve data and place on the page. Basic JSP is very simple
to teach -- it takes perhaps less than an hour. JSPs can get complicated, but the goal of
the tool is to make this process trivial and easy.

See how the values for arg1 and arg2 are retrieved from pageData and
substituted onto the HTML page just like the {{arg1}} in the tags scenario.

The next example of JSP shows how one can populate repetitive structures, such
as list boxes and tables. Data for each repetitive structure is also available
in pageData, albeit with a name identifying it. This is necessary because on a
given page, you may have more than one repetitive structure. Each structure is
identified by a name. Once you know the name, you can access the data for the
repetitive structure using its name.

The data for list1-data is retrieved from pageData into a variable called
list1Data and, using a simple while loop, all of the rows are traversed. See
the similarities of list1Data.getValue() and pageData.getValue(). In essence,
the number of APIs that the developer needs to know is very minimal. It is this
simplicity that makes the JSP merging easy and powerful.

Merging with XSLT

For the sake of brevity, I will not go into the details of the XSLT, but it is very similar to the JSP section, except that you are using XPATH expressions for substitute and loop through. The example of this can be seen at the
Aspire
demo site.

JSP and XSLT: Are They not Complex Enough for the Stated Simplicity?

In the cases of both JSP and XSLT we are using a very minimal set of their respective facilities; in both cases we are limiting ourselves to the control flow statements of a language. You are basically using assignment, if/else, and loops. These should be very familiar to the relational developers, as they use these structures in writing stored procedures.

How do Updates Work?

Performing updates based on HTML forms is quite intuitive and flexible using Aspire. Let us consider a URL that is coming from the browser
as a result of form posting:

The above invocation implies that you want to call a business logic called update-employee with two arguments arg1 and arg2. How can you facilitate this so that your stored procedure, mypkg.sp_update_employee arg1, arg2, is called? Here is the configuration to do this (we've had to add some line breaks for formatting purposes here):

Aspire will pass the arguments to your proc and if the proc doesn't throw any exceptions, the user is redirected to the URL identified by redirectURL; if the exception has an error code, EMPLOYEE-DOESN'T-EXIST, the user gets redirected to that URL. If the error code doesn't match, the user is redirected to general failure-redirect-url.

How Long for a Typical Relational Developer to Start Effectively Exploiting the Web to Enhance His or Her Career?

Here is a toolset that can seamlessly transform your relational developers to Web developers in about a week. The toolset is firmly rooted in architecture and J2EE and provides a gradual learning path for the development teams into the complex areas of J2EE, while providing simple solutions to simple problems. Being a no-cost alternative should be attractive as well.

This could also work as a career-enhancement proposition to the database developers, as they can directly impact the business processes utilizing their superior knowledge of
corporate data. The goal is to make the relational developers take on the role of architects in enterprises and thereby provide a well-rounded career path.

Additional Help

For individuals that are interested in this article and want to try out
the tools outlined, or corporations that want to further explore the deployment opportunities available
for open source J2EE architectures like the ones proposed here, email me at
satya@activeintellect.com.