In-Depth

Business Intelligence Trends: A J2EE Cottage Industry

There’s a thriving market for J2EE-centric reporting tools—a surprising number of which are commercial propositions.

• By Stephen Swoyer
• 03/22/2006

It might surprise you to learn that the open source ecosystem is teeming with reporting tool projects, and that the Eclipse BI Reporting Tool (BIRT) is merely one of the newest SKUs on the shelf.

Open source reporting solutions abound, in fact, and at least one of them (a project called JasperReports) can claim to rival BIRT in terms of popularity. Open source hub Sourceforge.net lists dozens of reporting tool projects, many of which cater to what TDWI director Wayne Eckerson has described as an "underserved" segment of the technorati—Java or J2EE developers.

These projects are complemented by a host of commercial (or quasi-commercial) J2EE-friendly reporting products—tools from vendors such as JasperSoft (which markets a commercial reporting solution based on JasperReports), InetSoft (developer of StyleReports), InetSoftware (developer of CrystalClear), and Report Mill Software Inc. (developer of the ReportMill reporting engine and the Ribs GUI-based design environment).

More so than a lot of programmer-oriented open source tools—which are overwhelmingly IDE-driven propositions—these commercial offerings tend to focus even more specifically on user friendliness—especially with respect to highly usable GUI-based report design or client authoring facilities.

Shane Petroff, a programmer with Mayet Information Systems Inc., says his company taps a commercial solution as the embedded reporting component of its K-12 student administration software. "We utilize CrystalClear … for all of our Java-based products. We use it for standard servlet backend Web-based reports … via Tomcat [an open source application server] … and embedded into a Swing [Java] UI and embedded in a headless 'export' server which accesses the reporting engine's API's directly," Petroff explains.In this respect, he says, Mayet opted for Crystal Clear over another, more recognizable commercial solution—Crystal Reports. "Our selection criteria were highly non-standard. We originally committed to Crystal based on previous experience, and had to abandon that decision because the costs were so high and reliability so low. After investing thousands of dollars in report development it became clear that using CrystalReports was going to put us out of business," he comments, cautioning that Mayet experienced these difficulties with older (pre-Business Objects SA-takeover) versions of Crystal. "Inetsoftware's ability to leverage those original investments directly made the choice fairly easy. Approximately 80% of our original CrystalReports ran without alteration in inetsoftware's reporting package, and most of the remainder required only minor changes. The new tools handle the loads easily for a fraction of the cost."

A J2EE programmer with a not-for-profit R&D outfit who spoke on background had similarly encouraging things to say about another commercial J2EE reporting tool, Report Mill version 8, which he’s using as the reporting component of a large-scale inventory management, product movement, customer service, and pricing application his firm has been commissioned to build for a client. "[This] all [has to be] operated by the usual broad spectrum of users—[from] non-computer literate clerk- and professional-types to management specialists to computer geeks in the IT shop. The overall system will involve a lot of ‘marks on paper’ - barcodes, labels, operating reports and forms as well as extensive canned and ad hoc reporting printouts and enterprise data mining."

This programmer’s employer, too, considered a more prominent commercial tool—once again, Crystal Reports. But that product didn’t make the cut for a few reasons, the most serious of which included the fact that it’s not a native Java reporting solution, its its inability to accept plain old Java objects (or POJOs) as data sources (without requiring direct database connections), and—of course—its prohibitive cost. "The client has a preference for Crystal [in other applications in their corporate structure] but that has serious technical issues in the client mandated architecture," he concludes. "Cost is a major concern for the client. Licensing for the number of sites they have could be a major headache. Deployment could also be a pain."

A Sort of Homecoming

Cost is a major concern for just about everyone, and—for this reason—many users of commercial J2EE-friendly reporting solutions won’t discount the possibility eventually transitioning to open source alternatives, especially as solutions such as BIRT and JasperReports mature.

"BIRT is definitely something we are interested in, however, truth be told, we have not had the time to foray too far into that field," Petroff concedes. "We havea new project starting right now which could easily benefit from a less expensive reporting solution, and Jasper/JFreeReport and their ilk do not seem up to the task. BIRT's embeddable designer, it's capacity for tighter integration with existing Java code and the 'everything is a plugin' Eclipse-style architecture are all attractive, as is the IBM backing." He adds: "Somewhere in the next few months I will have to investigate further."

J2EE developers aren’t the only ones mulling a transition to open source solutions. Fact is, there’s a thriving market of freely available (and often open source) Microsoft-oriented business intelligence (BI) or reporting alternatives. There’s OpenRDL, for example, a Sourceforge.net project based on Microsoft Corp.’s Report Definition Language (RDL) specification that aims to provide an open source analogue to the software giant’s SQL Server Reporting Services (SSRS). There’s also RDLWriter, another SSRS-oriented open source project, along with a host of other Microsoft-friendly projects.

There’s a lot more where they came from, says TDWI’s Eckerson. "Well, Microsoft developers have .NET components and I've seen complete BI dashboards with drill down, hierarchy management, drill to detail done with a half-dozen .NET components for an enterprise finance department," he comments. These components aren't yet BI-specific, Eckerson concedes—in most cases, they’re custom built—but they could be the tip of an emerging spear.

Luke Philips, a software engineer with a prominent U.S. telco provider, tapped the open source BIRT tool for one of his reporting-heavy software project, but says his employer is already invested in SQL Server (it uses SQL Server Reporting Services elsewhere internally) and could conceivably pursue an SSRS-powered solution as it continues to build out its BI stack.

Java and J2EE development skills are pervasive across his organization, Philops says, but both remain a tough sell to the BI folks. At the same time, he stresses, his employer does have an enterprise-wide commitment to open source. So it would almost certainly tap any of several open source .NET initiatives in its next-gen BI infrastructure. "We don’t have a lot of Java expertise in the BI portion of our IT shop. It is possible we could use open source .NET tools in this space."