JWIG: YET ANOTHER FRAMEWORK FOR

MAINTAINABLE AND SECURE WEB APPLICATIONS

Anders Møller and Mathias Schwarz

Department of Computer Science, Aarhus University, Denmark

Keywords:

Web programming, Web services, Java, XML, XHTML, AJAX, REST.

Abstract:

Although numerous frameworks for web application programming have been developed in recent years, writ-

ing web applications remains a challenging task. Guided by a collection of classical design principles, we

propose yet another framework. It is based on a simple but ﬂexible server-oriented architecture that coher-

ently supports general aspects of modern web applications, including dynamic XML construction, session

management, data persistence, caching, and authentication, but it also simpliﬁes programming of server-push

communication and integration of XHTML-based applications and XML-based web services.The resulting

framework provides a novel foundation for developing maintainable and secure web applications.

1 INTRODUCTION

Web applications build on a platform of fundamen-

tal web technologies, in particular, XHTML, HTTP,

and JavaScript. Although these are relatively man-

ageable technologies, it is generally regarded as dif-

ﬁcult to write and maintain nontrivial, secure appli-

cations. The programmer must master not only the

fundamental technologies but also techniques for ses-

sion management, caching, data persistence, form in-

put validation, and rich user interfaces. In addition,

most web applications are exposed to all hackers in

the world, so the programmer must also consider po-

tential security problems, such as, injection attacks,

cross site scripting, and insufﬁcient authentication or

encryption.

In recent years, a multiplicity of web application

frameworks have emerged, all claiming to make web

application development easier. Among the most

widely known are Struts (McClanahan et al., 2008),

Spring MVC (Johnson et al., 2008), Google Web

Toolkit (Google, 2008), Ruby on Rails (RoR) (Hans-

son et al., 2008), PHP (Lerdorf et al., 2008), and

ASP.NET (Microsoft, 2008). These frameworks rep-

resent different points in the design space, and choos-

ing one for a giventask is often based on subjective ar-

guments. However, a general limitation is the lack of

a simple uniﬁed communication model that supports

both the traditional server-oriented structure and the

more modern style using AJAX, server-push/Comet,

and JSON or XML-based web services (Crockford,

2006; W3C, 2008).

In this paper, we try to take a fresh view on the prob-

lem. Based on essential design principles, we ex-

hibit some of the limitations of existing frameworks,

propose yet another web application framework, and

compare it with the existing ones. The main contribu-

tions can be summarized as follows:

• First, we identify and argue for a small collection

of requirements and design principles for creating

a Java-based web application framework.

• In Section 2 we propose a simple architecture

that supports the basic features of receiving HTTP

client input and producing XHTML output, in ac-

cordance with the design goals.

• In Sections 3–8 we demonstrate the ﬂexibility of

the architecture by showing how it can smoothly

handle other important aspects that can be chal-

lenging to work with in other frameworks, includ-

ing server-push communication, session state,

persistence, and authentication.

• The resulting framework, which is evolved from

the 2003 version of JWIG (Christensen et al.,

2003), provides a clear structure of both control

and data. This makes the application program

code amenable to specialized static analysis. For

example, one analysis checks at compile-time that

only valid XHTML 1.0 data is sent to the clients

during execution.

• The new framework is evaluated through a series

of short but nontrivial example programs and a

MÃÿller A. and Schwarz M.

JWIG: YET ANOTHER FRAMEWORK FOR MAINTAINABLE AND SECURE WEB APPLICATIONS.

DOI: 10.5220/0001836800470053

In Proceedings of the Fifth International Conference on Web Information Systems and Technologies (WEBIST 2009), page

ISBN: 978-989-8111-81-4

case study that demonstrate the resulting system

in relation to the requirements and design princi-

ples, in comparison with alternative frameworks.

Premises and Requirements

To specify the aims of our task and narrow the design

space, we begin by formulating the basic premises

and requirements:

We assume that the browsers are capable of ren-

dering XHTML and executing JavaScript code, as in

Internet Explorer 8 and Firefox 3, but the framework

cannot use browser plugins. This means that the ap-

plications will be readily deployable to all users with

modern browsers.

We postulate that a majority of web applications

do not require massive scalability and have less than

a thousand concurrent uses. Our framework design

should focus on this category.

The framework must uniformly support both

XHTML applications (where the clients are browsers)

and XML-based web services (where the clients are

other types of software). It should be possible to

statically check that only valid XML output is pro-

duced, relative to a given XML schema. This requires

a clear ﬂow of control and data in the code. For the

back-end, the framework must integrate with existing

object-relational mapping (ORM) systems, e.g. Hi-

bernate (O’Neil, 2008), such that data persistence can

be obtained with minimal effort to the programmer,

but without being tied to one particular system.

Representational state transfer (REST) is a collec-

tion of network architecture principles that the Web is

based on (Fielding and Taylor, 2002). We focus on

its use of URLs for addressing resources with generic

interfaces as HTTP methods (GET, POST, etc.) and

caching. In contrast, the remote procedure call (RPC)

approach encourages the use of URLs for address-

ing operations. Both approaches should be uniformly

supported by the framework.

Design Principles

To guide the design of the framework, we adhere to

the following key principles:

High Cohesion and Low Coupling. Cohesion

is a measure of how strongly related and focused the

responsibilities of a software unit is. The related con-

cept of coupling is a measure of how strongly depen-

dent one software unit is on other software units. It is

common knowledge in software engineering that high

cohesion and weak coupling are important to main-

tainability and reliability of the software (Stevens

et al., 1974). Nevertheless, many web programming

frameworks fail in these measures when considering,

SERVER CLIENT

request

response

web application

web methods

event handlers

XML producers

page event

page update

XML page

Dispatcher

Database

ORM

Figure 1: The new JWIG architecture. The boxes and cir-

cles represent the main static components, and the arrows

show the dynamic interactions between the components.

for example, handling of form data and asynchronous

client–server communication. Examples of this are

shown in Sections 4 and 5.

Secure by Design. Buffer overruns are an exam-

ple of a security concern that has largely been elimi-

nated by the use of languages that are secure by de-

sign, for example Java or C# instead of C or C++.

However, injection attacks, cross-site scripting, in-

secure direct object references, broken session man-

agement, and failure to restrict URL access remain

among the most serious classes of web application

vulnerabilities (OWASP, 2007). We believe that the

principle of ‘secure by design’ should be applied at

the level of web application frameworks to address

those classes of vulnerabilities.

Convention over Conﬁguration. All conﬁgura-

tion should have sensible defaults, in order to mini-

mize the number of detailed decisions that developers

need to make for the common cases. This principle

was popularized by Ruby on Rails.

In the following sections, we give examples of

how existing frameworks violate these principles and

explain our proposal for a solution. Due to the limited

space, many features of our resulting system are omit-

ted in this paper; for an extended version see (Møller

and Schwarz, 2009).

2 ARCHITECTURE

Web clients in general cannot be trusted, and es-

sentially all web applications contain sensitive data,

so according to the ‘secure by design’ principle and

for simplicity our starting point is a classical server-

oriented approach where the application code is ex-

ecuted on the server rather than on the client. This

WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies

public class Main extends WebApp {

public XML hello(String what) {

return [[

<html>

<head><title>Example</title></head>

<body>

<p>Hello <{ what }></p>

</body>

</html>

]];

}}

Figure 2: A “hello world” web application.

means that we avoid many of the security considera-

tions that programmers have if using a client-oriented

architecture, as e.g. GWT. A concrete example of this

advantage is shown in (Møller and Schwarz, 2009).

One of the typical arguments in favor of a client-

oriented approach is the opportunity to create rich

user interfaces—however, such effects are possible

also in server-oriented frameworks using tag libraries

containing JavaScript code. Also, pushing computa-

tion to the client-side may imply a decreased load on

the server, but, on the other hand, it often conﬂicts

with the use of ORM systems: It is difﬁcult to ensure

high performance if the application code is physically

separated from the ORM system.

Figure 1 illustrates the basic architecture. As in

many other newer server-oriented frameworks, a dis-

patcher on the server receives the client HTTP re-

quests and invokes the appropriate server code, here

called web methods. Many frameworks rely on sep-

arate conﬁguration ﬁles for mapping from request

URLs to application code. To decrease coupling, our

web methods are instead discovered using introspec-

tion of the web application code, as in e.g. CherryPy.

The web methods have formal parameters for receiv-

ing arguments from the clients and return values to be

sent as response.

As an example, the tiny web application shown

in Figure 2 accepts HTTP GET requests of the form

http://example.org/Main/hello?what=World

and returns a small XHTML page as response.

The class

Main

is a web application that contains

a single web method

hello

. We explain the XML

construction and the

[[...]]

notation in Section 3.

Following the ‘convention over conﬁguration’

principle, no application speciﬁc conﬁguration is

required to make this run—unlike the situation in, for

example, Struts or RIFE (Bevin, 2007).

The architecture is a variant of the Model-View-

Controller pattern that many other frameworks also

apply. Most importantly, the model is separated from

the main web application code. However, we propose

a less rigid division between the view and the con-

troller than used in other frameworks, as we explain

in Section 3.

In the following sections, we go into more details and

extend this basic architecture to fulﬁll the require-

ments we deﬁned, which includes introducing the no-

tions of XML producers and event handlers and the

page event and page update actions appearing in Fig-

ure 1.

3 GENERATING XML OUTPUT

A common approach to generating XHTML output

dynamically in web application frameworks is to use

a template system, either where templates contain

code for dynamic construction of content (as in e.g.

ASP.NET, PHP, or RoR) or where templates contain

placeholders where the code can insert content (as

in e.g. RIFE). Another approach is to use GUI com-

ponents that are assembled programatically (as e.g.

GWT or Wicket). Web services, on the other hand,

need the ability to also receive and decompose XML

data, which is often done completely differently in a

DOM-style fashion.

All those systems lack the ability to ensure, at

compile time, that output is always well-formed and

valid XML data. This is known to affect reliability

and may lead to, for example, cross site scripting vul-

nerabilities.

We propose a solution that (1) uniﬁes the template

approach and the DOM-style approach, (2) permits

static validation analysis, and (3) avoids many secu-

rity issues by design. This approach is a further devel-

opment of the JWIG framework presented in (Chris-

tensen et al., 2003).

We build on a new version of the XACT sys-

tem (Kirkegaard et al., 2004). XML data is repre-

sented as well-formed XML fragments that are ﬁrst-

class values, meaning that they can be stored in vari-

ables and passed between methods (unlike most other

template systems). Figure 2 shows an XML value

constant (enclosed by

[[...]]

, using a simple syn-

tax extension to Java) that contains a snippet of code

(enclosed by

<{...}>

in XML content or

{...}

in at-

tribute values), which at runtime evaluates to a value

that gets inserted. The syntax extension reduces the

burden of working with XML data inside Java pro-

grams and is desugared to ordinary Java code.

XML values may also contain named gaps where

other XML values or strings can be inserted, which

makes it easy to reuse them. As an example, the fol-

lowing code deﬁnes a wrapper for XHTML pages and

stores it in a variable

XML w = [[<html>

JWIG: YET ANOTHER FRAMEWORK FOR MAINTAINABLE AND SECURE WEB APPLICATIONS

]];

This wrapper can then be used whenever a complete

page needs to be generated, for example in this web

method:

XML time() {

return w.plug("BODY", [[

]]);

}

To obtain separation of concerns between program-

mers and web page designers, XML values can also

be stored in separate ﬁles. In fact, contracts can be

established to formalize and verify this separation, as

explained in the article by B¨ottget et al. (2006). XML

values can also be decomposed and transformed with

operations inspired by JDOM and XPath. By design,

XML values are always well-formed (i.e. tags are bal-

anced, etc.). When inserting text strings into frag-

ments, special characters are automatically escaped,

which eliminates a signiﬁcant class of security vulner-

abilities. In addition, variables can be annotated with

XML Schema type information, and a program analy-

sis can perform type checking to ensure that output is

always valid according to a given schema (Kirkegaard

and Møller, 2005).

By default, web methods react only on HTTP

GET requests. This can be changed using an anno-

tation, for example

@POST

for web methods that are

unsafe in the HTTP sense.

4 XML PRODUCERS AND PAGE

UPDATES

The response of a web method is generally a view

of some data from the underlying database. When

the data changes, the view should ideally be updated

automatically while only affecting the relevant parts

of the pages to avoid interfering with form data be-

ing entered by the user. With many frameworks, this

is a laborious task that requires many lines of code

and insight into the technical details of JavaScript and

AJAX, so many web application programmers settle

with the primitive approach of requiring the user to

manually reload the page to get updates.

We propose a simple solution that hides the

technical details of the server-push techniques (aka.

Comet) and integrates well with the XACT system.

An XML producer is an object that can produce XML

data when its

run

method is called. When the ob-

ject is constructed, dependencies on the data model

are registered according to the observer pattern. An

XML producer can be inserted into an XHTML page

such that whenever it is notiﬁed through its depen-

dencies,

run

is automatically called and the resulting

XML value is pushed to all clients viewing the page.

All the technical details involving AJAX and Comet

are hidden inside the framework, and it scales well to

hundreds of concurrent uses.

Typically, the XML producer is created as an

anonymous inner class within the web method that

generates the XHTML page. This ensures high cohe-

sion for that software component and low coupling by

only depending on the model of the data that is shown

to the client. An example is shown in Section 6.

5 FORMS AND EVENT

HANDLERS

Forms constitute the main mechanism for obtaining

user input in web applications. With most frame-

works, the code that generates the form is separate

from the code that reacts on the input being submit-

ted, and these pieces of code are connected only indi-

rectly via the URLs being generated and the conﬁgu-

ration mapping from URLs to code. This violates the

principle of high cohesion and low coupling, and the

ﬂow of control and data becomes unclear.

Our solution is to extend the architecture with

event handlers as a general mechanism for reacting

to user input. Due to the limited space, we here fo-

cus on forms although the mechanism also works for

other kinds of DOM events. The technique is related

to the use of action callbacks in Seaside.

Forms are created by building XML documents

that contains a

form

tag with relevant input ﬁelds. A

specialized event handler, called a submit handler, is

plugged into the

action

attribute. The submit han-

dler contains a method that can react when the form

is submitted and read the form input data. (An ex-

ample is shown in Section 6.) As with XML produc-

ers, event handlers are typically anonymous classes

located within the web methods.

The consequence of this structure is a high degree

of code cohesion. Also, it becomes possible by static

analysis to verify consistency between the input ﬁelds

occurring in the form and the code that receives the

input ﬁeld data.

6 EXAMPLE: MICROCHAT

The following example shows a tiny chat application

that uses the features explained in the previous sec-

WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies

tions. It shows a list of messages and a text ﬁeld

where users can write new messages.

public class MicroChat extends WebApp {

List<String> messages =

new ArrayList<String>();

public XML chat() {

return [[<html>

<head><title>MicroChat</title></head>

<body>

<{ new XMLProducer(messages) {

XML run() {

if (!messages.isEmpty())

return [[

<ul>

<{ [[<li><[MSG]></li>]]

.plugWrap("MSG", messages) }>

</ul>]];

else

return [[]];

}}}>

</form>

</body></html>

]]

.plug("SEND", new SubmitHandler() {

void run(String msg) {

messages.add(msg);

update(messages);

}});

}}

For simplicity, the application state is here repre-

sented as a ﬁeld

messages

in the application class; we

discuss persistence in Section 8. The XHTML doc-

ument being created when the user invokes the

run

web method contains an instance of an

XMLProducer

that declares itself to be an observer of

messages

and

writes the messages in the document. The

plugWrap

method here builds a list of

<li>

items containing the

messages. Secondly a submit handler is plugged into

the

action

attribute of the form. The handler method

reads the form ﬁeld

msg

, adds it to the list of mes-

sages, and then invoke

update

to notify all observers

of the list, in this case the XML producer. The effect

is that whenever a user posts a new message, the list

of messages is automatically updated in all browsers

viewing the page.

Notice the high degree of cohesion within the

chat

web method. In most other frameworks (with

Seaside and as a notable exception) the equivalent

code would be more fragmented and hence less main-

tainable.

7 PARAMETERS AND

REFERENCES TO WEB

METHODS

Web methods and event handlers can be parameter-

ized, as shown in the previous examples. Any Java

class that contains a static method

valueOf

can be

used for such parameters for deserializing values, as

known from the basic Java library. Conversely, seri-

alization for output is performed using

toString

(for

strings) or

toXML

(for XML values). The dispatcher

then transparently handles the serialization and dese-

rialization. For example, JSON data is trivial to trans-

fer with this mechanism.

The URL format used in requests to web methods

can be controlled by an annotation, to support REST-

style addressing of resources. Links between pages

can be created using the method

makeURL

XML my_link = [[

click here

</a>

]];

The web method name is passed as a constant string

(since methods are not ﬁrst-class values in Java), but

it is straightforward to statically type check that it

matches one of the web methods within the applica-

tion. Parameters are serialized as explained above,

and the resulting URL is generated according to the

URL pattern of the web method.

This approach ensures that the coupling between

web pages becomes explicit in the application source

code, in contrast to frameworks that involve URL

mappings in separate conﬁguration ﬁles. As we ex-

plain in the next section, it additionally provides

a novel foundation for managing session state and

shared state.

8 SESSION STATE AND

PERSISTENCE

A classical challenge in web application program-

ming is how to represent session state on top of the

inherently stateless HTTP protocol. Although REST

prescribes the use of stateless communication, with-

out ever storing session state on the server, we believe

that the beneﬁts of allowing session state on the server

outweigh the disadvantages—a concrete example is

shown in (Møller and Schwarz, 2009).

Our approach is to store session state in objects

derived from an abstract class named

Session

. Us-

ing a class instead of a map means that the ordinary

JWIG: YET ANOTHER FRAMEWORK FOR MAINTAINABLE AND SECURE WEB APPLICATIONS

Java type checker will check that expected properties

are present when a web method accesses the session

state. The class deﬁnes the

valueOf

and

toString

methods so the objects can be given as parameters to

web methods using the mechanism described in Sec-

tion 7. The following example extends the “Hello

World” example from Section 2 so it now saves the

what

parameter in a newly created session object and

then redirects to the

sayHi

method, which reads the

session data and embeds it in its XML output:

URL hello(String what) {

return makeURL("sayHi",

new HelloSession(what));

}

class HelloSession extends Session {

String name;

public HelloSession(String s) { name = s; }

}

public XML sayHi(HelloSession s) {

return [[

<html>

<head><title>Example</title></head>

<body><p>Hello <{ s.name }></p></body>

</html> ]];

}

Session state is here encapsulated in the

HelloSession

objects, and it is clear from the

signature of the

sayHi

web method that it requires

the client to provide a session key. This way of track-

ing clients is effectively a variant of URL rewriting

that is integrated with the dispatching mechanism of

the framework.

For persistent data in the web applications,

we utilize the same pattern as for session state:

Persistable data must implement the

Persistable

interface, which requires it to deﬁne an ID string for

each object. This ID can be used to query the object

from the database during deserialization. It can be

passed around in the URLs in a call-by-reference

style via the

makeURL

mechanism or hidden inside

session objects.

Among the currently most serious web application

vulnerabilities is insecure direct object references,

i.e. situations where malicious users can modify data

references passed in URLs with insufﬁcient authenti-

cation on the server (OWASP, 2007). Employing the

‘safe by default’ principle, our framework requires

that permission must explicitly be given to use an ID

of a persistable object. This is done coherently by

deﬁning a method named

access

that returns true

when the use of the given ID is allowed in the context

of the HTTP request concerned.

9 CONCLUSIONS

We have presented a novel minimalistic Java-based

frameworkthat providesuniform support for common

tasks in web programming. By the use of a reﬂection-

based dispatcher, XACT for XML processing, XML

producers for server-push communication, event han-

dlers for user input processing, and ﬁlters for caching

and authentication, we obtain a frameworkfor making

maintainable and secure web applications with high

cohesion, low coupling, and security-by-design. Ex-

ample programs and a larger case study are presented

in the technical report (Møller and Schwarz, 2009).

As ongoing and future work, we aim to provide

a more detailed analysis of the capabilities and limi-

tations of other frameworks and their relation to the

one we have presented here. Also, we remain to show

how the framework can handle user input validation

through a combination of XML producers and event

handlers and rich user interfaces by integrating exist-

ing JavaScript libraries using tag-like XHTML exten-

sions.

REFERENCES

Bevin, G. (2007). RIFE.

http://rifers.org/

Christensen, A. S., Møller, A., and Schwartzbach, M. I.

(2003). Extending Java for high-level Web service

construction. ACM Transactions on Programming

Languages and Systems, 25(6):814–875.

Crockford, D. (2006). JavaScript Object Notation

(JSON). RFC4627.

http://tools.ietf.org/

html/rfc4627

Fielding, R. T. and Taylor, R. N. (2002). Principled design

of the modern web architecture. ACM Transactions on

Internet Technology, 2(2):115–150.

Google (2008). Google Web Toolkit.

http://code.

google.com/webtoolkit/

Hansson, D. H. et al. (2008). Ruby on Rails.

http://www.

rubyonrails.org/

Johnson, R. et al. (2008). Spring MVC.

http://www.

springframework.org/

Kirkegaard, C. and Møller, A. (2005). Type checking with

XML Schema in XACT. Technical Report RS-05-31,

BRICS. Presented at Programming Language Tech-

nologies for XML, PLAN-X ’06.

Kirkegaard, C., Møller, A., and Schwartzbach, M. I. (2004).

Static analysis of XML transformations in Java. IEEE

Transactions on Software Engineering, 30(3):181–

192.

Lerdorf, R. et al. (2008). PHP.

http://www.php.net/

McClanahan, C. R. et al. (2008). Struts.

http://struts.

apache.org/

Microsoft (2008). ASP.NET.

http://www.asp.net/

WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies

Møller, A. and Schwarz, M. (2009). Designing yet another

framework for maintainable and secure web applica-

tions. Technical Report RS-09-02, BRICS.

O’Neil, E. J. (2008). Object/relational mapping 2008: hi-

bernate and the entity data model (edm). In Proc.

ACM SIGMOD International Conference on Manage-

ment of Data, SIGMOD ’08.

OWASP (2007). The ten most critical web application

security vulnerabilities.

http://www.owasp.org/

index.php/Top 10 2007

Stevens, W. P., Myers, G. J., and Constantine, L. L. (1974).

Structured design. IBM Systems Journal, 13(2):115–

139.

W3C (2008). Web services activity.

http://www.w3.org/

2002/ws/

JWIG: YET ANOTHER FRAMEWORK FOR MAINTAINABLE AND SECURE WEB APPLICATIONS