From: "Andrew C. Oliver" <[EMAIL PROTECTED]> > > #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).
There are many ways to work with HTTP, servlets is just one. There are many others even just at Jakarta. JSP, Velocity, Struts, Turbine, Avalon, Cocoon etc. Incidentally having worked with various 'distributed models' such as CORBA and EJB I find Servlets the cleanest and best designed applicaiton server solution so far by quite some margin. There's a great open source implementation of the spec (Tomcat 4) and look at all the diversity in layers added on top to improve developer productivity. > JMS is not > appropriate for a number of areas. Like what? > In truth I've not yet learned enough > about SOAP to speak intelligently about it All I'll say is I think SOAP has a much better future than EJBs. > > #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. There should be a strategy yes. Though this doesn't advocate EJBs. (Though I don't think you are advocating them). > 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) Agreed. Scalability needs to be thought about seriously. > > 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. Not really but maybe I'm not expressing it properly. Using EJBs wastes *alot* of valuable developer time when they could be doing something more useful like adding new features, making things more scalable or making things more performant. > 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. Agreed. > > 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". Agreed. > 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. Agreed - but like I said, they are pretty easy to do with HTTP, SOAP, JMS etc. It doesn't *have* to be EJB. That was my main point. Too many developers start building a web application and *start* with the EJB parts - rather than building the actual web application then seeing where EJB, JMS, SOAP or HTTP servers might help to distribute some of the load. > > 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. I don't follow. How is using EJB any less complex? > > 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) Agreed. > > 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 was just emphasizing that web applications are scalable - just add more boxes - and often they require quite modest hardware. EJB systems on the other hand can often need huge machines just to make quite simple systems. > > 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. Agreed. > 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. I'm just saying EJBs suck and web applications don't need them. Though I agree we do need something else. My other point I guess was that the area of distributed systems can learn an aweful lot from web technologies. > 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. Agreed. 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]>
