ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.F. Zarama" <jf.zar...@gmail.com>
Subject Re: Please Help in arguing for iBatis SqlMaps
Date Fri, 08 Apr 2005 03:46:37 GMT
Further help from IBM to newcomers on the subject include:

http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0502cline/
http://www-1.ibm.com/support/docview.wss?uid=swg4f0a6040763358eee85256f9c005cad80

http://www-128.ibm.com/developerworks/opensource/newto/
http://www-128.ibm.com/developerworks/opensource/library/os-merrier.html
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0410prial/
http://www-128.ibm.com/developerworks/opensource/library/os-worldos.html
http://www-128.ibm.com/developerworks/xml/library/x-think15/index.html

jfz.


On Apr 7, 2005 11:34 PM, Clinton Begin <clinton.begin@gmail.com> wrote:
> Hi Kaushik,
>  
>  I was going to respond with a technical rebuttal, until I read:  "my
> business acumen says that IBM will definitely take care of that".
> (apparently from your supervisor or something)
>  
>  Let me instead tell you how IBM made $96 Billion dollars in 2004.  Or you
> can read it yourself at: 
> http://www.ibm.com/investor/filings/index.phtml
> 
>  IBM basically makes money in two ways:  1) By selling software (that may or
> may not work) and 2) By selling services to "help" you with that software. 
> The profit from these services is about 50/50 and together they make up 70%
> of their total profits (their proprietary hardware makes up another 25%).
>  
>  Because 35% of IBM profit depends on also selling you services, it's in
> their best intersts to offer you products that are over complicated,
> underdocumented and that generally don't work well (i.e. WebSphere).  It
> simply makes business sense.  If you doubt my motives for this, let's look
> at how IBM spends their money.
>  
>  All of IBMs expenses can be categorized in two areas:  1) Sales, General
> and Administration and 2) Research, Development and Engineering.  They spend
> 80% of their money on SG&A and a measly 20% of it on RD&E. 
>  
>  So, when we look at how IBM makes and spends money we see this:
>  
>  * IBM depends on selling you complex software and proprietary hardware
>  * IBM depends on selling you services to support, extend and maintain that
> software and hardware
>  * IBM spends 4x more money on SELLING you these things, than IMPROVING them
>  * IBM makes you pay for all of this up front, but you won't know how bad it
> really is until your project fails
>  * IBM is a sales organization that succeeds in business by taking your
> executives out for lunch.
>  
>  In contrast, open source software:
>  
>  * Depends on compatibility and openess to achieve network effect
>  * Depends on an energetic community of smart people to keep it alive
>  * Spends 100% of resources on IMPROVING the software and none on selling it
> (except for this thread)  ;-)
>  * You don't pay a dime for it EVER whether your project succeeds or
> fails...you're never any worse off
>  
>  Open source software succeeds solely on its merits.
>  
>  Chances are your organization will still choose to buy into IBM (or Sun, or
> HP, or Microsoft, or ...).  I see it happen every day in large companies. 
> The other nice thing about open source software though, is that no matter
> what your boss chooses...I don't lose a dime.  ;-)
>  
>  Cheers,
>  Clinton
>  
> On Apr 7, 2005 10:55 AM, Kaushik Ashodiya <kaushik.ashodiya@ucop.edu> wrote:
> > Hi,
> > 
> > I have hard time arguing for iBatis SqlMaps (not because something wrong
> with SqlMaps).
> > 
> > Please give me more reasons so that I can convince them.
> > 
> > Their argument:
> > 1. For small project SqlMap is adding unnecessary complexity.
> > 2. Why learn one more tool when you have a simple base data access object
> that gives you connection, prepared statement and a result and does cleanup?
> (only when extended class calls cleanup() !!!)
> > 3. Generally open source projects dies shortly and does not have support.
> > 4. Adding many jars of those open source projects make out project more
> complex and un-maintainable.
> > 5. What if SqlMaps goes out of market? It is fairly new and not hardened.
> >  
> > 
> > 
> > 
> > <my-peers-arguments>
> > Again to re-iterate a point I was trying to make yesterday,
> architecturally speaking you should always try and keep it simple (not on an
> individual application level) but as far as possible on an enterprise level.
>  I'm going to ask you the same question that I asked yesterday...what do you
> think are the advantages/disadvantages of O/R mappings for relatively small
> applications where persistance is not the deciding criteria (or for that
> matter not even a criteria)?(I've attached yesterdays email thread for Kevin
> since he didn't get that one :))
> >  
> > I'll list the disadvantages:
> > 1) You add multiple third party jars (open source or otherwise), which you
> need to be aware of when building new apps.  These include components which
> the vendor will eventually provide if the market demand is high...
> > 2)You add multiple configurations for each of those products, which you
> need to understand on how to tune in case there are performance issues.
> > 3) Most of these components seem to be build on the current versions of
> jdk which take a decent time to hit mainstream commercial product support.
> > 4) If these products are not built to a spec (even though they may end up
> driving a spec), the migration process becomes an added overhead.  Even when
> they do become a part of the spec, the implementation differences of the
> vendor of choice may be so different that you pretty much waste any
> advantage of early adoption.  If you are a vendor of a product, an effective
> early adoption can translate into you either being bought out by the bigger
> established vendor or you getting to be a key player in that space....but we
> don't fall in that category.
> > 5)You need to be able to train existing resources to use the product
> (unless there is a plan to let go people and get "new" fresh resources who
> may have had experience with the adopted product).  Now if the existing
> resources themselves have a discomfort moving over to an object oriented
> paradigm, putting up them up against the challenges of going thru the
> learning curve of extra products further lowers the probability of success.
> > 6) You increase the possibility of chaos and reduce flexibility of
> resource utilization.
> >  
> > Besides the six points above, I would not recommend use of products like
> iBatis in applications at UCOP is because in my opinion the applications
> that we do or have done are relatively small and O/R mapping for those kinds
> of apps is probably an overkill (again personal opinion.)  To some level
> Hibernate is a valid candidate for evaluation (taking into account that it
> is driving the EJB spec). But again, my business acumen says that IBM will
> definitely take care of that.   
> >  
> > Now my perpective looking at the example below, one of the key
> shortcommings that I see is it couples the "Display/View" with the model
> (Data Access).... Basically what this means is that if you wanted to create
> the same object tomorrow from not a "non" database/jndi source, you would be
> re-writing the logic for creating the same object.  Another disadantage that
> I mentioned yesterday was if your display object gets created from multiple
> datasources (one db2, one sybase) transaction management becomes an
> issue....  How would you use iBatis in a system which does not need
> persistanc but needs transaction management?
> >  
> > Isn't the whole idea of going with some big commercial vendor like IBM to
> consolidate your infrastructure source so that you dont knock on different
> doors? Often such a vendor is selected based on how many services required
> by a business are provided by the vendor. Nothing against Hibernate or
> iBatis.  I'm sure they are great at what they are designed to do.  But each
> one of them doesn;t do all that we probably need  (they still  need an
> underlying EJB container.) If thats the case, why would you want to
> introduce the additional learning curve and the additional layer associated
> with each product? Do you truely think that it's a necessity?  
> >  
> >  
> > Short of long: I would recommend usage of vendor supported spec based ejb
> conatiner for applications needing persistance or transaction management. 
> Eventually these will be simplified (if there is fear of complexity....thats
> an issue the specs and the commercial vendors like IBM will definitely
> answer).  If persistance is not required, use the existing framework
> component.  What that does is you dont have to code the basic JNDI lookups,
> creation of connections, clean ups.  Since you are pretty much just
> accessing data, there is no coupling between the dataaccess and object
> creation.  The learning curve is almost next to nothing.  So I'd recommend
> for the present continue usage of the existing "Model" framework...
> >  
> > Just a small note on the side we'll still need to maintain components that
> we develop to be UCOP specific...(e.g. Employee Object etc).  These will
> have to be harvested in a generic layer outside individual applications,
> else we commit the same mistake that was made on ucfy, fje and danris (you
> copy the same code over and over again!!)
> > 
> > 
> > I wasn't ever saying iBatis is an O/R tool...  that was for Hibernate (I
> am trying to get your view on advantages/disadvantages of O/R mappings for
> relatively small applications where persistance is not the deciding
> criteria.)  The last email was just providing my thought process for not
> recommending the use of products that probably have little or no advantages
> for a business like UCOP.
> >  
> > Its a perspective with substantiation.  In the end we should try to do
> things becuase they make sense to our environment, not just because it's
> cool technology.  Is there a significant business advantage to using either
> iBatis or Hibernate, considering that we have existing solutions, be it ucop
> framework's jdbc component (comparing it with iBatis) or EJB/CMP (comparing
> it to Hibernate).
> >  
> > I've listed some of the disadvanatges of using iBatis and Hibernate in our
> environment.  Just to be fair, let me try to list some Advantages:
> >  
> > iBatis:
> > 1) Probably good documentation and support from user forums as compared to
> the ucop jar's jdbc component.  However, the design principle used for all
> ucop component is to enable novices to use it within minutes (and thats
> something that has already been proven)
> > 2)Resources with iBatis experience can be hired (Is there a plan?)....
> >  
> > All right I guess I can't think of more reasons
> >  
> > Hibernate V/s CMP:
> > Actually I cant think of any advantages since I know we have a EJB
> container....  
> >  
> > we should talk... it'll be an interesting discussion.
> > 
> > 
> > </my-peers-arguments>
> > 
> 
>

Mime
View raw message