On Fri, 2002-02-01 at 08:53, James Strachan wrote: > Hey Andrew > > Insteresting thread ;-) >
Thanks! you too. <snip> > 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. > True, I don't like the Servlet approach. I tend to admire clean code and a Servlet approach makes this less likely (assuming the team is more than 1 guy and you have differing skill levels on the team). JMS is not appropriate for a number of areas. In truth I've not yet learned enough about SOAP to speak intelligently about it > #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'm not into XP, but often the scalability concern happens over night. There should be some framework in place for making it possible to do this somewhat suddenly. I'd say you have about a weeks warning on most systems on just how much you need to scale up after deployment. Systems are make it or break it. You can apply techniques to make this more predictive, but a lot of this happens outside my area of control most of the time. (Political, socio-economic and chaos theory are involved which often result in unpredictable community size, and you must plan to be way off no matter how careful or disciplined your approach) > 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. > I'm more into a scalable version of the RUP. In my opinion XP is a hack of a methodology (the RUP actually covers most of its issues). XP also suffers from the misconception that programming is the most important activity in software development (I would argue requirements gathering as the most important activity in software development...programming is easy, figuring out WHAT to program is hard.... This is not to say I'm not into an iterative approach to this, only that I think XP is lacking. At least it admits its own lack of scalability.) One day I'll start a project to create a methodology that merges the disciplined approach to software that I admire with the opensource principles and approaches that I think are necessary for effective teamwork. (minus the flamewars ;-) ). > 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 That is irrelevant to the issue. I would like to see an adequate distributed system (which it looks like there are at least 2 in the works within or slightly external to our community), and EJB does not fit the definition. > 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. > That doesn't mean you plug your fingers in your ears and say "na na na scalability I'll refactor later".. I find a balanced approach between planing for the future and refactoring later works best. We do need an adequate distributed object system for some situations. > 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. > > +1 > > > 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 ;-). > yes. > 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. > Its very difficult to assure data validity in this manner without some rather complex logic for database management. > 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. > CORBA sucks too. You're talking for more general web systems and I agree. There is a time and a place for a distributed CTM type approach, but there are not at present, good implementations of it. (the problem I'm pointing out) > 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 think you're about to find you have less luxury in the new market for having LOTS of hardware. > I still don't see the 'scalability' argument as in any way advocating that > EJBs are actually useful for web applications. > No EJBs suck. I'm arguing we need something better. I think you're thinking distributed systems as a whole are bad and perhaps we've worked in different problem areas so we've reached differing opinions on this. Distributed systems are NOT the answer for every system. In fact MOST systems do not. That being said, I've worked on plenty that used or needed a distributed approach regardless of whether they had one. I do thing CTMs are a good and necessary thing for some systems. I just think the EJB implementation of one is very poor. > In fact this idea that EJBs are required to build scalable web applications > is plain false - probably marketing hype spread by the EJB vendors. > +1 > James > -Andy > > _________________________________________________________ > 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]> > -- 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]>
