What is JSP?

This blog briefly discusses about Java Server Page (JSP).

What is JSP?

JavaServer Pages—JSP, for short—is a Java-based technology that simplifies the process of developing dynamic web sites. With JSP, designers and developers can quickly incorporate dynamic content into web sites using Java and simple mark-up tags.

The JSP platform lets the developer access data and Java business logic without having to master the complexities of Java application development.

In short, JSP gives you a way to define how dynamic content should be introduced into an otherwise static page, such as an unchanging HTML file. When a JSP page is requested by a web browser, the page causes code to run and decide, on the fly, what content to send back to the browser. Such dynamic content allows for the construction of large and complex web applications that interact with users.

JSP is flexible: it adapts to the needs of developers and organizations. For some, JSP is a simple way to mix Java code and HTML text to produce dynamic web pages. For others, it helps separate Java code from presentation text, giving nonprogrammers a way to produce functional and dynamic web pages. JSP is not even limited to the production of dynamic HTML-based content. For instance, it can be used in wireless and voice-driven applications.

Because JSP is based on widely accepted standards, products from numerous vendors support it. Like Java itself, JSP isn’t dependent on a particular platform. When you learn JSP, you can be confident that your new skills will be applicable outside the individual environment in which you learned them.

Dynamic content on the web

DEFINITION: static content on the Web comes directly from text or data files, such as HTML or JPEG files. These files might be changed, but they are not altered automatically when requested by a web browser. Dynamic content, on the other hand, is generated on the fly, typically in response to an individual request from a browser.

Why dynamic content?

• Dynamic website support interaction with web users efficiently
• They allow for more than simply sending HTML or other data when a request is issued, as they take programmatic, behind-the-scenes action in response to a request. For example, an online store might need to save users’ orders into a database; an email application would actually have to send an email message. In many cases, simply displaying prefabricated HTML isn’t enough

For all these reasons, several web-specific technologies have been designed to allow programmers to design sites that respond dynamically to requests for URLs from browsers. JSP is one such technology.

Common Gateway Interface

• Was the first widely used standard for producing dynamic web content
• CGI takes advantage of different strategies to enable communication between programmes running in different operating system. Such strategies involve specifying particular text on the target program’s command line, setting up environment variables, or use a handful of other strategies
• When a web server receives a request that’s intended for a CGI program, it runs that program and provides it with information associated with the particular incoming request. The CGI program runs and sends its output back to the server, which in turn relays it to the browser
• CGI is not an application programming interface (API) for any particular language. In fact, CGI is almost completely language-neutral. Many CGI programs have been written in Perl, but nothing prevents you from writing one in C, LISP, or even Java. The CGI standard simply defines a series of conventions which, when followed, let programs communicate with CGI-aware web servers and thus respond to web requests

Disadvantages

Because it imposes few constraints, CGI is quite flexible. However, the CGI model has an important drawback: a web server that wants to use a CGI program must call a new copy in response to every incoming web request.

In operating-system parlance, a running instance of a program is known as a process. In slightly more formal terms, then, CGI requires that a new process be created, or spawned, for every new incoming web request.

CGI doesn’t provide for any mechanism to establish an ongoing relationship between a server process and the external CGI processes it runs. This limitation leads to a relatively large cost of initialization upon each new request, for creating a process on a server is a relatively expensive operation. This cost isn’t immediately obvious when a server runs only a handful of programs, but for large web sites that deal with thousands of requests every minute, CGI becomes an unattractive solution, no matter how efficient an individual CGI program might be.