Java Server Pages

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:

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?

-- KyleBrown

JSP tag library complaints in ScriptletsCanBeBetterThanTags.

Why have both JavaServlets and JavaServerPages?

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.

-- KyleBrown

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.

-- ThomasMaeder

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 ?

-- AlanFrancis

My JSP wiki clone VeryQuickWiki runs on ApacheTomcat. -- GarethCronin.

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.

-- KyleBrown

That is now reality. See http://jakarta.apache.org/tomcat/index.html and download Apache's TOMCAT. -- KyleBrown

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?)

-- RichardEmerson

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.

-- DrewMarsh (claiming to know almost anything MicroSoft related ;)

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.

I would be very interested to hear/discuss ServletAndJspPatterns. -- ChanningWalton

I think you'll find that http://virtualschool.edu/wap boils down to precisely that, particular the "The Problem" link in the left margin. -- BradCox

BrokenLink as of 2005-05-06 -- has it moved to http://virtualschool.edu/jwaa/ , or is that something completely unrelated ?

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?

Yes, XSLT is a good choice, and not permanently tied to Java. It's the choice du jour.
We used WebMacro on the DenaliProject. Incredibly simple Java technology. The pages looked like HTML. The file names could even be whatever.html. And the embedded dynamic stuff was simple, flexible, and easy for the HTML design team to avoid. The ultimate advantage? We could unit-test the pages without deploying the application! And the design team could even run the test suite! Ah, the good old days of simplicity.
That system where we removed all the JSP pages? A set of home-grown Widget objects. TomMeloche? of MenloInstitute had pointed out that we were not building a "web application." We were building an application that happened to have a web interface. There was talk of porting the interface to Swing. That never happened, but the customer did eventually require that every important page would have a "PDF" button. The page itself would have to re-render as PDF using the current data. Everyone was smiling at that planning meeting: We all knew it wasn't going to require re-architecting the entire site.
But if it did write directly to HTML, then why not convert the HTML into PDF? As described in SeparateDomainFromPresentation, a generic formatting interface is often elusive. HTML is as good (or limited) as any other. Remember, HTML is not an "implementation", but a high-level protocol/language in itself. I find HelpersInsteadOfWrappers a helpful technique to reduce repetition that may appear for any given application.

Before someone points out how incredibly efficient JSP pages can be: Well, sure. They're compiled into Java byte-code rather than using reflection (as WebMacro did). I'm forced to reflect on JimShore's tongue-in-cheek rule of optimization: It ain't what you think it is. (See OptimizationStories).

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.

-- RobMyers

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

CategoryWebDesign CategoryJava