They may indeed be. I think the arguments drifted to methodology (as far as whether distributed object technologies are even necessary which was moot). I'd really like to help with a case studies page. Some end-end Apache and Jakarta solutions. We should be a bit more "project agnostic" on this and include where HTTPD, or XML stuff was used.
There is only one problem with that. We need some case studies. Once you get the resources up, let me know, I'll at least write a placeholder page with a request. Thanks, Andy On Fri, 2002-02-01 at 11:01, 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]> > -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
