Java Server Pages are an HTML template technology similar in form to Microsoft ActiveServerPages, but different in concept. A JavaServerPage is compiled into a Servlet by an application server, rather than being interpreted. Also, in addition to the ability to provide in-line code in Java like so:
<HTML> The date is <%= new Date() %> </HTML>
JavaServerPages are different from ASP's in that they provide special tags to interact with JavaBeans. These tags allow a JSP to "pull in" a bean from a number of sources and display parts of it. They can also be used to "fill" a bean from the input parameters of an HTTP request.
Could you explain a little more about JavaServerPagesAndJavaBeans?
JSP tag library complaints in ScriptletsCanBeBetterThanTags.
A Servlet is Java that writes out HTML, while a Java Server Page is HTML with embedded Java and other special constructs. The JSPs are easier for HTML designers to create, a Servlet really needs a programmer to create. -- RobertField
JavaServerPages exist because you often have the case where you have a relatively small amount of dynamic content is embedded in a much larger set of static content. Since it is better to let your page designers (who presumably work in MicrosoftFrontPage or something of that ilk) work on the HTML rather than your Java programmers, the idea is to let the page designers do their stuff and then place a little Java code into the results to accomplish what you want.
IMO the big advantage over plain servlets is that you can edit the appeareance of your web page without touching java code. You don't need to know about all the nifty processing going on behind the scenes just to change an image link. Second, you get a clean separation of your buisiness objects and the presentation. You put the hard stuff in some (Enterprise) beans and whip up a new presentation of the data easily.
I've written a little Wiki clone using JavaServlets, JavaBeans and JavaServerPages. The JavaServlet interprets the request (edit, post, search, browse), uses one JavaBean (PageDatabase) to construct a another JavaBean (Result) with the resultant info (pagename, body text, last edit date etc) and redirects the request (and the JavaBean) to a JavaServerPage. This way the format of a page, and edit form etc is stored in a JSP and the logic about retrieving and storing pages (including edit histories etc) is kept in the JavaServlet.
Main problem at the moment is this strategy of embedding the bean in the request relies on Servlet2.1 (which I've got working with my evaluation version of JavaWebServer?). It doesn't seem to work with Servlet2.0 which is all that Apache supports.
Anyone got any ideas on a freely available server which will support servlet2.1, serverpages1.0 and is a little more fully-featured than servletrunner ?
IBM and Sun announced an initiative at JavaOne that will end up putting a freely available Servlet runner and JSP engine into Apache. No more details immediately, but keep your eyes on the Sun and Apache websites.
I was just about to do exactly the same - a Wiki clone with JSP and Beans. JRun (http://www.jrun.com/) is the chap for JSP 1.0 support. There's a free-no-charge version but not a free-open-source version. JSP 1.0 is an add-on download. We're using WebSphere here, which I'm told won't do JSP 1.0 until its 3.0 version (due soon... Kyle?)
I like the idea that they're compiled. MicroSoft's ASPs are interpreted on the server at run time -- every time you fetch the page. Now how scalable can that be? -- JeffGrigg (Not claiming to really know what I'm talking about, honestly. ;-)
That's incorrect actually. I'll describe the process for execution under ActiveServerPagesExecution.
In the long and short of it, I would agree that JSPs could beat ASPs in some performance tests. However, if you consider the total overhead of actually compiling the damn things on the first run... I'd say it's a close call.
On a reasonably set-up server, the overhead of compiling jsp's is comparable to the overhead of compiling any application, because it's only done when the code has changed. The implication is the overhead of compiling is likely to dwindle into insignificance rapidly for any jsp with a reasonable hit rate. This isn't an assertion about which is faster - just that the compilation overhead isn't likely to be high in a busy system.
See the AtgDynamo pages for information on JHTML.
JSP is an instance of the TemplateView pattern.
JSP is an instance of WagTheDogAntiPattern, which I will define when I get up the courage to actually try to describe a pattern in this Wiki, where I feel genuinely intimidated by the knowledge and experience of the ... elders. In brief: HTML is one of many external protocols that should be kept external by encapsulation, not brought into the heart of an application. I have seen this done with XML to the utter ruination of an app. We have a perfectly good OO basis for generating *ML: the DOM. -- TomRossen
But...the standard approach is to keep the HTML external to the app with the JSP. Or are you suggesting that you should always use XSLT to convert XML into HTML?
Another question: Isn't JSP supposed to be the encapsulation? Unless you are putting lots of your application logic in scriptlets (which is itself another CodeSmell). From my experience, if you bother to wrap your business objects in JavaBeans, the JSPs can be very clean.
But HTML is a protocol, not an implementation. The browser is the implementation. See FuzzyDistinctionBetweenInterfaceAndImplementation. Perhaps this is just another manifestation of the NoStrings HolyWar.
I've found JSP pages to be a solution to a nonexistent problem, and the cause of a huge set of their own avoidable problems. I have successfully lobbied clients to drop JSP pages from existing architectures. Yes, we had to go back and rewrite them. And, yes, it turned out to be worth it. The client later thought we were prescient.
First, some history: JSP was Sun's response to ASP. The justification (marketing hype) went something like this: HTML strings embedded in your Servlets is a Bad Thing. So, CLEARLY (sarcasm drips from my keyboard), embedding Java source code into your HTML pages is The Solution.
Sun backed off from their initial suggestion that an entire web app could be written with JSPs, and "MODEL2" was born. Because JSPs represented a View in the ModelViewController architecture, we needed a Controller servlet to forward to the correct JSP page. Essentially, one servlet hands responsibility off to another (since a JSP page is compiled into a servlet...a really ugly servlet). Since this requires state, let's hang that state on the session. (I don't think we had persistent sessions at that time.) Things continued to snowball, until some intrepid developers built Struts to put simplicity back into MVC.
But note: Had we (and every other dot-BOMB architect) not selected JSP technology in the first place...no snowball...
What else is there?
Non-JSP "single servlet" solutions can be fast and scaleable. Add another machine, load-balance, and you could handle nearly twice the volume, I suppose. Imagine the money you'll save on a system that is flexible, scaleable, easy to maintain. Enterprise-level web applications on a budget. I sense a disturbance in TheForce. Surely, it's those VC-burning dot-BOMB super-consultants I worked with in the 90's, writhing with fury.
You toss a bomb shell out without the first thing to back it up. That is a sign of someone who likes to fire for effect or does not know the technology that they criticize or both. Have you ever built a JSP/Servlet infor system of any size. Doubt it. HHall