(accidentially sent off-list) ----- Original Message ----- From: "Dmitri Colebatch" <[EMAIL PROTECTED]> To: "John Harby" <[EMAIL PROTECTED]> Sent: Sunday, October 13, 2002 9:59 AM Subject: Re: the truth about entity beans
> I dont believe I mentioned buying anything... my argument in that email was > that you shouldn't be re-inventing the wheel, or inventing a wheel that > others also need. There are many useful open source frameworks out there > that are valid alternatives to ejb... in terms of persistence and O/R > mapping, castor comes to mind. > > ----- Original Message ----- > From: "John Harby" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, October 13, 2002 8:50 AM > Subject: Re: the truth about entity beans > > > > Yeah, as some of my views of late integration has become the IT mantra. > > Even the EJB container is not enough buy for IT. More and more are wanting > > to buy and not build. Providers such as Siebel are actually offering > entire > > e-commerce sites "out of the box" (although I would expect a good deal of > > effort to get these working ;)). Here is one site that is doing this > > already: http://www.tidalwire.com/default.htm > > > > > > >From: Dmitri Colebatch <[EMAIL PROTECTED]> > > >Reply-To: Dmitri Colebatch <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Re: the truth about entity beans > > >Date: Sun, 13 Oct 2002 08:21:00 +1000 > > > > > > > > > > transaction management, etc. > > > > > > > > > > > > You have to be more specific. JDBC does > > > > > > transactions. > > > > > > > > > > > > > > > > yes, but it does not do transaction management. > > > > > > > > That still doesn't explain it. Doing searches on the web seems to > > > > suggest that there most references seem to think that there is little > or > > > > no difference. > > > > > > > > So perhaps you could provide an example or a reference that explains > the > > > > difference? > > > > > >The real difference (in my view) is the transparent (from a coding pov) > > >support of XA. To be honest, I'm not sure what is meant by "transaction > > >management" in this context. But here's my understanding of the > advantages > > >of ejb tx model: > > > - XA support (can send JMS message and update db, or two dbs, in the > one > > >tx) > > > - transaction demarkation (can have some methods that must execute in > > >their own tx, and some that must create new tx, and some that never use a > > >tx... and so on) > > >both these features come without writing code. > > > > > > > I do not understand your point. I was trying to point out that > > > > understanding how to configure the container so it uses those > wonderful > > > > features takes time. And is sometimes impossible. The alternative is > > > > writing code to do some or all of the same thing. Presumably if > someone > > > > writes the code then they do understand how to use it. Naturally one > > > > alternative is to hire and expert from the container vendor and have > > > > them configure it correctly. But whether one figures it out themself > or > > > > hires an expert it still costs. And that step must be factored into > the > > > > calculation of the overall cost of the two alternatives. > > > > > >Ahh yes... and here's the real cruncher. OK, I'm more than happy for > > >someone to say "framework X is more appropriate for my requirements than > > >EJB", but saying "thats too hard to set up, and its cheaper to roll my > own" > > >is hard to see being entirely accurate. Writing your own framework (or > > >worse still not using a framework) means you will have more lines of code > > >to > > >maintain, and hence more bugs to fix. Sure, EJB containers have bugs, > but > > >at least its not your responsibility to fix them. > > > > > >We are still yet to see a suggestion for an alternative framework in this > > >thread. > > > > > >my 2c > > > > > >cheers > > >dim > > > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > > =========================================================================== > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
