19/02/2006

development environment (two)

(note: this is part two of a series on developing java enterprise applications. part one deals with the tools used to set up your development environments.)

the current project i'm working on requires a number of external libraries for its functionality. i use open source projects from apache's jakarta and the jakarta commons projects for many of these features, but there is a lot of good, quality OSS code around. the application i'm working on is a web based service, running under tomcat. i will go through each of the packages it depends on and explain why i chose and use them.

struts


apache struts is an MVC (model-view-controller pattern) framework. the current release version is 1.2.8 and it has been around for long enough that there are many good books available.

the struts project is currently undergoing a revision, and will be split into two frameworks, action (much like the current version) and shale (which will integrate with sun's JSF presentation layer) as well. currently, the 1.2.8 release is likely to remain useful and stable, and i would not recommend using any of the forked versions until they have more support and documentation avaialable.

in terms of books, the two i would recommend are both part of the o'reilly java series: jakarta struts cookbook by bill siggelkow and programming jakarta struts by chuck cavaness. the documentation and javadocs are available on the jakarta site.

struts implements the front controller pattern, and is mainly concerned with the C of MVC. the model and presentation layers are up to you. the controller is based on the concept of actions, which are invoked from the struts action servlet, usually by any URL ending in .do and are defined declaratively. in fact, the whole of the struts configuration is done this way, from a single (or multiple, if required) XML file. this specified the forms, their contents and the actions that process them, as well as any exceptions that may occur, message resources, plug-ins and forwards. forwards are struts mechanism for separating the presentation layer from the controller, and allow you to give a name to a a JSP or HTML file, that an action will then forward to. this way, you can change what the forward points to without re-coding your actions.

in general, struts is a very nice framework, particularly since you can mix and match any other model and presentation frameworks you want. many, many commercial sites use struts - look for the tell-tale .do extensions on pages that perform the business functions in the site. for example, Blogger uses this, as do Sony Austrailia and Yell to name just three.

torque


this was a difficult choice. i knew that i didn't want anything to do with real J2EE and the mindless tedium that is developing EJBs (ie writing tons of boilerplate template code for home, remote, whatever interfaces) and anyway i don't want to be running a heavyweight app-server. Resin (a lightwight J2EE container from Caucho Software) and JBoss (the de facto standard OSS app-server) are overkill. i didn't contemplate BEA WebLogic, IBM WebSphere, Oracle AS etc. for even a moment - they are all hugely expensive too, as well as requiring more cpu power than i or my client have available.

basically, torque is a spin-off from the turbine project, and now forms part of the Apache DB project, which is an attempt to produce a completely open-source database system by the apache organisation. this includes DDL (the data description language), an XML dialect for specifying relational database schemas. the torque system parses a DDL definitionj file, and produces a java object model. the model is provided as a set of SQL files used to create the database tables in whichever dialect of SQL you require, and a set of java source files implementing the model. the generation of the model and SQL is easily autyomated, and a build.xml ant file is provided that can be imported into your projects build process.

the objects created follow the JavaBeans standards, and come in two types. there are the actual model objects, which have get/set methods for the database columns in whatever table the object is represented by, and peer objects, which implement finder methods. the peers use torque criteria objects to specify which bits of the model to retrieve from the database and populate the model with, and can handle complex 1:n, 1:1 and m:n relationships. it is also possible to feed straight SQL to a criteria. the model and peer objects are defined as super classes, and a set of empty sub-classes extending them are made available for you to use in your project, and add any convenience methods you require.

generation and runtime configuration are accomplished by .properties files, which specify the dialect of SQL used, and a connection to a database. at runtime, the only thing required is to call Torque.init(properties-file) somewhere in your applications startup code. from then on, you can use the model and peer objects as desired, loading your data from the peer's finder methods, and calling .save() on the model objects to update them.

i particularly like torque because the only configuration required is the DDL, and the database connection details at runtime. the object model code is auto-generated, so you only need to write out your database definition once. for example, hibernate needs the database SQL to be written, the hibernate mapping configuration to be written in an XML file, and the model beans to be coded, which involves repeating the same list of fields three times, with different implementations, and hoping they all match. plus if you were to alter a table, those three files all need modified, with torque, just run the generator again after updating the DDL. spring just adds another configuration file representing the same data... (yes, i know things like xdoclet go some way towards solving this, but it's still complex, and just something else to learn.

i'm not sure how scalable torque is, but for a small webapp with a few users, i think it should be fine, and i believe turbine was designed as an enterprise class system, so you should be safe.

log4j


this is the best-of-breed standard java enterprise logging library. it is part of the Apache Logging project, available here. there are actually various implementations, in .NET, C++, Perl and several others, all using the same compatible API and output. configuring log4j can be problematic, since may j2ee containers and application servers also use it, and class-loader issues can prevent the library being loaded correctly. the onjava site has a good discussion of the problem, and it's solutions.

(note: this is not to be confused with commons logging, which is a super-api for many logging services. logging using log4j under the commons-logging framework will be covered later in this series.)

quartz


i need to have jobs that run, producing reports and emailing messages and information to users and administrators on a regular basis. quartz is developed by OpenSymphony and has been open sourced recently. it provides job/task scheduling for enterprise java systems, with facilities for triggers and schedules, including a cron-style trigger. this uses the same configuration options as the standard Unix crontab file, with a few extra selectors for ranges and last-n of month, third-m of month etc. i haven't added the scheduler to my current project, but this project appears to include everything i could ever need. there's also part of a soon to be published book, written by struts and j2ee developer and author chuck cavaness available for free download.

poi


an important part of a webapp for businesses is reporting. it's all very well to present data in HTML tables, but this is not easily exported into other applications for analysis. sometimes formatting your data as a comma-separated or tab-separated file is sufficient, but i prefer to output Microsoft Excel workbooks directly, and so do most users. the apache POI project provides apis to manipulate and generate DOC, XLS and PPT files. i used the HSSF (horrible spreadsheet format, by the way) routines to produce excel sheets with tabular data returned by an SQL query on a database. the code is extremely simple if all you want is numbers and text in boxes, and often that's all that the users need - they can pretty it up themselves. the api allows a lot more than this, though, and in my current project i'd like to take this a step further and start formatting the cells appropriately, and maybe even insert formulas and colours/lines to produce a sheet that can be printed out or used immediately.

related to the generation of MS Office documents is Adobe PDF file generation. there are a couple of options here that i have yet to fully explore. the iText library seems fairly basic, but there is a lot of good documentation and tutorials. for a more complex solution, XSL formatting objects may be the way to go. the Apache FOP project implements this.

the next installment of this series will deal with some more libraries, including many of the Jakarta Commons sub-projects. hopefully you found this information useful, but let me know if you think i missed anything or got something wrong...

No comments: