I have provided real life examples and some good points. I'm sure you could add some to these, especially if you've been around J2EE for 2 years. Tell us about some of the characteristics of J2EE systems you've built, such as load it handles, hardware/software it runs on, etc.
I have 3+ years experience with J2EE. But I have worked in only 10-15 projects, all of them quite large and quite different (hardware/software/db/solution-domain) therefore I cannot come up with consistent metrics I can vouch for. I agree with Sven that having those metrics would help lots to "sell" EBs to management, and the issue has been discussed here before. That is one of the reasons Sun came up with ECPerf. Producing these metrics is expensive. Also, their validity is limited because they're based on a number of assumptions(like that the applications that are run truthfully depict common applications) and are undermined by Moore's law. I think it is fundamentally flawed to expect to be given such metrics(very expensive to create and quickly out-dated) to prove that EBs aren't slow(compared to JDBC), specially because: EBs ARE SLOWER THAN RAW JDBC WITH OPTIMIZATIONS, all other things being equal. EBs AREN'T MUCH SLOWER THAN RAW JDBC WITH OPTIMIZATIONS, all other things being equal. If a large system is not fast enough(whatever it may mean in the solution-domain context), then falling back to raw JDBC isn't going to fix it, unless there is a poor architecture(so problems may only be concealed by changing persistence management). My point is: EBs do not provide per se any boost in performance that you couldn't code yourself using JDBC. Benefits of using EBs are connected with faster coding, no need to know about RDBMS, RBDMS independence, and less maintenance costs. Marginal performance boosts are available. I use Orion extensively(altough I've worked with other app servers). Apart from the extra fast web server(quite a lot faster than Tomcat), Orion implements caching techniques that minimize database hits that, while could be coded with raw JDBC, are quite difficult to implement. Also, as the spec and the server itself mature, optimizations refine(at no cost to me), bringing even more performance boosts. Finally, I suspect you raise the issue while having an agenda. I don't have anything against that as long as you disclose your agenda; otherwise, a valid debate(as I think this one is) becomes a pouncing session to a certain technology(and every technology has its flaws) just to prepare the field to introduce "the solution", in the form of a product. I didn't like it when people tried to make the list say "log4j isn't good" and I don't like implying that flaws in EBs should make everybody buy certain O/R tool. It seems to me that compiling information about these could be helpful, so I'm putting everything I can ellaborate about systems I've been involved with into a web page. If anybody wants to contribute feel free to send me the info. Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: Vin�cius de Faria Silva [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 11, 2002 6:40 PM > To: Juan Pablo Lorandi > Subject: Re: Re: the truth about entity beans > > > Dear Juan, > if you do not have arguments in favor of Entity Beans, it is > pity. If you plan to convince your customers about using > Entity Beans in J2EE projects... jokes about cars won't work, > be sure of it. I have been working with J2EE for 2 years and > i didn't hear any good argument from you in this thread yet. > I am sure this list is plenty of J2EE architects with > rational arguments in favor of using Entity Beans, as i have > already got today. > > regards, > > Vin�cius > > ----- Original Message ----- > From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, October 11, 2002 12:24 PM > Subject: Re: the truth about entity beans > > > > > > > > Answers like that, make me think that the lack of arguments > > > justifying the use of Entity Beans instead of O/R mapping > tools or > > > Session Beans + SQL, etc, is still a barrier for a wide > adoption of > > > Entity Beans by the market... > > > > > > > Also, one reason to promote O/R mapping tools is this: > > > > You've built one. > > You have a partner who built one. > > > > Let's say the company's name is... Mmm let's come up with a name > > here.... > > > > InterSystems. > > > > And let's say you built an O/R mapping tool... Let's call it.... > > > > Cach�. > > > > Let's assume you work on a company... Let's call it.... > > > > Cybiz. > > > > And let's say you have an alliance with that company. > > Then, probably you want to use O/R, regardless of metrics, etc. > > > > That's just another reason to favor O/R tools over Entity Beans. > > > > 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".
