The Rest of Java (and Java Server Pages)

1. The Rest of Java (and Java Server Pages) CSE301 University of Sunderland Harry R Erwin, PhD

2. Resources You should read further if you intend to program in Java professionally. Resources include: • D. Flanagan, 2005, Java in a Nutshell, fifth edition, O’Reilly. • Other texts in the O’Reilly Nutshell series ({Java Foundation Classes|Java Enterprise|Java Examples} in a Nutshell). • Many other good books, mostly published by O’Reilly, Addison-Wesley, and Manning.

3. Client/Server Processing • Java provides a large number of facilities to support network and client/server processing. These include: • Threads • Serialization • RMI • Corba • TCP/IP libraries • Java Beans • Applets • Servlets • JDBC • JNDI • JSP

4. Threads and Parallel Processing • Java supports multiple threads of execution within a program. • There are two ways to create a thread object: • Subclass Thread and instantiate the subclass • Implement the Runnable interface and pass to Thread() • You can control: • Priorities, sleep/wake, timers, synchronization, interrupts • The javax.swing package uses threads, so they’re unavoidable.

5. Multi-Threading If you run multiple threads or use javax.swing, you must consider: • Deadlock (where two threads wait for each other to release a resource) • Data sanity (i.e., two threads may each change the state of an object or variable at the same time. The last change wins.) • Priorities (a thread should not delay more important activity longer than necessary) • Clean-up (a program cannot just terminate suddenly, leaving persistent data half-written).

6. Serialization • Objects can be serialized—converted to a byte stream that can later be converted back to the object. • Serialization can be over a network or pipe, to a file, or to a byte array. • Used by RMI • Can be used to allow agents to migrate from machine to machine. • Supports persistent storage on disk of objects.

7. RMI(Remote Method Invocation) • Allows you to create and use remote objects in Java. To work outside of Java, you need to use CORBA or the Java Native Interface (JNI). • The following elements are provided: • Remote object classes • Client interfaces to remote objects • A remote object registry • A network protocol for communication • The ability to create remote objects

8. CORBA • Java interfaces to CORBA (Common Object Request Broker Architecture) via the Java IDL API. This is language-agnostic. • This allows you to interface to remote objects and make your objects accessible to other CORBA clients. • RMI is easier to use from Java, while CORBA gives you access to more services. • We use this in our robotics work.

9. TCP/IP • The java.net package makes network access very simple. • The URL class gives you direct access to resources on the network. You open a stream on a URL to read it. • If you want to connect to a TCP/IP port on a host, you can create a Socket object. If necessary, you can use SSL. • If you want to deploy a server, you create ServerSocket class objects for each port you will be listening to. • Finally, you can create DatagramSocket and DatagramPacket class instances to use the UDP protocol. • I have seen a COM379 student write and fully debug an IRC client in 15 minutes using this package.

10. Java Beans • A framework for software components in Java. • Designed for compatibility with visually-oriented builder tools. • Most beans are GUI components, including many in the awt and Swing packages. • Can be used as COM or ActiveX components. • Found in the java.beans and java.beans.beancontext packages. • There is no superclass, Bean—any class that meets the basic rules can be used as a bean. See the resources for the rules (several pages!).

11. Applets • Applets are miniapplications, downloadable over the web to be run in a web browser. <APPLET code =“Name.class”> <PARAM name=“message” value=“string”> </APPLET> • Allows you to deliver Java programs to end users. • Subclasses the java.applet.Applet class. No main method(). Arguments are provided by <PARAM> tags. Applet is a subclass of java.awt.Panel, an AWT Component. You can also use javax.swing.JApplet. • Strict security restrictions. • The applet is allowed to create threads to handle time-consuming actions.

12. Servlets • Primarily a Java-based replacement for CGI scripts, but can be used in a request/response context in any server. • Persistent between invocations; hence provide better performance. • Portable between operating systems and computers • Can access the Java APIs. • Much more secure than scripts. • Can interface to JSP pages (later).

13. JDBC • The Java version of ODBC. • Supports the following: • Loading a driver • Class.forName(“drivername”); // loads a class • Connecting to a database • Executing SQL statements • Retrieving results • Detecting database errors • There is a JDBC-ODBC bridge available. Inefficient but a useful work-around for development. • Can work with database metadata. • Supports transaction processing and batch updates.

14. JNDI • Supports access to directory and naming services in Java programs. • Allows you to access objects by name rather than by reference. • A solution to the same problem addressed by the Singleton pattern (later) and CORBA. • Directory services associate attributes with names. • Provides a standard protocol-independent API for vendor implementations.

15. Java Server Page (JSP) Basics • HTTP • Servlets

16. HTTP • A Communications Model: • A client, often but not always a web browser, sends a request for a resource to a server. • The server returns a response or an error message. • Points to remember: • Stateless protocol. • Delayed feedback. • Server cannot tell how the request was made. No client-side processing can be invoked. (If it could be, it would be a security nightmare.)

17. Examples of HTTP Clients • Web browsers (many, including specialized ones for console interfaces—lynx—and handicapped users) • Search utilities (Sherlock on MacOS X) • Help utilities • FTP clients (e.g., interarchy on MacOS X) • Software registration programs • telnet (a hacker can emulate a web browser by connecting to port 80) • Specialized programs (e.g., curl) • Cracker toolkits (generating malformed http requests)

18. HTTP Requests • Information is specified by an HTTP Uniform Resource Locator (URL, see RFC-2396 and RFC-2616). http://www.cet.sunderland.ac.uk:80/~cs0her/index.html • Consists of: • Protocol designation (http and https) • Server name:port number (port number defaults to 80 for http and 443 for https) • Name of the resource being requested. Need not be a file. Here it is: /~cs0her/index.html

19. HTTP Request Message • Consists of: • Request line • GET resource_name protocol_in_use • POST (provides parameters in the request body, see below) • Request headers • Host (server name) • User-Agent (browser type) • Various Accept headers describing formats and languages • Request body (optional)

20. Java Servlets • Currently, Java is the predominant language for SSP. This is due to the Java Servlet API. • Advantages over other SSP technologies: • Persistent between invocations, avoiding process instantiations. • Portable across operating systems and servers. • Good security. • Can use the Java APIs, particularly JDBC. • Integrated closely with the J2EE environment.

21. Servlets • A servlet runs in a servlet container within a Java Virtual Machine. • Servlet containers: • Apache/Jserv, which supports Servlets 2.0. • Mortbay.com/Jetty • IBM/WebSphere • Jakarta/Tomcat 4.0 (reference implementation for the Servlet 2.3 API). Available from http://jakarta.apache.org.

22. Servlet Basics • The Servlet API consists of two Java packages: • javax.servlet • javax.servlet.http • Required for J2EE 1.3

23. Servlet Lifecycle • A client makes a request involving a servlet running on the server. • The servlet is responsible for loading and executing the Java classes that generate the HTML content. • To the client, this looks like standard HTML processing, except faster. • The servlet then need not shut down. Instead, it can handle subsequent requests without restarting.

24. Servlet Methods • init(), to handle startup. Once init() runs, the servlet is available. • service() is called to process each request. Disk writes are only needed to preserve state. Arguments to service() are ServletRequest and ServletResponse objects. • destroy() is called to clean up resources when the server shuts down (if it ever shuts down).

25. Core of the API • javax.servlet.Servlet interface. • javax.servlet.http.Servlet class, implementing the interface. Designed to work with the HTTP protocol. • javax.servlet.GenericServlet class, implementing the interface. This class is communication protocol agnostic. Can implement a filtering servlet to adapt output from some other source. This can provide other protocol services (e.g., ftp).

26. A Web Application • A set of resources (servlets, static content, .jsp files, class libraries) installed in a specific path, making up a directory. • Organized as a chroot ‘jail.’ • Multiple servlets can exist concurrently. Run in a common ServletContext. • Be careful—the path to the application can change from machine to machine.

27. Supporting JSP • Requirements: • Workstation or PC with an internet connection. • Java SDK (available from Sun, links on the handbook page) • JSP-enabled web server such as Apache Tomcat (Jakarta Project). This is available here at the Informatics Centre.

28. Summary • Consult the reference documentation if you need these services.