Discussions

News: And the winner of the appserver marketshare war is...Tomcat!

Bookmark and Share Get thread feed

  1. And the winner of the appserver marketshare war is...Tomcat! (69 messages)

    The most commonly used Java application server execution environment today is Apache Software Foundation’s Tomcat, according to BZ Research’s latest Java Awareness Study, conducted in August 2002. In the study, 52.2 percent of all respondents said Tomcat was currently in use at their companies.

    "The app-server question response clustered into four groupings, with Tomcat standing alone. Next were the three major commercial Java app servers: IBM’s WebSphere, at 29.0 percent; BEA’s WebLogic, at 24.5 percent; and Oracle’s Oracle9iAS, at 20.8 percent."

    Read: http://www.sdtimes.com/news/063/story2.htm.


    Reply to this

    Threaded Messages (69)

  2. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    When did a servlet container become an application server?
    Unless tomcat supports EJBs, I wouldn't call it an app server.
    Reply to this Reply to original

  3. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Me too..
    BTW what is the definition of Appserver !!!

    Look at JBoss . Is it any app server.No i see that as an EJB engine !!!. Becoz you add separate Servlet engine into it. So if JBoss becomes the best appserver then how do they share the credit ;)

    cool.
    Reply to this Reply to original

  4. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Greetings,

    It runs Web APPLICATIONS - so it is an Application Server.

    Regards,

    Taras
    Reply to this Reply to original

  5. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    and if we use Tomcat , struts and good transactional classes
    do we still need Jboss or any other j2ee app server? Ejbs! ...we can do without them ...and all the rest of services can be provided by Tomcat ,jetty ...
    Faisal
    Reply to this Reply to original

  6. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Phhhh ... my first cgi's also ran APPLICATIONS ... please.
    Reply to this Reply to original

  7. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

       Well, literally, an application server is a program that serves applications.

       There are many enterprise-grade development frameworks/production apps that only require a servlet engine, EJB is not the defining factor of an appserver in my opinion, even if most of the products that call themselves appservers offer EJB.

    Floyd
    Reply to this Reply to original

  8. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I have to agree with Floyd. An application's robustness is more often a funtion of architecture, practices, and the developers than whether or not they use EJB's. I've seen EJB apps that can't handle more than about 2 transactions per week, and I've seen servlet apps that'll handle many thousands per minute.



    Plenty of people are handling major-league big transactional apps in Tomcat and Resin, and the servlet engines (without EJB's) of the J2EE vendors.

    -Newt
    Reply to this Reply to original

  9. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I've seen EJB apps that can't handle more than about 2 transactions per week


    2 transactions per week? Shoot the programmers! :)

    Floyd
    Reply to this Reply to original

  10. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    2 transactions per week? Shoot the programmers! :)

    I might have been exagerating a little. but you're right. shoot the programmers.

    -Newt
    Reply to this Reply to original

  11. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    "Well, literally, an application server is a program that serves applications. "

    Isn't that the definition for 'Operating System'?
    Reply to this Reply to original

  12. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Mr. Murali Varadaraja,

    An Appserver implements J2EE technologies, Web services, and other leading Internet standards to provide a reliable framework for highly available, scalable, and secure applications. Is this enough? if not, please write to me at krishananth at yahoo dot com.

    JBoss as an EJB engine...you're right, it also has an EJB engine.

    - ananth

    Reply to this Reply to original

  13. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Only newbies need EJBs. After some experience like these:
    www.basebeans.com/bad.jsp.
    you find.
    EJBs are not scalable; for real work people do roll you own beans such as http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/basicPortal_07/src/org/commons/DAO/

    You can't have performance and complexity.
    That is why JDO, and OJB (Jakarta), and others are trying to come up with something common other than EJB.

    Same is true of IDE. Vi and similar text editors is for real heavy lifting and handcrefting. Borland adds no value.

    The more companies spend on tools, server, the less they spend on people.

    Newbies feel that they will get support for being riped of... but oposite is true. Tomcat mail list is better support than paid suport, this is true of all open source.
    http://www.opensource.org/advocacy/case_for_business.php.

    btw. I use Resin with CodeGuide and pgSQL, over a DAO design pattern for persistance.


    .V

    Reply to this Reply to original

  14. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I have to agree with you Vic,

    I have seen a lot of lead-developers and architects moving away from EJB's and towards JDO or ORM. Sort of an epiphany process I've seen a lot. My first instinct after the release of EJB 1.0 was "wow...cool." Then I did it. Now I avoid them unless I really need them. Been workin a lot with OJB, and it's great too. 2.0 seemed to be come a lot of the way, but still not quite there.

    Although, I don't entirely agree on IDE's. Intellij doesn't really make me a better developer, but it does save me a _ton_ of time.

    -Newt
    Reply to this Reply to original

  15. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    ORMs are crap too. Use Object Relational Mappers outside of very simple result set mapping and you are doing yourself a huge dis-service. You put an abstracted object model on top of a relational database and you've masked away most of the power of the relational model. Why on Earth would you want to cover up the flexibability of the relational model with the cross eyed retarded static object model whose only real flexable part is polymorphism.
    Reply to this Reply to original

  16. Wrong again, Tony.[ Go to top ]

    Even the White Tornado knows that conflating an ORM with an RDBMS is helpful in myriad ways.
    Reply to this Reply to original

  17. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Vic -
    <Vic Quote>
    Only newbies need EJBs.
    </Vic Quote>

    Most newbies don't know what to do with EJBs.

    <Vic Quote>
    EJBs are not scalable;
    </Vic Quote>

    Sure they are. Where do you come up with such a blanket statement? Any technology won't scale if you don't understand it and use it properly. EJBs are quite scalable.

    Cheers
    Ray
    Reply to this Reply to original

  18. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Has anyone checked out Tomcat 4.1.x yet? It's pretty sweet. With JMX, a Struts based management web app, connection pooling, and a bunch of other neat stuff, you may actually consider using Tomcat in production (if you haven't already :)

    Speaking of Tomcat, does anybody know where I can find a tutorial on how to integrate Tomcat 4.1.x with Apache 2.0.x using JK2? The documentation on Jakarta's site is not that great (spelling/grammatical errors galore!)

    TIA
    Reply to this Reply to original

  19. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I´m using it in production (4.1.12). It really shines!!! It´s very fast.
    I can´t undertand why jboss keeps using something like Jetty. Throw that away, jboss guys!! Use tomcat 4.1.x!
    Reply to this Reply to original

  20. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    :I can´t undertand why jboss keeps using something like Jetty.

    Well, perhaps amongst the many reasons would be:

      + it is fast (faster according to latest benchmarks)
      + it has a lot less bugs reported against it
      + the development community is responsive and helpful
      + it is architected to be embedded within other applications
        and this allows a tight integration with JBoss and other
        app servers

    Jan
    Reply to this Reply to original

  21. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    It is not surprising to me that Tomcat is so popular... It is the "appserver" to which most people who are new to JSPs and Servlets would be introduced. After all, it is the "free, open-source implementation of Java Servlet and JavaServer Pages technologies" that SUN presents to people looking for information on JSPs and Servlets.

    We have been using JBoss/Tomcat in our production environment for over a year now. We have been very happy with this combination. We had been using WebLogic for some of our apps and Dynamo for others. (We "inherited" the applications...)

    To lower our total costs and to create a more extensible set of applications, we chose to re-engineer and rebuild the apps from scratch.

    Even though the EJB spec had made significant progress, we chose not to use either session or entity EJBs. I understand and appreciate the design patterns that have been developed around these technologies (the same sorts of solutions that we had developed around other distributed technologies, i.e. CORBA, RMI, Encina/DCE), but, at the end of the day, we couldn't justify the additional complexity and overhead given our environment.

    We do employ JSP, Servlets, JMS, JNDI, JDBC (via jRelationalFramework), JTS, JavaMail, etc. and MBeans...

    MBeans... Now there's a GREAT addition to the J2EE toolset. The idea of simple "plugging in" a fully managed message consumer into your application is awesome! Sometimes, some of the best uses of technology are pretty simple. It certainly isn't rocket science, but it makes using JMS and implementing message consumers a HECK of a lot easier. :)

    As far as what's an appserver and what's not... I'll leave that one alone. If you find the tool useful, use it. Who cares how it's categorized?
    Reply to this Reply to original

  22. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Here are some links on integrating Tomcat with Apache:

    http://www.acg-gmbh.de/mod_jk/
    It includes links to download a compiled mod_jk adapter.

    And another, longer tutorial:
    http://www.webmasterbase.com/article.php/305

    I've posted my notes on configuring Apache2 with Tomcat 4.1.X on Win2K here:

    http://www.convergentarts.com/wiki/index.php?pagename=Config

    -Tom
    Reply to this Reply to original

  23. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I gave a link bad.jsp above that supports that EJBs are not scalable, a word to the wise. Feel free to click and read some. But I can’t make you drink.
    I have had experience that they do not scale.
    I also see only newbies doing EJBs, the pros are kind of once burned twice shy.

    This is why MS .NET comes in and has an opportunity to claim that .NET are faster than J2EE.
    .NET is not faster if you do J2EE w/o EJB.

    Look at ADO.NET disconnected books and books in a bookstore, and claims around ADO. If .NET claims that it can do more with less resources, software engineers should pay attention, and address or switch.

    But if you feel you like EJB and you manager does not mind the resources, that's ok with me.

    .V





    Reply to this Reply to original

  24. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Vic -

    I have had plenty of experience that EJBs do scale. And scale quite nicely. Especially EJB 2.0. I mostly see newbies complaining how hard EJBs are to learn so they run away as fast as possible. I've read your source (bad.jsp) a number of times - it gets quoted often as reasons people have for not using EJBs. But just as a note, it isn't the be-all-end-all statement as to the usefullness of EJBs. Thankfully I am both a professional and I'm not a newbie AND I like EJBs. But the key to using them is knowing when and knowing how. If someone uses them simply as a persistence mechanism they stand a greater chance of failure. So, I still contend that you can't make a blanket statement like that. And since it doesn't require a lot of resources to do EJBs, my management and clients like it just fine.

    Cheers!
    Ray
    Reply to this Reply to original

  25. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I am very comfortable saying:
    EJBs take more resources and more time than if one by passes them and just does a regular Java Bean with DAO.

    I say this all the time.
    It is obvious. Complex things are slow, simple things are fast.

    You are welcome to disagree, I am not selling anything, other that this has been my experience.

    Again, read www.basebeans.com/bad.jsp, I found that I agree with those people.

    Folks, anyone can build a web site, kids in high school can. Same as anyone can build a bridge. But an engineer can tell you how tin a cable you can make and still support.
    So you can use EJB, and build a web site, I agree with that 100%.
    My experience is that if you avoid use EJB, you can spend less and have the web site faster.

    I found this out in hind site. I use to believe the hype. Than I found some rumblings about EJB problems and some people did other things. I tried the other stuff and it worked better.

    Also, I saw some people with my own eyes disappointed in EJB switch to .NET.

    I am not laying.

    .V




    Reply to this Reply to original

  26. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I have never heard of Tomcat referred to as an "application server" in my two years attending seminars and working with Bean-test.

    Steve
    Bean-test Engineering
    Reply to this Reply to original

  27. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    What about calling "Application Server" (AS) anything that
    hosts "business" layer and provides some set of
    framework/infrastructure/services. For example:
    workflow, logging, security-AA, deployment, persistance
    or easy access to it, administration, various
     utilities/libs, mails, plug-in-ability (sic-?),
    tools, transactions, jndi, you name them more...

    Tomcat fits this description providing some
    useful subset of services.

    AlexV.

    Reply to this Reply to original

  28. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    <quote>
     What about calling "Application Server" (AS) anything that
    hosts "business" layer and provides some set of
    framework/infrastructure/services. For example:
    workflow, logging, security-AA, deployment, persistance
    or easy access to it, administration, various
     utilities/libs, mails, plug-in-ability (sic-?),
    tools, transactions, jndi, you name them more...
    Tomcat fits this description providing some
    useful subset of services.
    </quote> -- Alex

    Sure, but it isn't fair to designate Tomcat as the most popular app server if most installations only use it for trivial dynamic content. I mean, how high would Tomcat rank if we only counted those installations that actually used at least two of the services you mention?
    Reply to this Reply to original

  29. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    <quote>
    Sure, but it isn't fair to designate Tomcat as the most popular app server if most installations only use it for trivial dynamic content. I mean, how high would Tomcat rank if we only counted those installations that actually used at least two of the services you mention?
    </quote>

    And how high would WebLogic and especially WebSphere rank if we only counted those installations that actually used more than plain Servlets and JSPs? AFAIK many departments have been given "Enterprise" licenses but just use them for dynamic web content, without EJB, JTA, or JNDI resources. There has even been an "overspending on app server licenses" report by some research group a few months ago.

    Tomcat 3.2 may have been a rather unhandy servlet engine, but IMHO Tomcat 4.1 is a rich and viable application server capable of running standalone. Even though it is not perfect and not the fastest of its kind, it is feature-rich and fast enough for many applications and thus a valid choice for both development and deployment.

    I wouldn't call Jetty a web application server, though, as it does not provide any JNDI resources. For me, the minimum requirements for a J2EE web application servers are: Servlets, JSP, and JNDI resources including JDBC datasources and JavaMail. Accordingly, Tomcat 4.1 and Resin 2.1 are J2EE 1.3 web application servers. Beyond, e.g. JBoss 3.0 (with integrated Jetty) and JRun 4 are "full" J2EE servers, including a web container but also an EJB container and a JMS provider.

    My personal view: Tomcat 4.1 is fine, but Resin 2.1 is my favorite - Caucho rocks! I wonder why the survey does not mention Resin as application server and IntelliJ IDEA as IDE. Both are very popular, so their marketshare can't be that insignificant. The "not a survey answer option" phenomenon, or "did not pay for being included"? ;-)

    Juergen
    Reply to this Reply to original

  30. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    :I wouldn't call Jetty a web application server, though, as it does not provide any JNDI resources.

    Perhaps, but it doesn't preclude you using any JNDI services you want, admittedly it's a couple of extra lines of code to set up, but it's certainly not *that* onerous. Also, AFAIK JDNI services are not in the servlet spec that defines web applications - which is what you're discussing - but it *is* part of the J2EE spec, which is why you get that service when you use Jetty within a J2EE server like JBoss.


    Jan
    Reply to this Reply to original

  31. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I did small test using elementary jsp + include_jsp,
    no access to database or business logic under
    constant or pseudo-random request load.

    Resin was able to serve 2-3 time more clients
    than OC4J and Tomcat. Started from ant Jetty
    was yet 2 time slower. Resin and OC4J were better
    than Tomcat in term of dropped requests.

    (just raw data)
    http://pages.infinit.net/sir/test/test-1.htm

    (For sure, speed of web container can be less
    relevant if bottleneck is business or database
    layer )
     
    AV
    Reply to this Reply to original

  32. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    The Jetty 4.0.x releases were not the best for
    performance, as new 2.3 servlet spec features did
    not fit well in the architecture.

    4.1 fixes these problems and is now the stable release
    and included with JBoss. For us it benchmarks twice as
    fast as tomcat 4.0 and approx 15% faster than 4.1.

    Jetty 4.2 is in development and lifts the bar another 10-15%

    Jetty uses standard jakarta jasper, for JSPs, so there
    should be no difference to tomcat there. The 4.1 release
    is using jasper2.

    Besides, the reason that JBoss bundles Jetty is probably
    more to do with support and branding rather than raw
    speed. Eg. tomcat 4 has >350 open bugs against it - which
    don't appear to be getting addressed any time soon. Some
    are over a year old and have yet to be analysed or assigned.
    Granted, most of them are probably kruft, but the support
    mechanism is very slow finding that out.

    Thus you wouldn't want to sell a support contract that included tomcat, unless your prepared to go resolve those
    350+ bugs yourself!

    Beside JBoss is an open platform and you can use tomcat if
    you really want to (4.0 only so far).

    cheers

    Reply to this Reply to original

  33. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    <quote>
    Perhaps, but it doesn't preclude you using any JNDI services you want, admittedly it's a couple of extra lines of code to set up, but it's certainly not *that* onerous. Also, AFAIK JDNI services are not in the servlet spec that defines web applications - which is what you're discussing - but it *is* part of the J2EE spec, which is why you get that service when you use Jetty within a J2EE server like JBoss.
    </quote>

    The Servlet spec says: "Servlet containers that are not part of a J2EE technology compliant implementation are encouraged, but not required, to implement the application environment functionality described in the J2EE
    specification. (...) Servlet containers that are part of a J2EE technology compliant implementation are required to support this syntax and should consult the JavaTM 2
    Platform, Enterprise Edition v 1.3 specification for more details."

    Accordingly, J2EE application servers have to support JNDI resources while pure Servlet containers don't. So I interpret the terminology as follows, according to the application developer's view (what tools are there?):

    1. Servlet container: Servlet, JSP, (HTTP server)
    2. J2EE web application server: + HTTP server, JNDI, JTA
    3. "full" J2EE-compliant application server: + EJB, JMS

    J2EE marketing does not differentiate between 1 and 2, more or less ignores both for deployment, and tells you to use 3 in any case. I see the areas of use as follows, including deployment:

    1. for simple dynamic websites
    2. for rich web applications
    3. for transaction-centric enterprise systems

    Note that 2 includes Web Services support, access to multiple databases, and even some legacy system integration. You will probably need additional tools for 2 and also 3, if not already included in the server distribution, e.g. an O/R mapper and a Web Services toolkit.

    Juergen
    Reply to this Reply to original

  34. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Respectfully disagree.
    Point in case: ECPerf is build on top of EJB, and it quite obviously scales. We can discuss whether it could be done in a better way etc, but it's a practical proof of EJB scalability (both horizontal and vertical).

    As for the links:
    - 101 has been discussed here at TSS some time back, and amongs the other things it was made apparent that the author(s) make false assumptions in a number of cases. Just going throught the first 10:
    1 - bean's not a bean. The idea of "bean" as presented by Sun is "a component", nothing to do with vetoable properties etc.
    2 - Remote access yes, pessimistic locking no. The spec does not mandate either pessimistic or optimistic locking, if fact no locking at all. Pessimistic locking (sort of) can be achieved with one of the commit options, but so can optimistic.
    3 - Pooling objects is not about saving memory, but the cost of instantiation and GC. OTOH, it represents very little saving for entity beans.
    4 - True with 1.0, not true with 2.0 Still can't do all but much better than 1.0. Not even close to a real OR thouhg :(.
    5 - So? Some of statements there are invalid anyway, as shown in 6-9 :).
    6 - Writing distributed systems with location transparency as a goal is a nice idealistic approach that won't work. Too long to discuss here.
    7 - Hmm.. not entirely sure what the author meant here. A number of the issues (value objects, client caching, serialization, don't know what mean by "session-based methods") stem from 6 - i.e. distributed system. Minimize number of your calls, maximize your granularity.
    8 - There's nowhere in the spec saying location cannot be transparent, indeed there's a number of AS that provide it.
    9 - Well, the spec does not address it, but leaves the area (as with a lot of other ones) open to vendors to implement. Again, concurrency is not trivial (unless you do pesimistic lockin) and should not be transparent anyway.
    So, about one point I could in better part agree with (4).
    ....
    Tim Hyde's mail is around the same things, most of which I will believe in J2?? 1.2 projects, but are quite different in 1.3 (I refuse to call anything earlier than 1.3 J2 Enterprise Edition)
    ...
    PetStore is in a class of its own. I don't know whether I have seen more overengineered, in parts badly designed and sometimes even seeming not to know what the spec says, application. All that PetStore shows to me is that there are some really bad engineers at Sun.

    That is not to say that EJB is great. In fact, I have a number of problems with them. For example no support for inheritance to name one of the worst ones - something I don't have a clue how they want to deal with and keeping backwards compatibility.
    Before 1.3 all that was usable were session beans. With 2.0, and the abstraction it gave to vendors (thus allowing vendor's optimizations) it is becoming more usable, at least for some applications.
    Regards,
    Vlad.
    Reply to this Reply to original

  35. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Hi Vlad,

    You wrote:
    > 6 - Writing distributed systems with location
    > transparency as a goal is a nice idealistic approach that
    > won't work.

    Why not? BEA Tuxedo supports what is (IMVHO) a pretty spiffy implementation of location transparency - your code has absolutely no idea about where the services it's calling are located, and these services can be deployed across servers however you wish, with little more than a config file change (and that file does not reside on the client, so the client doesn't even know / care that you've just moved the services around).

    > Too long to discuss here.

    I'm very interested to hear your argument(s) as to why location transparency can't work in practice. After all, there's about 17 years worth of Tuxedo systems that would seem to contradict what you're saying! :-)

    Cheers,
    Peter
    Reply to this Reply to original

  36. Location transparency[ Go to top ]

    Hi Peter,
    I should first clarify what I mean by location transparency (at least in terms of point 6). I used the wrong term really. My fault.
    So, what I meant is "your code cannot tell whether the invocation is local or remote".
    When you have this, you have a whole set of problems:
    - you cannot predict the performance. Doing
    for(...) {
     doSomething();
    }
    as a local call is obviously very different from a remote call. And if I don't know whether it's a local or remote, I can get some very interesting (=generally bad) results.
    - recoverability & failure. With local calls, when an exception happens, you know your code at least attempted to do something and what state you are in (more or less). With remote/local you cannot really tell what state the target is, because the problem could happen: while sending, on the other side, somewhere while receiving. ACKs don't help. Even with 2PC there's a state where if the whole thing drops, the system's state is "unknown" and has to be resolved manually. You can do some smart things by constraining your system, but there's no generic automated way how to get past this (basically a constraint that anytime you have to pass a piece of a non-persistent information between independent nodes, it can be lost).
    - there are some other issues, but I consider the above ones as the most problematic.

    If we talk about "location transparency" as in "it executes on whatever server I want and the failover switches to a new one" I don't have a problem with, it's achievable, and a number of servers does implement it now.
    Hope this clarifies it.
    Vlad.
    Reply to this Reply to original

  37. Nothing to fix[ Go to top ]

    <quote>
    They hired me to make them faster.
    Then a lot of them went out of business. That means less consulting for me
    </quote>

    Less work for all of us.
    Reply to this Reply to original

  38. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Vic -
    I guess my point is that EJBs can be good to use in given situations - I don't typically use them to build web sites - I use them in EAI/data warehouse work that I do. They work, perform, and scale very nicely.

    Cheers
    Ray

    Reply to this Reply to original

  39. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I hope you look at this banter as fun, since I do:

    http://www.cs.rice.edu/CS/Systems/DynaServer/perf_scalability_ejb.pdf

    If you look at page 6, it says EJB2 or Session Facade do 4,000 transactions per minute.

    Very respectable!

    (It also says w/o EJB it 12,000 transactions per minute)
    That is all I am saying.
    Maybe without EJB you need 1/3 less HW.

    Also, EJBs are complex. You can say you are expert since you can do it.
    Other say they are expert becuase they simplify. There was another thread here if J2EE is to complex.
    It could be.

    So development is more complex as well.
    But I do just MVC w/Struts, and DAO. KISS.

    .NET can't come close to Struts w/DAO in performance or producivity or cost.

    Next?

    V.


    Reply to this Reply to original

  40. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Hi Ray,

    Your post implies that you find EJBs useful in EAI and data warehousing but not very useful in websites. Why is this so? Can you elaborate on this? Thanks.

    Regards,
    Jason
    Reply to this Reply to original

  41. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Hi Jason -
    I actually just meant to say that I don't build web sites too often and if I did, I'm not sure how (entity)EJBs would stack up and if I would use them. For instance, if I just need persistance without all of the other pieces of functionality that comes with entity EJBs, I might use some other piece of the J2EE platform or JDO, that sort of thing. Often, people look at entity EJBs as strictly a persistence mechanism and that gets them into trouble. With some of the work that I do, it is helpful to have not only that piece, but the declarative transactions, naming, security, etc that comes with it. In that regard I find entity beans quite useful.

    Cheers
    Ray
    Reply to this Reply to original

  42. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Whatever you guys say..

    If its for the kick you guys need to aruge over some naming conventions....I think someone needs to play you " Grow up guys".

    But otherwise I agree TOMCAT is a real king.Having used both Resin and tomcat...I find resin is a speed=demon engine and tomcat is no way less.

    My just recent project """""" www.malebox.com """"" runs Tomcat 4.x with all time favorite MySQL holding approx 30,000 userbase and growing happily
    Reply to this Reply to original

  43. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    1.-What type of reasoning against EJB is "Very little effort was made getting EJB to naturally extend the Beans
    specification (remember Java Beans are not just about GUI widgets)." I mean...who ever said that the model followed the name???

    6.-"The EJB spec doesn't address access transparency. Local and remote object definitions are not transparent, as you inherit from a different interface and have to cast using the narrow convention." Thats is why several AS let you use remote interfaces with almost the same efficiency as local inerfaces (smart JNDI look-ups, intra-process calls and so)

    8. "The EJB spec doesn't address migration transparency. If any object moves, the client must throw away the remote or local interface and get a new one." Not at all.. ever heard of TAF for ejb clusters??

    9.- "The EJB spec doesn't address Concurrency transparency. There are no clear sets of locking strategies to suit different application programming tasks. The application and EJB programmer is left to handcraft locking
    strategies." ???? So what?? Almost every AS has several locking options for you to use....

    13.-"The specification does not provide for proper handling of views or read only tables. Back in the real world, read only tables and views are very important." That is why several Application Servers and frameworks implement it for you...


    And so on...i had to stop reading no senses..:-)...almost all the "Damnations" are well known issues well addresed by several application servers in the market...

    What´s your option??? Implement it all by yourself??? do you think that it will work better of be easier just becuase you use JDO or a DAO??? Not at all..we are all aware of many "lacks" in the spec... but still Application Servers have the solution in many cases, and it will almost 90% be a better implementation than your own "hand coded" one...
    Cheers

    Reply to this Reply to original

  44. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    <quote>
    What´s your option??? Implement it all by yourself??? do you think that it will work better or be easier just because you use JDO or a DAO???
    </quote>

    I keep repeating this (have a look at my post in the "J2EE Container Shootout Summary" thread):

    You can write well-architected plain Java services that access JNDI resources, execute JTA transactions programmatically if they need to, and use a decent O/R toolkit (e.g. Castor, Hibernate, OJB) for persistence. A very valid choice IMHO. And for remote accessibility, there are some nice toolkits too, e.g. GLUE, Caucho's Hessian/Burlap, or even good old RMI.

    EJB is a technology option, not a magic silver bullet for creating "complex" systems. Its main particular features are declarative transactions, declarative security, and simplified remote access including state management. If you don't need those, you are better off without EJB. And even if you do, you should probably stick to Session Beans, and use an O/R toolkit for persistence.

    Juergen
    Reply to this Reply to original

  45. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Vic:

    JDBC connection pools are more complex than just creating a Connection object on demand (that goes for all object pools).

    Building a cache on top of a DB is more complex than getting things straight out of the DB.

    I don't think anyone would argue that these more complex solutions are slower.
    Reply to this Reply to original

  46. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]


    "Also, I saw some people with my own eyes disappointed in EJB switch to .NET. "

    Yeah sure. They did't know how to use EJBs in the right way so they switch to .NET to *belive* they are doing it right.
    Reply to this Reply to original

  47. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    This is what you get when accessing http://www.ado.net/:

    Microsoft VBScript runtime error '800a01a8'



    Object required: 'Application(...)'

    /include/header.asp, line 64
    Reply to this Reply to original

  48. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I dislike those comments ... Coming in, calling EJB coders "newbies" and then "Hey, stupids, now listen what the real pros do". Might be you never really understood how to deploy them yourself?
    Reply to this Reply to original

  49. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]


    For some, it might be easier to believe that the links I gave out are by developers that are not as good as you.

    The alternative is that they are developers like you and me, and that some overspent or over designed. Sorry that you did.

    I agree with the camp that found EJB FUBAR (Fouled up beyond repair).

    Consider that .NET says they are faster and cheaper.
    I do not believe that! My clients say .NET is slower and more expensive!
    Building a Web App in .NET is more expensive, and costs more to deploy, and more to operate and have other limitations.
    For writing commercial large scale applications, there is only one choice and that is J2EE.
    You do have a choice of vendors and a choice of proven high performance designs, such as beans that use rowsets and static data source.
    (One such example is Apache license (read free and open source) of a good practice example at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/basicPortal_07/src/org/commons/DAO )

    But you can also make bad choice on a vendor, or a use a slow design. The clients that make mistakes, might find that next project is ASP with ADO, and rightly so. It is only fair.

    At no time did I say that you can’t deploy EJB. I just said that they are not as scalable as alternatives, in this case, cheaper alternatives. (Slow, difficult and expensive, why do that?)
    EJB’s do not make sense for persistence.
    http://radio.weblogs.com/0107789/stories/2002/05/24/isEjbAlwaysNecessary.html
    One more link.
    Garner group says that over 80% of people should never look at EJB.
    Read baseBeans.com/bad.jsp as to why.

    Another way to say it, if you did not need CORBA in the past for you application, you do not need EJB.

    Only the paranoid survive.

    In the long run, it will be open source vs. MS, with inevitable open source win, Tomcat in this case.
    See:
    http://www.opensource.org/advocacy/case_for_business.php

    For one, .NET has very few seasoned developers to follow.

    Peace,

    .V
    ps:
    Oh, and I can teach you a "good practices" way to develop faster, hands on labs, as per:
    http://www.mail-archive.com/mvc-programmers%40basebeans.com/msg00242.html






    Reply to this Reply to original

  50. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    No, "open source" (os) will not overpower MS.
    It is a dream.

    What can overpower MS is full of new ideas
    somewhat chaotic os (e.g. sourseforge) PLUS
    more focused organized os (e.g. Apache) PLUS
    big players's comunities (e.g Borland, Eclipse)
    PLUS big players (e.g. Ibm,Bea,Oracle etc)
    PLUS managers of standarts (e.g. Sun JCP)

    BTW, somebody mentioned that open source
    flagship Apache is [partially] IBM's baby.

    There are nice cars builded in backyards and very
    first cars were build exactly this way. But now
    millions ppl drive cars builded by big companies.

    AlexV.
    Reply to this Reply to original

  51. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Vic -
    <quote>
    I agree with the camp that found EJB FUBAR (Fouled up beyond repair).
    </quote>
    No offense intended, but I find it difficult believing that you have done anything real with EJBs other than read about them on the links you provided.

    I absolutely agree with you that not everyone needs to use them, and if people are using them for persistence only then they are very likely in for trouble. However I do use them a lot, they are not slow, difficult or expensive, and in fact add a great deal to the projects I work on (EAI, warehousing). If one knows how to use them and when to use them, they can be great.

    Weren't you the one suggesting that newbies are the only ones to use EJB? I think you are taking the line from your bad.jsp out of context. While newbies do use the technology, very often they use it badly because they don't understand it. At least that has been my experience.

    Cheers
    Ray

    Reply to this Reply to original

  52. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Ray,

    I agree with you that maybe Vic's line of reasoning is flawed, and that EJB's certainly have their place.

    I quite like the idea and use of EJB's and still use them. I have a coupld of "however's" though.

    First, I consistently see people using EJB's simply because that's sort of the buzz-word technology that sells. This in itself certainly doesn't make EJB's bad (non-sequiter).
    And it's not even really a "newbie" problem, it's a business problem of choosing the right tool for the job, which may or may not be EJB.

    Second, and sort of a continuation of the first: EJB's are often used in places where they are just overkill. My term for this is "it's like swatting a fly with a pickup- truck." You can do it, but it makes more sense to use something else. Again, it doesn't mean that EJB's are bad, it's just that they are either oversold by vendors, or overused by developers, or both. I've just seen this happen too many times, and talked to too many people with the same experience. Again it comes down to the right tool for the job. To many people (on sales, development, whatever) think that since EJB's are designed with certain things in mind, that's _always_ what they should use for those things (persistence, whatever).

    Third, and this is really non-technical: I _have_ seen a lot of very experienced developers and architects moving away from EJB's. This has nothing really to do with Vic's line of thought about newbies or whatever. It probably has to do with the first two things I mentioned. These people, who have lots of experience with EJB's, hand-coded JDBC, and maybe ORM or JDO are beginning simply to realize that EJB's are not the catch all solution that is advertised. To sound repetitive, it doesn't mean EJB's are bad, just that when the design analysis is done, EJB's aren't the only thing that meets the need, and sometimes they aren't the right fit: Too many people fitting a suare peg into the round hole with EJB's.

    I went through the third process a bit myself: I got a bit sucked up into the EJB hype. When they first came out, and then in version 1.1, I thought I'd just use EJB's all over the place, "man what a great way to do things." But I simply had to come to the realization that it's really, "man, what a great way to do _some_ things." I particularly like the EJB 2.0 spec, although it's still got a little ways to go.

    So, my point is not that EJB's suck, it's just that they aren't the panacea that has been so hyped, and as people and companies get greater institutional knowledge of them, they are realizing that there are other things that can be used in certain cases.

    As to Tomcat being an App Server, I don't know why everyone is so resistant to that. I mean, who really cares?! If it works as an app server for one company that's fine. If it doesn't and you need Weblogic or JRun or Orion or whatever, also fine. It seems that too many people in here are getting caught up in the hype, and too few are just looking at these things as the tools for doing the job; more importantly choosing the _right_ tool for the job. Hell, if PHP or Cold Fusion (pre-J2EE cold fusion) work, more the power to them.

    -Newt
    Reply to this Reply to original

  53. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    "it's like swatting a fly with a pickup- truck."
    As the link above pointed out, (transactions per minutes) EJBs are slower to do same thing than not using them. This was an independent 3rd party test, so you can say every one of the links was done by people who do not know EJB. They used to do EJB, now they don’t.
    Conclusion: If you need high performance or low cost for persistence (ok I adjusted) avoid EJB.
    If you think you need high performance and because of that select EJB, than you missed the point.
    More like using a spoon when you need a knife.
    I now mostly see people who do not have experience using EJB, such as PHB, people with experience moved on.

    Above link on why open source says that open source build better quality sofware.

    This link say big companies like MS build bad software:
    http://www.tuxedo.org/%7Eesr/writings/cathedral-bazaar/index.html

    Ex: Most companies bar Windows on web for servers because they are not secure. They use Linux. (I read someplace that Linux has more server market share than MS, not even counting other Unixes)
    IIS has smaller market share than Apache. Source: Netcraft.

    It is possible that Tomcat will have larger market share than .NET. It has lower cost of operations, so people gravitate towards it.
    Companies that waste money, end up merging with companies that are efficient, so with a lower cost of Operations, it goes in that direction over time.

    When you have a new project, consider how you can lower the cost, based on your experience.
    If I got you to hesitate before doing EJB, I am satisfied.

    .V

    ps: One reason I dislike EJB is that Silicon Valley used a lot of EJB based on Hype. It required lots of expensive HW and SW.
    1 HW for Web Server. 1 HW for App Server. 1 HW for EJB server. Lots of EJB servers. They hired me to make them faster.
    Then a lot of them went out of business. That means less consulting for me.
    Reply to this Reply to original

  54. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Vic -
    I can assure you that if I don't need a technology I don't use it. I don't use EJBs because of hype - if you bought into it, sorry. I know lots of people that went ape with the technology and got burned. I didn't. I don't run out and use EJBs (or any technology) because I read it somewhere - I do it because at this time it makes since with what I do because we are moving from a CORBA system to a J2EE system. It's easy. It scales. It's not expensive. In fact it's far, far cheaper (and easier) to develop and maintain than the CORBA system we are moving from. I'm not developing web sites.

    I'm glad your links mean so much to you - unfortunately they have less meaning to me than perhaps you would like. It's great your writers have their opinion. While I'm not always successful, I try and not get caught up in hype from either side. It's just a tool after all. If you don't like the tool, don't use it. Simple as that. There are plenty more tools out there.

    That's all for me on this particular topic - at least for now. I'll leave the last word to you if you desire such.

    Cheers
    Ray
    Reply to this Reply to original

  55. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    EJBs? EJBs are a bullshit scam that only serve to slow down and complicate your application.
    Reply to this Reply to original

  56. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Posted by Anthony Bielobockie 2002-10-03 08:15:25.0.
    > EJBs? EJBs are a bullshit scam that only serve to slow
    > down and complicate your application

    Truely spoken by a person who doesn't know how to code and how to use EJBs.

    People tend to blame poor performance on the software/compilers rather than put into to doubt their know all knowledge. Humans beings are simply too perfect, if the thing doesn't work it's because the concept sucks, not the developper.

    I remember doing a small PoC to convince IT to go ahead with the projet using stateless EJBs within weblogic and oracle. If my souvenirs are correct we where handling roughly 350 contextual transactions (business transactions) per second and a couple thousand database transactions per second.

    Now from reading all the interactions (i answered Anthony's mail, but i'm refering to all the previous mails) i believe that most posters need to read some good java books. Confusing JDO, Servlet engines and EJBs is like confusing my hairdresser with my dentist: they don't do the same flipping thing!

    If i where you, i'd get a life, a brain and a good java tutorial.

    However, the question is what is an appplication server in this contexte (Floyd pointed that out)? Surely one can't pretend in this contexte that it is a J2EE compliant server.

    What services should an application server offer ?
    If i where answering the question i'd say that Tomcat doesn't offer a messaging service, hence it ain't an app server :o)

    If we refer to the official website (jakarta.apache.org/tomcat) it says:

    "Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies"

    I don't see application server standing there fellows ...

    Cedric

    ps: By the way i don't recall taking part of this survey or seeing, so what is it worth ?
    Tomcat coming out first may proove that a lot of college students voted, more than professional ITs ? :o)
    Reply to this Reply to original

  57. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    <quote>
    I believe that most posters need to read some good java books. Confusing JDO, Servlet engines and EJBs is like confusing my hairdresser with my dentist: they don't do the same flipping thing!
    </quote>

    You don't bother reading the posts carefully, do you? I consider my previous elaborations in this thread appropriate and reasonable.

    Discussing JDO and the services of a web container does make sense in the context of the benefits of EJB:
    - JDO and O/R toolkits are alternatives to EJB CMP, for persistence of lightweight, fine-grained entities;
    - "J2EE web container" aka "servlet engines" provide not only servlets and JSPs but also JNDI resources and often even JTA;
    - EJB "just" adds remote accessibility, declarative transactions, and declarative security: particular features for those who need or like them;
    - the same applies to JMS: use it if you need asynchronous messaging, else don't bother about it;
    - therefore a decent J2EE web container is a valid and viable alternative to a full-blown J2EE-certified application server that also provides EJB and JMS.

    I have stated my views numerous times at TSS, including that I do consider EJB a valid choice: an option in the J2EE toolkit but not the magic silver bullet for every system.

    Finally, you are right, noone should blame EJB: Use them if they are appropriate, it's your choice.

    Juergen
    Reply to this Reply to original

  58. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Before EJB came out, We also call servlet engine App Server. Such product I used like Websphere2.0, only Servlet/Jsp. I did call it app server. Before Servlet, we also have the concept of app server, it is a generic term...
    Reply to this Reply to original

  59. EJB=servlets[ Go to top ]

      In my mind, servlets and EJBs are exactly the same thing: a piece of software that does not run on its own but invoked by a container. Same issues of localization, pooling, state, etc.

      There is some discrepancy in the APIs for legacy reasons, but I see no reason a servlet should not be a specialized class of SessionBean. There is some confusion because they tried to put more services in EJB like persistence, altough it should have been the job of JDO (if it were born at the right time) to persist the stateful session bean, and now I am wondering why we have stateful session beans and entity beans.


    Loïc
    Reply to this Reply to original

  60. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    What the hell Tomcat , first ???

    An Open Source , first ??
    Reply to this Reply to original

  61. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Well TSS has some EJBS in it, so I guess it must be run by newbies right Vic?
    Reply to this Reply to original

  62. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Where did we get the figure that 50+ % of the respondents were using Tomcat? I followed the link provided, but that figure was not there. Is it in the print version of SDTimes?

    thanks,

    harris
    Reply to this Reply to original

  63. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    It's in the first paragraph, look closer
    Reply to this Reply to original

  64. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    I'm not surprised by a number of the results, but I'm quite surprised to see Resin not even listed in the results, not to mention Orion (although Oracle's there).
    Reply to this Reply to original

  65. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    "java application server" is not a term that you hear very often. "j2ee application server" is, and tomcat is not a j2ee application server.

    Why draw a distinction between "java application server" and "servlet container" ??? Are there any "java application servers" that don't use the servlet paradigm? Maybe zope running on jython??? :-)






    Reply to this Reply to original

  66. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]


    The definition of app server is not that you over paid over $10,000 for it per CPU.
    You can use Resin for $500, or TomCat for $0, or Orion for $1000.

    Some of you overpaid, just like you over designed. So now you are saying there must be something I paid for.

    You can pay more! You could use EJB!

    However:
    The role of a software engineer is figure our how to do something efficiently!
    Imagine if you had to build a bridge. You might use thick stone, since you do not want it to fall into the river. But a engineer could figure out how thin the cable can be and still support a bridge.
    You could build a car. An engineer can make it weigh less, less air drag, more efficient engine.

    I have to say again, anyone could build a web site!
    Better programmers can build it faster and cheaper. The also need less HW and less SW.

    As I write this and elevator bar on the right is say .NET is better!
    Or J2EE is to complex.

    Only if you let them my fiends.

    Save money! Save time!
    This way software engineers could justify their high bill rates.

    .V

    ps: How come no one is suprised that Apache has more market share than IIS or the Linux is more popular server than MS?

    Reply to this Reply to original

  67. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    Vic-

    The "E" in EJB is for Enterprise. If you want to build a website, don't use it. If you want to build an enterprise application, you would be crazy not to use it. EntityBeans are a _great_ improvement over Txn Monitors, Corba OTS, OODMBSes, home-grown access layers and O/R tools. Most enterprises (i.e. Fortune 100 companies) have an amazing amount of legacy systems. One client I worked for had customer information in 22 back-end systems. (There's even a niche industry called "customer de-duping".) Without using EJB's, how do you deal with this? Like an earlier poster, I've used EJBs with EAI and data warehousing systems and it's worked out great. And they are scalable.

    -Scott
    Reply to this Reply to original

  68. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    <quote>
    EntityBeans are a _great_ improvement over Txn Monitors, Corba OTS, OODMBSes, home-grown access layers and O/R tools
    </quote>

    Let's look at that issue a bit more fine-grained:

    1. JTA/JTS is a great improvement over Txn Monitors and Corba OTS. EJB "just" allows to use JTA transactions in a declarative instead of programmatic way, for both Session Beans and Entity Beans.

    2. Entity Beans are an improvement over home-grown access layers and APIs specific to a certain OODBMS. But IMHO some current O/R tools are a focussed, cleaned-up version of Entity Beans, not the other way round. They concentrate on persistence and decouple it from remote accessibility and declarative transaction demarcation, building upon JNDI resources and JTA. JDO tries to standardize this pure persistence approach but is a bit questionable due to some quirks. Still, I believe that pure persistence toolkits are the way to go, in terms of simplicity and reusability. IMHO Entity Beans just make sense for remotely accessible coarse-grained entities, not for local fine-grained entities. And you can always export the latter via service classes and RPC toolkits, or Session Beans.

    <quote>
    ORMs are crap too. Use Object Relational Mappers outside of very simple result set mapping and you are doing yourself a huge dis-service. You put an abstracted object model on top of a relational database and you've masked away most of the power of the relational model.
    </quote>

    Sure, O/R mappers can never offer the full power of relational databases. Should they at all? The object storage abstraction makes things easier for application programmers but comes at a price: less flexibility. A valid tradeoff IMHO: Choose whatever your project needs and what suits your taste.

    <quote>
    I agree with the camp that found EJB FUBAR (Fouled up beyond repair). (...) Another way to say it, if you did not need CORBA in the past for you application, you do not need EJB.
    </quote>

    I'm not in the "EJB FUBAR" camp. I consider myself in the "EJB is overhyped and overused" camp, and probably in the "Entity Beans are not suitable for general persistence but only for special needs" one. But I do see value in EJB, if appropriately used. Concerning the CORBA comparison: There may be some truth in it, but EJB 2.x definitely offers more than CORBA-inspired functionality.

    Juergen
    Reply to this Reply to original

  69. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]

    How did you use EJB to deal with this (22 legacy back-end system) situation? Can you recommend any reference material to this kind of problem?

    Thanks,
    Calvin Loh
    Reply to this Reply to original

  70. And the winner of the appserver marketshare war is...Tomcat![ Go to top ]


    "Better programmers can build it faster and cheaper. The also need less HW and less SW"

    Wraps it up extremely well. The problem IMO is that people don’t discriminate between:

    Web-pages vs rich web applications
    Contract vs product development

    Contract-programming of simple web-pages (CPSW) have almost nothing in common to product development of rich web applications (PDRW).

    Almost all the tools and patterns to day concentrate onto CPSW. Everything is aimed at as painless as possible finish the contract in time with reasonable performance.

    That is not good enough in PDRW. Utmost efforts must be taken to shave of seconds and milliseconds to obtain a lean mean and fast product. To use EJB would be suicide. OR tools are not that important. Look for instance at all the shitty portals products available today.. heavy, extremely slow and useless already before the users begin to put content into them.

    A market for rich web apps is emerging.
    http://story.news.yahoo.com/news?tmpl=story&u=/nf/20021003/bs_nf/19571

    Regards
    Rolf Tollerud
     
    Reply to this Reply to original