Framework comparision

Others Java Framework

Quartz http://www.quartz-scheduler.org/

Quartz is a full-featured, open source job scheduling service that can be integrated with, or used alongside virtually any Java EE or Java SE application - from the smallest stand-alone application to the largest e-commerce system. Quartz can be used to create simple or complex schedules for executing tens, hundreds, or even tens-of-thousands of jobs; jobs whose tasks are defined as standard Java components that may execute virtually anything you may program them to do. Quartz is very flexible and lite job scheduler that continues working despite system shut down. The Quartz Scheduler includes many enterprise-class features, such as JTA transactions and clustering.

The History of Quartz

Quartz has been around for a while, although it has started to receive a lot of attention this year. It was created by James House and originally added as a SourceForge project in the spring of 2001. Over the next several years, a number of features and releases came, but it wasn't until the project was moved to a new site and became part of theOpenSymphony family of projects, that it really started to take off and receive the attention it deserves.

House still participates in much of the development work, with several part-time developers assisting him. The Quartz development team has been able to release several new versions this year, including the 1.5 release, which is currently in a candidate release stage.

Features

Quartz comprises from small java library (.jar file) that contains the core Quartz functionality and scheduler interface is the main interface (API) to this functionality. It needs little configuration to be set in the system. Simple scheduling process like scheduling jobs, unscheduling jobs, starting/stopping/pausing the scheduler can be done through it.

How it works?

Quartz Scheduler automatically performs the scheduling operation once after it is configured and set up. If it is set for repetition, it performs the same. But before initiating the scheduling process, it needs to be instantiated (who'd have guessed?). For this, we can use a SchedulerFactory. After instantiating, you can implement the simple job interface to perform the scheduler executing process of your software components.

Uses

Quartz scheduler is used for performing process workflow, system maintenance and providing reminder services within an application. It is in use by many thousands of entities, many of whom have directly embedded Quartz in their own custom applications, and others who are using products that already have Quartz embedded within them. Quartz enables the programmers to write the code in the natural way with no intervention. It is a feature rich framework that is extremely useful for simply execution of certain system process on given schedules.

Other Features of the Quartz Framework

The Quartz framework has a very rich feature set. In fact, there are too many features to really appreciate in just one encounter. The following list will give a taste of some of the other features contained within Quartz that we won't have time to talk about in detail here.

Listeners and Plugins

Everybody likes Listeners and Plugins. Download just about any open source framework today and you'll be sure to find support for both of these concepts.

Quartz Listeners are Java Classes that you create and that will receive callbacks from within the framework when key events take place. For example, when a Job is scheduled or unscheduled, or when a Trigger has ended and will not fire anymore, all can be setup to notify your Listener. The framework includes Listeners for the Scheduler, for Jobs, and for Triggers. You can also configure the Job and Trigger Listeners to be global or specific to a Job and/or Trigger.

Once your concrete Listener is called, you can use this knowledge to perform any logic you want within your Listener class. If, for example, you wanted to send an email each time a Job completes, you could program that into the Job. You could also use a JobListener, which enforces a looser coupling and probably makes for a better design.

Quartz Plugins are new functionalities that can be created and added to the framework without having to modify Quartz source. It's done for those developers who need to extend the Quartz framework but don't have time to submit changes to the development team and wait for a new release. If you're familiar with Struts plugins, then you understand the use of Quartz plugins completely.

Rather than Quartz providing a finite set of extension points that may not serve your needs, you have an almost open-ended extension point through the use of Plugins.

Clustering Quartz Applications

Quartz applications can be clustered, both horizontally and vertically, depending on your needs. Clustering offers the same benefits as any other type of clustering:

· Scalability

· High Availability

· Load Balancing

Currently, Quartz supports clustering with help from a relational database and one of the JDBC JobStores. In a future version, this constraint will be lifted and clustering will possible with the RAMJobStore and will not require a database.

The Quartz Web Application

One of the needs of Quartz users that usually manifests after a few weeks or months of using the framework is the need to integrate Quartz into a GUI. There are facilities that currently exist in the framework that allow you to initialize and start Quartz using a Java servlet. Once you have access to the Scheduler instance, you can store it in the ServletContext of the web container and manage the scheduling environment through the Scheduler interface.

Fortunately, some Quartz developers have been working on a stand-alone Quartz Web Application that can be used to better manage the Quartz Scheduler environment. This GUI, built on top of several popular open source projects like Struts and Spring, supports great functionality, all wrapped up in a simple interface.

IBATIS http://ibatis.apache.org/

iBATIS is a persistence framework which automates the mapping between SQL databases and objects in Java, .NET, and Ruby on Rails. In Java, the objects are POJOs (Plain Old Java Objects). The mappings are decoupled from the application logic by packaging the SQL statements in XML configuration files. The result is a significant reduction in the amount of code that a developer needs to access a relational database using lower level APIs like JDBC and ODBC.

The greatest feature of iBatis is simplicity, and that is the only reason of being it easier to use in any database application. iBatis makes it really simple to use a database with Java or any other Microsoft applications.

Other persistence frameworks such as Hibernate allow the creation of an object model (in Java, say) by the user, and create and maintain the relational database automatically. iBATIS takes the reverse approach: the developer starts with an SQL database and iBATIS automates the creation of the Java objects. Both approaches have advantages, and iBATIS is a good choice when the developer does not have full control over the SQL database schema. For example, an application may need to access an existing SQL database used by other software, or access a new database whose schema is not fully under the application developer's control, such as when a specialized database design team has created the schema and carefully optimized it for high performance.

Comparing iBatis & Hibernate & JPA (Java Persistence API)

We introduce and compare two of the most popular open source persistence frameworks, iBATIS and Hibernate. We also discuss the Java Persistence API (JPA). We introduce each solution and discuss its defining qualities, as well as its individual strengths and weaknesses in broad application scenarios. We then compare iBATIS, Hibernate, and JPA based on factors such as performance, portability, complexity, and adaptability to data model changes.

iBATIS: Using SQL directly

Object-relational mapping (ORM) uses direct mapping to generate JDBC or SQL code under the hood. For some application scenarios, however, you will need more direct control over SQL queries. When writing an application that involves a series of update queries, it's more effective to write your own SQL queries than to rely on ORM-generated SQL. Also, ORM cannot be used when there is a mismatch between the object model and the data model. As we've mentioned, JDBC code was once the common solution to such problems, but it introduced a lot of database code within application code, making applications harder to maintain. A persistence layer is needed to decouple the application and the database.

The iBATIS Data Mapper framework helps solve these problems. iBATIS is a persistence framework that provides the benefits of SQL but avoids the complexity of JDBC. Unlike most other persistence frameworks, iBATIS encourages the direct use of SQL and ensures that all the benefits of SQL are not overridden by the framework itself.

Simplicity is iBATIS's greatest advantage, as it provides a simple mapping and API layer that can be used to build data-access code. In this framework the data model and the object model need not map to one another precisely. This is because iBATIS uses a data mapper, which maps objects to stored procedures, SQL statements, or ResultSets via an XML descriptor, rather than a metadata mapper, which maps objects in the domain to tables in the database. Thus, iBATIS enables the data model and the object model to be independent of each other.

How iBATIS works

iBATIS allows loose coupling of the database and application by mapping the input to and output from the database to the domain objects, thus introducing an abstraction layer. The mapping is done using XML files that contain SQL queries. This loose coupling allows the mapping to work for systems where the application and the database design are mismatched. It also helps in dealing with legacy databases and with databases that change over time.

The iBATIS framework mainly uses the following two XML files as descriptors:

SQLMapConfig.xml
SQLMap.xml

When to use iBATIS

iBATIS is best used when you need complete control of the SQL. It is also useful when the SQL queries need to be fine-tuned. iBATIS should not be used when you have full control over both the application and the database design, because in such cases the application could be modified to suit the database, or vice versa. In such situations, you could build a fully object-relational application, and other ORM tools are preferable. As iBATIS is more SQL-centric, it is generally referred to as inverted -- fully ORM tools generate SQL, whereas iBATIS uses SQL directly. iBATIS is also inappropriate for non-relational databases, because such databases do not support transactions and other key features that iBATIS uses.

Hibernate:

Hibernate is an open source, lightweight object-relational mapping solution. The main feature of Hibernate is its support for object-based modeling, which allows it to provide a transparent mechanism for persistence. It uses XML to map a database to an application and supports fine-grained objects. The current version of Hibernate is 3.x, and it supports Java annotations and hence satisfies the EJB specification.

Hibernate includes a very powerful query language called Hibernate Query Language, or HQL. HQL is very similar to SQL, and also defines some additional conventions. HQL is completely object-oriented, enabling you to leverage the complete strength of the object-oriented pillars of inheritance, polymorphism, and association. HQL queries are case insensitive, except for the names of the Java classes and properties being used. HQL returns query results as objects that can be directly accessed and manipulated by the programmer. HQL also supports many advanced features of pagination and dynamic profiling that SQL has never supported. HQL does not require any explicit joins when working with multiple tables.

Why do we need Hibernate?

Entity beans, which have traditionally been used for object-relational mapping, are very difficult to understand and hard to maintain. Hibernate makes object-relational mapping simple by mapping the metadata in an XML file that defines the table in the database that needs to be mapped to a particular class. In other persistence frameworks, you need to modify the application class to achieve object-relational mapping; this is not necessary in Hibernate.

With Hibernate, you needn't worry about database changes, as manual changes in the SQL script files are avoided. If you ever need to change the database your application uses, that can be easily accommodated by altering the dialect property in the configuration file. Hibernate gives you the complete power of SQL, something that was never offered by earlier commercial ORM frameworks. Hibernate also supports many databases, including MySQL, Oracle, Sybase, Derby, and PostgreSQL, and works well with plain old Java object (POJO)-based models, too.

Hibernate generates JDBC code based on the underlying database chosen, and so saves you the trouble of writing JDBC code. It also supports connection pooling. The APIs that are used by Hibernate are very simple and easy to learn. Developers with very little knowledge of SQL can make use of Hibernate, as it lessens the burden of writing SQL queries.

When to use Hibernate

Hibernate is best used to leverage end-to-end OR mapping. It provides a complete ORM solution, but leaves you control over queries. Hibernate is an ideal solution for situations where you have complete control over both the application and the database design. In such cases you may modify the application to suit the database, or vice versa. In these cases you could use Hibernate to build a fully object-relational application. Hibernate is the best option for object-oriented programmers who are less familiar with SQL.

The Java Persistence API

The Java Persistence API is the standard object-relational mapping and persistence management interface for the Java EE 5 platform. As part of the EJB 3 specification effort, it is supported by all major Java vendors. The Java Persistence API draws on ideas from leading persistence frameworks and APIs, such as Hibernate, Oracle TopLink, Java Data Objects (JDO), and EJB container-managed persistence. JPA provides a platform on which specific implementations of persistence providers can be used. One of the main features of the Java Persistence API is that any persistence provider can be plugged in to it.

JPA is a POJO-based standard persistence model for ORM. It is part of the EJB 3 specification and replaces entity beans. The entity beans defined as part of the EJB 2.1 specification had failed to impress the industry as a complete persistence solution for several reasons:

Entity beans are heavyweight components and are tightly coupled to a Java EE server. This makes them less suitable than lightweight POJOs, which are more desirable for their reusability.
Entity beans are difficult to develop and deploy.
BMP entity beans force you to use JDBC, while CMP entity beans are highly dependent on the Java EE server for their configuration and ORM declaration. These restrictions will affect the performance of the application.

To address these issues, the EJB 3 software expert group developed JPA as part of JSR 220. JPA borrows the best ideas from other persistence technologies. It defines a standard persistence model for all Java applications. JPA can be used as the persistence solution for both Java SE and Java EE applications.

JPA uses metadata annotations and/or XML descriptor files to configure the mapping between Java objects in the application domain and tables in the relational database. JPA is a complete ORM solution and supports inheritance and polymorphism. It also defines an SQL-like query language, JPQL (Java Persistence Query Language), which is different from EJB-QL (EJB Query Language), the language used by entity beans.

With JPA, you can plug in any persistence provider that implements the JPA specification instead of using whatever default persistence provider comes with your Java EE container. For example, the GlassFish server uses TopLink Essentials, provided by Oracle, as its default persistence provider. But you could choose to use Hibernate as the persistence provider instead by including all the necessary JAR files in your application.

When to use JPA

JPA should be used when you need a standard Java-based persistence solution. JPA supports inheritance and polymorphism, both features of object-oriented programming. The downside of JPA is that it requires a provider that implements it. These vendor-specific tools also provide certain other features that are not defined as part of the JPA specification. One such feature is support for caching, which is not clearly defined in JPA but is well supported by Hibernate, one of the most popular frameworks that implements JPA. Also, JPA is defined to work with relational databases only. If your persistence solution needs to be extended to other types of data stores, like XML databases, then JPA is not the answer to your persistence problem.

Comparing persistence technologies

Features	iBATIS	Hibernate	JPA
Simplicity	Best	Good	Good
Complete ORM solution	Average	Best	Best
Adaptability to data model changes	Good	Average	Average
Complexity	Best	Average	Average
Dependence on SQL	Good	Average	Average
Performance	Best	Best	N/A ^*
Portability across different relational databases	Average	Best	N/A ^*
Portability to non-Java platforms	Best	Good	Not Supported
Community support and documentation	Average	Good	Good

^* The features supported by JPA are dependent on the persistence provider and the end result may vary accordingly.

JFreeChart - JFreeChart is a free Java class library for generating charts, including:

* pie charts (2D and 3D)
* bar charts (regular and stacked, with an optional 3D effect)
* line and area charts
* scatter plots and bubble charts
* time series, high/low/open/close charts and candle stick charts
* combination charts
* Pareto charts
* Gantt charts
* wind plots, meter charts and symbol charts
* wafer map charts

JAT is a flexible Java base-framework which can be easily extended to improve projects start-up time. JAT allows to build Web applications (J2EE) or standalone application (server, batch, etc.). JAT supplies the main basic functionalities of any Java application, such as:

* High Business Object abstraction
* Integration facilities (provided for DBMS, LDAP and open to any software product)
* Authentication and user privileges management
* MVC pattern implementation (with privileges management and page flow control)
* HTML layout structure management (header, footer, menu, etc.)
* HTML dynamic contents and facilities (form, report, paging)
* Logging feautures
* Help on-line utility
* High configuration of all described functionalities
* Administration and configuration GUI