Clicking the Submit Query button sends the following URL to the Web server:
http://hunding/scripts/htmSQL.exe/example7-1.hsql?
region=United+States
The result is the report of sales by product for the selected region, shown in Display 7.1.
The .hsql source code for Example 7.2 is similar to the other htmSQL we have seen;
directives are shown in bold. The SQL SELECT DISTINCT statement creates a list of unique REGION values. The {®ion} variable reference in the eachrow section creates the option box displayed in Display 7.2. That’s all there is to it!
Example 7.2 htmSQL Code to Generate Form Control Values
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
<head>
<title>SAS IntrNet Examples: htmSQL</title>
</head>
<body>
{query server="hygelac:5011"
sapw="user" userid="sas" password="sasuser" } {sql} select distinct region from sashelp.shoes{/sql}
<div style="text-align: center; ">
<form method=get
action="http://hunding/scripts/htmSQL.exe/example7-1.hsql">
<h1 style="color: blue;">International Shoe Company</h1>
<h2>Request Current Sales Report</h2>
<p>Select Region:
<select name=region>
{eachrow}<option>{®ion}</option>{/eachrow}
</select>
<input type="submit" />
</p>
</form>
</div>
{/query}
</body>
</html>
Issues with CGI Applications
CGI-based programs can be powerful and flexible, but they do come with some
drawbacks. Primary among these is that CGI technology can be resource intensive, since each new request to the server starts a new operating system process. It should be noted, however, that this constraint largely does not apply to the Application Broker.
The broker is written in C and operates as a transient “traffic cop,” directing traffic between the client and the SAS server. The SAS server does all the heavy lifting.
Most other CGI applications don't have the luxury of having a SAS server available, and thus must do all the heavy lifting themselves. Yes, other CGI applications can open connections to database servers, but once they get the data, THEY need to crunch/format/present it. In contrast, the SAS server does all the heavy processing, and the broker just passes the output back to the client with little overhead. In the 11 years that SAS/IntrNet has been in the field, we have had few, if any, reported performance problems that were due to the broker consuming too many resources and choking. This cannot be said for other traditional CGI applications, which are typically written using an interpreted language such as Perl.2
2Quote from SAS developer Vince DelGobbo, February 15, 2006, used with permission.
Chapter 7 SAS/IntrNet: htmSQL 135
There are also some unavoidable security issues with CGI. Consequently, the newest technologies for server-side Web development, based on the Java servlet API or Microsoft Active Data Objects, are gradually replacing CGI applications in many sites.
This doesn’t mean that there is no point in using the SAS/IntrNet CGI tools, but only that it is important to be aware that there are alternatives. The next section of this text covers using SAS AppDev Studio for creating server-side Java applications.
References
SAS Documentation
URL references are current as of the date of publication.
SAS Institute, Inc. 1995. Getting Started with the SQL Procedure. 1st ed. Cary, NC: SAS Institute Inc.
SAS Institute, Inc. 2000. SAS SQL Procedure User's Guide, Version 8. Cary, NC: SAS Institute Inc.
SAS Institute, Inc. 2001. SQL Processing with the SAS System (Course Notes).
Cary, NC: SAS Institute Inc.
SAS Institute, Inc. Automatic Variables –
http://support.sas.com/rnd/web/intrnet/htmSQL/autovar.html
SAS Institute, Inc. Directives –
http://support.sas.com/rnd/web/intrnet/htmSQL/syntax.html
SAS Publications
Wyland, Karen L. 2002. “Ask DSS…using HTML, JavaScript, htmSQL, and SAS to Create Dynamic Web Applications.” Proceedings of the Twenty-Seventh Annual SAS Users Group International Conference. Cary, NC: SAS Institute Inc.
P a r t 3
Server-Side Java Programming
Chapter 8 Java Servlets and JavaServer Pages 139
Chapter 9 Developing Java Server-Side Applications with webAF Software 169
C h a p t e r 8
Java Servlets and JavaServer Pages
Introduction 140 Java Servlets 140
A Hill of Beans 141 Servlet Example 142 Deploying Servlets 144 Creating a JavaServer Page 145 Scripting Elements 146
Predefined Variables 147 A Simple JSP Example 149 JSP Custom Tag Libraries 151
Tag Handlers 151
Tag Library Descriptors 152 JSP with Custom Tags 153 Deploying Tag Libraries 154
Database Access Using JDBC and JavaServer Pages 154 JDBC Overview 154
Using SQL with JSP Custom Tags 157 Web Archive Files 163
Building a Web Archive File 164 Web Application Manager 164 References 166
Introduction
The perceived limitations of CGI (see Chapter 7, “SAS IntrNet: htmSQL,”) have led to a number of alternative strategies for delivering dynamic content on the Web. Of these, the most commonly used are Microsoft Active Server Pages (ASP), PHP (Linux freeware) and JavaServer Pages (JSP) from Sun. These protocols do not rely exclusively on scripts that run within HTML forms (like CGI and DHTML), but instead use a more
sophisticated object-oriented approach. Active Server Pages use Active Data Objects (ADO) to provide a distributed information environment for Microsoft operating systems.
The equivalent in the cross-platform world is Sun’s J2EE Web Technology including servlets, JavaServer Pages and JavaBeans.
SAS AppDev Studio provides comprehensive support for cross-platform development.
Chapter 9, “Developing Java Server-Side Applications with webAF Software,” illustrates how to use webAF software to implement server-side access to SAS data sets, while Chapter 10, “Using the SAS Open Metadata Architecture with the Integrated Object Model,” introduces SAS Integration Technologies and the SAS Open Metadata Architecture. This chapter is a short introduction to the major concepts of Java servlets and JavaServer Pages. For more detail and examples of how to implement JSP, see the Sun online documentation at http://java.sun.com/products/jsp/. The syntax reference for JSP v1.2 is at http://java.sun.com/products/jsp/syntax/1.2/syntaxref12.html. This chapter and the following one assume some familiarity with Java programming, classes, and methods. JSP is a large and complex set of concepts, and the following exposition assumes an understanding of the fundamentals of Java.
Java Servlets
In order to make use of JavaServer Pages to supply dynamic page content, it is necessary first to understand how Java servlets work; see http://java.sun.com/products/servlet for an overview of Java servlet technology. Java servlets are the server-side equivalent of Java client-side applets (see Appendix B, “Client-Side Programming with Java Applets,” for a discussion of writing Java applets). Like JavaScript and applets, servlets can be run only within a servlet container, and are called from a Web browser. There is no main method as in Java console applications. A user calls the servlet from the client Web browser, the servlet executes in the servlet engine, and then it sends results back to the browser (in the form of HTML code). Consequently, Java servlets require a servlet engine, or container such as Apache Jakarta Tomcat, IBM’s WebSphere or BEA WebLogic; see
http://servlets.com/engines/ for a detailed list of commercial and open-source servlet engines).
The function of the servlet engine is to load the servlet .class file into the Java Virtual Machine (JVM) running on the server. The engine can then run the servlet. (The .class file is not reloaded into the JVM again after the first time; most servlet engines now include options to reload .class files automatically when they are updated, so that it is usually necessary to restart the server when the .class file changes.
The most widely available servlet engine is Tomcat from the Apache Foundation Jakarta Project (see http://jakarta.apache.org/tomcat). Since it is both free and widely used, the examples presented in this article all use the Tomcat engine with the Apache Web server.
Chapter 8 Java Servlets and JavaServer Pages 141
It is to be hoped that users at sites with other server software will be able to generalize from the principles and requirements illustrated here.
The Tomcat servlet engine is available for a wide variety of platforms; commonly, it can be installed on either Windows or UNIX systems.1 For the examples that follow, the instructions reference a server running a version of the Linux operating system, but they apply equally to a Windows host as well. In order to configure Apache or IIS to use the Tomcat servlet container, it is first necessary to install the Tomcat redirector plug-in.2 However, Tomcat is itself an HTTP server, so it can work without Apache or IIS.
A Hill of Beans
One additional concept needs to be introduced in order for you to understand how servlets and JSP can be customized. The JavaBeans architecture provides the developer with a set of self-contained components that interoperate according to a standard set of rules. These are the cross-platform equivalent of the Microsoft Component Object Model (COM). If you have created forms in Microsoft Access or Visual Basic, you are familiar with the process of selecting controls from a toolbox and dropping them onto the form.
Of course this is just a small part of COM, which provides users of Microsoft software the ability to build and deploy all sort of reusable components.
For developers who wish to create non-proprietary solutions, the answer is to use
JavaBeans. Do not confuse the JavaBeans architecture with Enterprise JavaBeans, which are a way to distribute components across all the platforms in an organization (and hence equivalent to Microsoft’s DCOM). JavaBeans are just reusable software components.
They are frequently used in visual programming environments (like webAF) but it is not necessary for a Bean to have a visual component.
The following example shows what is perhaps the simplest possible Bean. It has only one data item, an integer field called num, and two methods, one to set the value of num and the other to get it.
Example 8.1 The Basic JavaBean
// A simple Bean
import java.io.Serializable;
public class TestBean implements Serializable {
private int num;
public void setValue(int n) {
num = n;
}
1The Tomcat binaries are frequently updated as new features are added. Note that while the current version is Tomcat 5.5, Tomcat 4.1.18 is the only one recommended for use with SAS AppDev Studio 3.1 (see the next chapter for more details).
2See Gal Shachor, “Tomcat IIS HowTo,” The Apache Software Foundation, 1999-2001.
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-iis-howto.html.
public int getValue() {
return num;
} }
A good Bean has to follow the rules: the two most important are that Beans must be serializable and that they must conform to a specific set of design patterns when naming features (like the getValue() and setvalue() methods in the example). This enables them to interoperate with other components. The term “serializable” means that you can store a Bean in a file on the computer or send it over a network to another host, an obvious necessity for components that are used to create distributed systems. The second requirement ensures that Beans will all work together in harmony, without the developer needing to know (or care) what is happening inside the Bean code.
For a more detailed overview of the JavaBean architecture, see
http://java.sun.com/docs/books/tutorial/javabeans/whatis/beanDefinition.html. Sun has also provided the Beans Development Kit (BDK) free to developers; you can download it from their Web site at http://java.sun.com/products/javabeans/index.jsp. The BDK enables you to write your own JavaBeans (assuming you can program in Java).
Fortunately for developers, you do not need to be able to create your own Beans in order to be able to use the full power of this new technology. In Chapter 9, we shall see how to use webAF 3.1 software and the reusable components that SAS has provided to create powerful, modular, and reliable Web servlets.
Servlet Example
The canonical first program in any software tutorial is always “Hello World;” here is a servlet example:
Example 8.2 Hello World Servlet
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorld extends HttpServlet {
public void doGet (HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
PrintWriter out;
String title = "Simple Servlet Output";
response.setContentType("text/html");
out = response.getWriter();
out.println("<HTML><HEAD><TITLE>");
out.println(title);
out.println("</TITLE></HEAD><BODY>");
out.println("<H1>" + title + "</H1>");
out.println("<P>Hello World!");
Chapter 8 Java Servlets and JavaServer Pages 143
out.println("</BODY></HTML>");
out.close();
}
public void doPost (HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
doGet(request, response);
} }
This class illustrates the most important features of servlet programming. The servlet class is derived from the parent class javax.servlet.http.HttpServlet. The two overridden methods are:
doGet() – called either by going directly to the page or by an HTML get request
doPost() – called by a form using a post request
In this case, both method calls result in the same code being executed. The
HttpServletRequestparameter object is bound to the page that called the servlet, while the HttpServletResponse parameter is the generated page. The servlet writes to a PrintWriter object that is bound to the response object by the call to getWriter(); the out.println statements then generate the HTML source.
The Tomcat engine must be running as a server process; this is the responsibility of the system administrator, who can configure the server to start Tomcat automatically at start- up. Assuming Tomcat is started, the HTML output of this program should appear be as shown in Display 8.1: