Obviously, I meant to say Apache is member of the J2SE group at Sun ... Ted Husted wrote: > > You know, since Apache is a member of the J2SE group at Apache, it would > make a lot of sense for us to develop a resource page regarding J2SE > scalability. > > I'd be very happy to start and maintain such a page here, as I do for > Struts. > > http://husted.com/struts/resources.htm > > If anyone has some starter links, send them along, and I'll get going. > > More importantly, we should also not hesitate to pubish our own orignal > material, such as case studies, if anyone here wants to pass one along > :-) > > Personally, like James, I think all the tools are already there, and > much easier to deploy that bothering with EJBs. The vendor slove to say > you get this-and-that for free, but the "hidden" costs are staggering, > and in the end, it's obvious that you lose much more than you gain. Two > steps forward, six steps back. > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Java Web Development with Struts. > -- Tel +1 585 737-3463. > -- Web http://www.husted.com/struts/ > > James Strachan wrote: > > 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]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
