Hey Andrew Insteresting thread ;-)
----- Original Message ----- From: "Andrew C. Oliver" <[EMAIL PROTECTED]> > On Fri, 2002-02-01 at 04:14, James Strachan wrote: > > Hi Jeff > > > > I share your oppinions on EJB. Whenever I ask developers why they are using > > EJB the common answer I get from people is 'well I get transactions for > > free'. When most of the time they don't do 2 phase commit with their > > database anyways. And all that extra work just to get 'acceptable' > > performance from EJB. Jeez this stuff is meant to help us not hinder us. > > > > I agree that EJB has shoved too many things together in one 'server side > > component' framework. Perhaps working from core specs is better and just > > choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias > > is to use 'local' object technologies such as Java Beans, Servlets, JDBC, > > JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP > > or whatnot) when distribution is required. I try to avoid RMI if truth be > > told. It seems so 80s ;-) > > > > I'm still not convinced at all that EJBs are even worth considering when > > when building web applications - why should be business logic be remote in a > > web-centric world? Why not deploy the business logic with the web > > I agree with everything but this. > > For scalability you should have the option but should not always use > it. Agreed. Though I've 2 points to make. #1 you don't need to use EJBs to distribute business logic If you do need to distribute business logic, then there are various alternatives open, from HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits, cost/benefits etc. #2 just because you may eventually distribute your business logic, assuming you're going to from the start (and assuming that means EJBs and then jumping through lots of EJB hoops & headeaches and paying a fortune to some EJB vendors) is bad XP practice IMHO I prefer to take an XP approach, first build a web application that works, is performant and scalable then worry about whether business logic needs to be distributed later. Afterall us Java folk are OO guys right? We can write our business logic in such a way that it could migrate to EJB later if we think thats the right thing to do. Or to put that another way - I'd prefer to focus on giving the customer what they want and making a good web application than grappling with EJBs just because one day, maybe, under some conditions, I might want to distribute some of the business logic in the web app under the 'faith' that its the right thing to do. Most business logic in most web applications is pretty minimal in terms of computation and is often mostly database intensive so moving this code to another process doesn't usually buy much in terms of scalability - if anything its the reverse thats true - what with all that EJB distributed garbage collection & connection based protocol stuff that needs to be done scalability (and usually always performance) can go down. > If your application will grow it is good to have a middle tier that > can be moved and load balanced. With Entity beans of course this is > less possible. (And stateful session beans ;-). I think this is true of traditional GUIs, say a Swing client front end, a middle tier server (say server side beans aka EJBs) and a database. I don't think this is true of web applications as they are quite different things - a servlet engine is not a 'GUI' client. Servlet engines are a stable, performant and very scalable application servers in their own right. Get a hardware load balancer and a farm of servlet engines and your *way* scalable. Arguing for the need for another, remote CORBA component-centric application server based on mostly connection-based protocols, RMI, stubs and distributed garbage collection to make your web-application more scalable seems, well, strange. In my experience web applications scale best when you have a big server farm of servlet engines which are load balanced. A database at the back and hopefully some kind of read only caching going on to take as much load off the poor database as you can. Then you can distribute parts of your web application into different server farms, get load balancing, shuffle things around as load changes etc. Then pick the web technologies of your choice, Struts, JSP, Velocity, Turbine etc. Away you go. I still don't see the 'scalability' argument as in any way advocating that EJBs are actually useful for web applications. In fact this idea that EJBs are required to build scalable web applications is plain false - probably marketing hype spread by the EJB vendors. James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
