>On Fri, 1 Feb 2002 18:35:55 -0000 "James Strachan" <[EMAIL PROTECTED]> wrote. >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. >
Of these I've used JSP, Struts and Cocoon. There are a few contributions I need to make to the other technologies documentation-wise before I'm ready/able to use them. From what I know of Velocity, Turbine, Avalon, they look very promising and I plan to use them in the future. >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? > UI, guaranteed failure situations. >> 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. > >From what I've read I'd tend to agree, though it looks...bulky. >> > #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). > +1 > >> 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. > +1! Like I said: EJB sucks. We need something better, not *similar* but in the same...space. A few postings to this list have indicated such things are in the works. I'll be studying them once I achieve a lower level of cycle utilization. > >> 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 understand. In summary, one can make due with other technologies, a distributed CTM technology would be a good thing, however efforts into a good and reasonable design, coverage of the requirements is far more important as a well designed system and a well designed CTM would allow you to switch through limited refactoring later. Unfortunately EJB does not fit that bill. > >> > 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? > It is possible to do this slightly easier with EJB just not as easy as it should be. > >> > 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. > Agreed. I have fully stated: EJB sucks. However it would be nice to have something there where you can isolate your database resources into a pool of *servers* such as with any transaction processing system (going back to even DCE crap -- which did suck too, but served a purpose) > >> > 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. > +10! > >> 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. > So it looks like we basically agree. ;-) We're very verbose guys ;-) >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]>
