Server-side web programming is well established on the web. It lets you build systems with a client part that can run in a browser on any computer, with any operating system, at any time, from anywhere in the world.
The HTTP protocol provides a framework for communicating with a server, where all the real work is done. The server-side code may do load-balancing to move incoming requests to the system best equipped to handle them. The server code can access/update your database and process any data using the most up-to-date information. It does this in a safe way.
The client cannot call server routines directly. It can only send over HTTP requests saying what it wants. Opportunities to subvert the server are more restricted than when everything runs on one physical system. You still need to code defensively because people may try to access your page in a way that could make the server spend all its time trying to service their request.
Client/server programming was popular even before the web went mainstream, and bringing the two together was a natural marriage. CGI—the “Common Gateway Interface”—was the first attempt to get dynamic content into web pages. CGI got the job done, but it had big problems with security and performance. CGI implementations often start up an entire new process to run a script. It doesn't have to be done that way, but in practice it usually was. Servlets are loaded into memory once, and stay around ready to handle all future requests. So there can be a big performance advantage to using servlets. It also means that servlets can choose to hold system resources (such as a database connection) between requests. Since opening and closing a database connection is a lengthy operation, this is another win for servlets.
Servlets make it easier to separate the business logic used to generate results from the HTML that displays those results. JSP takes that one step further. Separation of logic from presentation has benefits. It's an enabler for the use of component software such as Java Beans. Component software lets a system designer deploy the same code to handle a transaction whatever the origin is: web-based, online transaction, or batch processing. We're getting into enterprise-level software issues here, but servlets deliver consistency and code reuse.
Servlet technology replaces the family of server plugins such as the Netscape API, CGI, or the Microsoft ISAPI, none of which are standardized or multiplatform like the servlet API. Servlets today are the most popular choice for building portable interactive web applications. Add-on software to run servlets is available for Apache Web Server, iPlanet Web Server, Microsoft IIS, and others. Servlet containers can also be integrated with web-enabled application servers such as BEA WebLogic Application Server, IBM WebSphere, iPlanet Application Server, and others.
Servlets are highly effective in implementing web services. Chapter 28 reviews two public implementations of web services. For now, think web services = “a way for a program here to run a program on a remote server and get the output back here in easily processed form”.
People are currently driving the technology even further with a technique called “ASP” or Application Service Provision. Don't confuse Application Service Provision with “Active Server Pages.” Provisioning is all about extending the benefits of client/server systems to all kinds of application software. The idea is that instead of buying software and installing it locally on your PC, you rent access to the software at the ASP site. Instead of running a spreadsheet locally, the program executes on a server at the ASP site and sends you the equivalent data for display on your screen. Instead of running a mail program on your system, you pay Google to filter, store and serve your email to a browser client. You pay Google “in kind” by accepting the ads they insert into your messages, then Google brokers the ads for real money. Google has done pretty well with the ASP model; its 2004 revenue was about $1 Bn.
Ideally, you don't see a feature difference between using an ASP and running your programs locally, but the total cost of ownership is lower. The ASP takes care of all the system administration tasks, data backup, etc., and your PC is just used as a communications device to reach the ASP. You don't even need an expensive heavyweight PC. You can use any number of cheap or portable or wireless devices to connect to the ASP. Servlets are ideal for use in an ASP, providing a simple way to connect clients to server processing.
The ASP model has some compelling advantages and is winning acceptance. If you think this sounds like a rerun of X-Windows or Citrix technology, you are right, but the web aspect adds a significant new dimension: the ability to run from any computer, any OS, anywhere. Nobody yet knows when Application Service Providers can deliver on the early promise, but there are a number of smart people working hard to make it happen.