HTML, XHTML and XML

1
HTML, XHTML and XML
HTML Current browsers permit poorly formed HTML
- Incorrect nesting of tags Missing end
tags Insensitive to case Omission of quotes
for quoted strings This can lead to problems
with mobile devices which dont have the
resources to support sophisticated
browsers. XHTML The introduction of XHTML is an
attempt to tighten-up the standards and conform
to the same rules that apply to XML. XML XML
specifies data content rather than presentation.

P. Martin 2001 SV -1
2
HTML, XHTML and XML - 2
XML (continued) XML allows users to define
their own tags, for example -
lt?xml version 1.0?gt lt!- - simple example of
xml - - gt ltbook isbn 0-101-1234gt
lttitlegtTime Machinelt/titlegt ltauthorgt
ltinitialsgtH.G.lt/initialsgt
ltnamegtWellslt/namegt lt/authorgt ltpublished
name Addison Wesley date 2000/gt lt/bookgt
XML tags must be correctly nested and are case
sensitive. All tags must be Terminated but a tag
without a body is coded lttagname parameters /gt
P. Martin 2001 SV -2
3
HTTP protocol
HTTP is - A request/response, client/server
protocol Client makes a connection to the
server Server (usually) closes connection after
issuing response. Protocol is stateless. Request
s/responses are made up of a header and an
optional body. Message types - GET requests
a resource (request has no body content) POST
requests a resource and provides body
content. HEAD requests a response consisting
only of a header. Others are OPTIONS, PUT,
TRACE, DELETE and CONNECT. URIs URIs are
Universal Resource Identifiers and are either
- URLs Universal Resource Locators,
or URNs Universal Resource Names
P. Martin 2001 SV -3
4
Client/Server Interaction with Servlets
Servlets are Server-side components which are
managed by a web-application container. The
basic interaction between client and server is
shown diagrammatically below -
servlet
servlet
GET or POST request
doGet or doPost
Servlet/JSP
Client browser
Web server
Web container
service
static resource e.g. html, image etc.
Servlets respond to client requests using Either
a doGET() or a doPost() method.
P. Martin 2001 SV -4
5
Tomcat Directory Structure
The Tomcat web-server comes with a built-in
web-container and the Installation has the
following directory structure - ltinstall-dirgt\bi
n --executable programs and
tools \conf \server.xml --server
configuration file \ --other files
\webapps \ROOT \index.html --tomcat home
page \ --pages served by
server --in this and sub-directories
\myApp1 --root of user web application
\ --more web applications
\myOtherApp.war --war (web application
resource) --files
\ --other directories Web applications are
held within a specific file structure during
development and converted to WAR files on
completion. This is done by issuing the
JAR Command from the web application root
directory, e.g. From the myApp1 directory -
jar cf myApp1.war
P. Martin 2001 SV -5
6
Web-application Directory Structure
The web-application must be deployed in a
directory structure with the following components
- webapps\ myApp1\
index.html --this or one
of a number of --possible welcome files
--JSP pages, error pages
--other static html
pages images\
--image
files for application
literature\
--documentation on
application WEB-INF\

web.xml --application descriptor file
classes\

myApp1.class --application class files

--other class files
lib\
--application jar
files
P. Martin 2001 SV -6
7
Deploying a web-application in Tomcat
Having created a sub-directory (say myApp1) below
the webapps directory With the appropriate
structure, the server.xml file needs to be
modified as follows -- lt!-- Tomcat Root
Context   --gt lt!-- ltContext path""
docBase"ROOT" debug"0"/gt   --gt lt!-- Context
paths for applications   --gt   ltContext
path"/myApp1" docBasemyApp1" debug"0"
reloadable"true" /gt lt!-- Tomcat Manager Context
  --gt   ltContext path"/manager"
docBase"manager" debug"0" privileged"true" /gt
lt!-- Tomcat Examples Context   --gt ltContext
path"/examples" docBase"examples" debug"0"
reloadable"true"gt  ltLogger className"org.apache
.catalina.logger.FileLogger The two lines in
red have been inserted into the server.xml file
at the point indicated just over half way
through the file. If the application is packaged
as a WAR file, the whole directory structure must
be replaced by the WAR file and the line above
changed to - ltContext path"/myApp1"
docBasemyApp1.war" debug"0" reloadable"true"
/gt
P. Martin 2001 SV -7
8
API support for Servlets
The web server will normally send multiple
concurrent requests to the same servlet instance
and the developer is responsible for making the
application thread-safe. This marker interface
tells the web-container to either - a)
serialise requests or b) create a pool of
instances or both.
P. Martin 2001 SV -8
9
Processing client requests
client browser
web server
web container
GET request
GET request
response
response
service
response
Servlet
service(HttpServletRequest,HttpServletResponse)
P. Martin 2001 SV -9
10
Servlet descriptor file
All web applications require an XML descriptor
file web.xml placed in the WEB-INF directory,
e.g. - ltweb-appgt ltservletgt
ltservlet-namegtmyApplt/servlet-namegt
ltservlet-classgtmyApp1lt/servlet-classgt
ltinit-paramgt ltparam-namegtnamelt/param-n
amegt ltparam-valuegtFredlt/param-valuegt
lt\init_paramgt ltinit-paramgt
ltparam-namegtagelt/param-namegt
ltparam-valuegt21lt/param-valuegt
lt\init_paramgt lt/servletgt lt/web-appgt These
init parameters can be accessed via the
ServletConfig object available to Servlets.
P. Martin 2001 SV -10
11
Servlet Life cycle
Instantiated
Initialised Ready
Created on request or At container start-up
Initialisation calls init()
Initialisation failure
HTTP Request(s) from client(s). calls service()
Unavailable
Recover from temporary failure
Temporary or permanent failure
Servicing Request
End of service
Timeout or container shut-down calls destroy()
P. Martin 2001 SV -11
12
Greeting Servlet

• The following example illustrates a simple
  Greeting servlet which
• references initialisation parameters through the
  ServletConfig.
• The servlet class helloApp.java

P. Martin 2001 SV -12
13
Greeting Servlet
2. The web.xml file -
P. Martin 2001 SV -13
14
Greeting Servlet
2. A welcome file index.html
3. Deployment webapps/
helloApp/
index.html
WEB-INF/
web.xml
classes/

helloApp.class Entry in server.xml -
ltContext path"/helloApp" docBasehelloApp"
debug"0" reloadable"true" /gt
P. Martin 2001 SV -14
15
Request Response classes
wrapper classes provide an easy way of creating
response objects for redirection etc.
P. Martin 2001 SV -15
16
Responding to Information
The following Servlet illustrates a simple use of
request parameters in Obtaining information from
the user -
P. Martin 2001 SV -16
17
Responding to Information (continued)
Once deployed, we can call this servlet up with
the URI response/servlet/resp to obtain the form.
P. Martin 2001 SV -17
18
Session Tracking
As has been noted, the HTTP protocol is
stateless. This presents a problem when we wish
to information during a clients interaction
session (e.g. to Provide a shopping-cart or
maintain client-profiles. There are three
methods available to retain information over a
session - URL rewriting addition of data as
query parameters or extra path information
e.g. http//hostport/
url pathuidfred?age21sexm Use of hidden
fields in forms ltinput type hidden name uid
value fredgt Use of Cookies client side
files containing namevalue pairs and
transmitted in message headers. Cookie new
Cookie(uid,fred) Sessions using Secure
Socket Layer (SSL) Use of session keys to
uniquely identify a client session.
P. Martin 2001 SV -18
19
Using Cookies for Session Tracking
Cookies created in servlets are transmitted to
the client machine in message Headers and stored
on the client machine. When connections are made
to the same or other pages on the site, any
client-side Cookies in existence will be
transmitted to the server in the message
header. Using cookies it is possible to
- Limit the life of the cookie
setMaxAge() Restrict the domains for uploading
setDomain() Set the path to place the cookie
on the server setPath() e.g. servlet use of
cookies - The web container may use cookies
automatically for session tracking, unless
the client browser prohibits them.
P. Martin 2001 SV -19
20
The Cookie Class
With this API and the methods public Cookie
getCookies() of the HttpServletRequest class and
public void addCookie(Cookie c) of the
HttpServletResponse class it is possible to
maintain state programmatically so long as the
browser Enables cookies.
P. Martin 2001 SV -20
21
Other methods of Session Tracking
Use of Hidden fields The main problem with
the use of hidden fields is that during the
course of a clients interaction with a site,
they might call up pages which are not forms
and dont supply the hidden fields or transmit
their contents back to the server. This makes
the technique very limited and inconvenient to
use. Use of SSL session keys This works
fine if operating in secure mode with HTTPS, but
clearly not appropriate for non-secure
interaction. URL rewriting This provides
the most effective means of session tracking and
requires that all URLs to site pages be encoded
to include an extra information field -
P. Martin 2001 SV -21
22
Using the HttpSession Interface
The HttpServletRequest interface provides two
methods for creating and tracking client sessions
- public HttpSession getSession(boolean
create) and public HttpSession getSession() The
second method will create a session if none
currently exists, as will the first method unless
the boolean parameter is false. The mechanism
employed is chosen by the web-container depending
on the whether The browser has enabled cookies,
it a secure link and URL encoding is used.
Sessions consume resources on the Server and are
managed by it. Session lifetime can be set
programmatically or in seconds in the web.xml
file -
P. Martin 2001 SV -22
23
Example the shopping-cart metaphor
The following example is based on one from Java
Server Programming by Wrox
First, the catalog browsing servlet -
P. Martin 2001 SV -23
24
Example the shopping-cart metaphor
Then, the shopping cart servlet -
P. Martin 2001 SV -24
25
Example the shopping-cart metaphor
Finally, the web.xml file
P. Martin 2001 SV -25
26
Servlet Context
Whereas sessions maintain state during the
interaction of a client with a web application
on a client by client basis, a context object
provides state information to be shared across
all clients. The Context class contains
the Following (and other) methods -
The initialisation parameters for context are
similar to those for servlet except that they
apply to the whole application and are defined in
the web.xml file in ltcontext-paramgt tags. These
are simple strings specified by name/value pairs,
whereas attributes are Java objects.
P. Martin 2001 SV -26
27
Chat-Room example
based on an example from Wrox Professional Java
server programming
This is a simplified example of a chat-room
application. The components consist of two simple
objects ChatEntry an individual chat message,
ChatRoom a collection of ChatEntries and three
servlets - A ChatAdmin servlet to allow new
rooms to be created A ListRooms servlet to
display rooms currently available A Chat servlet
to enable clients to chat The two object classes
are as follows -
P. Martin 2001 SV -27
28
The client interaction with the application
update rooms
exit room
select a room
enter a room
start
new entry
create/ delete rooms
P. Martin 2001 SV -28
29
The ChatAdmin Servlet - 1

Ensure that a collection of rooms has been
created and added to application context.

Remove a room from the collection if request
has been made.

Add a new room to the collection if a request has
been made.
Redisplay the form for further changes.
P. Martin 2001 SV -29
30
The ChatAdmin Servlet - 2

Display rooms along with checkboxes to select for
delete

Allow specification of a new room.
P. Martin 2001 SV -30
31
The ListRooms Servlet - 1
P. Martin 2001 SV -31
32
The ListRooms Servlet - 2
P. Martin 2001 SV -32
33
The Chat Servlet - 1
P. Martin 2001 SV -33
34
The Chat Servlet - 2
P. Martin 2001 SV -34
35
The Chat Servlet - 3
P. Martin 2001 SV -35
36
The Chat Servlet - 4
P. Martin 2001 SV -36
37
Deployment descriptor welcome page
P. Martin 2001 SV -37
38
Servlet Dispatching
A servlet, after performing some processing may
pass the request on to another resource
(servlet, JSP or html page) for further
processing and generating a reply, or can request
the output generated by another resource to be
included in the response. This is made possible
by calling methods of the RequestDispatcher
interface -
A RequestDispatcher may be obtained by calling
- RequestDispatcher
getRequestDispatcher(String path)
from the ServletContext object with an
absolute path. RequestDispatcher
getRequestDispatcher(String path) from the
ServletRequest object with an absolute or
relative path. RequestDispatcher
getNamedDispatcher(String name) from the
ServletRequest object with the servlet alias name.
P. Martin 2001 SV -38
39
Filtering
Client requests can be filtered prior to
processing by passing through one or more
filters in a filter chain -
------------------------Filter chain--------------
-----
Filters implement the Filter interface and make
use of the FilterChain and FilterConfig
interfaces -
The methods of the Filter interface are called by
the web-container under the direction of the
application descriptor file web.xml
P. Martin 2001 SV -39
40
Filtering example counting accesses
A simple filter to count accesses to web pages
could be implemented as follows -
All that is needed in addition is a servlet to
access and report on the context object count.
Any number of filters can be defined, the order
of processing in the chain being defined by the
order in web.xml. The mapping indicates which
requests the filter should be applied to. The
ltinit-paramgt,ltparam-namegt and ltparam-valuegt
tags allow init parameters to be passed to
individual filters.
P. Martin 2001 SV -40
41
Implementing security
There are a number of ways to provide security on
a web application - Programmatically Di
rect user to a login form and collect login ID
password. Use SSL to transmit login ID and
password to validating servlet. Check
validity and access rights against database
entry. If ok, set a session attribute to
signify access rights and pass request on to
application. Check in all servlets for valid
access rights. Provide software (e,g, form) to
maintain database of users.
Declaratively Use a built-in mechanism to
implement the above in one of several ways
- HTTP basic authentication above
process provided by web server
but not using SSL. HTTP digest
authentication as above, but password
sent as a hashed value. HTTPS
client authentication using digital
certificates. Form-based
authentication

P. Martin 2001 SV -41
42
Form-based Security
This approach is based on the definition of user
roles. What a user can do depends on their role.
Many users can have the same role and a user may
have several roles. The resources that need
protecting and the roles permitted are defined in
the web.xml file, e.g. for the ChatRoom
application -
The transport methods here can be NONE,
INTEGRAL or CONFIDENTIAL
P. Martin 2001 SV -42
43
Example login error pages
The web.xml file specified a login.html and
error.html which might be as follows -
Finally, entries are needed in the
tomcat-users.xml file located in the conf
directory. lttomcat-usersgt ... ltuser name
"userID" password "pqr123" roles
"chatAdministrator"/gt lttomcat-usersgt
P. Martin 2001 SV -43
44
Exception handling
The servlet API provides two types of exception
as follows -
Servlets should normally convert any detected
exceptions to ServletExceptions in catch blocks
and embed the root cause exception. The web
container accesses this information for logging
purposes.
P. Martin 2001 SV -44
45
Error pages
Servlets can signal common errors using the
sendError(int code) or sendError(int code, String
message) methods of HttpServletResponse. (no
further output should be generated in such
circumstances) Some of the common error codes
that can be used with HTTP are - 400 SC_BAD_REQU
EST 401 SC_UNAUTHORIZED 403 SC_FORBIDDEN 404 SC
_NOT_FOUND 500 SC_INTERNAL_SERVER_ERROR 501 SC_N
OT_IMPLEMENTED 502 SC_SERVER_UNAVAILABLE Error
pages to be invoked by the web container on
receipt of an exception or an error status code
can be defined in the web.xml file for the
application. Such 'pages' can be static html, JSP
or servlets.
A Servlet throwing an error can set the following
attributes in the request object which can be
picked up by the error handling page
javax.servlet.error.status_code, javax.servlet.err
or.exception_type and javax.servlet.error_message.
P. Martin 2001 SV -45
46
Issues concerning Servlets
There are a number of aspects of the use of
Servlets which can cause problems and which can
be eased by the use of other technologies, such
as the need to handle - Database
connections Database connections are costly to
establish and consume a lot of system
resources. Database access and update
Writing and maintaining SQL for database
access and update adds to the developers
burden. Database transactions Most
database operations involve the use
of transactions and frequently distributed
ones. Multi-threading Server side
programs always have to deal with multiple
users and need to be thread safe.
Generation of static html Very cumbersome in
Servlets. Java Server pages (JSP) provide a
more conventient approach. Application
security - Difficult to provide thorough and
consistent policy with no gaps. These issues
are addressed by the use of JSP and Enterprise
JavaBeans (EJB).
P. Martin 2001 SV -46
47
JNDI and Database Connections
Before dicussing alternative ways of making
database connections, a few words about JNDI
the Java Naming Directory Interface.
Naming services - This provides a simple mapping
between names and the objects they represent
(e.g. the RMI registry) like telephone white
pages. Directory services - By providing
further information, objects can be searched for
using a number of different criteria (similar
to Yellow pages). Computer systems provide a
variety of different directory services for
locating resources on Local and networked
machines, e.g. - Novell directory services
(NDS) Network information services (NIS) Active
directory services (ADS) Windows NT
Domains Each with their own distinct programming
interface. A common (lowest denominator)
protocol for accessing such services has evolved,
called LDAP (lightweight directory access
protocol) in an attempt to provide a standard
method of accessing All these services.
P. Martin 2001 SV -47
48
Connection management using JNDI
In Server-side applications, the variety of
resources spans a wider range than
typically provided for in a traditional directory
service. JNDI provides a universal means of
accessing directory resources of any type on any
system. Database connections can be obtained in
the following ways - During
initialisation of the servlet- init()- and held
until destruction -destroy(). Undesirable to
hold connections open for long periods, even for
connections to DBMS running on local machine.
Also, limits the ability of web-container to
serialise the application to file store when not
active. On each service call -doGet(),
doPost() etc. Undesirable due to the high
overhead in setting-up and taking-down
connections. By allocation from a
connection pool. A pool of database connections
is held by the web-container and allocated to
applications on demand. For this to work, the
requesting and return of connections must be
visible to the web container.
P. Martin 2001 SV -48
49
Obtaining database connections
Programmatically - The way we have been
obtaining database connections so far is by
explicitly programming them using -
This is invisible to the web-container,
which can thus play no part in their
allocation. Through use of JNDI - Here
resources are declared to the web-container
through xml descriptor files ( server.xml
web.xml ) and accessed in the program using the
JNDI API. An example of this
approach follows on the next slide.
P. Martin 2001 SV -49
50
Accessing database connections through JNDI
web.xml
server.xml
JNDI look-up
P. Martin 2001 SV -50
51
Database Transactions
Even the simplest of applications involve the
need for database transactions, e.g. if money
is to be transferred from one bank account to
another, the following operations are involved
- 1. Debit account A by amount X. 2. Credit
account B by amount X. If something goes wrong
with either operation, or the program crashes
between them, either operation could complete
without the other resulting in an amount X too
much in account A or an amount X too little in
account B. The transfer needs to have the ACID
properties - A Atomic set of operations
must be seen as an indivisible group either all
sub operations must succeed or all must fail.
C Consistent the database must be left in a
consistent state here the sum of both accounts
remains the same. I Isolated operations
must be able to proceed without regard to other
operations being carried out at the same time,
e.g. spouse withdrawing money from account A.
D Durable once completed, the effects of the
operation must persist regardless of
any subsequent program, system failures or disk
crashes.
P. Martin 2001 SV - 51
52
Implementing Transactions
The Connection class of JDBC provides the
following support for transaction management -
Actually programming transaction and allowing for
appropriate acion in the case of program
run-time exceptions etc is not easy. The
situation in practice is usually complicated by
the need for distributed databases the accounts
A and B are on different databases located on
different machines accessed over a WAN. Here
two-phase commit is needed, whereby the parties
involved are first asked if they are prepared to
commit before actually being asked to do so. Java
2 and JDBC2 provide this in the class
XAConnection where a method prepare(Xid
transactionID) is used. In a distributed
database environment, achieving ACID transactions
is difficult, and although Java 2 provides for
this as well as connection pooling and
DataSources, such concerns are better left to an
EJB container.
P. Martin 2001 SV - 52
53
Multi-threading
Server applications must be able to handle
multiple client requests simultaneously. Even if
the SingleThreadModel interface is used, there is
no guarantee that the web container will not
create multiple instances of a Servlet and serve
them to clients from a pool. Ensuring code is
Thread-Safe by appropriate use of synchronized
methods and synchronized blocks is difficult and
avoidance of deadlock is a major concern. The
Enterprise Java Beans (EJB) container handles
concurrent access on behalf of the application
developer, making code development much easier.
P. Martin 2001 SV -53