Proposal for iBATIS Data Mapper Project

10 August 2004, Clinton Begin (, Ted Husted (

(0) rationale

A Data Mapper is "A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself" [Patterns of Enterprise Application Architecture]. Many Data Mapper frameworks are object/relational mapping (ORM) tools that generate SQL statements and support a subset of the possible object/relational mappings. Unlike ORM tools, iBATIS supports any conceivable mapping between runtime objects and a persistent store. Rather than generate SQL statements, iBATIS helps developers and database administrators manage SQL as an external resource.

The SQL statements used by an application are defined through a set of XML documents, as are the mappings. Literal and dynamic SQL statements are supported. When stored procedures are preferred, iBATIS provides a consistent interface for accessing either procedures or statements, as needed. Of course, value-added services such as caching, lazy loading, and transactions are supported by iBATIS and defined through the XML configuration.

iBATIS serves the needs of developers who need an advanced Data Mapping layer, like Apache OJB or Hibernate, but find it difficult to express their object/relational mappings with an ORM tool. The tradeoff is that iBATIS does not generate SQL, but many developers find this consequence to be an advantage rather than a drawback.

Teams worldwide have been using iBATIS is production for nearly two years. The approach continues to gain popularity and has been implemented for the two most popular enterprise software platforms (J2EE and .Net).

(0.1) criteria


The iBATIS project started as the work of a sole developer, Clinton Begin. As the community and codebase grew, Clinton recruited other members of the iBATIS community to work with him on the project, based on their prior contributions and interest. This group became the team that is now making this application. Current development is consensus-based. Discussions regarding development take place on an open list, where the entire community can participate. Although there are two implementations, there is only one iBATIS team, and all developers have commit rights to both codebases.


iBATIS enjoys a vibrant community of users. Since August 2002, almost 3000 support messages have been posted to the user and development lists. The 1.3.1 release of the Java implementation (January 2004) has had over 4000 downloads. In the first week of its release, the 2.0 release (June 2004) saw over 800 downloads.

The iBATIS 80 page developer guide was even translated to Chinese by one kind contributor. Translations into other languages are being planned.

The iBATIS .NET community is younger, but already show signs of growth. One user has already contributed an example application based on the iBATIS J{{`Pet}}`Store. Other users have demonstrated an interest in downloading and improving the C# source code. The team is working on create a joint set of documentation that the implementations can share, along with a common specification that implementations can observe.

Core Developers:

The core iBATIS development team is created from the most committed users from the community and industry experts. The core developers include the original creator of iBATIS and an Apache Software Foundation member as well.


iBATIS aligns well with existing Apache projects including Jakarta Commons and Struts. Many Struts users find a natural synergy between the frameworks because of the similarities in their principles and values.

(0.2) warning signs

Orphaned products:

The existing iBATIS framework is growing rapidly and recently released version 2.0. At the same time, nearly half of the iBATIS committers were focused on developing iBATIS.Net to bring the benefits of this paradigm to C# developers.

Inexperience with open source:

All of the iBATIS developers are familiar with open source. The iBATIS SourceForge project has been in existence for nearly two years. The second major version of the original Java implementation has just been released, along with the first major version of the .NET implementation.

iBATIS team members are active in other open source projects, including the Jakarta Commons and Apache Struts communities.

Homogenous developers:

Two of the developers share a common employer, but are not working on the project as salaried employees. The other developers are scattered around the globe, in Canada, the US, and France. The developers communicate by email.

Reliance on salaried developers:

Developers work on a volunteer basis. The project does not rely on salaried developers.

No ties to other Apache products:

Some people have described iBATIS as "Struts for the Persistence Layer". Many of the dynamic SQL tags were influenced by the Struts JSP tag library. iBATIS for Java makes use of a number of Jakarta Commons components. iBATIS for .NET uses Apache Logging. There is a great deal of potential for integration with other Apache projects.

A fascination with the Apache brand:

iBATIS shares a common license and culture with Apache products. We especially share the goal to create a product that outlives its original creators. We are not making this application to acquire the Apache brand, but to strengthen our technological and cultural ties. iBATIS recently expanded from a sole developer to a team of developers, and we want to continue and solidify our expansion by joining the ASF.

(0.3) subproject or top-level project

The iBATIS scope is as broad as products like Ant, Struts, and Maven. iBATIS is not just a Data Mapper framework, there is also a second Data Access Object framework, as well as an implementation of the infamous Petstore application. All implemented for both Java and .NET. Other subproject to create and maintain GUI tools and a common specification are planned, and PHP implementation may also follow.

The iBATIS team believes that all active committers should be PMC members. As iBATIS continues to grow, we expect the development/management team to also grow.

While the iBATIS products would fit under the broad scope of the project, the iBATIS developers would not be comfortable overseeing the products. We simply do not have enough experience with the other products to provide PMC-grade oversight.

Accordingly, our preference would be to apply as an Apache top-level project.

(1) scope of the subproject

Two main subprojects will be responsible for creating and maintaining the C# and Java implementations of iBATIS Data Mapper and iBATIS Data Access Objects. A third subproject, now in the planning stage, will provide a common specification for the implementations.

(1.1) interaction with other packages

iBATIS has very few dependencies. With the exception of commons-logging, all dependencies are optional and serve to enable features of the framework.

The following are optional Apache Software Foundation project dependencies:

  • commons-collections
  • commons-pool
  • commons-dbcp
  • log4j
  • xalan
  • xerces

The following are optional 3rd party dependencies, which do not need to be present to compile or run our software:

(2) identify the initial source from which the subproject is to be populated

(2.1) identify the base name for the package

  • org.apache.ibatis (Java)
  • I{{`Batis}}`Net (C#)

(2.2) identify the coding conventions for this package

The Java code mostly follows a Sun's standard coding conventions, including the following characteristics:

  • No newlines before braces
  • Indentation of two blank spaces (not tabs)
  • No underscores ("_") on private members
  • No "I" prefix on interfaces

The .Net implementation follows the coding standards provided by the Visual Studio.NET IDE and JetBrain Resharper plugin.

(3) identify the ASF resources to be created

(3.1) mailing list(s)

  • ibatis-ppmc (with moderated subscriptions)
  • ibatis-commits
  • ibatis-dev
  • ibatis-user-java
  • ibatis-user-cs

(3.2) subversion repositories

  • /incubator/ibatis

(3.3) jira

  • ibatis-java
  • ibatis-cs

(4) identify the initial set of committers

  • Gilles Bayon (**)
  • Clinton Begin (**)
  • Ka-Wai Chan
  • Brandon Goodin (**)
  • Ted Husted (**)
  • Larry Meadors (**)

(5) identify Apache sponsoring individual

Ted Husted, Champion and Mentor for the project, (as defined in

(*) CLA filed. (**) CLA acknowledged.


  • No labels