> Ever tried to do a distributed transaction across multiple database > connections? Hardly ever never needed them. When we did we wished for EJB's. I'd strongly recommend putting all your data on 1 big relational database so a transaction can be managed by it. This is far simpler than EJB's. Of course this isn't always possible - but you distribute data when you are forced to - not coz it's more high tech fun. Example - in the UK big companies buy a copy of the Post Office Address database & some software to call in their systems. Hundreds of companies install the same software & get regular database updates. Some time soon they'll just do an EJB call to a Post Office server - much better! Another example - online checking of credit details - 1 credit company services hundreds of users - code on it's server must be called from servers all over the place. These are a requirement of a minority of systems. I fear that over-use of EJB by people who aren't skilled/experienced enough is going to give java a bad name! & Microsoft is gunning for us. Vic is mostly right - forget EJB's use them only if you are driven to it ie. there is a significant real requirement. If high volumes are required you will need to performance test your app & have expert tuners available etc. Time for some-one to complain - this is off topic! PS I never used EJB's but looked into them & recommended my company not use them & I was right.
--- "Cakalic, James" <[EMAIL PROTECTED]> wrote: > Hmm. And this guy claims to be training other developers using Struts. If > this is the kind of ranting that goes on in his book then its no longer a > wonder to me why people have blasted it so mercilessly. > > Ever tried to do a distributed transaction across multiple database > connections? Hard enough without substantial design even when they are all > targeting the same physical database. Now try a distributed database. What > if your enterprise data is coming from multiple sources? Or you want to > involve messaging in the transaction? As for security, you can take it or > leave it in the EJB model. But wouldn't be a good idea to design a single > access point for such a resource to encapsulate the security policy? And > wouldn't it be good for that policy to be declarative? And wouldn't you like > the security credentials to be automatically propogated by the ORB? And > wouldn't you like the roles to be retrieved from the same mechanism used to > authenticate the user in the first place? And why would you write all that > when it already exists? > > Granted, excessive use of EJB technology just because it is in your pocket > is not a good design choice. But claiming it is always a bad choice > regardless of circumstances is just as bad if not worse IMHO. Disputing the > pros/cons of EJB and related technologies with someone who clearly does not > appreciate the systemic issues the technologies are attempting to address is > sorta like debating the benefits of MVC with one of those died-in-the-wool, > you'll-never-change-my-mind, always-choose-the-most-expedient-route Model 1 > programmers we've all run up against. They're so indoctrinated with their > own BS that they just can't see anything else. > > Jim Cakalic > > > -----Original Message----- > > From: Struts Newsgroup [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 20, 2002 12:25 PM > > To: [EMAIL PROTECTED] > > Subject: Re: EJB = bad = MS.net > > > > > > Subject: Re: EJB = bad = MS.net > > From: Vic Cekvenich <[EMAIL PROTECTED]> > > === > > > > Transaction: DBs have it; or you can have a Java Bean, that has 2 > > JavaBeans in it, and all have a "commit()" method. You use EJB for a > > commit()? > > Security? : > > -Menu based based on a role (using Struts-menu), some items > > are disabled > > based on your role. > > -JAAS JDBC Realms (I also get groupID) > > -Based groupID some rows retrieved / selected are editable, > > some RO and > > some invisible on your selects. It's called row based security. > > - Status based, based on a status of a row, some fileds become RO. > > > > EJBs give you 0 useful security. > > > > EJBs are also very slow to develop, and they distract developers to > > develop technology and not solve a business problems. They > > are also .... > > slow to execute, thus they are only suitable for small > > applications with > > low volume (and for organizations where a profit margin is > > not important > > or on going cost of operations is not important). > > THere are some with EJB and and some resumes with EJBs are by > > people who > > have written a laboratory "hello world" ejb and never > > actually used them > > in production deployed where there is volume. > > > > "Custom" RowSet can code circles around a large team of "EJB > > developers". > > OK, its a Flame: I have a bridge for sale by a smooth talking > > sales guy, > > aka The emperor is not wearing any clothes. > > > > Vic > > > > Carl Sziebert wrote: > > > > > Just a question for those of you who knock EJBs... How is > > it that you > > > plan to provide transaction management and security within your > > > applications? Going straight to the database won't provide that for > > > you. This whole debate makes me wonder how many people really > > > understand Java and quality application design. I suggest > > that anyone > > > with questions get themselves a copy of Pro JSP Site Design > > by Wrox. It > > > might help. > > > > > > This debate has the potential to go on for a while... > > Sorry, but I just > > > had to add my 2 cents. > > > > > > -----Original Message----- > > > From: Vic Cekvenich [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, February 20, 2002 9:42 AM > > > To: Struts Users Mailing List > > > Cc: [EMAIL PROTECTED] > > > Subject: EJB = bad = MS.net > > > > > > Home page of Jakarta has this > > > http://jakarta.apache.org/site/news.html#0130.2 > > > on this: > > > > http://www.mail-archive.com/general%40jakarta.apache.org/msg03376.html > > > > I agree. Doing EJBs is bad on many levels and creates more problems. > > Avoid EJB if you want to stay in Java. > > > > Alternative is to just use Struts + TomCat + RowSet (or DAO if you are > > doing something simple or small) and done. This is the sweet spot. MVC > > is all you need. > > > > Alternative, do EJBs and your organization WILL switch to MS .NET on the > > > > next project, leave J2EE, and you have to learn VB.net. > > > > EJBs are for newbies. (If you need middleware (very rare) use SOAP) > > > > lol, > > Vic > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > ===== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Search the archive:- http://www.mail-archive.com/struts-user%40jakarta.apache.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Keith Bacon - Looking for struts work - South-East UK. phone UK 07960 011275 __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
