1. DESIGN ISSUES
* Assumed syntax - a simpler RDF syntax used in the following. (1999). This proposed
altervative to RDF/XMl was never adopted, RDF/XML prevailing as a standard and in practice
also Notation3.
Original design issues
1990 archives These documents date from the original design of the web, dating from 1990 when
the first HTML editor was available to write them. When reading them please bear this in mind.
Some have been updated later. Although the design is for a global general hypertext system, the
justification for the initial project was the CERN environment and this may be evident in some
places.
This lists decisions to be made in the design or selection of a hypermedia information system. It
assumes familiarity with the concept of hypertext. A summary of the uses of hypertext systems is
followed by a list of features which may or may not be available. Some of the points appear in the
Comms ACM July 88 articles on various hypertext systems. Some points were discussed also at
ECHT90 . Tentative answers to some design decisions from the CERN perspective are included.
Here are the criteria and features to be considered:
* Intended uses of the system.
* Availability on which platforms?
* Navigational techniques and tools: browsing, indexing, maps, resource discovery, etc
* Keeping track of previous versions of nodes and their relationships
* Multiuser access: protection, editing and locking, annotation.
* Notifying readers of new material available
* The topology of the web of links
* The types of links which can express different relationships between nodes
These are the three important issues which require agreement between systems which can work
together
* Naming and Addressing of documents
* Protocols
* The format in which node content is stored and transferred
* Implementation and optimization - Caching , smart browsers, knowbots etc., format
conversion, gateways.
Introduction
In the web-application server domain, Java servlets are fast replacing the CGI. By year 2000,
most of the Java based application servers are expected to be based on Java servlets for
connecting the middle-tier components with the HTML content (or templates).
This article is an extract of an internal development effort, during which the author happened to
examine some of the development issues associated with developing small-to-medium scale web
applications using Java Servlets.

2. This article does not intend to be a tutorial on how to program with Java servlets, although it
covers the principal concepts associated with servlets. This article examines some of the design
issues, and offers some guidelines on the applicability of Java servlets for web based application
development. For a detailed tutorial on Java servlets, see the Tutorial on Servlet Essentials at
http://www.novocode.com/doc/servlet-essentials.
Java Servlets
Java servlets are small, platform independent server-side programs that programmatically
extend the functionality of the web server. The Java servlet API provides a simple framework for
building applications on web servers. This API is described in the Java Servlet API Specification
(currently version 2.1) by the Java Software Division of Sun Microsystems Inc.
Java servlets are not user-invocable applications. Servlets interact with a servlet engine (an
implementation of the Java Servlet API specification) through requests and responses. The
servlet engine in-turn interacts with the web server by delegating requests to servlets and
transmitting responses to the web server.
When compared to the Common Gateway Interface (CGI) and proprietary server extensions
such as Netscape Server API (NSAPI) or Microsoft's Internet Services API (ISAPI), servlets
provide a better abstraction of the Hypertext Transfer Protocol (HTTP) request-response
paradigm. In addition, servlets have all the advantages of the Java programming language,
including platform independence. Java servlet based applications can be deployed on any web
server with built-in (in-process) or connector-based (out-of-process) servlet engines, irrespective
of the operating system and the hardware platform. This is one of the reasons for servlets gaining
wide acceptance over the past one year.
Java Servlet Framework
In the HTTP based request-response paradigm, a client user agent (a web browser or any
such application that can make HTTP requests and receive HTTP responses) establishes a
connection with a web server and sends a request to the server. If the web server has a mapping
to a servlet for the specified URL in the request, the web server delegates the request to the
specified servlet. The servlet in turn processes the request and generates a HTTP response. For
a description of the HTTP protocol and the request-response paradigm, see RFC-2068.
For web application development, the servlet API provides three primary abstractions: HTTP
requests, request processing based on some application logic, and HTTP responses. These
abstractions simplify the application development as far as the requests and responses are
concerned. In addition, the servlet API also provides a mechanism for session tracking and state
management. These are described below.
HTTP Request: The interface HttpServletRequest is the first abstraction provided by the servlet
API. This interface encapsulates HTTP request from a user agent. When a request is received by
the servlet engine, an object of this type is constructed and passed on to a servlet. This object
provides methods for accessing parameter names and values of the request, other attributes of
the request, and an input stream containing the body of the request.
HTTP Response: The HttpServletResponse interface of the servlet API provides an
encapsulation of the HTTP response generated by a servlet. This interface defines an object
created by the servlet engine that lets a servlet generate content in response to a user agent's
request. This object provides methods to set type and length of the content, character encoding,
cookies, response status including errors, and an output stream into which binary response data
may be written. Alternatively, this object also provides a print writer object for writing formatted
text responses.

3. Application Logic and Content Generation: The HttpServlet interface specifies methods for
implementing the application logic and generating content in response to a HTTP request. These
methods handle the GET, POST, HEAD, DELETE, OPTIONS, PUT and TRACE requests of
HTTP. These methods are invoked by the servlet engine and act as placeholders for
implementing application logic. The servlet engine also supplies HttpServletRequest and
HttpServletResponse objects to these methods.
HTTP Servlet Framework
Figure 1: HTTP Servlet Framework
These interfaces are shown in Figure 1 in the context of a request and a response. In this
diagram, the service method of the HttpServlet is shown to implement the application logic and
content generation, although one of the doGet, doPost, doHead, doDelete, doOptions, doPut or
doTrace methods can handle HTTP requests.
Session Tracking and State Management: The HTTP, which is the underlying protocol for web
applications, is stateless. This protocol covers only a single request (with the connection initiated
by the user agent) and a response. In this protocol, irrespective of the status of the protocol, the
connection may be closed by either of the transacting parties. This has the following
ramifications:
* The protocol has no mechanism by which a series of unique requests from a user agent
may be identified as being from the same user agent. Consequently, in a transaction spanning
multiple requests and responses, the web server can not uniquely determine that all the requests
are from the same user agent. A user, therefore, can not establish a dialog with the web server to
perform a business transaction.
* Since connections are not maintained by either of the transacting parties, the state of the
transaction (and the application) can not be preserved across multiple requests.
The Java servlet API provides the HttpSession interface for session tracking and state
management in a session. A servlet obtains a HttpSession object from the associated
HttpServletRequest object. Servlets track sessions by URL rewriting or by cookies (See the
tutorial on Servlet Essentials at http://www.novocode.com/doc/servlet-essentials for more details).
Objects of type HttpSession can be set or obtained for new and existing sessions respectively
from HttpServletRequest objects. Session specific data can be stored into these objects.
Application Development Issues
The Java servlet framework provides an object-oriented abstraction of the request-response
routing model of CGI, and is well suited for gluing back-end applications to the web server.
However, this framework is not adequate for object-oriented application development because of
its inherent nature. This section examines the issues associated with servlet management, and
some of the possible application architectures.
Servlet Management
Java servlets are server-side programs and are completely managed by the host servlet
engine as described below:
1. Servlets are managed by a host servlet engine. The servlet specification guarantees that a
servlet is available for service against a request pointing to that servlet. However, there is no
guarantee that the same instance of the servlet will be invoked against another identical request
from the same or another user agent. There are several possibilities:
* Based on some policy, the servlet engine might destroy and reinitialize a servlet
between two consecutive and identical requests from the same or different user agents.
* Alternatively, the servlet engine may maintain a pool of servlet instances and execute
one of the free instances in the request thread.

4. * The web server may have a load-balancing scheme under which identical requests to a
servlet URI (Universal Resource Interface)) may invoke service methods of different servlet
instances in different servlet engines running on two different platforms. Thus, identical requests
may be serviced by different servlet instances in different Java virtual machines.
2. Object references to servlets can be obtained by using the ServletContext (deprecated in
version 2.1 of the Java Servlet API Specification), but not directly. This implies that objects should
not hold references to instances of servlets, but should obtain them from the host servlet engine.
3. Servlet methods can not be invoked with object references in the usual way. There are
three ways in which a servlet can call methods of another servlet:
* By specifying such methods to be "static."
* By obtaining reference to a servlet as in (2) and then calling its methods. However,
such instances can not maintain state in view of (1).
* By forwarding the request and response objects to another servlet referenced by a
URL (as of version 2.1 of the Java Servlet API Specification).
* Alternatively, by including content generated by one servlet in the body of content
generated by the calling servlet (as of version 2.1 of the Java Servlet API Specification).
4. At any given instance, there can either be multiple instances of a servlet, or a single
instance servicing multiple requests (in different service threads) or both. A servlet implementing
the SingleThreadModel interface is an exception to this, in which case a servlet instance
executes only one request at a time.
The following issues summarize the above discussion:
1. Servlets are not reentrant programs, and therefore can not maintain state. HttpSession
objects should be used to preserve state across multiple invocations of servlets. The application
developer must explicitly determine the state attributes and store these in HttpSession objects.
The servlet specification recommends that only serializable objects be stored into sessions. This
is necessary to allow a servlet engine to serialize sessions either for load balancing or for
memory management.
2. Servlets may handle requests concurrently and must be ensured to be multi-thread safe.
This precludes servlets having class-level attributes to hold application state.
3. Servlets are completely managed by the host servlet engine, and inter-servlet
communication is not equivalent to usual method invocation on objects.
4. Objects implementing application logic can not maintain state unless these are maintained
in HttpSession objects.
5. Each servlet need to implement session tracking and state management explicitly.
6. The bare-bones servlet API provides a simple abstraction over the traditional CGI model,
but application developers need to leverage on the object-oriented features of the Java
programming language to implement the application logic. However, this is not the natural servlet
model.
Application Architecture
The following architectures are possible within the Java servlet framework.
Single-Tier Architecture:One of simplest approaches for servlet-driven web application
development is based on the single-tier architecture. In this architecture, the application consists
of a number of servlets each generating one or more web pages. The simplicity of this approach
arises from the fact that there is often a one-to-one correspondence between a business
transaction and a web page generated dynamically by the application. This usually leads to a
one-to-one correspondence of a web page to a servlet generating that web page. The resulting
architecture is shown in Figure 2. The arrows towards HTML pages indicate HTTP responses
from servlets while the arrows in the reverse direction are HTTP requests.
Single-Tier Architecture
Figure 2: Single-Tier Architecture

5. Note that, in the cases of client-side programs (for example Java Applets or ActiveX
components) in the generated content, this architecture may be treated as a two-tier architecture.
Web browsers rendering plain HTML pages should not otherwise be considered to form the
additional client-layer, since this approach does not actually partition the application.
Two-Tier Architecture: The single-tier architecture is not adequate for applications requiring
data or services from additional servers. In this case, some or all the servlets need to connect to
such back-end systems. This results in a two-tier architecture as shown in Figure 3. In this
architecture, servlets act as gateways for the backend systems.
Two-Tier Architecture
Figure 3: Two-Tier Architecture
Three-Tier Architecture: This is the most common architecture for servlet based applications. In
this architecture (shown in Figure 4), the application logic is implemented in a set of helper
classes. Methods on objects of these classes are invoked by the service methods in the servlets.
Three-Tier Architecture
Figure 4: Three-Tier Architecture
If instances of helper classes contain session-specific state, such instances should be stored in
session objects, as servlets can not hold references to such objects across multiple requests.
This leads to breaking encapsulation of the application.
In all the above architectures, each servlet typically performs the following tasks:
1. Session tracking: The first servlet establishes the session and the rest of the servlets in the
application track the session either by cookies or by URL rewriting.
2. State management, by storing pre-identified state of the application (including instances of
helper objects, if necessary) in HttpSession objects associated with HTTP requests.
3. Application logic, as necessary.
4. In the case of a two-tier and three-tier architectures, connections to back-end systems for
data or services.
5. In the case of a three-tier architecture, invocation of methods on helper objects.
6. Content generation.
INTRDUCTION OF DATA
ABSTRACTION
This is the second of a 4 part series, for those of you new to object-oriented programming,
discussing the 4 major principles of an object-oriented language: Data Abstraction, Encapsulation
we’ve already discussed, Polymorphism and Inheritence. Data abstraction is the simplest of
principles to understand. Data abstraction and encapuslation are closely tied together, because a
simple definition of data abstraction is the development of classes, objects, types in terms of their
interfaces and functionality, instead of their implementation details. Abstraction denotes a model,
a view, or some other focused representation for an actual item. Its the development of a
software object to represent an object we can find in the real world. Encapsulation hides the
details of that implementation.
Abstraction is used to manage complexity. Software developers use abstraction to decompose

6. complex systems into smaller components. As development progresss, programmers know the
functionality they can expect from as yet undeveloped subsystems. Thus, programmers are not
burdened by considering the waysin which the implementation of later subsystesm will affect the
design of earlier development.
The best definition of abstraction I’ve ever read is: “An abstraction denotes the essential
characteristics of an object that distinguish it from all other kinds of object and thus provide crisply
defined conceptual boundaries, relative to the perspective of the viewer.” — G. Booch, Object-
Oriented Design With Applications, Benjamin/Cummings, Menlo Park, California, 1991.
Lets look at this code for a person object. What are some things that a person can do? Those
things must be represented here in our software model of a person. Things such as how tall the
person is, and the age of the person; we need to be able to see those. We need the ability for the
person to do things, such as run. We need to be able to ask the person if they can read.
Public Class Person
Private _height As Int16
Public Property Height() As Int16
Get
Return _height
End Get
Set(ByVal Value As Int16)
_height = Value
End Set
End Property
Private _weight As Int16
Public Property Weight() As Int16
Get
Return _weight
End Get
Set(ByVal Value As Int16)
_weight = Value
End Set
End Property
Private _age As Int16
Public Property Age() As Int16
Get
Return _age
End Get
Set(ByVal Value As Int16)
_age = Value
End Set
End Property
Public Sub Sit()
‘ Code that makes the person sit
End Sub
Public Sub Run()
‘ Code that makes the person run
End Sub
Public Sub Cry()

7. ‘ Code that make the person cry
End Sub
Public Function CanRead() As Boolean
‘ Code that determines if the person can read
‘ and returns a true or false
End Function
End Class
So, there we have started to create a software model of a person object; we have created an
abstract type of what a person object is to us outside of the software world. The abstract person
is defined by the operations that can be performed on it, and the information we can get from it
and give to it. What does the abstracted person object look like to the software world that doesn’t
have access to its inner workings? It looks like this:
You can’t really see what the code is that makes the person run. This is encapsulation that we
discuseed last week.
So, in short, data abstraction is nothing more than the implementation of an object that contains
the same essential properties and actions we can find in the original object we are representing.
Definition Of Encapsulation
In programming, the process of combining elements to create a new entity. For example, a
procedure is a type of encapsulation because it combines a series of computer instructions.
Likewise, a complex data type, such as a record or class, relies on encapsulation. ObjectOriented
ProgrammingLanguages rely heavily on encapsulation to create high-level objects. Encapsulation
is closely related to abstraction and information hiding.
Encapsulation is a word that gets bandied about a lot in discussions on wiki, and it almost always
is being misused as a synonym for abstraction or information hiding. (I do it too.)
To give a concrete example of the differences:
* a java interface provides an abstraction.
* implementations of this interface which do not exposed any other methods are employing
information hiding; we cannot tell how they are implemented.
* if the implementation exposes multiple methods, it is employing encapsulation.
In the strictest OO sense of the term, encapsulation is gathering all operations on the object's
state into the object's interface, and only those operations. This is one sense in which you can
talk about 'enforcing encapsulation'. The other is that methods can only operate on the state of
their own object (which implies that other objects in the system employ information hiding).
Another example, Perl's OO syntax allows for encapsulation, but does not provide full information
hiding - you can access any part of an objects data, to any depth. EmacsLisp is a language with
very little encapsulation - functions and data are often independent and freestanding. In the
SelfLanguage method definitions (that would in normal OO be part of the class) are placed in
'traits' objects; objects delegate manipulations of themselves to the traits object (ie encapsulation

8. is broken, deliberately).
Erm, not to be picky, but Perl does allow for information hiding, it just doesn't do it by default. See
InformationHidingInPerl for my description of how to do it. -- JeffBay
Mostly when we associate encapsulation with OO, we mean that languages provide support for it,
not that they enforce it (a claim made for ComponentOrientedProgramming that probably meant
information hiding).
Examples of ways to break (strict) encapsulation:
* Utility classes, containing unrelated methods whose return value is a function only of their
inputs. e.g. Math.sin(x) in java. (Strict encapsulation would lead to x.sin())
* Operations on streams (usually achieved with a pipline of objects, each of which is
responsible for some of the manipulation of the stream 'state'. (Strict encapsulation may well be
achievable in this case, but doesnt lead to reusable code)
Hopefully the message is getting through: encapsulation is not information hiding, and is not
necessarily an unequivocal force for good, especially in its strictest sense.
Information hiding is more often pure natural goodness, allowing you to work with layered
architectures, component frameworks, and all that jazz. I'm curious if anyone can provide
examples WhereInformationHidingIsaBadThing?. (whoops just thought of one. optimizing code
has a tendency to break IH - accessing members is faster than accessing methods)
In Java, directly accessing class attributes is often slower than assigning an accessor's return
value to a local variable, then using the local variable. JVMs use a longer bytecode for instance
variables than local variables. Lest you argue assigning a local variable directly to an instance
variable, keep in mind that the compiler will likely inline the call to the accessor, thus allowing the
code to maintain its speed without breaking encapsulation*.
Before you mess with information hiding, use a profiler to make sure you are changing the
sluggish part of your code! I very much doubt the techniques used in proper information hiding
result in poorly performing code.
Parameterized Abstract
Data Type
Parameterized Abstract Data Type
Divine answer all right, straight from the geek gods. If the phrase sounds Greek to you, then take
comfort in the knowledge that I, a programmer, was confounded, dumbfounded, and humiliated
by the answer. What the hell does that mean?
Life poses many mysteries, and answers can only be found by delving deep into our
subconscious and, yes, daydreams. And finally, after much rumination (10 minutes is lengthy
prison time for the wandering mind), I have broken down the answer and arrived at the conclusion
that this blog, Slip of the Pen, is indeed a parameterized abstract data type.
Parameterized. Everything is bounded, restricted, chained to some rule. Even the free wolf can
only roam where there is prey. The corsair can only sail seas where the law doesn’t hold; the

9. cutlass can only remain unscratched when sheathed. Same goes for this blog. What I write here
has limitations — you haven’t seen the worst of me, nor the best. You have seen the bad and the
good, but not all. Knowing me only in person won’t work either. I’m a writer, so part of me lives in
the pedestrian world and another in the pen-world. Know both, know me all.
Abstract. Writers, insert knowing laugh here. Many artists proclaim their work as abstract, and
love to hear others comprehend and imbue mystical meanings to their art. I guess the same goes
for me (even though I write in relatively concrete images). This blog is an abstraction of its author
— it presents to you the Corsarius through a mishmash of vignettes which, oddly enough, have
something in common.
Data type. What is a data type? According to E.P. Quiwa, it’s the kind of data a variable may take
on in a programming language. Examples are integers (9 and 23), characters (i and x), Boolean
values (true and false). To put it more bluntly — it’s a category. And without trepidation, I can say
that this blog is a category of its own. Why, every blog is! Each blog has that x-factor, that
intangible something which renders it inimitable. My blog and your blog might have similarities,
but they are not the same. Don’t be misled by web directories which order you to “kindly place
your blog under the most relevant category, e.g. literary, technology, showbiz, etcetera”. They’re
only there to give some semblance of homogeneity amongst blogs. Use them, but don’t let them
dictate what your blog is all about.