About Java^TM Servlets

All user interaction is by means of Java Servlets. These are small java programs that run on the server side of a web server/web client connection. The servlets employed here use the same HTTP communications standard that ordinary static web pages use to communicate with the client's web browser, so from the point of view of the browser, web pages produced by servlets look no different from ordinary static HTML pages.

Java^TM servlets are small, platform-independent Java programs that can be used to extend the functionality of a Web server in a variety of ways. Servlets are to the server what applets are to the client - small Java programs compiled to bytecode that can be loaded dynamically and that extend the capabilities of the host.

Servlets differ from applets in that servlets do not run in a Web browser or with a graphical user interface. Instead, servlets interact with the servlet engine running on the Web server through requests and responses. The request-response paradigm is modeled on the behavior of the HyperText Transfer Protocol (HTTP).

A client program, which could be a Web browser or some other program that can make connections across the Internet, accesses a Web server and makes a request. This request is processed by the servlet engine that runs with the Web server, which returns a response to a servlet. The servlet in turn sends a response in HTTP form to the client.

From the point of view of the client, the dynamic HTML generated by a servlet is indistinguishable from static HTML pages.

In functionality, servlets lie somewhere between Common Gateway Interface (CGI) programs and proprietary server extensions such as the Netscape Server API (NSAPI). Unlike CGI programs and NSAPI modules, you do not need to modify servlets to be specific to either a platform or a server.

Servlet Server

Just as regular web pages are "served" by a web server application, servlets are also provided to the client via a web server. This can be the same web server as is used for static pages (as is the case with Sun's Java Web Server), or an entirely different product that runs on either the same or a different server (such as JRun).

The user of the system first browses through static web pages, which act as a navigation guide to the various parts of the system (much like menus in legacy systems). The user then clicks a link which refers to a servlet, and some action takes place as a result of the link being activated.

Normally, this will be a form being presented to the user, or some confirmation that a request has been handled. For more time-consuming functions, however, the system has a job queue. Longer requests are queued in this job queue, and handled in background on the server. The user is then usually notified when the job completes via e-mail.

Servlet Advantages

Servlets have the following advantages over other common server extension mechanisms:

• They are faster than CGI scripts because they use a different process model. 
• They use a standard API that is supported by many Web servers. 
• They have all of the advantages of the Java language, including ease of development and platform independence. 
• They can access the large set of APIs available for the Java platform (Database access, email, directory servers, CORBA, RMI, Enterprise JavaBeans and others).

Alternative Solutions

Most applications on the web today are of four general types: 

• server based CGI forms; 
• Active Server Pages
• client-based Java applets 
• and servlets.  

CGI Forms

An early web solution was the CGI-BIN interface; developers wrote individual programs to this interface, and web-based applications called the programs through the web server. This solution has significant scalability problems -- each new CGI request launches a new process on the server. If multiple users access the program concurrently, these processes consume all of the web server's available resources and the performance slows to a grind.

Java Servlets is a technology that is rapidly replacing CGI scripts as the preferred choice for web site server-side processing. If you have heard anything about Servlets you know that one of the advantages over CGI is that a Servlet can keep information between requests and share common resources.  Using CGI, performance and scalability are big problems since a new process is created for each request, quickly draining a busy server of resources. Sharing resources such as database connections between scripts or multiple calls to the same script leads to repeated execution of expensive operations.

CGI forms are quick to download and allow developers to use heavy processes located on back-end servers to calculate/query results.  Their disadvantage is they require the user to hit the Submit button to get anything to happen, don't offer intuitive navigations between data fields, and are slow to regenerate the results screen.  In general they are not friendly to use. 

Security is another big concern. Most Perl scripts use the command shell to execute OS commands with user-supplied data, for instance to send mail, search for information in a file, or just leverage OS commands in general. This use of a shell opens up many opportunities for a creative hacker to make the script remove all files on the server, mail the server's password file to a secret account, or other undesirables.

The Web server vendors defined APIs to solve some of these problems but an application written to these proprietary APIs is married to one particular server vendor. If you need to move the application to a server from another vendor, you have to start from scratch. Another problem with this approach is reliability. The APIs typically support C/C++ code executing in the Web server process. If the application crashes, e.g. due to a bad pointer or division by zero, it brings the Web server down with it.

Active Server Pages

Microsoft's Active Server Pages^TM (ASP) technology makes it easier to create dynamic content on a web page, but only works with Microsoft IIS or Personal Web Server. ASP is a proprietary technology developed by Microsoft, and limits deployment to only their own web server. It utilizes a subset of the non-portable visual basic language, and is not suitable for commercial-quality development of web applications for a number of reasons, including performance, database portability and access, and the structure of the language itself.

Java Applets

Java applets, on the other hand, usually download the business logic to the client machine and run what is essentially a little application there.  Once downloaded they are quick to respond and can offer a more application-like user interface.  However, they can be painfully slow to download initially and they cannot access server-side processes easily.  A separate slow download must be endured for each new piece of functionality in the overall application.

Jcorporate is servlet technology to achieve the advantages of java technology while eliminating the drawbacks of applets and CGI. All business logic runs on the back-end server, which means that it is never downloaded to the user machine and it can easily access server processes, such as database queries, real-time feeds and multi-processor calculation engines.

The Evolution to Servlets

As Web sites get more and more interactive, customized and dynamic, developers turn to technologies that allow them to do more than the first-generation tools could handle. One technology that is rapidly replacing CGI and Perl scripts as the preferred choice for dynamic Web sites is Java Servlets. 

It's a simple API supported by virtually all Web servers and even load-balancing, fault-tolerant Application Servers. It solves the performance problem by executing all requests as threads in one process, or in a load-balanced system, in one process per server in the cluster. Servlets can easily share resources.

Security is improved in many ways. First of all, since the Java APIs provide access to all commonly used functions you rarely need to let a shell execute commands with user-supplied data. You can use JavaMail to read and send email, Java Database Connect (JDBC) to access databases, the File class and related classes to access the file system, RMI, CORBA and Enterprise Java Beans (EJB) to access legacy systems. The Java security model makes it possible to implement fine-grained access controls, for instance only allowing access to a well-defined part of the file system. Java's exception handling also makes a servlet more reliable than proprietary C/C++ APIs - a divide by zero is reported as an error instead of crashing the Web server.

Servlet-based applications avoid a lot of overhead processing. Using threads instead of processes means that a Servlet can keep data persistent between requests. For instance, a pool of database connections can be shared by multiple requests and frequently requested information can be cached. Threading and persistence makes it much easier to develop high performance solutions. 

Performance and scalability are important concerns when selecting a technology for your Web site development. A popular site can receive an enormous number of requests per day. With the inherited threading and techniques like database connection pooling and caching, Servlet-based solutions are well fit to handle the pressure. 

JavaServer Pages (JSP) Technology

Jcorporate implementations use industry-wide technologies.  For creating pages with dynamically-generated content we suggest Javaserver Pages (JSP); and have appropriately integrated the use of this technology into our products which allows developers to build their own custom interfaces to our servlets if they want to. A few years ago, JSP pages were introduced to the Java programmer community as a way to bring dynamic content and programmatic-like function to the Web browser.

This solution addresses the limitations of other alternatives by:

• Working on any web or application server
• Separating the application logic from the appearance of the page
• Allowing fast development and testing
• Simplifying the process of developing interactive web-based applications

JSP pages have evolved to bring reusable components, known as tag libraries, into developer hands. With tag libraries, programmers can build tags that Web developers use to invoke actions while at the same time buffering Web developers from changes in the underlying tag support (either sheltered from developer changes to the code or even from changes to the JSP specification itself). Tag libraries go well beyond the first generation of JSP pages, which largely centered on JavaBean interactions.

The present comes with another year of growing up for the specification and JSP capabilities. It is clear that JSP pages are a pivotal player in the coming Web services revolution, the Java Enterprise Edition answer to Microsoft's .NET platform.

The JSP specification is the result of extensive industry cooperation between vendors of web servers, application servers, transactional systems, and development tools. Sun Microsystems developed the specification to integrate with and leverage existing expertise and tools support for the Java programming environment, such as Java Servlets and JavaBeans^TM. The result is a new approach to developing web-based applications that extends powerful capabilities to page designers using component-based application logic.

Simply put, JSP pages enable Web developers to add predefined actions and capabilities to their Web content. When a Web page is accessed that contains JSP tags, the Web page is generated into a servlet (on the first hit), the servlet is executed, and output is produced.

In the past, JSP pages were essentially tags that were added to an HTML-based page. The output of the servlet was a complete HTML page that the browser accepted and the user could interact with. JSP 1.2 changes all of that. Riding atop the changes to the underlying servlet architecture, the new JSP 1.2 specification formally recognizes that XML plays a heavy role in Web services. JSP pages can now be authored as full XML documents. Also, additions to the JSP and servlet specifications make it possible to create tag libraries that provide a robust user interface, as well as tag libraries that are coupled with the ability to extract data from back-end databases.

Let's cover some of the updates that are a part of the Servlet 2.3 specification, as well as some of the major updates to JSP technology for version 1.2 of the JSP specification. These updates allow developers to build onto the JSP base and produce robust, reusable tag libraries, frameworks, and Web services.

The reference implementation for the Servlet 2.3 and JSP 1.2 specifications is available in the open-source, free, Tomcat 4.0 implementation available from Apache. "JSP Quick-Start Guide" has been updated recently for use with Apache 1.3.22, Tomcat 4.0.1, and mod_webapp which is the new Apache connector module for Tomcat 4.x. This step-by-step tutorial shows you how to set up and run a JSP-enabled server under Windows. By the end of this, you'll have a basic JSP page working smoothly.

Servlet 2.3 Updates

Among many iterative changes in the servlet specification are two specific changes that have a large impact on the purpose of, and how you use, servlets:

• Filters
• Event handling

Filters are a mechanism for intercepting and modifying requests and responses. The uses of filters can vary from blocking particular users or identities to transforming content after it is output from the servlet itself.

Filters are a formal part of the Servlet 2.3 specification. Within the new servlet packages, look for the Filter, FilterChain, and FilterConfig classes.

Event handling delivers the ability for a client to listen for a variety of page life-cycle events and HTTP request events. The event mechanism looks toward Web applications and the activities that are vital to controlling a Web application.

The first set of events that can be handled in servlets relates to the start-up and shutdown of servlets and changes in context attributes. The second set of events relates to HTTP sessions. With the events that can be intercepted by the HTTP event handling, you can watch:

• Creation and invalidation of HTTP contexts
• Changes in session attributes
• Migration of contexts from container to container

Like the filters, to get a "handle" on the new ability to handle events that relate to servlets and sessions, look to the Servlet 2.3 specification.

JSP 1.2 Updates

JSP technology inherits the changes to the Servlet specification by the nature of the generative programming that turns JSP pages into servlets under the covers. The servlet capabilities become a major part of delivering new tag libraries and capabilities to users. In addition to the inherited changes from servlets, formal XML support is perhaps one of the biggest additions to the JSP specification.

XML is one of the major workhorses that enable Web services. Prior to JSP 1.2, JSP supported XML by allowing JSP pages to generate XML data or be placed with XML streams themselves. With JSP 1.2, the JSP page itself becomes a well-formed XML document. XML support goes further than just the JSP pages; XML is being woven into the structure of tag libraries to help with meta-data information for the tag libraries. By becoming fully XML-compliant, JSP becomes a far easier specification to integrate into toolsets. It also becomes intertwined, and in some cases inseparable, from the whole Web services initiative.

There are other iterative changes to the core JSP specification, but in many ways the changes to JSP that are most important are those that are occurring above the core JSP specification.

Besides the substantial changes to the JSP and servlet bases that I mentioned earlier, there are a large number of updates to the inner workings of JSP. A community of developers is building atop the core JSP technology. These additions, in the form of standardized tag libraries, frameworks, and Web services, are what will propel JSP into the enterprise space and into programmers' rapid application development toolkits. In many ways, JSP can be compared to the Java platform, with tag libraries playing the crucial role for JSP that extension libraries play in the Java platform.

Struts Integration

What we've done (in a very quick nutshell) is made Controller objects available to Struts as Actions, so the URL mapping, configuration, and other great capabilities of Struts are available - with all of the advantages that the Controller object, DBObjects, and other Expresso components bring as well. The Controller servlet (ActionServlet) still handles dispatching, then the specific Controller object provides the UI-independant business logic. The release notes give a few more details at http://www.jcorporate.com/doc/release.html.

Tag Libraries

Companies spend resources on developing common components, frequently user interfaces, which other developers within the company then build upon. The capability for building tag libraries really came in JSP 1.1, but now tag libraries are common and robustly used. In the next year, you are going to see communities and products form around tag libraries. If you are new to JSP development, custom tag libraries are something that you'll want to become familiar with. Custom tags are a way to separate presentation from logic. If you have tasks that are being done repetitively they are probably good candidates to be incorporated into a tag library. Incorporating them into the tag library makes life easier for the page designer because if there are logic changes, they can be handled within the tag library. There is no need to actually change the JSP. This also means that if there are page layout changes, there is no need to change the logic. Using tag libs makes for more maintainable JSP.

Custom tags can modify content within a tag body and have access to the application context. Custom tags can be used to generate dynamic content as well as to implement flow control. Additionally, tags can interact with other tags as well as be nested within each other.

There are several JSRs to watch from Sun Microsystems that help seed the evolving tag library market. Among the JSRs that are working their way through the community process that involve tag libraries:

• JSR 97: JavaHelp, formalization of the JavaHelp specification for use from JSP pages.
• JSR 114: RowSet, helping to extract and present data from databases.
• JSR 128 and JSR 126: JESI and Distributed Page Assembly help bring what could be considered a four-tier model to JSP pages. These two JSRs revolve around the ability to cache and use data nearer the client, thus alleviating traffic and server load.

The JSRs are remarkable in what they represent, rather than any huge technical challenges that they may or may not be solving. The core JSP model is stabilizing, much like the Java platform itself has stabilized. Services and capabilities are now exploding on top of the JSP specification which will make rapid application development possible in the J2EE space.

One of the greatest challenges facing individual companies that develop with JSP pages is the difficulty in developing browser-based user interfaces. A lot of resources in a development shop go toward developing tag libraries that present the user interface to a browser (and thus, the client). Developers are building a common look-and-feel and turn it into a tag library for other developers to use for representation of data and user interface.

Last year, tag libraries made JSP pages usable and versatile for developers. This year, the proliferation of tag libraries and standards will make possible efficient use of JSP pages when building Web interfaces and interacting with data, through such projects as JavaServer Faces and a myriad of community processes that may be smaller in scope (like JSR 114 bringing RowSets to the JSP community), but no less important to the overall Web services strategy.

JSP pages have grown up and are now an essential piece of the future of the Java platform. Keep track of this technology; it is no longer a relatively Web-centric niche that demands little attention. There will be JSP pages in your future.

For more information: http://java.sun.com/products/jsp/

JavaServer Faces

JavaServer Faces, JSR 127, changes this process. With JavaServer Faces, a common user interface infrastructure (developed at Sun) is handed to developers in the form of tag libraries, which developers can then reuse and customize to be their own. Not only does this help break down the barrier to full acceptance of JSP pages, it helps tool vendors to support JSP pages within their IDEs and application development suites. JSP is evolving to a pivotal standard that will make offering Web services from the Java platform a reality. From the perspective of Struts, JavaServer Faces will provide an alternate approach to building the pages in the view layer -- and you can still use the the rest of the framework to manage the overall application. JavaServer Faces is focused on creating a GUI component model for web apps, so that you can create development tools that give page developers an experience similar to WebForms -- drag some GUI components onto your page and attach event handlers to them. Due to the nature of HTML and HTTP, some of these events will happen on the client side, and some will require a roundtrip to the server to do something and redisplay the same page. JSF is going to be developed under the Java Community Process as JSR-127. From the perspective of Struts, JavaServer Faces will provide an alternate approach to building the pages in the view layer -- and you can still use the the rest of the framework to manage the overall application. As for "an MVC framework as part of J2EE's future", a *lot* of people at JavaOne seemed to think that this would be a good idea, and that Struts would make a good framework ... you never know what the future might hold.

The complete acceptance of XML into the authoring of JSP pages makes it easier to integrate JSP pages into Web-building applications. It also provides essential meta-data to the JSP pages and tag libraries so tag libraries become an efficient and standardized means of reusing code.

Enterprise Java Beans

The most promising segment of Java's component model is clearly Enterprise JavaBeans (EJB). Building on a growing trend toward enterprise computing architectures based on multi-tiered applications, EJB technology promises dramatic improvement in enterprise server portability and scalability, along with simpler application development, deployment, and maintenance. Instead of writing code from scratch, EJBs allow developers to snap together pre-built software modules.

Analysts at the Gartner Group, note that while companies on average spend about $1.1 million for an e-commerce site, more than 70 percent of that cost is tied up in labor. A library of proven, reusable components could dramatically shrink those labor costs. And desirable as a platform-independent alternative to something like Microsoft's DCOM.