You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by An...@healthnet.com on 2007/01/02 23:17:48 UTC
Offer of contribution....any interest?
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.
---------------------------------------------------------------------
Re: Offer of contribution....any interest?
Posted by Ma...@healthnet.com.
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
...matt.cleveland@healthnet.com
* There's no place like 127.0.0.1
"Clinton Begin" <cl...@gmail.com>
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, Andrew.X.Lewis@healthnet.com <An...@healthnet.com>
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.
---------------------------------------------------------------------
Re: Offer of contribution....any interest?
Posted by Clinton Begin <cl...@gmail.com>.
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, Andrew.X.Lewis@healthnet.com <An...@healthnet.com>
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.
>
> ---------------------------------------------------------------------
>