Why most large-scale Web sites are not written in Java

Home

News: Why most large-scale Web sites are not written in Java

  1. Nati Shalom has written up a blog entry on "Why most large-scale Web sites are not written in Java," inspired by a discussion with a co-worker at GigaSpaces. According to "Why doesn't anyone use j2ee?," two reasons are:
    1. The LAMP stack is open source and cost effective;
    2. J2EE is used, but only as part of the application stack, not as the entire stack itself.
    From Nati's post:
    The application stack of these Web applications [Ed. Note: Google, Amazon, eBay, LinkedIn, TypePad, WikiPedia, flickr] is very different from the stack that mission-critical applications in the financial world are built with. In the financial world, Java -- and to a lesser degree J2EE -- is used extensively. In recent years scalability requirements in capital markets led to a rapid shift in the middleware stack, introducing Compute Grid solutions for virtualization of CPU resources, enabling parallelization of batch applications. Data Grids were also introduced, enabling the virtualization of memory resources. Spring is becoming the common development framework in this world. At GigaSpaces, we're seeing more and more cases where Spring acts as a complete alternative to J2EE.
    Nati closes by asking why readers think that J2EE isn't used more for high-scale applications like Amazon, up and down the entire stack. What do TSS' readers think?

    Threaded Messages (67)

  2. Maybe the blog should actually include large "Enterprise" websites when questioning why they don't use Enterprise Java. As listed in the comments to the Blog, Ebay uses JEE. Most of the sites listed don't really need the Enterprise stack JEE provides and therefore their developers probably made the correct choices in technology. Websites don't all have the same requirements and different technologies satisfy these requirements differently. I'm sure someone could easily put together a hand-picked list of 8-9 large-scale websites and ask "Why most large-scale Websites are not written in PHP ?" Or don't use Apache. Or chose Linux, Windows whatever...
  3. Simple sites don't need J2EE[ Go to top ]

    This one is easy, simple sites don't need the full J2EE suite :) -Tracy Milburn
  4. i think the reason "The LAMP stack is open source and cost effective" is completely bogus. Java (and most related server side technologies) is free, and cost effective too. Problem is, most of the sites in question started by a small group of enthusiastic developers who are more experienced in Lamp stack. they start small, develop fast.. later, once if they are lucky, they got popular and start fixing the crappy code they wrote. throw hardware as needed. Same thing would happen if some capable Java developers do the same. possibly with less messy code, maybe a longer time to start. Also, i dunno if why tens of Google projects does not enter his categories?
  5. The application stack of these Web applications [Ed. Note: Google, Amazon, eBay, LinkedIn, TypePad, WikiPedia, flickr] is very different from the stack that mission-critical applications in the financial world are built with.
    I've personally visited with engineering teams at Google, Amazon, eBay and LinkedIn all this year. They all use Java extensively for their web sites. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  6. The application stack of these Web applications [Ed. Note: Google, Amazon, eBay, LinkedIn, TypePad, WikiPedia, flickr] is very different from the stack that mission-critical applications in the financial world are built with.


    I've personally visited with engineering teams at Google, Amazon, eBay and LinkedIn all this year. They all use Java extensively for their web sites.

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid for Java and .NET
    I have worked in France and spain for most of the big banks on europe including ING. They all use Java Jee with a lot of spring. Here in the US i see a lot of financial institutions use jee too with one exception Charles Schwab which i heard is moving from jee to msft.
  7. So the two main reasons Java isn't used are * cost of the stack - I'm sure it beats the $0.0 I've spent on JDKs over the years - I know, I know they are talking about app servers. * That Java is used but not every available Jee framework at the same time - wow, you can do that? Actually, it is the poster's summary that is misleading, not the article. The article's title addresses why they are not written in J2ee (jee), not Java Jee, you'd think TSS and its contributers would realize that Java != Jee. I think the obvious but missing point is that much of Jee is geared toward making available "enterprise-level" technology to average-level programmers doing everyday projects. That's its sweet spot and is what has sold countless WSAD licenses over the years. Does it surprise me that ebay doesn't use JMS? Not in the least. Ebay is basically moving data to and from the database as quickly as possible. Not much more than a basic (but well done) CRUD app.
  8. Java isn't really a good language for writing web pages. Actually, it's never been very good for any kind of presentation layer. It's niche is in the stodgy back-end parts of a system. Java has discredited itself with misguided attempts to Java-ize all parts of a system e.g. JSP and Struts. I think the Java community just needs to admit that these are complete disasters and focus on what Java is good at. The good news is that this is already happening as Java is accepting other tools into it's fold instead of trying to replace them.
  9. ...Java has discredited itself with misguided attempts to Java-ize all parts of a system e.g. JSP and Struts...
    Well, I just dived into Ruby on Rails and guess what - it is exactly mirrors Struts MVC architecture and rhtml files are exactly like JSPs :)
  10. ...Java has discredited itself with misguided attempts to Java-ize all parts of a system e.g. JSP and Struts...


    Well, I just dived into Ruby on Rails and guess what - it is exactly mirrors Struts MVC architecture and rhtml files are exactly like JSPs :)
    I don't know much about RoR so I can't comment on whether this works for Ruby. The problems I have with these are not the architecture per se but how the Java language is clumsy in the context of presentation. Switching out the language and keeping the architecture might be a perfect solution. Although, I would hope hat RoR wouldn't require all the different files that you need to get struts working or follow what it does.
  11. ...Java has discredited itself with misguided attempts to Java-ize all parts of a system e.g. JSP and Struts...


    Well, I just dived into Ruby on Rails and guess what - it is exactly mirrors Struts MVC architecture and rhtml files are exactly like JSPs :)
    rails mirrors struts MVC - you must be nuts.
  12. ...rails mirrors struts MVC - you must be nuts.
    Perhaps, but let us see MVC is the RoR architecture, so is true for Struts Controller is called Controller in RoR and Action in Struts Controller redirects to View, which is rhtml file in RoR and usually JSP in Struts. In RoR view name is the same as method name to call and method name to call is mapped through generic URL mapping. The same convention can be implemented in Struts really easy. And lastly rhtml - that is exactly twin brother of JSP but Ruby is used to code scriplets: <%= start_form_tag :action => 'create' %> <%= render(:partial => 'shared/nubform', :object => @editform, :locals => {:subdesc => true}) %>
    <%= submit_tag _(:add_new) %>
    <%= end_form_tag %> partial is exactly the <jsp include.. So, I might be a nuts but I see some remarkable similarities
  13. ...Java has discredited itself with misguided attempts to Java-ize all parts of a system e.g. JSP and Struts...


    Well, I just dived into Ruby on Rails and guess what - it is exactly mirrors Struts MVC architecture and rhtml files are exactly like JSPs :)


    rails mirrors struts MVC - you must be nuts.
    Not at all crazy. The design of Rails is *extremely* close to Struts. Very different to modern Java web frameworks.
  14. rails mirrors struts MVC - you must be nuts.


    Not at all crazy. The design of Rails is *extremely* close to Struts.
    Convention over configuration. That's the reason why some RoR people seem to think: "If the name is different - it must be a completely different thing."
    Very different to modern Java web frameworks.
    Ok, that's another thing where Struts and RoR differ besides their names. Struts isn't modern any more ^^
  15. ...Java has discredited itself with misguided attempts to Java-ize all parts of a system e.g. JSP and Struts...


    Well, I just dived into Ruby on Rails and guess what - it is exactly mirrors Struts MVC architecture and rhtml files are exactly like JSPs :)


    rails mirrors struts MVC - you must be nuts.


    Not at all crazy. The design of Rails is *extremely* close to Struts. Very different to modern Java web frameworks.
    Well probably closer to Turbine, Struts made the huge mistake to pump as much as possible into the configuration, Turbine, which I loved more than Struts, didnt do that, it made sane assumptions on the action -> pageflow mapping, which you could override. One think Turbine has in favor over modern day rails, still is the better templating engine. While rails uses a jsp like mechanism Turbine from day one was using Velocity. Turbine just made a huge mistake in their db binding layer, Torque while back then being the only choice (Hibernate came somewhat later) in the oss world, simple is aweful :-( Anyway I always loved Turbine more than Struts (which I still cannot warm up to today) for many reasons, one being the more elegant design choices in the view layer.
  16. Java has discredited itself with misguided attempts to Java-ize all parts of a system e.g. JSP and Struts. I think the Java community just needs to admit that these are complete disasters and focus on what Java is good at. The good news is that this is already happening as Java is accepting other tools into it's fold instead of trying to replace them.
    Based on this logic there is a .NET disaster, Ruby disaster, Stack X disaster. I am not saying that there are no disasters, but other platforms are not actually except from the same problem of trying to do it all. And I would not go as far as to say that JSP or Struts are disasters. I think there are worse things in the Java land, at least there were.
  17. I am not saying that there are no disasters, but other platforms are not actually except from the same problem of trying to do it all.
    I made no such suggestion.
    And I would not go as far as to say that JSP or Struts are disasters. I think there are worse things in the Java land, at least there were.
    I think from a long term maintenance perspective, they are really big problems. And lets be honest, JSP was Suns "me too" answer to ASP. I don't think it was the brainchild of some high-minded philosopher. I doubt there was much discussion about whether it was a good idea. It was a huge improvement over the situation that existed at the time but I don't think it's an optimal solution by any stretch of the imagination. I like Java (for the most part) and I think it's going to last. But I also think the age of "Java everywhere for everything" is over and that's a good thing.
  18. But I also think the age of "Java everywhere for everything" is over and that's a good thing.
    Unfortunately didn't Jonathan Schwarz claim the exact opposite when rechristening Sun's stock ticker from SUNW to JAVA?
  19. But I also think the age of "Java everywhere for everything" is over and that's a good thing.

    Unfortunately didn't Jonathan Schwarz claim the exact opposite when rechristening Sun's stock ticker from SUNW to JAVA?
    I think it's more of a 'JVM everywhere for everything' view and that's a different discussion entirely.
  20. I think from a long term maintenance perspective, they are really big problems. And lets be honest, JSP was Suns "me too" answer to ASP. I don't think it was the brainchild of some high-minded philosopher.
    It's interesting to see someone condemn the JSP paradigm while acknowledging the success of something like PHP when they're essentially identical. JSP has all of the problems and features of PHP. There are obviously some differences, of course, but they both live in the realm of "code + content", with simply developer discipline the only factor involved in keeping code out of content. JSP technology is fine. It works, it's powerful, has a low barrier to entry, and will scale with the best of them because of its Java foundations. Modern JSP is eminently refactorable. It's easy to start with a pure JSP application, migrate to JSP + Beans, from there to a Model 2 application, and from there to an N tier whatever, incrementally upgrading and transforming the application as you go. Java hosting is what holds JSP back. PHP is dirt cheap to host, from a system resources and support perspective for hosting companies. Java is much more difficult compared to JSP, so PHP is ubiquitous (and thus expertise and demand are also more widespread in this domain).
  21. I think from a long term maintenance perspective, they are really big problems. And lets be honest, JSP was Suns "me too" answer to ASP. I don't think it was the brainchild of some high-minded philosopher.


    It's interesting to see someone condemn the JSP paradigm while acknowledging the success of something like PHP when they're essentially identical.

    JSP has all of the problems and features of PHP.

    There are obviously some differences, of course, but they both live in the realm of "code + content", with simply developer discipline the only factor involved in keeping code out of content.

    JSP technology is fine. It works, it's powerful, has a low barrier to entry, and will scale with the best of them because of its Java foundations.

    Modern JSP is eminently refactorable. It's easy to start with a pure JSP application, migrate to JSP + Beans, from there to a Model 2 application, and from there to an N tier whatever, incrementally upgrading and transforming the application as you go.

    Java hosting is what holds JSP back. PHP is dirt cheap to host, from a system resources and support perspective for hosting companies. Java is much more difficult compared to JSP, so PHP is ubiquitous (and thus expertise and demand are also more widespread in this domain).
    PHP is for code junkies who say the word " cool "every 15 minutes. :-) It cannot scale and its very page centric. PHP guys just accept it, you have not done any serious enterprise development with PHP. A few registration forms, a few graphs and forgot password pages is all what you can do with PHP. Ofcourse I will get a lot of bashing to say this but its true. We tried it for a internal CSR facing application in a big insurance company and it failed miserably. Just didnt work. we moved to java. I agree though with some overhead cost of java,jsp. Peace please !

  22. PHP is for code junkies who say the word " cool "every 15 minutes. :-) It cannot scale and its very page centric. PHP guys just accept it, you have not done any serious enterprise development with PHP. A few registration forms, a few graphs and forgot password pages is all what you can do with PHP.
    Ofcourse I will get a lot of bashing to say this but its true. We tried it for a internal CSR facing application in a big insurance company and it failed miserably. Just didnt work. we moved to java. I agree though with some overhead cost of java,jsp.

    Peace please !
    Yeah i'll bash you, but only because you quoted his whole comment and replied to the least important detail of it.
  23. Switch to PHP now for this reason[ Go to top ]

    PHP is for code junkies who say the word " cool "every 15 minutes. :-)
    So isn't this better than saying the word "boring" every 15 minutes as seen in enterprise developers (who can only "cool" when their eyes land on a Dilbert strip)? Isn't enjoying your work every 15 minutes the best thing we can hope for? Maybe we should start learning PHP.
  24. So isn't this better than saying the word "boring" every 15 minutes as seen in enterprise developers (who can only "cool" when their eyes land on a Dilbert strip)?

    Isn't enjoying your work every 15 minutes the best thing we can hope for?

    Maybe we should start learning PHP.
    No, you simply need to use people that find enterprise work interesting. "So, I reworked the posting program so that the new invoices are processed faster. Also the process is restartable in case of a system failure so we don't have to rerun the entire batch. And all of the unit tests are in. It even all balances!" "Cool!"
  25. "So, I reworked the posting program so that the new invoices are processed faster. Also the process is restartable in case of a system failure so we don't have to rerun the entire batch. And all of the unit tests are in. It even all balances!"

    "Cool!"
    If there are still anything cool in balancing accounts behind the brick walls of corporations, they will be promptly removed by your hierarchy of bosses of your company and the hierarchy of bosses of the customer companies you are serving. I guarantee that!
  26. Re: Switch to PHP now for this reason[ Go to top ]

    Isn't enjoying your work every 15 minutes the best thing we can hope for?

    Maybe we should start learning PHP.
    Saying "cool" and enjoying your work are not the same thing. Doing PHP is, at best, enjoyable for about 15 minutes.
  27. PHP is for code junkies who say the word " cool "every 15 minutes. :-) It cannot scale and its very page centric. PHP guys just accept it, you have not done any serious enterprise development with PHP. A few registration forms, a few graphs and forgot password pages is all what you can do with PHP.
    Facebook is just a few graphs and registration forms?
  28. I think from a long term maintenance perspective, they are really big problems. And lets be honest, JSP was Suns "me too" answer to ASP. I don't think it was the brainchild of some high-minded philosopher.


    It's interesting to see someone condemn the JSP paradigm while acknowledging the success of something like PHP when they're essentially identical.

    JSP has all of the problems and features of PHP.
    I never mentioned PHP.
    JSP technology is fine. It works
    A lot of stuff works. I always assume that in these conversations we are talking about stuff that works.
    , it's powerful,
    Powerful in what sense?
    has a low barrier to entry,
    That must be why I am always helping people with it.
    and will scale with the best of them because of its Java foundations.

    Modern JSP is eminently refactorable. It's easy to start with a pure JSP application, migrate to JSP + Beans, from there to a Model 2 application, and from there to an N tier whatever, incrementally upgrading and transforming the application as you go.
    Yes, JSP is great for moving away from JSP. N-tier? That's so nineteen-nineties ;)
  29. I never mentioned PHP.
    No, but this thread is, essentially, about PHP (many of the referenced web sites are "PHP" sites).
    Powerful in what sense?
    Powerful in the sense that it's extensible through it's Tag system, and that now those Tags are particularly easy to use (with tag files), making that power readily available to the developer and user. And the Expression Language is a decent and usable language. You can make very clean pages in JSP. Not to mention that a JSP is "Just a servlet", you can have pages descending from you own custom classes if you like (though these tend to be container dependent), etc.
    That must be why I am always helping people with it.
    That's right. That's why you're not helping them with Tapestry or JSF pages, where they'd be dead in the water and not make any progress at all and have no reason to even talk to you. At least now they're trying and learning something because it's easy to get started. It's very easy for folks to get started with JSP. Once you're passed the burden of getting the server set up and an app deployed, you can go quite far with little more than an editor and browser refresh. And, really, this is NOT a bad thing.
    Yes, JSP is great for moving away from JSP.
    Yes, it is. Obviously the point was missed. The point is that JSP is a great technology for folks to use and start with it will take you as far as you want to go, up to and including getting rid of it all together if you choose to. That means there is very little lock in, and makes it a safe medium for experimentation. You can prototype readily and easily and not toss everything away when done. And if you're just starting out and don't know better, JSP let's you leverage what you know and move forward. As you learn more you can easily migrate code. Is it all "reusable" out of the box as is? No. But it's cut and paste reusable, which is essentially the foundation of refactoring. Start with a bunch of JSPs with embedded Java code. Then, perhaps, learn about tags and move the code from the JSPs and into the tags -- getting some easy reuse. Next, you may learn that putting that code in a Servlet or some frameworks action class is a better idea, so you factor it out of the tags and push it back to the action layer. Finally you can pull it out of the action/servlet layer and push it in to a Session Bean or whatever. The majority of the code is the same, just leaving refactoring crumbs and references in its path. It's all Java. That's a feature. So, yea, JSP is a powerful technology. It scales well and takes you as far as you want to go. It's accessible by novices and powerful and flexible when used by experts. Most folks perception of it seems to be locked in what it was over 5 years ago. They really need to catch up.
  30. I never mentioned PHP.

    No, but this thread is, essentially, about PHP (many of the referenced web sites are "PHP" sites).
    You made the implication that I was acknowledging the success of PHP. I don't have any strong feelings about PHP except that it kind of seems like a toy to me.
    Powerful in what sense?

    Powerful in the sense that it's extensible through it's Tag system, and that now those Tags are particularly easy to use (with tag files), making that power readily available to the developer and user. And the Expression Language is a decent and usable language. You can make very clean pages in JSP.

    Not to mention that a JSP is "Just a servlet", you can have pages descending from you own custom classes if you like (though these tend to be container dependent), etc. That it should take (as I count it) 5 different syntaxes to create a web page is where I start to think perhaps it's not the best approach.
    That must be why I am always helping people with it.


    That's right. That's why you're not helping them with Tapestry or JSF pages, where they'd be dead in the water and not make any progress at all and have no reason to even talk to you. At least now they're trying and learning something because it's easy to get started.
    I don't quite follow that logic but I'm not really advocating complex frameworks. I'm just don't think that Java is a good language for presentation.
    That means there is very little lock in, and makes it a safe medium for experimentation.
    We are feeling pretty locked it. Struts compounds the pain. We've got a lot of code embedded in these JSP pages where I can't really see how we will extract it without basically rewriting it. If you have some suggestions for removing Struts and JSPs from an application I'm listening (figuratively, of course.)
  31. We are feeling pretty locked it. Struts compounds the pain. We've got a lot of code embedded in these JSP pages where I can't really see how we will extract it without basically rewriting it. If you have some suggestions for removing Struts and JSPs from an application I'm listening (figuratively, of course.)
    I agree with you that you seem to be in an awkward position. I don't really see how it is technology-related, though. You have mixed code and content in your JSP pages. Obviously not a good thing to do. So far we are in total agreement. You also seem to be saying that there is some technology out there that will replace competence with technology, so that mistakes such as these are not made. If you were only using technology B, people would not be so dumb and create an solution that you are now thinking about replacing. I think that technology is not on the market yet, but I would be very happy to be proven wrong. I think quality and knowledge issues are people problems, and need solutions that are based on fixing the people-based problems. I really don't think technology is going to be a big part of that solution, even if geeks like me would like it to be. Technology is what we know, so it is easier to turn to. If all you have is a hammer, and all that. Geir
  32. You have mixed code and content in your JSP pages. Obviously not a good thing to do. So far we are in total agreement.
    Seriously, this is the key to all of these problems. Despite what folks may say, there IS logic in presentation, and in many places that logic is very convenient when placed next to the content -- ala JSP or PHP. Even Velocity (purists love Velocity and slam JSP) has IF statements and iteration, it just tries to prevent a page from changing the model. But there is nothing stopping you from writing JSPs like that. As for being trapped by Struts and JSP, I guess it depends on what aspect of that platform is trapping you. Just as an example: That's one of our List pages -- albeit a simple list page. We have more complicated pages, of course, but they tend to be laced with more local Javascript routines than anything else. But on this page, when rendered, we have role based navigation, search/filtering, sorting, paging (ajax paging to boot), ValueList pattern. You'll notice the "Print PDF" action at the top. This gets placed in the task section on the side (kinda sorta like on Windows). So, when you select a row in the list, the PDF action will light up. Double Click on a row, and we get a default action that fires. For example, we have "edit" and "delete" "for free", that's why they're not listed here. Obviously, this is backed by a bunch of code on the server as well and supported by a bunch of Javascript, all blissfully hidden here. But I would like to think that most folks think that's a pretty clean page, and we get a boat load of functionality. When rendered, these 30 lines create a page that is ~750 lines of actual HTML (not counting blank lines -- JSP LOVES blank lines, but I think I found a Glassfish setting to clean that up). We use Stripes here as our base action framework, but at this level, frankly, an action framework is an action framework. I see no real reason why you can't do this kind of thing against legacy Struts actions. Perhaps your pages don't have enough commonality to make the effort that we took to factor stuff out in to tags and support classes pay off for you. But for us, it was a worthwhile effort and resulted in some powerful constructs that we can leverage. And none of this was pre-ordained. We didn't start with a grand plan, rather we wrote a couple of applications and just followed tried and true refactoring principals to let the abstractions fall out of the system rather than forcing perhaps bad abstractions in to the system. Finally, all of those "t:*" tags are custom tags done with tagfiles -- we didn't write a single regular JSP tag. Note, the t:listpage tag relies internally on a more general t:page tag, so even within the Tag files we get reuse. Tag files simply rock. We wouldn't have done this without them. I do not feel trapped by this page, IMHO. It is ALMOST pure model -- it could almost be a simple XML file that's read and processed by some other functionality to produce the final page. But we didn't need to go to that level for our stuff, we just let the JSP processor do all that work for us. The other nice thing about this technique is that it follows the golden rule: make the code better when you leave it. There's no reason to have to go through and make sweeping changes all at once. You can go as fast or as slow as you like. So, if nothing else, I hope maybe I gave you some hope that whatever your JSPs look like now, perhaps you can get them better.
  33. I do not feel trapped by this page, IMHO. It is ALMOST pure model -- it could almost be a simple XML file that's read and processed by some other functionality to produce the final page. But we didn't need to go to that level for our stuff, we just let the JSP processor do all that work for us.

    The other nice thing about this technique is that it follows the golden rule: make the code better when you leave it. There's no reason to have to go through and make sweeping changes all at once. You can go as fast or as slow as you like.

    So, if nothing else, I hope maybe I gave you some hope that whatever your JSPs look like now, perhaps you can get them better.
    I think that looks pretty nice. But it looks nothing like what I have to work with. I'm in 'how do I get from there to here' hell. I'm in the actions, then the jsps, then struts config and back to the jsp to look at some javascript and then to some beans etc. By the time I find what I'm looking for, I can't remember why I was looking for it. One thing to note too is that there is not a lick of Java in that code. And, AFAICT, you could implement the interpreter for that with pretty much any general purpose language. I have no problem with the above. And Java is a good language for implementing that interpreter, IMO. My original point was obviously not well stated. The point is that a lot of developers that are not already well versed in Java see it as an extremely over-complicated platform. The thing that annoys me about this is that Java is a very simple language (minus generics) and really very easy to learn. It's all of the crazy stuff that we do with it that makes it complicated. There's just a lot of stuff that is over-complicated. Do I even need to name the example? The niceness of the above will always be tainted by the kind of JSP I am working with. And yes that does give me some hope. I'm not really keen on learning it but maybe I can get the person who needs help with this so often to learn how to do it.
  34. The thing that annoys me about this is that Java is a very simple language (minus generics) and really very easy to learn. It's all of the crazy stuff that we do with it that makes it complicated. There's just a lot of stuff that is over-complicated.
    Don't use them. Use plain Java and JSPs, or pick a framework inspired in rails, frameworks over coupled, and heavily based on code generation (but no very much round trip) but oriented to say "oh no hands, what easy".
  35. The thing that annoys me about this is that Java is a very simple language (minus generics) and really very easy to learn. It's all of the crazy stuff that we do with it that makes it complicated. There's just a lot of stuff that is over-complicated.


    Don't use them. Use plain Java and JSPs, or pick a framework inspired in rails, frameworks over coupled, and heavily based on code generation (but no very much round trip) but oriented to say "oh no hands, what easy".
    lol. Which reminds me of the joke about the little boy learning to ride a bike. "Look mom, no hands! Look mom, no feet! Look mom, no teeth!"
  36. I think that looks pretty nice. But it looks nothing like what I have to work with. I'm in 'how do I get from there to here' hell. I'm in the actions, then the jsps, then struts config and back to the jsp to look at some javascript and then to some beans etc. By the time I find what I'm looking for, I can't remember why I was looking for it.
    I feel that pain. Despite the apparent simplcity of my page, we're far from completely immune from that phenomenon. It IS better, but we still have those byzantine bug hunts at times.
    One thing to note too is that there is not a lick of Java in that code. And, AFAICT, you could implement the interpreter for that with pretty much any general purpose language. I have no problem with the above. And Java is a good language for implementing that interpreter, IMO. My original point was obviously not well stated. The point is that a lot of developers that are not already well versed in Java see it as an extremely over-complicated platform. The thing that annoys me about this is that Java is a very simple language (minus generics) and really very easy to learn. It's all of the crazy stuff that we do with it that makes it complicated. There's just a lot of stuff that is over-complicated. Do I even need to name the example? The niceness of the above will always be tainted by the kind of JSP I am working with.
    You're absolutely correct on both counts. The language IS simple, and the platform IS complicated. Frankly, annotations are the singular addition that turns around and helps us reduce the apparent and day to day complexity that we face. As with any simplifying technique, the complexity is still there. However now it's buried behind Convention over Configuration, and embedding configuration information directly in to the classes. CoC is cleary the "cheaper" and less intrusive of either of these techniques, but even there the complexity isn't shoved in your face like it with, say, the Struts config file. A layman can look at the Struts config file vs a simple Java bean and say "boy this Struts stuff looks complicated, while this is really simple". But in truth, with the simple Java bean, there is potentially a lot being said there that the novice can not see. With JPA, for example, all you need to create a persistent class is the @Entity tag. That's the only requirement. But if you don't understand the CoC rules, then you can't readily know the mapping of that bean to the database. The complexity is still there, the assumptions unsaid and documented elsewhere, but it certainly LOOKS simpler. (To be fair it most certainly IS simpler, the rules are not that complicated, but I'm simply portraying this as an example. But then you get to deal with the details of manage and unmanaged objects, living with the secondary caches, etc.) The real benefit of CoC and annotations is, after learning their basic rules, is that it helps make the simple case simple, and complexity scale with the need. In Struts, you have complexity for the most simple of actions, since there is no defaulting. Today, modern frameworks default nicely and require the extra configuration only as necessary as your requirements drift away from the defaults. So, anyway, despite the simplicity of the Java language, the actual problems we try to solve with are actually quite complicated. HTTP SEEMS simple, but we all know what a pain stateless applications are to write, and what tedium there is in processing even the most mundane of HTTP requests.
    And yes that does give me some hope. I'm not really keen on learning it but maybe I can get the person who needs help with this so often to learn how to do it.
    Our ca. 2000 Struts project no doubt looks exactly like yours. Lot of new people, and the train is running with just crushing deadlines, so, anyway, not pretty. And when I was thrust in to trying to make changes to it, having someone try to explain the workflow and lifecycle was simply a nightmare. As I said earlier, though, the best part about the tags is that it's iterative. Many JSP pages were cut and pasted in to existence, with perhaps a jsp:include for the large chunks. But the tag files are great for not just the big chunks, but even the little bits. For example, lots of pages may have something horrible like this: This can become, simply using JSTL: A simple step eliminating little Java bits. Next you can go anther round and create your own tag: The tag file looks like: The tag prefixes the path for you, and the "border='0'" comes "for free" now. You can see how simple the simple tags are. Basic templating. As you build more and add use cases, you can make them more and more complicated internally. I think the latest version is certainly cleaner and "simpler" than the first, even though there is "hidden" knowledge in the final one (embeding the context and the border attribute). So, hopefully your developer can make some passes through your JSPs to clean them up and codify some of your assumptions that are now, no doubt, quite explicit in the code.
  37. We are feeling pretty locked it. Struts compounds the pain. We've got a lot of code embedded in these JSP pages where I can't really see how we will extract it without basically rewriting it. If you have some suggestions for removing Struts and JSPs from an application I'm listening (figuratively, of course.)


    I agree with you that you seem to be in an awkward position. I don't really see how it is technology-related, though.

    You have mixed code and content in your JSP pages. Obviously not a good thing to do. So far we are in total agreement.

    You also seem to be saying that there is some technology out there that will replace competence with technology, so that mistakes such as these are not made. If you were only using technology B, people would not be so dumb and create an solution that you are now thinking about replacing.

    I think that technology is not on the market yet, but I would be very happy to be proven wrong.

    I think quality and knowledge issues are people problems, and need solutions that are based on fixing the people-based problems.

    I really don't think technology is going to be a big part of that solution, even if geeks like me would like it to be. Technology is what we know, so it is easier to turn to. If all you have is a hammer, and all that.

    Geir
    Well the Wicket approach seems pretty interesting to me but I've yet to have the chance to try it out. But the idea of keeping linking the Java code to the page in a very decoupled way seems to be the right idea. Honestly, I'm not really a big web page guy. I'm more of a back-end processing and fat-client person. I guess I shouldn't generalize too much based on the piece of crap I have to work with at the moment. But if I were going to do it from scratch I probably wouldn't go with JSP unless I found no other way to get it done.
  38. I'm just don't think that Java is a good language for presentation.
    No C-family programming language really is - they are geared towards computation. They can express the mathematical aspects like dimensions and ordering of components. For presentation you want a 4GL-like thingy, or use XHTML with a secondary "framework" namespace that provides the "hooks" for processing, e.g. but if you desperately want to keep logic out of the presentation you end up with either splitting the view into a multitude of managed sections (losing sight of the whole) or N separate views if you have N different "logical states" (e.g. search hit list shown or hidden contributes a factor of two to the number of possible states)... and you are looking at a management nightmare that frameworks that put logic into the page (Webmacro, JSP+scriptlets, JSP+JSTL) largely avoid.
  39. Java isn't really a good language for writing web pages. Actually, it's never been very good for any kind of presentation layer. It's niche is in the stodgy back-end parts of a system.
    If you would have read the comments before you, then you would know that the article is wrong, most of the mentioned sites use java extensively.

    Java has discredited itself with misguided attempts to Java-ize all parts of a system e.g. JSP and Struts. I think the Java community just needs to admit that these are complete disasters and focus on what Java is good at. The good news is that this is already happening as Java is accepting other tools into it's fold instead of trying to replace them.
    Actually java is pretty well positioned in the html area, otherwise we all wouldnt debate here ;-)
  40. If you would have read the comments before you, then you would know that the article is wrong, most of the mentioned sites use java extensively.
    There are a lot of confused posts here, caused partly by an incorrect (from what I can tell) note from the editor. If you read Nati's article, and/or the one he's referencing in his article the sites discussed are: Flickr, YouTube, PlentyOfFish, Digg, TypePad, LiveJournal, Friendster, MySpace, Wikipedia. Most of the sites that most people have noted use Java are not in this list except perhaps Flickr which is noted as using Java in the article.
  41. Java isn't really a good language for writing web pages. Actually, it's never been very good for any kind of presentation layer. It's niche is in the stodgy back-end parts of a system.

    Java has discredited itself with misguided attempts to Java-ize all parts of a system e.g. JSP and Struts. I think the Java community just needs to admit that these are complete disasters and focus on what Java is good at. The good news is that this is already happening as Java is accepting other tools into it's fold instead of trying to replace them.
    I suggest you try Java Server Faces with the Richfaces components before arriving at such conclusions. Cheers...
  42. Argument 1 is not really correct because the Java stack is also opensource (or can be open source). Yes you can get obnoxious about SUNs licensing behavior in the past but the fact is that all the components needed to run a J2EE server have been available for free (i.e. there's no cost argument here) and also as open source (e.g. running JBoss on one of the OSS java environments works fine) The real reason is (as the blog post states) that J2EE is optimized for the enterprise domain which is simply quite different than the domain of large scale consumer oriented websites or the domain of small scale consumer oriented startups. These websites have relatively simple data base structures; relaxed requirements for things like transactions and persistence layers (mysql + non-transactional & ACID backend is good enough in most cases); virtually no requirements for heavy duty web service stacks; etc. Basically all the stuff J2EE is excellent for is just mostly overkill for implementing consumer oriented websites. You don't need the fancy IDEs; uber-flexible messaging buses; outrageously complicated transactional logic; etc. Instead the focus is on extreme scalability; memory usage; cpu usage; caching; etc. Those things can be addressed with off the shelf components like squid, apache, distributed linux filesystems etc. They can also be addressed with Java components too but it requires that you have some J2EE experts around to integrate them. These are not exactly easy to recruit due to current scarcity on the job market and tendency of these people to end up in extremely well payed enterprise type jobs. I think Google is a good example of a extremely scalable web infrastructure that applies a mix of Java and other languages. Key point is that they depend heavily on managability and maintainability advantages java provides while at the same time optimizing key parts of the system by rolling their own custom C components (down to the kernel level if needed). There is simply no off the shelf 100% Java solution for this stuff so they built their own technology. BTW, nor is there a off the shelf LAMP stack for this stuff. For example, while facebook is written in PHP, the facebook people are also doing lots of native stuff. Including working on the PHP interpreter itself to make it scale better. Anybody interested in reading up on large scale infrastructures on large scale websites should check out http://highscalability.com. They provide some really insightful overviews of architecture at flickr, google, facebook and other websites. Lesson is that all these systems use heavily customized components and employ the best people available to build and maintain these components. Finally, I think all this is changing. Running the Java implementation of ruby or php can give a nice security, performance, scalability and managability boost to your php or rails application. You'd be a fool not to try this if you are operating large scale deployments of these systems. This is still relatively unknown to php and ruby developers and quite many simply don't care about performance enough to do anything about it, instead preferring to invest in hardware. But once they make the shift to deploying on php or ruby on Java application servers, they'll discover that there is a world of additional components that can further enhance their applications. Arguably Google's web development tool chain (partially open sourced) is the state of the art in extremely large scale & rapid protyping web development. And writing the application logic is done 100% in Java from the web developer point of view. To the best of my knowledge, Google has no large scale deployment of php or similar architectures in their web UI layer (I'd be interested to learn if this is not true).
  43. Wrong answer to wrong question. Look, once more, at this summary. What measure had been taken to define 'large scale'? Number of visitors? Community? Other? For sure, those sites are busy, very busy - but I can find at least few other, not listed here backed by Java - what about LinkedIn (unless thay fake users, they use Apache-Coyote/Tomcat to serve their dynamic content). Also eBay use Java. If one would take this list of 'large-scale' serious would conclude that the best language to build such a site is... Perl. Having written few applications in Perl, it would be my last choice, even after RoR ;). Those sites have one thing in common - they are almost 'read only', 'transactionless' sites. Basically it is the matter how well are You on caching data, building shards etc. It's why nobody here uses J2EE - and thats perfectly right! Why would one choose J2EE stack for transactionless site? Artur
  44. Not sure exactly what is the meaning of large website? 1. A website with large number of people visits one time per day? 2. A website doing large number of business computing transactions?? If you are looking for second type of website, I think they are all using JAVA one way or another way, for examples All US airline website All major E-commerce transactional web sites such as Amazon. All major banking applications Even when I write this, I am sitting at a major airlines head office. All the people here know only JAVA and J2EE So who is the stupid asking this question? A myspace guy or a blog site guy? ( I do not think JAVA can contribute much into such websites)
  45. Title is rather misleading[ Go to top ]

    It is interesting and provocative point of view but I think the title is rather very misleading. In fact, significant (if not major) parts of Google, Amazon and eBay businesses run on Java – it is a publicly known fact. Of course, with these large web businesses they have an absolute zoo of technologies in production simply because of how they grew, often acquiring certain companies and technologies on the way and rapidly integrating them. There's so much information available on this topic that we can create all kinds of statistics and draw many conclusions from them (like kids in a candy store) but again I believe that title is not accurate. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple
  46. Most large-scale websites are not written in Java Most large-scale websites are not written in .Net Most large-scale websites are not written in PHP Most large-scale websites are not written in Perl Most large-scale websites are not written in Ruby etc.
  47. language is incidental[ Go to top ]

    Most large-scale websites are not written in ...
    I'll go further. Choice of programming language isn't critical for large scale websites.
  48. total flame bait[ Go to top ]

    This is hilarious. some one makes a stupid comment and people take it serious. The only thing it says is the person claiming "most" doesn't get around enough to realize some very big and popular websites like weather.com, and superpages.com use java. Anyone that has build a high volume website knows that you can do it with just about any stack. The key is having developers who understand the tools and use it carefully. peter
  49. Three reasons because PHP is more popular than Java: 1) PHP hosting is absolutely widespread and very very cheap. Every big telco offers some kind of free PHP hosting with the Internet connection but almost no one Java. RoR as a simple Apache plug-in is entering fast in this category. 2) Too many "kids" doing web development. A "kid" chooses a burger instead a sirloin. Of course I don´t consider as a kid a guy doing PHP because is *his job*, period, I talk about "decision makers" and "technology believers". Java is not for "kids". 3) Culture: Java has been ever focused to big companies, to complex and high demand sites. But every PHP site can be converted to Java straightforward with pure JSP + JDBC and no classes, in Java this is a "bad taste" solution (...crappy?) in PHP is the usual. Is hard and frustrating to use a language without a solid OOP (PHP has lacked it for years and years, with some bad attempt) and of course an OOP API, PHP API is a C clone. I'm sorry PHP is dirty, C is dirty these days too, is 2007, OOP was "invented" in 80s, but at least C is fast, typed and compiled.
  50. RoR / Mongrel[ Go to top ]

    1) PHP hosting is absolutely widespread and very very cheap. Every big telco offers some kind of free PHP hosting with the Internet connection but almost no one Java. RoR as a simple Apache plug-in is entering fast in this category.

    Referring to the RoR part: Not true. Typically you have a Mongrel cluster sitting behind Apache. Mongrel acts as application server for the Rails app. Same setup as with Java/JEE.
  51. Re: RoR / Mongrel[ Go to top ]

    1) PHP hosting is absolutely widespread and very very cheap. Every big telco offers some kind of free PHP hosting with the Internet connection but almost no one Java. RoR as a simple Apache plug-in is entering fast in this category.



    Referring to the RoR part:
    Not true. Typically you have a Mongrel cluster sitting behind Apache. Mongrel acts as application server for the Rails app.

    Same setup as with Java/JEE.
    That's not how the cheap hosters are deploying RoR. That may be how RoR folks deploy RoR on dedicated systems, but the $5 hosting services most certainly are not doing that. They're using either an Apache plugin or CGI. PHP is popular because I can host it on a $5/month host.
  52. Three reasons because PHP is more popular than Java: 1) PHP hosting is absolutely widespread and very very cheap. Every big telco offers some kind of free PHP hosting with the Internet connection but almost no one Java. RoR as a simple Apache plug-in is entering fast in this category. 2) Too many "kids" doing web development. A "kid" chooses a burger instead a sirloin. Of course I don´t consider as a kid a guy doing PHP because is *his job*, period, I talk about "decision makers" and "technology believers". Java is not for "kids". 3) Culture: Java has been ever focused to big companies, to complex and high demand sites. But every PHP site can be converted to Java straightforward with pure JSP + JDBC and no classes, in Java this is a "bad taste" solution (...crappy?) in PHP is the usual. Is hard and frustrating to use a language without a solid OOP (PHP has lacked it for years and years, with some bad attempt) and of course an OOP API, PHP API is a C clone. I'm sorry PHP is dirty, C is dirty these days too, is 2007, OOP was "invented" in 80s, but at least C is fast, typed and compiled.
  53. OOP was "invented" in 80s
    Off by over twenty years, kid unless you were attempting to be ironic. Pick up a book or at least wikipedea to get some knowledge on a subject if you are going to use it in an argument. Who the heck cares what is popular? The masses are asses - I'll stick with what is the best choice for the situation.
  54. OOP was "invented" in 80s


    Off by over twenty years, kid unless you were attempting to be ironic. Pick up a book or at least wikipedea to get some knowledge on a subject if you are going to use it in an argument.
    Yes I'm ironic, OOP is old stuff, but the sentence is true: * Wikipedia about Object Oriented Programming:
    Object-oriented programming roots reach all the way back to the 1960s... It was not commonly used in mainstream software application development until the early 1990s...Smalltalk was the first programming language to be called "object-oriented".
    * Wikipedia about Smalltalk:
    The language was first generally released as Smalltalk-80 and has been widely used since.
    * Wikipedia about C++:
    Dr. Bjarne Stroustrup developed C++ in 1979 at Bell Labs as an enhancement to the C programming language and named it "C with Classes". In 1983 it was renamed to C++.
    I was talking about "real world" not prototypes or papers.
  55. Good enough.
  56. OO history[ Go to top ]

    I was talking about "real world" not prototypes or papers.
    Simula from 1967, commonly considered the first OO language, was not just a "prototype or paper" but was used for real programming - though initiallty in an academic setting. I have read that Stroustrup made C++ simply because he missed Simula when he worked at AT&T. Just because the language predates the term does not mean it's not an example of what the term represents. Smalltalk, though standardized as Smalltalk-80, can at least be traced back to a spec and implementation from 1976.
  57. Err... Most Enterprise Web sites are in fact written in Java, including the ones listed by this FUD fan. Sorry, never saw that "LAMP" thing in use in any major enterprise where I've been consulting. I guess I haven't seen the light just yet. And I'm getting a little tired of these people complaining about the "complexity" (sigh) of J2EE nowadays. Enterprise environments are complex by nature. Provided people have some non-imaginary programming skills, J2EE applications are only as complex as they need to be. Besides, many of us still have a job due to that supposed "complexity".
  58. Maybe, should we need to know how are large-scale Web sites ? after that we will discuss to "Why most large-scale Web sites are not written in Java" problem. In order to choose what a technology and language for our application, I think we need to review business requirements, resources of team / project, etc before we make to decision. One more thing, almost banking applications are written in Java. -Baostone
  59. PHP - Java[ Go to top ]

    More specialists use PHP and there is more scripts and CMS ready rwiten in PHP. Now the framework Java that facilite web developement are growing. There is more and more web application writen in Java.
  60. Re: PHP - Java[ Go to top ]

    More specialists use PHP and there is more scripts and CMS ready rwiten in PHP.

    Now the framework Java that facilite web developement are growing. There is more and more web application writen in Java.
    Actually you must be kidding, php is often used, but only for dirty fast to go online websites. And true some of the bigger oss cmses are written in php, but that does not excuse the fact that some of them inside are simply aweful tailored to mysql using no transactional mechanisms (forced myisam) whatsoever etc... I know what I am talking about I have had to use typo3 the last year, and internally it is a horror come true. A dream come true for every sadist in earth! And this is the most widely used CMS, but believe me it is one of the most horrific systems I have ever seen bar none. And huge parts of the horror underneath it was caused by PHP. Forced innodb usage, crud data structures with huge global data holding singletons, non speaking names due to php size limitations in older versions weird distributed configurations triggered left and right. Configuration files which have added program structures out of every convention not really implementing basic flow control properly. Basically every antipattern you can think of is in that system en masse! And that is the most widely used CMS, but it doesnt mean you should use it, it just means, that junk can become successful, and specialists then have to bang their heads to get it running! Add to that that php itself is not a language really geared towards such a huge system and you scream for mess. Sorry but if you need some program security and structure then stay away from php. Php is fine for small webapps which you can get away with lamp, but if you need some good structuring program security, data security, stay the hell away from it. If I have to write a quick page I probably would consider php, but if I have to design a system which should run and give data security and should scale, everything else, not php! (well rails then is out of the game for now as well for other reasons which will be overcome in the following years)
  61. This is Complete Bullshit[ Go to top ]

    I have worked for a ton of large companies that use Java/J2EE exclusively for their websites and web applications: The list is: Hewlett-Packard: their support websites are all J2EE. Mutual of Omaha: all their online apps and internal apps (that weren't written in 1960) are in J2EE. Anthem Blue Cross: their online and internal apps: all J2EE. UnitedHealth Group: all their online sites are J2EE and all of their products are being rewritten in the J2EE stack. Barnes & Noble: J2EE is taking over everything. Sprint: J2EE etcetera. J2EE is thriving in the market place. The author has an agenda that he is not stating.
  62. What I find interesting is that while PHP is a good language for rapid prototyping (even though I don't use it anymore), it takes a different set of skills to write scalable, mission critical enterprise applications. Take for example Radiohead's website, which is written in PHP. These guys tried to generate some traffic last week by giving away free stuff with their new album. Guess what happened? Very cool, but not scalable. Sure, you can write scalable apps in PHP (Facebook, YouTube, etc.), but I don't think the average PHP programmer has the rigorous training and experience needed (or support from his server-side technology) for writing apps of the same calibre as you find in the enterprise Java community.
  63. Google runs it[ Go to top ]

    http://code.google.com/p/google-guice/wiki/SpringComparison "Guice was born purely out of use cases from one of Google's biggest (in every way) applications: AdWords. We sat down and asked ourselves, how do we really want to build this application going forward? Guice enables our answer."
  64. I posted a reply on the guy's site to the effect of (paraphrased): 'yeah, right; cherry pick a couple of sites and try to ask a "neutral" question, when actually you are merely trying to bait people to drive traffic to your site for self-promotion'. I mean, seriously, the guy is either really, really, really misinformed, which I doubt, or he's got an agenda. Of course, when I posted a comment along these lines to his site, he apparently deleted it(?) cuz it never showed up. Funny. Sadly, his technique is working - post something outrageous, with no facts to back it up, and then watch as your site traffic ramps through the roof. Sad self-promotion technique...
  65. When I posted a comment along these lines to his site, he apparently deleted it(?) cuz it never showed up
    I can assure you that i never deleted any post on my blog and you are welcome to state any comment that you wish to. You can see that other that share the same view as you are already did that and their response was not deleted by anyone. As for your theory above, I can assure you that the intent behind my question was from pure curiosity. I started to follow the LAMP stack more closely just recently. It seems that all of a sudden the large website companies (Google, Amazon, eBay...) decided to publish their architecture in the public. Looking into all this interesting available information made me thinking.... What can we learn from the fact that similar challenges had been dealt similarly but with different type of implementation approaches? Clearly there must be interesting lesson we can learn from that. You simply can't argue with the fact that the sites that i was referring too where able to deal with relatively large scale requirement without Java. Note i wasn't saying that you can't do it with Java, I was mainly pointing to the fact that you can do it WITHOUT JAVA and get pretty good results. Some argues that in a much simpler way. Nati S.
  66. It's not just PHP[ Go to top ]

    Python is emerging as a may player here too. It's also starting to introduce the idea that there's power in simplicity. Somebody (I can't find the link) put a finger on exactly what's wrong with the Java community: they think that because something is simple, it can only be useful for simple things. Wrong. It'd be much easier to use something simple for a very complex task because you'd focus less on the system and more on your logic.
  67. Why not compare PHP to JSP?[ Go to top ]

    Why compare two completely different technologies and treat them as the same?

    PHP is a scripting language designed for quickly and easily writing relatively simple websites. It’s designed for high productivity and quick development for websites where little expansion is considered or required. It’s the sort of technology usually used for something like Forums or Brochure sites.

    It’s quite a ‘heavy’ technology, which contains things like database access and validation directly within the pages.

     

    Java is an Enterprise standard technology designed for building structure expandable systems with lots of business logic and scope for continued growth.

     

    If you are going to compare PHP to a Sun technology then why not compare it to JSPs?  This comparison is far closer in my opinion than PHP and JavaEE.

  68. Nati Shalom has written up a blog entry on "Why most large-scale Web sites are not written in Java," inspired by a discussion with a co-worker at GigaSpaces. According to "Why doesn't anyone use j2ee?," two reasons are:
    1. The LAMP stack is open source and cost effective;
    2. J2EE is used, but only as part of the application stack, not as the entire stack itself.
    From Nati's post:
    The application stack of these Web applications [Ed. Note: Google, Amazon, eBay, LinkedIn, TypePad, WikiPedia, flickr] is very different from the stack that mission-critical applications in the financial world are built with. In the financial world, Java -- and to a lesser degree J2EE -- is used extensively. In recent years scalability requirements in capital markets led to a rapid shift in the middleware stack, introducing Compute Grid solutions for virtualization of CPU resources, enabling parallelization of batch applications. Data Grids were also introduced, enabling the virtualization of memory resources. Spring is becoming the common development framework in this world. At GigaSpaces, we're seeing more and more cases where Spring acts as a complete alternative to J2EE.
    Nati closes by asking why readers think that J2EE isn't used more for high-scale applications like Amazon, up and down the entire stack. What do TSS' readers think?

    It shows how well you understand this subject. Bookmarked this page, will come back for more.  The Panorama