I work with Andrew, and want to give my support to his idea, but again, we are just tossing around ideas here, to see if they stick. If you will indulge me a long-ish email, I want to explain how we came to think of the iBatis approach as applicable to more than just JDBC. If you're in a hurry, just jump down to the section marked with, "***key point***"
We work for the web team of a health insurance company (Health Net) and our team supports 3 web apps/sites. These sites are effectively the public user interface of the company. We expose data and transactions from many internal systems to the outside world. This means that our app (which is pure J2EE) does a lot of integration with other systems. We integrate with dozens of other systems, some of which are JDBC and some of which are not. Our application is organized on a 3-tier architecture, where we maintain a separation between UI code, business logic code and data access code. Since we do so much integration, we consider "data access" code to be pretty much any interface with another system. Whether we access another system via JDBC or SOAP, it's just a data store from the perspective of our application. And we use the DAO pattern for any access to a data store, regardless of the access mechanism. The problem with DAO code is that it is 95% redundant regardless of the API used to query the data store. For example if you're using JDBC, then the code for getting the connection, preparing the statement, binding the parameters, executing the statement, iterating the result set, retrieving data from the result set, handling errors, dealing with transactions and closing the connection is all the same for every DAO method. The only thing that changes is which statement you prepare, which parameters you bind and what you do with the results. Of course this is why iBatis is so great, because it deals with the 95% and allows us to only deal with the 5% of details which change from DAO method to DAO method. And iBatis adds no new complexity like what you get with an OR mapper. So in short we love iBatis and are using it as our newly adopted standard mechanism for implementing JDBC DAOs. Now that we have been using iBatis for a while, we look at our DAO code for other types of data stores and see that it is also 95% redundant, and the redundancy is very similar. Let me give an abstract explanation of how we think of iBatis that will show how it might be applicable to other data stores. For any query or update, iBatis does the following steps. 1. Map input data from the application domain into a structured query appropriate for the data store domain 2. Connect to the data store 3. Submit the structured query to the data store 4. Receive the results from the data store in some structure that is specific to the data store 5. Map the result data from a structure specific to the data store to a structure appropriate for the application domain 6. Close the connection to the data store I know I've generalized a lot and left some stuff out, but hopefully this conveys the idea. When described abstractly like this, it's clear that most any other data store or integration code will go through the same steps. Also, all the steps are highly redundant for any data store and for any query or update, with the exception of 1 and 5 which are specific to the particular use case being implemented (in other words the mapping differs from case to case but little else). So we view iBatis as providing a good pattern to use for any data store, or integration code. I think LDAP is the most obviously similar, because it is conceptually a data store (though obviously not an RDB), and like JDBC it uses a standardized, text based, structured query format. Implementing an iBatis-like pattern for LDAP should be easy and would be able to use much of the iBatis framework and configuration code. However, we are even more ambitious than this and would like to implement the iBatis pattern for all our data persistence and integration code. ***key point*** Our idea is not to clutter up the iBatis project with a lot of code for other data stores and integration protocols, quite the opposite in fact. What we would like to do is extract the pattern of iBatis into a protocol-neutral, generic framework, and extract the existing SQL implementation into an extension of the framework. The code we want to contribute back to iBatis is just the abstraction, not necessarily implementations for LDAP, Soap or Tibco. I think it is a given that SQL will always be the most widely used application of the framework, but I also think that there are only a few small steps needed to abstract and isolate the framework from the SQL implementation. This would allow for other extensions supporting other stores and protocols to be written and maintained as contrib code or related projects. The benefit would be a quality, stable core framework that includes the basic pattern, plus a standardized configuration mechanism and some of the core mapping code, but the core framework in iBatis would not be JDBC-specific. The JDBC code would become the de-facto extension to the framework, and always bundled with it. You are absolutely right that we can fork the code or just simply use the pattern to solve our specific integration needs in a similar way, but we have a couple of reasons for wishing the iBatis project would adopt this approach: 1. We like iBatis, the existing code, and the existing configuration mechanism and would like to be able to build on it, but the only technical thing preventing us from doing so is the lack of generic base classes and other abstractions that would allow us to build non-JDBC extensions. 2. Why fork when there is a potentially significant amount of framework code that could be shared across multiple protocol-specific persistence implementations (in other words why fork when much of the code could reasonably be common between a JDBC, LDAP, Soap, etc. etc. implementation) 3. We feel like the changes we are suggesting are not really that large. 4. We feel like the changes would be a reasonable evolution of the iBatis code base Sound convincing? Is there any room in the project for separating the framework code from the JDBC code? Isn't this a reasonable evolution to the code base? I know this is an idea coming out of nowhere, so I hope that we have at least been clear in communicating the motivation for the idea. I hope we are convincing, but if we are not able to sell the idea, we will at least be using the iBatis pattern for our internal efforts. Of course if we were to attempt this refactoring and contribute the code, we know that it would need to be reviewed and accepted by the team. Our reason for bringing this up now is two-fold. First we would like to see if we can sell anyone on the idea. And second we would like to see if anyone raises any serious objections to our approach which we may have overlooked. Thanks for reading :) ...Matt Cleveland ...Web Architect ...Health Net Inc ...916.935.1248 [EMAIL PROTECTED] * There's no place like 127.0.0.1 "Clinton Begin" <[EMAIL PROTECTED]> 01/02/2007 04:30 PM Please respond to dev@ibatis.apache.org To dev@ibatis.apache.org cc Subject Re: Offer of contribution....any interest? I would appreciate the work, and as a team member I'd be honored that you would think to put this under the iBATIS umbrella. However, I think it's such a diversion from the central purpose of iBATIS that it would threaten to blur what iBATIS is. I would rather see it as a fork. Forks aren't bad when they're doing something completely different. They're only bad when they do exactly the same thing so as to confuse the meaning of the framework. A LDAP or TIBCO data mapping framework would clearly be differentiated from a JDBC framework. Just my initial thoughts... Clinton On 1/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: The team I work on is currently using iBatis for Java for all of our JDBC data access with great results, and having found the benefits of it, we are now working towards a data access solution that has a slightly larger scope than iBatis, but wit the same benefits and general philosophy. Specifically we need to retrieve data not only from JDBC sources, but also from other sources such as TIBCO and , LDAP. We are looking to have the same ease of use and power of iBatis with these sources, and will be doing all of the development and testing to accomplish this. What we really do not want to do however is try to fork the project. so we are faced with either building functionality similar to iBatis for the other sources, our strong preference extending iBatis to handle these sources. For reviewing the source code, the primary outward change would be to create additional parallel methods using a more abstract iBatis specific class or interface in place of Connection and SQLException. Obviously the internal changes would need to be more involved. Were this development completed and offered as a contribution, what is the current feeling on how well it would be received? Many thanks in advanced..... --------------------------------------------------------------------- This message, together with any attachments, is intended only for the use of the individual or entity to which it is addressed. It may contain information that is confidential and prohibited from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination or copying of this message or any attachment is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return e-mail and delete this message, along with any attachments, from your computer. Thank you. --------------------------------------------------------------------- --------------------------------------------------------------------- This message, together with any attachments, is intended only for the use of the individual or entity to which it is addressed. It may contain information that is confidential and prohibited from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination or copying of this message or any attachment is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone or by return e-mail and delete this message, along with any attachments, from your computer. Thank you. ---------------------------------------------------------------------
