+ All Categories
Home > Documents > Lecture 3

Lecture 3

Date post: 08-Jan-2016
Category:
Upload: meira
View: 30 times
Download: 0 times
Share this document with a friend
Description:
Lecture 3. Introduction to Dynamic Web Content Generation: * The Java Servlet API * Java Serves Pages (JSP). Overview. Brief HTTP review Web servers and dynamic content generation Servlets The container Servlet API Advanced issues Multithreading Handling State and Session management, - PowerPoint PPT Presentation
61
Lecture 3 Introduction to Dynamic Web Content Generation: * The Java Servlet API * Java Serves Pages (JSP)
Transcript
Page 1: Lecture 3

Lecture 3

Introduction to Dynamic Web Content Generation:

* The Java Servlet API

* Java Serves Pages (JSP)

Page 2: Lecture 3

Overview Brief HTTP review Web servers and dynamic content generation Servlets

– The container– Servlet API– Advanced issues

• Multithreading• Handling State and Session management,• Filters

– Developing servlets with Tomcat Java Server Pages (JSP)

Page 3: Lecture 3

Review of HTTP and URL

HTTP – HyperText Transfer Protocol HTTP runs on top of TCP/IP protocol

– First specified in 1990 – Current is HTTP/1.1

• Specification is at: http://www.w3.org/Protocols/rfc2616/rfc2616.html

• http default port: default port 80• https (HTTP on SSL)default secure port 443

Universal Resource Locator (URL) format:– <protocol>://[user[:password@]]<server>[:port]/[path][/

resource][?parm1=parma&parm2=parmb&…]

Page 4: Lecture 3

HTTP Session and Message Format Client opens a connection to the server Request (use telnet to see socket conversation)

GET /index.html HTTP/1.0HEAD / HTTP/1.0

Response:

HTTP/1.1 200 OKDate: Sun, 13 Apr 2003 15:57:27 GMTServer: Apache/1.3.26 (Unix) mod_python/2.7.1

Python/2.0 PHP/4.0.4Connection: closeContent-Type: text/html[CRLF][Message Body]

Connection is closed by the server (or by the client)

Error codes: Every response contains an error code.

•100 level: Informational

•200 level: Success (200 == OK)

•300 level: Redirection

•400 level: Client Error (401 == BAD REQUEST)

•500 level: Server Error (503 == SERVICE UNAVAILABLE)

Header format:<Header>: <value>CRLF

Page 5: Lecture 3

HTTP HeadersFormat: [name] : [value] CRLFClient Examples: connection: Keep-Alive user-agent: Mozilla/4.04 [en] (WinNT; I) host: www.foo.edu accept: image/gif, image/x-xbitmap, image/jpeg accept-language: en accept-charset: iso-8859-1,*,utf-8

Server Examples: Date: Mon 18 Apr 2000 00:26:05 GMT Server: Netscape-Enterprise/3.6.2 Last-Modified: Mon, 24 Jun 1999 14:23:45 GMT Content-Type: text/html Content-Length: 450 Accept-Ranges: bytes

Page 6: Lecture 3

GET Most common method used to request a read

only resource from the server (e.g. a static HTML page)

May contain a If-Modified-Since header field, in which case it becomes a conditional GET: – only if the target has been modified since the

datestamp in the If-Modified-Since field,

– in this case returns 304 Not Modified error message.

Parameters are stored in the URL itself:GET /index.html?user=matei&password=secret HTTP/1.0

Page 7: Lecture 3

POST Allows the user to pass information to the server. All parameter information is stored in the body of the

request rather than in the URL, which provides for more privacy (see password above)

No preset limit on the amount of information that can be passed as there is with the parameter passing of a GET

A POST is typically generated by the browser in response to a click on a Submit button on an HTML form that declares the POST method

POST /login.html HTTP/1.1User-Agent: Mozilla/4.50 [en] (WinNT; I)Accept: image/gif, image/jpegContent-Length: 34<CRLF>user=matei&password=secret

Page 8: Lecture 3

Other HTTP Methods HEAD

– Identical to GET except that it only retrieves the header, not the body.

PUT– HTTP 1.1 method for file uploads

DELETE– HTTP 1.1 method for deleting resources on the server (with permission)

OPTIONS– HTTP 1.1 method for requesting information regarding the commands

(methods) the server supports

TRACE– a HTTP 1.1 method that returns the same request back to the client,

usually for debugging purposes.

Page 9: Lecture 3

HTTP is stateless Discrete connections

– Server closes TCP/IP socket connection after processing a client request.

– Client may also close a connection at will• eg: Pressing the Back or Forward button in a browser

– Each client request is handled in a discrete connection Features of Stateless Connections:

– Server can accommodate a number of clients exceeding the number of server threads

– No server overhead associated with tracking client sessions between connections

– Keep-Alive specification in HTTP/1.0• Multiple files (of a single URL) may be delivered over a single socket

connection, as opposed to each item delivery (.bmp, .jpg, .gif, etc.) requiring its own connection (pre 1.0)

• Client must specifically request a KeepAlive connection• Keep-Alive specification default in HTTP/1.1

Page 10: Lecture 3

Overview

Brief HTTP review Web Servers and dynamic content

generation Servlets Java Server Pages (JSP)

Page 11: Lecture 3

Server Side Processing: 1st generation

First generation Web servers provided primarily static, information-only HTML pages.

Problematic for sites that wished to allow users some level of interaction

Needed:

– Dynamic server-side content generation

– Database interconnectivity

– Connectivity with existing legacy applications and new applications

Page 12: Lecture 3

Server Side Processing: 2nd generationTechnologies to extend the Web Server: Common Gateway Interface (CGI) allows to

1. create an executable script that the web server may call on demand, 2. pass incoming HTTP GET or POST data to the CGI script, and 3. filter CGI generated answers back to the browser

– since ’98, provided by most Web servers: Proprietary Extensions:

– Netscape WAI (Web Application Interface)– Netscape NSAPI (Netscape Server Application Programming

Interface)– Microsoft ISAPI (Internet Server Application Programming

Interface)– IBM’s ICAPI (IBM’s Connection Server ICS))– O’Reilly’s WSAPI (O’Reilly’s WebSite API)– Tonto’s Kemo SAPI

Page 13: Lecture 3

Common Gateway Interface (CGI)

CGI provide a standard interface Allows you to write programs that process client

requests dynamically CGIs can be written in many languages, eg., C,

C++, PERL, TCL, and Visual Basic CGIs run on the server as an standard extension,

and process the client’s request, and then return a response to the web server, which forwards the response on to the client browser

Page 14: Lecture 3

CGI Pros and Cons Benefits:

– Dynamic server-side content

– Universal support Shortcomings:

– Not efficient: need to spawn CGI program (and interpreter) with each instantiation, i.e., a new process must be created for each connection

– CGI programs cannot easily support state maintenance

– Cannot change server’s internal steps for handling a client request

Page 15: Lecture 3

Server Side Processing: 3rd generation

Advanced Technologies that allow extension of the Web Server:

Server-Side Includes– <!--#echo var=“LAST_MODIFIED” -->

Server-Side JavaScript: – JavaScript embedded in HTML, precompiled, – Netscape LiveWire

Sun’s Jhtml (Java embedded in HTML) <java> … </java> tags

Microsoft Active Server Pages (ASP) (JScript embedded in HTML, non-precompiled)

Java Servlets Java ServerPages (JSP)

Page 16: Lecture 3

Overview Brief HTTP review Web Servers and dynamic content generation Servlets

– “Hello World” servlet– Servlet API– Advanced issues

• Multithreading,• Session management• Filters

Java Server Pages (JSP)

Page 17: Lecture 3

Java Servlets Servlets are efficient, generally much faster than

CGI scripts as a different process model is used.– Run within a “Server Engine” (container)

– Servlets can be pooled within the Servlet Engine

– Servlets can persist state between requests because they are not created and destroyed with each client connection (as are CGI scripts)

– Servlets can take advantage of multithreading

Servlets use a standard API supported by mamy Web servers. As a result their code is portable, and can be run within different Engines

Page 18: Lecture 3

Java Servlets Servlets have no limitations on the methods they

can call (the entire Java world is open to them). Servlets can be extended like any other class, thus

one Servlet can become a base class and others can extend it.

Servlets are secure as they run compiled within a JVM on the server side.

Page 19: Lecture 3

The Servlet Engine The Servlet engine runs as an extension of the Web server The Servlet engine will start up a pool of Servlet instances

(the same Java class) The engine will multiplex client calls onto the pool of

servlets. Should client demand exceed the number of servlets in the

pool, the engine may kick off new instances of the Servlet to handle the additional load (up to a defined limit).

The engine will keep the pool size relative to demand, and may shut down some instances if demand falls off sharply

Page 20: Lecture 3

“Hello World” Servletimport javax.servlet.*;import javax.servlet.http.*;import java.io.*;

public class Hello extends HttpServlet { public void doGet( HttpServletRequest req, HttpServletResponse resp)

throws ServletException, IOException { resp.setContentType(“text/plain”); PrintWriter out = resp.getWriter(); out.println(“<html><body>”); out.println(“HELLO WORLD”); out.println(“</body></html>”); }}

Page 21: Lecture 3

Servlet Lifecycle events init() on Servlet startup, the Servlet engine calls the

Servlet’s init() method, – the Servlet may establish socket or JDBC connections, etc.

– This startup cost is only done once per Servlet instance

doXXX() depending of HTTP method used this is doGet(), doPost(), etc.

destroy() when the engine shuts down a Servlet, the engine calls the Servlet’s destroy() method, – the Servlet can destroy persistent connections such as JDBC or

socket connections

Page 22: Lecture 3

javax.servlet.http.HttpServletHttpServlet is an abstract class that defines a number of methods to

handle common HTTP requests, such as GET, POST, etc. These (overridable) methods are:

– void doGet(HttpServletRequest req, HttpServletResponse resp)

– void doPost(HttpServletRequest req, HttpServletResponse resp)

– void doPut(HttpServletRequest req, HttpServletResponse resp)

– void doOptions(HttpServletRequest req, HttpServletResponse resp)

– void doDelete(HttpServletRequest req, HttpServletResponse resp)

– void doTrace(HttpServletRequest req, HttpServletResponse resp) Provides a default implementation for the service() method which

calls the appropriate derived doXXX() method based on the incomming HTTP request

Page 23: Lecture 3

Processing requests Interface HttpServletRequest extends javax.servlet.ServletRequest HttpServletRequest is passed into the service and getXXX() methods HttpServletRequest provides methods that facilitate access to

information related to an HTTP request, such as:

– getParameter, getParameterNames, getParameterValues

– String getHeader(): gets the header

– Enumeration getHeaderNames(): gets the header names

– Enumeration getHeader(): get all header values

– String getAuthType(): gets the authorization type, if one

– Cookie[] getCookies(): gets the cookies from the request

– String getMethod(): returns the HTTP request, i.e., GET, POST,

– String getRemoteUser(): returns the remote user id

– HttpSession getSession(): returns the current HttpSession object Derives getInputStream() from javax.servlet.ServletRequest

Page 24: Lecture 3

Building generated content Interface HttpServletResponse extends javax.servlet.ServletResponse HttpServletResponse is passed into the service and getXXX()

methods, and represents the response path from the Servlet in the communication

HttpServletResponse provides methods that facilitate access to information related to an HTTP request, such as:

– defines static final ints for response codes (202 = SC_ACCEPTED, etc.)

– void setHeader(String name, int value)

– Void addHeader (int value)

– void sendError(int sc)

– void setRedirect(String url)

– void setStatus(int sc) derives getOutputStream() from javax.servlet. ServletResponse

Page 25: Lecture 3

Overview Brief HTTP review Web Servers and dynamic content generation Servlets

– “Hello World” servlet

– More on the Servlet API

– Advanced issues• Multithreading,

• Session management, etc

• Filters

Java Server Pages (JSP)

Page 26: Lecture 3

Servlet API Java Servlet Specification 2.3 available at:

http://java.sun.com/products/servlet/ Two packages:

– javax.servlet & javax.servlet.http Three core base classes / interfaces:

– javax.servlet.Servlet• the core base class for all servlets

– javax.servlet.GenericServlet (extends Servlet)• used for servlets that do not rely on any particular

communication protocol– javax.servlet.http.HttpServlet (extends GenericServlet)

• used for servlets that implement the http protocol To create a Servlet, you subclass GenericServlet or, more

commonly, HttpServlet

Page 27: Lecture 3

javax.servlet.Servlet Servlet is an interface that defines the basic structure of a

Servlet. It’s notable methods are:– void init(ServletConfig)– void destroy()– ServletConfig getServletConfig()

• A ServletConfig object passes configuration information from the engine to the Servlet.

• Houses the initialization parameters for the Servlet in an Enumeration

– String getServletInfo()– void service(ServletRequest req, ServletResponse res)

• This method is called by the Servlet engine for each request

Page 28: Lecture 3

javax.servlet.GenericServlet GenericServlet implements Servlet, ServletConfig and

java.io.Serializable interfaces Used to create a protocol-independent (non-HTTP)

Servlet, such as:

– a telnet, ftp server, a remote mortgage calculator, a game server, almost anything else conceivable

Includes default implementations for init() and destroy() Keeps the service() method abstract, so service is the

only method you have to override to implement a GenericServlet

Page 29: Lecture 3

Other javax.servlet classes ServletException ServletContext (interfaces the Servlet and the host web

server)– String getMimeType()– getMajorVersion()– getMinorVersion()

ServletInputStream extends java.io.InputStream– int readLine(byte [], int off, int len)

ServletOutputStream extends java.io.OutputStream– void print(String s)– void print(int i)– void println(double d)– void println(String s)

Page 30: Lecture 3

Overview Brief HTTP review Web Servers and dynamic content generation Servlets

– “Hello World” servlet

– More on the Servlet API

– Advanced issues• Multithreading,

• Session management, etc

• Filters

Java Server Pages (JSP)

Page 31: Lecture 3

Advanced Topics: Multiple Threads A Servlet is thread safe if it always behaves predictably

and consistently regardless of the number of concurrent threads operating

The Servlet Specification reads (p22):“… The handling of concurrent requests to a web application generally requires the web developer design servlets that can deal with multiple threads executing within the service method at a particular time…

Generally the web container handles concurrent requests to the same servlet by concurrent execution of the service method on different threads.”

Additionally, concurrency may also be enhanced by the Servlet engine launching multiple instances of the same Servlet, and then running multiple threads through each one of these.

Page 32: Lecture 3

Example: A Race Conditionimport javax.Servlet.*;import javax.Servlet.http.*;import java.io.*;

public class Hello extends HttpServlet { String userName = null; //instance var. declaration (shared between all req.)

public void service( HttpServletRequest req, HttpServletResponse resp)

throws ServletException, IOException {response.setContentType(“text/plain”);PrintWriter out = response.getWriter(); //method variable

declaration is ok userName = request.getRemoteUser(); //assume user has been

// authenticated at clientsayHello(out);out.close();

} public void sayHello(PrintWriter out) {

out.println(“Hello there: ” + userName); }}

Page 33: Lecture 3

Multiple Threads: Solutions Calls to service(), etc. are executed in their own thread.

Therefore, method variables are automatically thread safe. Instance variables and Class variables are not thread safe. Their use is a dangerous practice in multithreaded servlets,

and if they exist, their use must be synchronized:synchronized (this) {

//code that access instance variables (global variables) or

//static (class) variables } The goal is to achieve fine granularization in sychronizing

(synchronize a code snippet rather than the entire service() method)

Alternative is to implement the SingleThreadModel interface, which guarantees only one thread will be in service() method at a given time (no need for synchronize)

Page 34: Lecture 3

Overview Brief HTTP review Web Servers and dynamic content generation Servlets

– “Hello World” servlet

– More on the Servlet API

– Advanced issues• Multithreading,

• Session management, etc

• Filters

Java Server Pages (JSP)

Page 35: Lecture 3

Handling State in a Stateless Protocol Store the Session ID in the URL:

– http://www.uchicago.edu/session/972368/courses.html– Problems: insecure, unreliable, cumbersome, invalidates search engines

Rewriting the URL: – Servlets can use getParameter() and getParameterValues() of

HttpServletRequest object– Server must rewrite every URL returned to the client with the client’s

state info• <A HREF=“info.html?session=972368”>Course Information</A>

Hidden Variables– Hidden HTML form variables can be used to store state information:

• <INPUT TYPE=“HIDDEN” NAME=“session” VALUE=“972368”>

– Hidden variables are not shown to the user by the browser

Usually, a combination of Hidden Variables and URL Rewriting will do the trick

Page 36: Lecture 3

Handling State in a Stateless Protocol (2) Cookies (state only)

– HTML mechanism for tracking user identity and preferences– Simple to use, (no URL rewriting, etc.) but...– All but useless for business-critical delivery because the user can

choose to turn cookies off Session Management (state and identity)

– Valid identification and association of a particular client over multiple discrete connections over some predefined period of time.

– This association is maintained by requiring the client to return a piece of state information uniquely identifying the session with each request.

– Session associations remain valid for a specified configurable amount of time, after which the session is destroyed and invalidated.

– Often, an option is available to allow a user to manually terminate a session, usually through a logout button.

– Session management is useful for storing large amounts of data, because only the SessionID is passed between the client and server.

Page 37: Lecture 3

Servlet Session Management By default, Servlet session management is based on cookies, but the

engine will resort to URL rewriting if cookies are unavailable– note that URL rewriting can become a major performance bottleneck

The important note is that session handling with cookies is done for you automatically by the Servlet engine, servers vary on URL rewriting methods, may require some work on your part

HttpServletRequest methods for session management:– HttpSession getSession(): gets the HttpSession object attached to

this request– HttpSession getSession(boolean):– boolean isRequestedSessionIdFromCookie(): is it derived from a

cookie?– boolean isRequestedSessionIdFromURL(): is it from a URL?– boolean isRequestedSessionIdValid(): true if valid, false if

invalid (i.e., expired)

Page 38: Lecture 3

Servlet Session Management (2)Session management -- javax.servlet.http.HttpSession class: Object getAttribute (String) Enumeration getAttributeNames() removeAttribute(String) setAttribute (Sring, Object)

String getId(): gets the session ID itself long getCreationTime(): gets the time the session was created long getLastAccessedTime(): gets the time of the client’s last request boolean isNew(): returns true if this is a new session (first client access

with this ID) void setMaxInactiveInterval(int interval): sets the max number of seconds

that a session is guaranteed to be held valid before it is expired by the Servlet engine.

void invalidate(): expires the current session

Page 39: Lecture 3

Example: Shopping cartpublic void service( HttpServletRequest req, HttpServletResponse resp)

throws ServletException, IOException {….HttpSession session = request.getSession(true);

ShoppingCart cart = (ShoppingCart) session.getAttribute(“example.shopping.cart”);

if (cart == null) {// there was no previous cart associated with this sessioncart = new ShoppingCart()session.setAttribute (“example.shopping.cart”, cart);

}… //produce output…out.println(response.encodeURL(<whatever>))…

}

Page 40: Lecture 3

Overview Brief HTTP review Web Servers and dynamic content generation Servlets

– “Hello World” servlet

– More on the Servlet API

– Advanced issues• Multithreading,

• Session management, etc

• Filters

Java Server Pages (JSP)

Page 41: Lecture 3

Filters New with Servlet Specification 2.3 Lightweight framework for filtering dynamic or static content A filter is a reusable piece of code that can transform the

content of HTTP requests, responses, and header information. Example uses:

– Authentication filters– Logging and auditing filters– Image conversion filters– Data compression filters– Encryption filters– XSL/T filters that transform XML content– Caching filters

Page 42: Lecture 3

Filters: An Examplepublic final class HitCounterFilter implements Filter {    

private FilterConfig filterConfig = null;    public void init(FilterConfig filterConfig) throws ServletException {

this.filterConfig = filterConfig;    }    

public void doFilter(ServletRequest request, ServletResponse, response, FilterChain chain) throws IOException,

ServletException {        if (filterConfig == null) return;       

StringWriter sw = new StringWriter();       PrintWriter writer = new PrintWriter(sw);       Counter c = (Counter)filterConfig.getServletContext().

getAttribute("hitCounter");writer.println("The number of hits is: " + c.incCounter());    writer.flush();       filterConfig.getServletContext(). log(sw.getBuffer().toString());  

    ... chain.doFilter(request, response);  ...    

} }

Page 43: Lecture 3

Servlet Programming Hints MAKE sure you have ALL of the relevant classes are

available to your servlet. – Tomcat class loader info:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html

ALWAYS remember to restart Tomcat after any change to the configuration files

If something is going continuously wrong, and you can’t figure out why, follow the following procedure:

start: recheck the classpaths

restart the Tomcat server

restart your browser (if you’re using one)

goto start:

Create JDBC Connections in the init() method of the Servlet (more efficient)

Page 44: Lecture 3

Overview

Brief HTTP review Web Servers and dynamic content

generation Servlets Java Server Pages (JSP)

Page 45: Lecture 3

Why JSPs?

Focus on different abilities:– graphic artists will do the presentation

– programmers will do the content handling

JSP is not limited to HTML. JSP can add content to XML, etc. as well.

JSPs add vendor independence and platform independence to other alternatives (eg., Microsoft ASP, Allaire Cold Fusion)

Page 46: Lecture 3

Why JSPs? (2)

JSP adds the full range of Java capability to the dynamic content delivery scene (compare this with CGIs for instance). This adds the following capabilities:

– secure socket communications (JSSE)

– directory service access (JNDI)

– use of EJBs (EJB)

– distributed transaction services (JTS)

– CORBA access (Java IDL)

– relational database access via JDBC (JDBC)

– messaging services (JMS)

Page 47: Lecture 3

Java ServerPages The JSP engine:

– Jasper if you use Tomcat

– is just another Servlet mapped to the extension *.jsp

Scriptlets allow you to directly insert Java code into HTML. Scriptlets are demarcated by:

Begin: <%End: %>

JSPs are compiled into a Servlet on first call, only recompiled when the source file changes

Page 48: Lecture 3

Java ServerPages

Variable directives demarcated by:

– Begin: <%@

– End: %>

– Eg.: <%@ language=“java” %><%@ import=“java.util.*,java.lang.*”

%><% out.println(“Hello, World”); %><% out.println(“Hello there, ” +

request.getRemoteUser()); %>

Page 49: Lecture 3

JSP Processing Event FlowJSP Page

Servlet alreadycom piled?

Is the com piledJSP Page

Servlet up todate?

If so, is itcurrently

loaded intom em ory?

W eb Serverreceives JSPRequest from

Browser

Yes

Yes

No

Have the JSPProcessor Servlet

of the JSPContainer Parse

the JSP page

No

Build source codefor the JSP Pageservlet, defining

the m ain_jspService()

m ethod

Load the com piledJSP Page Servlet

Com pile JSPservlet page

JSP Page Servletconstructs the

Response

W eb Serverreturns the JSPresponse to the

browser

No

Yes

Page 50: Lecture 3

What Does a JSP Page Look Like?

A “Hello World” for JSPs:

<HTML><HEAD><!--This is my comment--you can view this in the browser --

%><TITLE>Hello Matei Title Page</TITLE></HEAD><BODY><H2>Hello Matei!</H2>You are <%= request.getRemoteHost() %> at IP address <%= request.getRemoteAddr() %></BODY></HTML>

Page 51: Lecture 3

What is a JSP Page Made Up Of? Comments <!-- … --> Expressions <%= … %>

– Expressions are evaluated and their result is included in the HTML code

Declarations <%! … %>– To add variables, method definitions, – Code is copied “as is” in the main body of the servlet class

Scriptlets <% … %>– Code is copied as is in the service method

Page directives <%@ … %>– General format: <%@ page attribute=“value” %>– <%@ page import=“your.package” %>– <%@ page contentType=“text/xml” %>– <%@ page thredSafe=“false” %>

Page 52: Lecture 3

What is a JSP Page Made Up Of? (2) Implicit objects:

– request : The original HttpServletRequest object

– response: The original HttpServletResponse object

– in: The BufferedReader object that is part of the client request

– out: The BufferedWriter object that will be sent back to the client

Custom actions:– <jsp:forward page=“url” />

– <jsp:include page=“header.jsp” flush=“true”/>

Page 53: Lecture 3

Market Share – Servlet engines

April 2003, http://news.netcraft.com/

Page 54: Lecture 3

Market Share – Web servers

April 2003, http://news.netcraft.com/

Page 55: Lecture 3

Administrative Milestone 1 due Sunday. Start planning your project. Next time: CORBA.

Page 56: Lecture 3

NSAPI/ISAPI/ICAPI Benefits

Benefits:– NSAPI extensions can affect how the server processes a

client request– NSAPI programs run inside the server process (load

once,fire often metaphor) thus improving performance

– Implemented as dynamic (DLL) or shared (.so) libraries at the server

– Support for multithreaded processing is inherent– SAFs (Server Application Functions) usually

implemented in compiled C or C++– Other languages available (Nsapy with Python;

nsapi_perl with PERL)

Page 57: Lecture 3

NSAPI/ISAPI/ICAPI Limitations

Shortcomings:

– Since they run within the server process, greater risk of crashing the server

– Proprietary and non-portable

– Complicates server upgrades (Service functions may need to be recoded)

– SAFs must be thread safe

Page 58: Lecture 3

Netscape WAI

WAI is a Netscape-specific implementation of a CORBA-based interface for processing HTTP requests: http://<server>[:port]/iiop/<service_name>

WAI applications (Web Application Interface) are CORBA object implementations that can run in the server process space or out-of-process (distributed)

– In-proc WASs are written in C or C++ only

– Out-of-proc WASs may also be written in Java

• OOP WASs allow you to distribute your server application across the network

A WAI application is called a WAS (Web Application Service).

Page 59: Lecture 3

Netscape WAI

To write a WAS, you do not need to write IDL or generate skeletons, but merely write an application based on the API that Netscape provides (from VisiBroker)

– server.idl:

• HTTPServerRequest: provides access to HTTP headers, HTML body, etc.

• HttpServerContext: provides access to context information

• typedef sequence <octet> HttpServerBuffer: binary data buffer for in-out transfer

– HttpServerRequest::StartResponse()

– HttpServerRequest::WriteClient( in HttpServerBuffer)

Page 60: Lecture 3

Server-Side Includes(Server-Parsed HTML)

Server-Side includes allow us to create macros that access information on the server at the time the page is delivered by the server, rather than when the page was written, causing the server to rewrite the macro with the generated text

SSIs are embedded in HTML (usually .shtml files)

– begin with: <!--# and end with: --> SSI directives:

– echo <variable>e.g.: <!--#echo var=“LAST_MODIFIED” --> or DATE_GMT, etc.

– include <file>

– exec <command>potentially dangerous and often disabled on servers

Page 61: Lecture 3

Server-Side Includes(Server-Parsed HTML)

Java-enabled SSI’s can call servlets (part of Sun’s JavaServer Architecture)

– <SERVLET><NAME=AddMain> #or:<SERVLET CODE=AddMain.class><CODEBASE=http://localhost:8080/><PARAM NAME=pgtitle VALUE=“ON SALE!”></SERVLET>

– SSI’s could be used for:

• generating a common look and feel by inserting standard headers and footers in all web pages, just enter the <SERVLET> line, and the Servlet is loaded and run and html is returned an put in place of <SERVLET>

• generating customized messages for users (like looking up info in a customer database on login)


Recommended