Business Objects has had a commitment to Java developers for quite some time. Crystal Reports version 9 included a Java edition of the Report Application Server Software Development Kit (SDK), and Crystal Enterprise version 8.5 had a Java edition of the Crystal Enterprise SDK. Both of these solutions consisted of a processing tier of nonJava-based services and then an application tier of Java-based objects that acted as the entry point to those services. The theme here was around multitier, large-scale, enterprise applications. This might sound quite natural to some Java developers, who would argue thats what Java is for.
In the version 10 suite of products, the Report Application Server and corresponding Java SDK have been moved out of the Crystal Reports product line and into the Crystal Enterprise product line. This makes it clear that all servers are part of the Crystal Enterprise offering. However, without any other changes this would leave the Crystal Reports product without any Java-based developer components. Because developers have always been important to Business Objectsespecially Java developersthe Business Objects folks have spent a significant amount of time building a new offering in version 10 for Java developers: the Crystal Reports Java Reporting Component.
The key word in the name of the Java Reporting Component is "component." There is a clear distinction between the Crystal Reportsbased developer solutions and the Crystal Enterprisebased developer solutions. This is based around the distinction between components and servers. Crystal Reports provides reporting components and Crystal Enterprise provides reporting servers. The following sections describe some of the key differences between components and servers.
Components are self-contained and reside on the Web application tier. They are single tier in that there is no separation between the programmatic interface and the report processing. Although they can be run on multiple machines in a Web application server farm, they themselves are individual components and have no built-in mechanism to load balance or share state.
Although this kind of deployment architecture is initially attractive to many Java developers, many eventually find that the report processing degrades the performance of the Web application server to an unsatisfactory level. Keep in mind the size of your user audience before deciding to do all report processing on the Web tier.
Although the actual report processing of a single report is generally done just as fast with a component as it is done with a server, the capability to scale the components differs. Although a farm can be created, components running on different machines are not aware of each other and thus don have the smarts to figure out which component is least busy or has some information that is needed by another server. In general, the servers provide a more scalable, extensible solution for high-volume reporting. Obviously, cost can be a factor because the server solutions have higher licensing costs, so do your research about the product capabilities before you start development.
Besides product line differentiation, the other reason Business Objects created the Java Reporting Component was so it would have a 100% pure Java reporting engine. Although the server solutions have a pure Java SDK, the Java Reporting Component consists entirely of native Java code. This is attractive to both Java purists and also partners who embed Crystal Reports technology inside Java-based applications, and finally for customers wanting to deploy a reporting component on a Unix platform. Providing a 100% pure Java reporting engine means Business Objects rewrote a portion of the Crystal Reports engine into Java. Because this was not a total port of the functionality, some reporting features are not available. However, in practical terms, most reports off standard relational data will run just fine.