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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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> > > > >
