First, some background. I work for Sony Semiconductor & Electronic Solutions, and am based in Basingstoke, UK. Our current main business system is a client/server application written in PowerBuilder and uses a Sybase ASE12 database. Approximately 3 years ago, with the push to develop more ‘web based’ systems, and having a requirement from some of our customers, we embarked on the development of an Extranet. Being a Sybase shop, we opted for a combination of PowerBuilder and PowerDynamo running on Sybase’s Application Server - EAServer (formerly known as Jaguar CTS). We used Cynergy System’s EAF framework for this development. We needed to provide a download facility from this Extranet, and finding PowerDynamo a little lacking in this area decided to use Java servlets. After a week on a Sun Java training course we successfully implemented the site and it still runs today.
Around this time we made a strategic decision to base our future developments on the Java platform.
We also chose Borland JBuilder as our IDE. Our Applications Support area required a system to keep track of product versions. We decided to implement this as a web based system using J2EE technology. We chose Struts as the framework, and the application went live around 12 months ago, running on EAServer. The experience we gained during this project taught us that we really needed a good database persistence layer for our future developments. A Google search threw up Expresso, which had reached version 4, with version 5 in the pipeline. This was the first version release to be based on Struts, and provided the database persistence mechanism we needed via the DBObject, and as a bonus had a security mechanism too! After several days going through the Expresso Developer’s Guide (and quite a bit of code to fill in the blanks), I was suitably impressed. Some of the disadvantages in Struts, namely only one struts-config.xml and one ApplicationResources.properties file per web application were no longer present with Expresso. Each ‘sub-application’ within a webapp has it’s own ‘Schema’ class and separate struts-config.xml and MessagesBundle.properties files. Since we already had a Struts based application in production it seemed the ideal solution for us. Of course, at this stage I had plenty of questions. This is where Expresso’s excellent listserv comes in. There’s plenty of help and advice to be found here and it is truly invaluable for newbies and experienced Expresso developers alike.
Getting Expresso installed into EAServer presented no problems at all. I started off by using the supplied hsql database for the Expresso tables. I set up another context in Sybase ASE for my application tables. I have since migrated the Expresso tables over to a separate Sybase ASE database (took me around half an hour). All that I needed to do was modify one of the Expresso DBObjects to prevent ‘bit’ fields from allowing nulls (a Sybase restriction). I then ran the Expresso setup from the admin pages. The Jcorporate site has plenty of help with configuring most popular databases to run Expresso. I set up the Expresso source in JBuilder, and built a single JAR file of the Expresso classes.
A new requirement duly came along from our Sales and Marketing department, for a system to manage customer project information. We had around 3 months to implement this using 1 developer (yours truly). I felt pretty confident that I could meet the deadline using Expresso, even with the probability of a slight learning curve. By the time I started building the system Expresso 5.0 had been released.
Even though I was comfortable with Struts, I decided to use Expresso Controllers, States, Inputs, Outputs, Transitions etc. I did though wish to continue using the familiar (to me) Struts tag libraries, and Expresso provided it’s own ‘extended’ Struts tags to work with Expresso’s ControllerRequest and ControllerResponse. The documentation for these tags, however, was sadly lacking, and I spent quite a few hours getting to grips with the code to find out how they worked. Of course this is a great advantage of Open Source software – you can see how things work and you can add or change functionality to suit your particular circumstances (and contribute back to the project of course).
We also used the display tag library from jsptags.com in our Struts developments and this could also be used with Expresso.
I started off by getting my database tables designed. From these I then created my DBObjects. For the uninitiated, an Expresso DBObject represents a table in a relational database (see the Expresso docs for a full explanation). Expresso has a facility for generating database tables from DBObjects (and vice versa) but I decided to do it the hard way after being unable to get this to work in my environment (admittedly I didn’t try very hard!). It wasn’t a major thing for me as I was only working with around 8 or 9 tables.
Next, the Controllers and States. A ‘one Controller per DBObject’ model was a nice fit for this application, with separate State objects for display, insert, update and delete. Since Controller security is at State level this enables me to allocate certain roles display permission but not update for example.
For my View layer I used JSP with tiles and the Expresso extended Struts tags. The current version of Expresso (5.05 at the time of writing) has extensions to enable the JSTL (with expression language) to be used. We are also now making use of the tag libraries from the Jakarta Taglibs project.
This project was duly completed on time, and has been in production for around 5 months. It lives as a sub-application on our main applications intranet alongside the aforementioned pure Struts application. The only change I had to make to the Struts app was to rename the struts-config.xml to avoid conflicting with Expresso’s, and move it into the WEB-INF\config directory.
We’ve since implemented our second Expresso application which uses XSL Formatting Objects to generate PDF documents.
Now, I wouldn’t like to give the impression that everything was plain sailing from start to finish. I did have a few issues, particularly with DBObjects, MultiDBObjects and the extended Struts tags.
DBObjects have a method, setFieldsToRetrieve(), so that you can specify only the fields that you require in the generated SELECT statement. This had a bug which was easily fixed. There were also some inconsistencies in the behaviour of DBObjects versus MultiDBObjects. One had the ability to do case sensitive queries and the other hadn’t. Using setCustomWhereClause() in MultiDBObject wiped out the foreign key relationships between the composite tables. Also, it wasn’t possible to limit the columns included in an UPDATE statement to only those where the value had been changed. The extended Struts tags didn’t include a working <html:link> tag that worked with Expresso transitions. Well, since the source was freely available, I fixed the bugs I had found and added the functionality that I needed. I submitted these to the project for inclusion in future releases. This would save me having to port my own code to future versions. If you make use of a framework, it’s much easier and less painful to keep up-to-date if you can just ‘plug-in’ the latest release without having to re-customise it first.
In summary, Expresso gives us everything we need, and is constantly evolving and embracing new technologies as they emerge. The main purpose of a framework should be to allow developers to concentrate on meeting business requirements. Expresso fulfills this purpose, and once over the initial learning curve, allows you to do it more quickly.
Malcolm Wise is Technology Manager for Sony Business Europe in the division for Semiconductor & Electronic Solutions
|
Home | Products | Services | Partners | Customers | About Us | Login | Forums | Contact Us |
Last Modified: 18-Nov-2003