Sign In/My Account | View Cart  

advertisement

AddThis Social Bookmark Button

Print

Improve Your Career with Tomcat and Aspire

by Satya Komatineni
12/04/2002

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.

  • They know your business and know how to implement business logic.

    Related Reading

    Java Enterprise Best Practices
    By The O'Reilly Java Authors

    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:

  1. Write JDBC statements to call the procedures and paint a page with JSP.
  2. Make sure the user has logged in.
  3. Manage a session for that user so that his interactions are kept.
  4. 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.

Here is a list of tools that you will need:

  • A GUI tool to write your stored procedures (such as SQL Navigator for Oracle, or Query Analyzer for MS SQL Server 2000).
  • Tomcat (this usually comes with such Java IDEs as Jbuilder 7, or you can download it online).
  • Aspire (download it here).
  • FrontPage or Dreamweaver.
  • Jbuilder 7 (optional; having this will help you debug the JSP pages).

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

At the end of this exercise you will need to:

  • Understand how to install/uninstall Tomcat.
  • Understand the basic Tomcat configuration file, server.xml, and web.xml.
  • Understand what a webapp is and how to set it up.
  • Understand how to run/stop Tomcat.
  • Understand how to access Tomcat sample applications.

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:

  1. Download Aspire.
  2. Initialize Tomcat with Aspire as a webapp.
  3. Identify Aspire's master properties file.
  4. 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.

Conceptually, this looks like the following: 

DisplayPage1.main-data=PROC1
DisplayPage1.list-data=PROC2
DisplayPage1.table1-data=PROC3
DisplayPage1.table2-data=PROC4

Where PROC1 through PROC4 are defined as follows:

PROC1.clasname=com.aspire.StoredProcedure
PROC1.db=MYDATABASE
PROC1.stmt=call pkg.sp_procedure1 arg1, arg2, arg3
PROC1.type=query

PROC2.clasname=com.aspire.StoredProcedure
PROC2.db=MYDATABASE
PROC2.stmt=call pkg.sp_procedure2 arg1, arg2, arg3
PROC2.type=query

PROC3.clasname=com.aspire.SQLExecutor
PROC3.db=MYDATABASE
PROC3.stmt=select * from table1 where arg1 = {arg1-value} and arg2 = {arg2-value.quote}
PROC3.type=query

PROC4.clasname=com.aspire.FileReader
PROC4.filename=c:\a.txt

When you do this in the configuration file, Aspire will execute all of the above and return an XML-like data set to your front-end design page. Here is what that conceptual XML infoset looks like:

<AspireDataSet>
        <maindata>
                <arg1>50</arg1>
                <arg2>70</arg2>
        </maindata>
        <list-data>
                <row>
                        <col1>value1</col1>
                        <col2>value2</col2>
                </row>
                <row>
                        ....
                </row>
        </list-data>
        <table1-data>
                .......
        </table1-data>
        <table2-data>
                .......
        </table2-data>
</AspireDataSet>

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.

Pages: 1, 2

Next Pagearrow