Jasper, how to use in J2EE architecture.

[ktrinad]

By: BvRooij - barooi

Jasper, how to use in J2EE architecture.

2004-12-01 02:03

Hello everyone,

 

Let me first introduce myself, I'm Bob van Rooij. I am the architect responsible for the reporting functionality of our product.

Our product currently consists of a J2EE server architecture implementing a Business Objects & Rules framework including autorisation (all developed ourselfs). We develop on JBOSS but will need to support several mayor appservers, we therefore need to adhere to the J2EE specs without using too much appserver specific stuff.

 

Too much to go into right now, one thing that should be known is that we do not use entity beans to define our data abstraction layer, we use DTOs for this.

 

The application is also fully language independent on the server side with a separate translation layer between the client and the server.

 

Our client software is a feature rich Swing client that is fully tailored to work with our stateless J2EE server components.

 

Our reporting needs are two-fold, firstly we will provide complex reports using a large reporting system like Cognos or Crystal.

 

Secondly we aim to provide simple, ad-hoc reporting capabilities using a relatively simple report engine.

We've looked at a few of possible candidates for this functionality and our eyes are now fixed on Jasper reports to perform this role.

 

Jasper is simple, but very effective in our view. There are a few questions I would like to post here to help me decide on the architectural choices I need to make.

 

So if you have used Jasper in a similar architecture or have some tips please respond and tell me your experiences.

 

The report generator architecture I've designed is split into two mayor use case scenarios, wich result in two mayor sub-systems.

 

First there is a report definition sub-system that is used to allow users to define their reports, they build their Query here and also specify the properties on how the report should look.

 

We are not implementing a rich report designer like iReport, our reports are somewhat fixed in their layout (we provide simple list reports, consise list reports and thats about it..).

 

Off course grouping is available as wel as the use of sub-reports. This report definition data is split into two parts:

 

1. The Query Definition

2. Report Specific properties

 

Once a report is defined users may execute them, this will be the second sub-system; The report generator.

This piece of software will generate a Jasper Report based on the report definition, compile it, fill it (we will create our own JRDatasource which maps to our DTOs), view it and print it.

 

Now for the questions:

 

1. Client or Server?

 

Our system is used concurrently by 2 to 50 users, all capable of running reports.

 

We are considering on running the report generator implementation at the server side and send the resulting .jrprint to the client for viewing and printing.

Since our system is multi-language we will generate each report from scratch (so we do not pre-compile Jasper report definitions).

 

We do this because we need to generate the column headers in the report in the language of that specific user.

 

Off course we also considered doing all the runtime stuff on the client, which would result is less use of server resources, i'd like to think of it as a distributed report runtime.

Downside of the client approach would be increased network bandwith usage (DTOs need to be transported to the client) and raised memory usage.

 

What do you think, client or server?

 

2. Memory

 

The dataset will eat up the most memory, but what kind of figures are to be expected from Jasper?

 

3. Usage of temporary files

 

I understand Jasper needs to write to disk on some occasions. We would like to minimize this need. What are the mandatory files that are needed to be written to disk?

 

If Jasper will run on a server, are these files safely generated for concurrent use of the same Report?

 

Well, that's it for now. Any information is greatly appreciated!

 

Thank you in advance,

 

Bob